Våre prosjekter er vanligvis regionale, og oppdragsgiverne er vanligvis departementer. Men i tillegg til offentlig sektor bruker også private organisasjoner systemene våre. Det er praktisk talt ingen problemer med dem.
Så hovedprosjektene er regionale, og noen ganger er det problemer med dem. For eksempel med ytelse, når det i regioner er mer enn 20 XNUMX av våre dyrebare brukere i løpet av perioden med utrulling av ny funksjonalitet på produktservere. Det er en smerte…
Mitt navn er Ruslan og jeg støtter informasjonssystemene til BARS Group og utvikle en killer-bot for voldelige serielle DBA-er. Dette innlegget er ikke for sarte sjeler – det er mange bokstaver og bilder.
/awr
Noen av applikasjonene våre kjører på Oracle DBMS. Det er også prosjekter på PostgreSQL DBMS. Oracle har en fantastisk ting - å samle statistikk om belastningen på DBMS, som fremhever eksisterende problemer og til og med gir anbefalinger for eliminering - Automatic Workload Repository (AWR). På et tidspunkt (nemlig i smerteøyeblikket) ba utviklerne hele tiden om å samle AWR rapporterer for ytelsesanalyse. Vi gikk ærlig til DBMS-serveren, samlet rapporter, tok dem til oss og sendte dem til produksjon for analyse. Etter 5. gang ble det irriterende... etter 10. ble det irriterende...
En av mine kolleger uttrykte en gang ideen om at alt som gjøres mer enn én gang, skal automatiseres. Inntil irritasjonsøyeblikket, for å være ærlig, tenkte jeg ikke på det og prøvde å automatisere alt som kunne automatiseres, men ofte var det ikke etterspurt og var mer en forskning snarere enn en anvendt natur.
Og så tenkte jeg: "Administratorer er ikke nødvendig for å generere en rapport...". Tross alt betyr å samle en rapport å kjøre sql-skriptet @$ORACLE_HOME/rdbms/admin/awrrpt.sql og ta rapporten fra serveren til ditt sted... Å ja, vi tillater ikke utvikling for produksjon.
Deretter Googlet jeg den nødvendige informasjonen, opprettet funksjonen fra artikkelen om testbasen, kjørte scriptet og miraklet - rapporten ble kompilert og kan lagres lokalt. Laget funksjoner der AWR-rapporter ofte var nødvendig og fortalte utviklere hvordan de skulle bruke dem.
Rundt denne tiden, på fritiden min, etter å ha snakket med @BotFather, opprettet jeg en Telegram-bot for meg selv, bare for moro skyld. Jeg skrudde inn en enkel funksjonalitet der - vis gjeldende tid, valutakurser, vær, lærte det å sende komplimenter til min kone (daværende kjæreste) etter en tidsplan. Kanskje på den tiden var det å sende komplimenter den mest populære funksjonaliteten til boten min, og min kone satte pris på det.
Så. Utviklere skriver til oss i Telegram, vi sender en rapport til dem i Telegram... Hva om de ikke skriver til oss, men til en bot? Tross alt vil det være bedre for alle, rapporten vil bli mottatt raskere, og viktigst av alt, omgå oss. Dette er hvordan ideen om den første populære funksjonaliteten for boten min ble født.
Jeg startet implementeringen. Jeg gjorde det, så godt jeg kunne, i PHP (vår applikasjon i seg selv er i PHP, jeg er mer bevandret i det enn i Python). Jeg er ikke en god koder, så jeg vil ikke vise deg koden min :)
Boten bor på vårt bedriftsnettverk og har tilgang til visse prosjekter, inkludert måldatabaser. For ikke å bry meg med parametere i teamet eller menyen, la jeg denne funksjonaliteten til gruppechatten med overvåkingsvarsler. På denne måten vet boten umiddelbart hvilken database rapporten skal samles inn fra.
Etter å ha mottatt en kommando som /awr N, hvor N er antall hele timer som en rapport er nødvendig for (som standard - 1 time), selv for en uke, hvis databasen ikke er startet på nytt, begynner roboten umiddelbart å jobbe, samler inn rapporten, publiserer den som en nettside og gir umiddelbart (nesten akkurat der) en lenke til den sårt tiltrengte rapporten.
Følg lenken og her er den, AWR-rapporten:
Som forventet taklet utviklerne slik rapportgenerering, og noen takket oss til og med.
Etter å ha satt pris på bekvemmeligheten til teamet, ønsket prosjektledere fra andre regioner det samme, siden de får mest mulig fra kunden og er bekymret for ytelsen og tilgjengeligheten til systemene. Jeg la til boten i andre chatter. De bruker det fortsatt, og jeg er glad for det.
Senere fant kolleger fra CIT ut hvordan vi samler inn rapporter og ønsket å gjøre det også. Jeg la dem ikke til i chattene våre, jeg opprettet en egen chat med generering av rapporter på en tidsplan og på forespørsel.
/pgBadger
Vi har også andre applikasjoner i PHP i forbindelse med PostgreSQL. Jeg implementerte innsamlingen av pgBadger-rapporter for de som trenger det ved å bruke samme prinsipp - i gruppechatter. Først brukte de det, men så stoppet de. Funksjonaliteten ble kuttet ut som unødvendig.
/plikt
Vår avdeling har nattevakter og har følgelig en timeplan. Det er i Google Sheets. Det er ikke alltid praktisk å se etter en lenke, åpne et diagram, se selv... En av mine tidligere kolleger lekte også med Telegram-boten sin og introduserte den i chatten til avdelingen vår meldinger om oppstart av vaktvakt for avdelingsansatte. Boten analyserer tidsplanen, bestemmer personen på vakt innen gjeldende dato og rapporterer i henhold til tidsplanen eller på forespørsel hvem som er på vakt i dag. Det viste seg flott og praktisk. Riktignok likte jeg ikke formatet på meldingene. Også for ansatte ved en annen avdeling (for eksempel BC "Medisin") er det egentlig ikke nødvendig med informasjon om de på vakt i andre retninger, men du må vite hvem som er på vakt i "Medisin" i tilfelle problemer. Jeg bestemte meg for å "låne" funksjonaliteten, men endre det jeg ikke likte. Jeg laget et meldingsformat som var praktisk for meg selv og andre, og fjernet unødvendig informasjon.
/tnls
Etter å ha prøvd ut automatisering ved hjelp av en Telegram-bot, dukket det opp mange forskjellige ideer, men jeg ønsket å gjøre strengt nødvendige ting. Jeg bestemte meg for å lede statistikk over forespørsler. For å få tilgang til våre kunders prosjekter har vi implementert en såkalt "jump server" eller videresendingsserver. VPN-tilkoblinger heves på den, deretter videresendes applikasjonsporter, databaser og andre hjelpevideresendinger til vårt lokale nettverk via ssh, for enkel tilgang til prosjektene til våre ansatte, uten problemer med VPN-tilkoblinger. Alt du trenger å gjøre er å sette opp en VPN-tilkobling til vårt bedriftsnettverk.
Statistikken over forespørsler har vist at ofte, etter at en av tunnelene svikter (i tilfelle nettverksproblemer, for eksempel på grunn av tidsavbrudd), kontakter folk oss for å gjenopprette tilgangen til prosjektet. I de fleste tilfeller er det nok å starte tilkoblingen på nytt, og alt er i orden. La oss gjøre det selv. Her er kommandoen:
Du "faller gjennom" til ønsket menyelement, velger ditt prosjekt, vent litt og alle er glade og fornøyde...
Ved å motta en kommando, med en liten bevegelse av byte og biter, kobler boten seg til videresendingsserveren, og vet på forhånd hvilken videresending som må startes på nytt, og gjør jobben sin - gjenoppretter forbindelsen til prosjektet. Jeg skrev instruksjoner slik at du kan løse slike problemer selv. Og folk kontaktet oss bare hvis det medfølgende verktøyet ikke fungerte...
/ecp_to_pem
Ytterligere statistikk viste at det ofte er nødvendig å konvertere EDS Crypto Pro i pem-format() for ulike integrasjoner, og vi har ganske mange av dem. Oppgave: ta en beholder, kopier den til en Windows-datamaskin med P12FromGostCSP-verktøyet installert (betalt, forresten), konverter den til pfx, og konverter deretter pfx ved hjelp av OpenSSL (med støtte for GOST-kryptering) til pem. Det er ikke veldig praktisk, men du vil ha det med et enkelt fingerknips.
Google har kommet til unnsetning igjen. Funnet . Jeg satte det sammen som skrevet i README - det fungerte. Jeg lærte boten å jobbe med verktøyet og fikk en nesten umiddelbar konvertering.
På tidspunktet for endelig implementering ble det gitt en ordre om å bytte til et nytt krypteringsformat - gost-2012. Så vidt jeg husker, fungerte verktøyet på det tidspunktet bare med den gamle GOST (2001), kanskje det var et annet lignende verktøy fra en annen snill person, jeg husker ikke nøyaktig.
Etter overgangen til den nye GOST ble funksjonaliteten til boten fjernet av sikkerhetsgrunner. Implementerte det i en docker-container.
Dockerfile, i tilfelle noen trenger det:
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.shFor å konvertere må du plassere den originale beholderen (katalog som xxx.000) i /srv/in-katalogen, og ta den ferdige pem-en til /srv/out.
Å konvertere:
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 og /emstart
En dag fikk en veldig kul Oracle DBA, med mye erfaring innen DBMS-administrasjon og utvikling, jobb i selskapet vårt. Og han hadde umiddelbart problemer med å koble til DBMS-serverne med ssh: han vet ikke hvor eller hvordan han skal koble til, tilgangen er ikke tydelig beskrevet, eller han kan ikke videresende noe han trenger til seg selv. Vel, vi hjelper gjerne, vi fortalte ham hvordan han skulle koble til, og videresendte ham Enterprise Manager. Men ting fungerte fortsatt ikke med ssh. En av kollegene mine forklarte det enkelt: en renraset DBA :) Vi bestemte oss for at hvis vi trenger å justere noe på serveren, så gjør vi det selv.
EM krasjer noen ganger under tung belastning, og for å starte den på nytt... må du koble til via ssh og starte på nytt gjennom terminalen. "Administratorer er gode på dette," bestemte vår nye kollega. Tung belastning på DBMS er ikke uvanlig for oss, og forespørsler om å starte EM på nytt er også vanlige. Deretter samme scenario: spenning, irritasjon og leting etter en løsning på problemet. Så i de samme gruppechattene dukket følgende kommandoer opp: /emstop og /emstart.
/drepe
Hvis det er sterk konkurranse på databasen, og dette noen ganger skjer, er det nødvendig å raskt losse databasen. Den raskeste måten er å drepe den problematiske prosessen... For å gjøre dette, koble til via ssh, drep -9... Boten vil hjelpe!
Alexey satte pris på teamet og ga det et kjærlig navn - "Kilyalka" eller en pistol.
En dag, etter å ha sett hvordan Alexey prøvde og led, gikk inn /kill xxx hver gang for hver av prosessene, bestemte jeg meg for å legge til "multi-barrel" til våpenet vårt:
Det er bedre! Alt er for deg, Alexey, bare jobb, kjære!
Naturligvis var et så viktig lag begrenset tilgang av user_id - "idiotsikker". Etter å ha sett hvordan Lesha behendig dreper prosesser på databaseserveren, prøvde flere å skrive inn en kommando med et tilfeldig prosessnummer, men du kan ikke lure den smarte boten min, han nektet umiddelbart.
/alertlog
Vel, i tilfelle laget jeg kommandoen:
/alertlog <antall linjer> — få det angitte antallet varslingslogglinjer
Boten trekker en varslingslogg og sender den til tjenesten vår, som pastebin, kalt pyste, og sender en lenke til limen til forespørselchatten.
/sjekker
Deretter kom en forespørsel om overvåking av den virkelige ytelsen til applikasjonen vår. Til nå har prosjektteknisk støtte samlet inn disse dataene manuelt. Spiller ingen rolle! Våre tapre testere har utviklet testcases for dette. Den resulterende testloggen er ikke veldig praktisk å lese; en uerfaren bruker vil ta lang tid å forstå og er ikke sikker på at han vil fremheve den nødvendige informasjonen. Og vi liker ikke å gjøre med hendene våre det vi ikke kan gjøre med hendene... En ny oppgave for boten!
/checks-kommandoen viser en enkel og entydig meny; denne gangen lærte gutta våre å bruke denne kommandoen uten instruksjoner!
Når du velger ønsket element, i stedet for en meny, vises et varsel om starten av testen, slik at utålmodige brukere ikke kjører testen vår 100500 XNUMX ganger:
Avhengig av valgt menyelement, startes en spesifikk test fra nettverket vårt, nemlig fra maskinen der boten bor (jmeter er forhåndskonfigurert der, de nødvendige testene er lokalisert...) eller direkte fra datasenteret (fra en forberedt maskin ved siden av applikasjonen), for å utelukke nettverkstilkoblinger ved testing av forsinkelser, eller redusere dem til et minimum.
Etter å ha fullført testen og mottatt loggen, analyserer boten den og produserer resultatet i en "lesbar" form:
Samling av beregninger
Funksjonaliteten har kommet og interesserte prosjektledere har fått en slik funksjon for sine regioner. Og en medfølende prosjektleder sa: "Jeg vil ha tidsstatistikk!" Noen fra CIT fortalte henne at det ville være praktisk å overvåke alt dette i Zabbix. Zabbix, så Zabbix...
Jeg tenkte at jeg måtte forberede meg på behovet for å replikere løsningen... Jeg la ideen inn i en docker-container. I containeren lanseres jmeter etter en tidsplan (en gang hvert 10. minutt), legger loggen på et bestemt sted, php analyserer den og viser de nødvendige dataene i form av en nettside. Zabbix, ved å bruke web.page.get-nøkkelen, mottar denne siden, velger regelmessig de nødvendige dataene for visse avhengige elementer og bygger en graf.
Jeg synes det ble ikke dårlig. Ved å observere grafen, ser vi for det første den omtrentlige hastigheten til applikasjonen, og hvis det oppdages topper på grafen, vet vi omtrent hvor "pluggen" er. Det er enkelt. Så langt har det vist seg å være etterspurt kun for én region, men jeg er klar til å gjenskape det for de som er interessert.
Applikasjonsutvikling
Statistikk over lignende oppgaver har den siste tiden gitt opphav til flere ideer for å forenkle og lette arbeidet. På noen prosjekter, på applikasjonsservere, er det behov for å installere nøkkelbeholdere for Crypto Pro, det er mange av dem, og den digitale signaturen utløper over tid. Noen ganger kommer 2 oppgaver om dagen. Men jeg anså det som utrygt å bruke en bot til disse formålene og bestemte meg for at jeg ville lage funksjonaliteten direkte i applikasjonen. Naturligvis med autorisasjon og kontroll av tilgangsrettigheter. Hvis du har de nødvendige rettighetene, vil et ekstra menypunkt være tilgjengelig for arbeid med digital signatur, installasjon, sletting, visning av informasjon osv. Funksjonaliteten er for tiden under utvikling. Som det viste seg, er dette ikke veldig vanskelig, du trenger bare å lese de eksisterende instruksjonene litt, se på kodeeksempler, spørre kolleger som er mer erfarne i utvikling, og deretter gjøre det. I løpet av forskningsprosessen dukket det opp ideer å legge til søknaden. Jeg vil ikke lage Napoleonske planer - det er utvikling, la alle bry seg om sine egne saker. Men selv om det er interessant, gjør jeg det selv.
Planer
Som jeg sa, mange forskjellige ideer ble født for å bruke boten vår, og ikke bare - generelt, la oss si, ideer for "automatiseringspunkter", mange av dem ble glemt, siden jeg ikke hadde tid til å skrive dem ned. Nå prøver jeg å skrive ned alt som kommer til tankene, og jeg anbefaler at andre gjør det samme.
Men Alexey glemmer ikke å gi sine ønsker. Fra det siste:
/kill_sql SQL_ID — drep alle økter med denne SQL_ID-forespørselen
/kill_block - drep rotblokkeringsøkten
/vis_em — vis et bilde av EM-ytelse
Han er en lur fyr, han vil sy DBA fra telefonen sin =)
Slik jobber vi til beste for fedrelandet!
Hvordan slipper du rutinemessige og uinteressante oppgaver?
Jeg håper lesningen viste seg å være interessant, og kanskje til og med nyttig for noen, og jeg hadde ikke tid til å kjede leseren... Lykke til til oss alle.
Kilde: www.habr.com