Onze projecten zijn veelal regionaal en de opdrachtgevers zijn veelal ministeries. Maar naast de publieke sector maken ook private organisaties gebruik van onze systemen. Er zijn vrijwel geen problemen met hen.
De belangrijkste projecten zijn dus regionaal en er zijn soms problemen mee. Met prestaties bijvoorbeeld, wanneer er in regio's meer dan 20 van onze waardevolle gebruikers zijn tijdens de periode waarin nieuwe functionaliteit op productservers wordt uitgerold. Het is pijn…
Mijn naam is Ruslan en ik ondersteun de informatiesystemen van BARS Group en het ontwikkelen van een killer-bot voor gewelddadige seriële DBA's. Dit bericht is niet voor bangeriken - er zijn veel brieven en afbeeldingen.
/awr
Sommige van onze applicaties draaien op Oracle DBMS. Er zijn ook projecten op het PostgreSQL DBMS. Oracle heeft iets geweldigs: het verzamelen van statistieken over de belasting van het DBMS, die bestaande problemen benadrukken en zelfs aanbevelingen doen voor eliminatie: Automatic Workload Repository (AWR). Op een gegeven moment (namelijk op het moment van pijn) vroegen de ontwikkelaars voortdurend om te verzamelen AWR-rapporten voor prestatieanalyse. We gingen eerlijk naar de DBMS-server, verzamelden rapporten, brachten ze naar ons en stuurden ze naar productie voor analyse. Na de 5e keer werd het vervelend... na de 10e werd het irritant...
Een van mijn collega’s heeft ooit het idee geuit dat alles wat meer dan één keer wordt gedaan, geautomatiseerd moet worden. Tot het moment van irritatie heb ik er eerlijk gezegd niet over nagedacht en geprobeerd alles te automatiseren wat geautomatiseerd kon worden, maar vaak was er geen vraag naar en was het meer een onderzoek dan een toegepast karakter.
En toen dacht ik: “Beheerders zijn niet nodig om een rapport te genereren...”. Het verzamelen van een rapport betekent immers dat u het sql-script @$ORACLE_HOME/rdbms/admin/awrrpt.sql uitvoert en het rapport van de server naar uw locatie brengt... Oh ja, we staan geen ontwikkeling voor productie toe.
Vervolgens heb ik de benodigde informatie gegoogled, de functie uit het artikel op de testbasis gemaakt, het script uitgevoerd en wonderbaarlijk - het rapport is samengesteld en kan lokaal worden opgeslagen. Creëerde functies waar AWR-rapporten vaak nodig waren en vertelde ontwikkelaars hoe ze deze moesten gebruiken.
Rond deze tijd, in mijn vrije tijd, na een gesprek met @BotFather, heb ik voor mezelf een Telegram-bot gemaakt, gewoon voor de lol. Ik heb daar een eenvoudige functionaliteit ingebouwd: toon de huidige tijd, wisselkoersen, het weer, en leerde het om volgens een schema complimenten naar mijn vrouw (toenmalige vriendin) te sturen. Misschien was het versturen van complimenten destijds de meest populaire functionaliteit van mijn bot, en mijn vrouw waardeerde het.
Dus. Ontwikkelaars schrijven ons in Telegram, wij sturen hen een rapport in Telegram... Wat als ze niet naar ons schrijven, maar naar een bot? Het zal tenslotte voor iedereen beter zijn, het rapport zal sneller worden ontvangen en, belangrijker nog, ons omzeilen. Zo ontstond het idee van de eerste populaire functionaliteit voor mijn bot.
Ik ben begonnen met de implementatie. Ik deed het, zo goed als ik kon, in PHP (onze applicatie zelf is in PHP, ik ben er meer thuis in dan in Python). Ik ben geen goede codeur, dus ik zal je mijn code niet laten zien :)
De bot leeft op ons bedrijfsnetwerk en heeft toegang tot bepaalde projecten, inclusief doeldatabases. Om geen last te hebben van parameters in het team of menu, heb ik deze functionaliteit toegevoegd aan de groepschat met monitoringmeldingen. Zo weet de bot direct uit welke database het rapport moet worden opgehaald.
Na een bevel te hebben ontvangen zoals /awr N, waarbij N het aantal volledige uren is waarvoor een rapport nodig is (standaard - 1 uur), zelfs voor een week, als de database niet opnieuw is opgestart, begint de bot onmiddellijk te werken, verzamelt het rapport en publiceert het als een webpagina en geeft onmiddellijk (bijna precies daar) een link naar het broodnodige rapport.
Volg de link en hier is het, het AWR-rapport:
Zoals verwacht hebben de ontwikkelaars het genereren van dergelijke rapporten afgehandeld, en sommigen hebben ons zelfs bedankt.
Omdat ze het gemak van het team op prijs hadden gesteld, wilden projectmanagers uit andere regio's hetzelfde, omdat ze het meeste van de klant ontvangen en zich zorgen maken over de prestaties en beschikbaarheid van systemen. Ik heb de bot aan andere chats toegevoegd. Ze gebruiken het nog steeds en ik ben er blij mee.
Later hoorden collega’s van het CIT hoe wij meldingen verzamelen en wilden dat ook doen. Ik heb ze niet aan onze chats toegevoegd, ik heb een aparte chat gemaakt met het genereren van rapporten volgens een schema en op verzoek.
/pgBadger
We hebben ook andere applicaties in PHP in combinatie met PostgreSQL. Ik implementeerde het verzamelen van pgBadger-rapporten voor mensen in nood volgens hetzelfde principe: in groepschats. In eerste instantie gebruikten ze het, maar toen stopten ze. De functionaliteit werd weggelaten als onnodig.
/plicht
Onze afdeling heeft nachtdiensten en heeft daarom een rooster. Het staat in Google Spreadsheets. Het is niet altijd handig om een link te zoeken, een grafiek te openen, zelf te zoeken... Een van mijn voormalige collega's speelde ook met zijn Telegram-bot en introduceerde deze in de chat van onze afdeling meldingen over de start van de dienstdienst voor afdelingsmedewerkers. De bot parseert de planning, bepaalt de dienstdoende persoon op de huidige datum en rapporteert, volgens de planning of op verzoek, wie vandaag dienst heeft. Het bleek geweldig en handig. Het is waar dat ik het formaat van de berichten niet echt leuk vond. Ook voor medewerkers van een andere afdeling (bijvoorbeeld BC 'Geneeskunde') is informatie over degenen die dienst hebben in andere richtingen niet echt nodig, maar u moet wel weten wie dienst heeft bij 'Geneeskunde' in geval van problemen. Ik besloot de functionaliteit te ‘lenen’, maar te veranderen wat ik niet leuk vond. Ik heb een berichtformaat gemaakt dat handig is voor mezelf en anderen, waarbij onnodige informatie wordt verwijderd.
/tnls
Nadat ik de automatisering had uitgeprobeerd met een Telegram-bot, kwamen er veel verschillende ideeën naar voren, maar ik wilde strikt noodzakelijke dingen doen. Ik besloot de leiding te nemen statistieken over verzoeken. Om toegang te krijgen tot de projecten van onze klanten hebben we een zogenaamde “jumpserver” of forwardingserver geïmplementeerd. Daarop worden VPN-verbindingen tot stand gebracht, vervolgens worden applicatiepoorten, databases en andere hulpdoorsturingen via ssh doorgestuurd naar ons lokale netwerk, voor gemakkelijke toegang tot de projecten van onze medewerkers, zonder problemen met VPN-verbindingen. Het enige dat u hoeft te doen, is een VPN-verbinding met ons bedrijfsnetwerk opzetten.
Uit de statistieken van de aanvragen blijkt dat mensen vaak, nadat een van de tunnels uitvalt (bij netwerkproblemen, bijvoorbeeld door een time-out), contact met ons opnemen over het herstellen van de toegang tot het project. In de meeste gevallen is het opnieuw opstarten van de verbinding voldoende en is alles in orde. Laten we het zelf doen. Hier is het commando:
Je “valt door” in het gewenste menu-item, selecteert je project, wacht even en iedereen is blij en tevreden...
Bij ontvangst van een commando maakt de bot, met een kleine beweging van de bytes en bits, verbinding met de doorstuurserver, waarbij hij van tevoren weet welke doorsturing opnieuw moet worden gestart, en doet zijn werk: herstelt de verbinding met het project. Ik heb instructies geschreven zodat je dergelijke problemen zelf kunt oplossen. En mensen namen alleen contact met ons op als de meegeleverde tool niet werkte...
/ecp_naar_pem
Uit verdere statistieken bleek dat het vaak nodig is om te converteren EDS Crypto Pro in pem-formaat() voor verschillende integraties, en we hebben er behoorlijk veel. Taak: neem een container, kopieer deze naar een Windows-computer waarop het hulpprogramma P12FromGostCSP is geïnstalleerd (betaald overigens), converteer deze naar pfx en converteer vervolgens pfx met behulp van OpenSSL (met ondersteuning voor GOST-codering) naar pem. Het is niet erg handig, maar je wilt het in een handomdraai hebben.
Google is opnieuw te hulp gekomen. Gevonden . Ik heb het samengesteld zoals geschreven in de README - het werkte. Ik leerde de bot met het hulpprogramma te werken en kreeg vrijwel onmiddellijk een conversie.
Tegen de tijd van de definitieve implementatie werd een bevel uitgevaardigd om over te schakelen naar een nieuw coderingsformaat - gost-2012. Voor zover ik me herinner, werkte het hulpprogramma op dat moment alleen met de oude GOST (2001), misschien was het een ander soortgelijk hulpprogramma van een ander aardig persoon, ik weet het niet precies meer.
Na de overgang naar de nieuwe GOST werd de functionaliteit van de bot om veiligheidsredenen verwijderd. Implementeerde het in een docker-container.
Dockerfile, voor het geval iemand het nodig heeft:
FROM ubuntu:16.04
RUN apt update && apt -y install git sudo wget unzip gcc g++ make &&
cd /srv/ && git clone https://github.com/kov-serg/get-cpcert.git &&
cd get-cpcert && chmod +x *.sh && ./prepare.sh && ./build.sh &&
mkdir -p /srv/{in,out} &&
echo '#!/bin/bash' > /srv/getpem.sh &&
echo 'cd /srv/get-cpcert' >> /srv/getpem.sh &&
echo './get-cpcert /srv/in/$CONT.000 $PASS > /srv/out/$CONT.pem' >> /srv/getpem.sh &&
chmod +x /srv/getpem.sh ENTRYPOINT /srv/getpem.shOm te converteren moet je de originele container (map zoals xxx.000) in de map /srv/in plaatsen en de voltooide pem naar /srv/out brengen.
Bekeren:
docker run -t -i -e CONT='<имя директории с контейнером(без ".000")>' -e PASS='<пароль для контейнера>' -v /srv/in:/srv/in -v /srv/out:/srv/out --name ecptopem <адрес нашего репозитория>/med/ecptopem:latest /emstop en /emstart
Op een dag kreeg een hele coole Oracle DBA, met veel ervaring in DBMS-beheer en -ontwikkeling, een baan bij ons bedrijf. En hij had meteen problemen met het verbinden met de DBMS-servers via ssh: hij weet niet waar en hoe hij verbinding moet maken, de toegang is niet duidelijk beschreven, of hij kan iets dat hij nodig heeft niet naar zichzelf doorsturen. Welnu, we helpen u graag verder. We hebben hem verteld hoe hij verbinding moet maken en hebben hem Enterprise Manager doorgestuurd. Maar met ssh lukte het nog steeds niet. Een van mijn collega's legde het eenvoudig uit: een rasechte DBA :) We besloten dat als we iets op de server moesten aanpassen, we het zelf zouden doen.
EM crasht soms onder zware belasting, en om het opnieuw op te starten... moet je verbinding maken via ssh en opnieuw opstarten via de terminal. “Beheerders zijn hier goed in”, besloot onze nieuwe collega. Zware belasting van het DBMS is voor ons niet ongebruikelijk, en verzoeken om EM opnieuw te starten zijn ook gebruikelijk. Dan hetzelfde scenario: spanning, irritatie en zoeken naar een oplossing voor het probleem. Dus in dezelfde groepschats verschenen de volgende opdrachten: /emstop en /emstart.
/ doden
Als er sterke concurrentie is op de database, en dit gebeurt soms, is het noodzakelijk om de database snel te ontladen. De snelste manier is om het problematische proces te beëindigen... Om dit te doen, maak verbinding via ssh, kill -9... De bot zal helpen!
Alexey waardeerde het team en gaf het een liefdevolle naam - "Kilyalka" of een pistool.
Op een dag, nadat ik had gezien hoe Alexey probeerde en leed, waarbij ik elke keer xxx invoerde / doodde voor elk van de processen, besloot ik om “multi-barrel” aan ons wapen toe te voegen:
Dat is beter! Alles is voor jou, Alexey, werk gewoon, lieverd!
Natuurlijk was zo'n belangrijk team beperkt toegang via user_id - “foolproof”. Toen ze zagen hoe Lesha behendig processen op de databaseserver doodde, probeerden verschillende mensen een opdracht in te voeren met een willekeurig procesnummer, maar je kunt mijn slimme bot niet voor de gek houden, hij weigerde onmiddellijk.
/alertlog
Voor de zekerheid heb ik het commando gegeven:
/alertlog — het opgegeven aantal waarschuwingslogregels ophalen
De bot haalt een alertlog op en stuurt deze naar onze service, zoals pastebin, genaamd pyste, en stuurt een link naar de plak naar de verzoekchat.
/controles
Vervolgens kwam er een verzoek om het monitoren van de echte prestaties van onze applicatie. Tot nu toe verzamelde de technische ondersteuning van het project deze gegevens handmatig. Maakt niet uit! Onze dappere testers hebben hiervoor testcases ontwikkeld. Het resulterende testlogboek is niet erg handig om te lezen; een onervaren gebruiker zal er lang over doen om het te begrijpen en is er niet zeker van dat hij de nodige informatie zal benadrukken. En we houden er niet van om met onze handen te doen wat we niet met onze handen kunnen doen... Een nieuwe taak voor de bot!
Het commando /checks geeft een eenvoudig en ondubbelzinnig menu weer; deze keer hebben onze jongens geleerd hoe ze dit commando zonder instructies moeten gebruiken!
Wanneer u het gewenste item selecteert, verschijnt er in plaats van een menu een melding over de start van de test, zodat ongeduldige gebruikers onze test niet 100500 keer uitvoeren:
Afhankelijk van het geselecteerde menu-item wordt een specifieke test gelanceerd vanuit ons netwerk, namelijk vanaf de machine waar de bot woont (daar is jmeter vooraf geconfigureerd, de nodige tests bevinden zich...) of rechtstreeks vanuit het datacenter (vanaf een voorbereide machine naast de applicatie), om netwerkverbindingen uit te sluiten bij het testen van vertragingen, of deze tot een minimum te beperken.
Na het voltooien van de test en het ontvangen van het logboek, parseert de bot het en produceert het resultaat in een “voor mensen leesbare” vorm:
Verzameling van statistieken
De functionaliteit is gearriveerd en geïnteresseerde projectmanagers hebben een dergelijke functie voor hun regio gekregen. En een meelevende projectmanager zei: “Ik wil tijdstatistieken hebben!” Iemand van CIT vertelde haar dat het handig zou zijn om dit allemaal in Zabbix te monitoren. Zabbix, dus Zabbix...
Ik dacht dat ik me moest voorbereiden op de noodzaak om de oplossing te repliceren... Ik stopte het idee in een docker-container. In de container wordt jmeter volgens een schema gelanceerd (eens per 10 minuten), plaatst het log op een bepaalde plaats, php parseert het en geeft de benodigde gegevens weer in de vorm van een webpagina. Zabbix ontvangt deze pagina met behulp van de web.page.get-sleutel, selecteert regelmatig de benodigde gegevens voor bepaalde afhankelijke elementen en bouwt een grafiek.
Ik denk dat het niet slecht is geworden. Door de grafiek te observeren, zien we eerst de geschatte snelheid van de applicatie, en als er pieken in de grafiek worden gedetecteerd, weten we ongeveer waar de "plug" zich bevindt. Het is makkelijk. Tot nu toe is gebleken dat er slechts voor één regio vraag naar is, maar ik ben bereid het te repliceren voor geïnteresseerden.
Applicatie ontwikkeling
Statistieken over soortgelijke taken hebben de laatste tijd aanleiding gegeven tot meer ideeën om het werk te vereenvoudigen en te vergemakkelijken. Bij sommige projecten, op applicatieservers, is het nodig om belangrijke Crypto Pro-containers te installeren, er zijn er veel en de digitale handtekening vervalt na verloop van tijd. Soms komen er 2 taken per dag binnen. Maar ik vond het onveilig om voor deze doeleinden een bot te gebruiken en besloot de functionaliteit rechtstreeks in de applicatie te creëren. Uiteraard met autorisatie en controle van toegangsrechten. Als u over de nodige rechten beschikt, is er een extra menu-item beschikbaar voor het werken met digitale handtekeningen, installatie, verwijderen, informatie bekijken, enz. De functionaliteit is momenteel in ontwikkeling. Het bleek dat dit niet erg moeilijk is, je hoeft alleen maar de bestaande instructies een beetje te lezen, naar codevoorbeelden te kijken, collega's met meer ervaring in ontwikkeling te vragen en het dan te doen. Tijdens het onderzoeksproces ontstonden er ideeën om de toepassing verder uit te breiden. Ik zal geen Napoleontische plannen maken - er is ontwikkeling, laat iedereen zich met zijn eigen zaken bemoeien. Maar hoewel het interessant is, doe ik het zelf.
Plannen
Zoals ik al zei, er zijn veel verschillende ideeën geboren voor het gebruik van onze bot en niet alleen - in het algemeen, laten we zeggen, ideeën voor "automatiseringspunten", veel ervan zijn vergeten, omdat ik geen tijd had om ze op te schrijven. Nu probeer ik alles op te schrijven wat in me opkomt, en ik raad anderen aan hetzelfde te doen.
Maar Alexey vergeet niet zijn wensen kenbaar te maken. Van de laatste:
/kill_sql SQL_ID — beëindig alle sessies met dit SQL_ID-verzoek
/kill_block - beëindig de rootblokkeringssessie
/Laat het hun zien — laat een foto zien van de prestaties van EM
Hij is een sluwe kerel, hij wil DBA vanaf zijn telefoon naaien =)
Zo werken wij ten behoeve van het Moederland!
Hoe kom je af van routinematige en oninteressante taken?
Ik hoop dat de lezing interessant en misschien zelfs nuttig voor iemand is gebleken, en dat ik geen tijd heb gehad om de lezer te vervelen... Veel succes voor ons allemaal.
Bron: www.habr.com