Projektjeink általában regionálisak, megbízóink pedig általában minisztériumok. De a közszférán kívül magánszervezetek is használják rendszereinket. Gyakorlatilag nincs velük probléma.
Tehát a fő projektek regionálisak, és néha problémák vannak velük. Például a teljesítménnyel, amikor a régiókban több mint 20 ezer értékes felhasználónk van az új funkciók termékszervereken való bevezetésének időszakában. Ez egy fájdalom…
A nevem Ruslan és támogatom a BARS Group információs rendszereit és gyilkos bot fejlesztése erőszakos sorozatos DBA-k számára. Ez a bejegyzés nem a gyengébbeknek szól – rengeteg levél és kép található benne.
/awr
Egyes alkalmazásaink Oracle DBMS-en futnak. Vannak projektek a PostgreSQL DBMS-en is. Az Oracle-nek van egy csodálatos dolga – statisztikákat gyűjt a DBMS terheléséről, amely rávilágít a meglévő problémákra, és még javaslatokat is tesz a kiküszöbölésre – Automatic Workload Repository (AWR). Egy ponton (nevezetesen a fájdalom pillanatában) a fejlesztők folyamatosan kérték a gyűjtést AWR jelentések teljesítményelemzéshez. Őszintén elmentünk a DBMS szerverhez, összegyűjtöttük a jelentéseket, elvittük magunkhoz és elküldtük a termelésbe elemzésre. Az 5. alkalom után idegesítő lett... a 10. után már irritáló lett...
Egyik kollégám egyszer azt a gondolatot fogalmazta meg, hogy mindent automatizálni kell, amit többször csinálnak. Egészen az irritáció pillanatáig, hogy őszinte legyek, nem gondoltam rá, és megpróbáltam mindent automatizálni, ami automatizálható volt, de gyakran nem volt rá igény, és inkább kutatás volt, mintsem alkalmazott.
És akkor arra gondoltam: „Nincs szükség rendszergazdákra a jelentéskészítéshez...”. Hiszen a jelentés összegyűjtése azt jelenti, hogy végrehajtjuk a @$ORACLE_HOME/rdbms/admin/awrrpt.sql sql szkriptet, és elviszed a szerverről a jelentést a helyedre... Ja igen, nem engedélyezzük a fejlesztést termelésre.
Utána megkerestem a Google-ban a szükséges információkat, a tesztbázison lévő cikkből elkészítettem a függvényt, lefuttattam a scriptet és csoda - összeállt a riport és helyben menthető. Olyan funkciókat hozott létre, ahol gyakran volt szükség AWR-jelentésekre, és elmondták a fejlesztőknek, hogyan kell használni őket.
Ez idő tájt, szabadidőmben, miután beszélgettem @BotFatherrel, létrehoztam magamnak egy Telegram-botot, csak szórakozásból. Becsavartam egy egyszerű funkciót - mutatom az aktuális időt, árfolyamokat, időjárást, megtanítottam, hogy ütemezetten küldjem bókokat a feleségemnek (akkori barátnőmnek). Talán abban az időben a bókküldés volt a robotom legnépszerűbb funkciója, és a feleségem nagyra értékelte.
Így. A fejlesztők a Telegramban írnak nekünk, mi a Telegramban küldünk nekik jelentést... Mi van, ha nem nekünk, hanem egy botnak írnak? Hiszen így mindenkinek jobb lesz, gyorsabban érkezik a bejelentés, és ami a legfontosabb, minket megkerülve. Így született meg a robotom első népszerű funkciójának ötlete.
Elkezdtem a megvalósítást. Megcsináltam, ahogy tudtam, PHP-ben (maga az alkalmazásunk PHP-s, jobban értek hozzá, mint Pythonban). Nem vagyok jó kódoló, ezért nem mutatom meg a kódomat :)
A bot a vállalati hálózatunkon él, és hozzáfér bizonyos projektekhez, beleértve a céladatbázisokat is. Annak érdekében, hogy ne bajlódjak a paraméterekkel a csapatban vagy a menüben, hozzáadtam ezt a funkciót a csoportos chathez a figyelő értesítésekkel. Így a bot azonnal tudja, hogy melyik adatbázisból gyűjtse a jelentést.
Miután megkapta a hasonló parancsot /awr N, ahol N azoknak a teljes óráknak a száma, amelyekre jelentésre van szükség (alapértelmezés szerint - 1 óra), akár egy hétig is, ha az adatbázist nem indították újra, a bot azonnal munkába áll, összegyűjti a jelentést, közzéteszi egy weboldalt, és azonnal (majdnem ott) megadja a linket a nagyon szükséges jelentéshez.
Kövesse a linket, és itt van, az AWR jelentés:
Ahogy az várható volt, a fejlesztők megbirkóztak az ilyen jelentéskészítéssel, és néhányan meg is köszönték nekünk.
A csapat kényelmét értékelve más régiók projektmenedzserei is ezt akarták, hiszen ők kapják a legtöbbet az ügyféltől, és aggódnak a rendszerek teljesítménye és elérhetősége miatt. Hozzáadtam a botot más csevegésekhez. Még mindig használják, és örülök neki.
Később a CIT munkatársai rájöttek, hogyan gyűjtjük a jelentéseket, és ezt is meg akarták tenni. Nem adtam hozzá őket chatjeinkhez, külön chat-et hoztam létre a riportok ütemezett és kérésre generálásával.
/pgBadger
Más alkalmazások is vannak PHP-ben a PostgreSQL-lel együtt. A pgBadger jelentések gyűjtését a rászorulók számára ugyanezen az elven - csoportos chatekben - valósítottam meg. Eleinte használták, de aztán abbahagyták. A funkcionalitást szükségtelenül kivágták.
/kötelesség
Osztályunk éjszakai műszakos, ennek megfelelően órarendje is van. A Google Táblázatokban található. Nem mindig kényelmes hivatkozást keresni, diagramot nyitni, magadat keresni... Egy volt kollégám is játszott a Telegram botjával, és bevezette osztályunk chatjébe. osztályos dolgozók ügyeleti műszakának kezdetéről szóló értesítéseket. A bot elemzi a beosztást, meghatározza az aktuális dátumra az ügyeletes személyt, és az ütemterv szerint vagy kérésre jelenti, hogy ki van ma szolgálatban. Remek és kényelmes lett. Igaz, nem igazán tetszett az üzenetek formátuma. Egy másik részleg (például BC „Gyógyász”) dolgozóinak sem igazán van szükségük a más irányban szolgálatot teljesítők információira, de tudnia kell, hogy probléma esetén kik teljesítenek szolgálatot az „Orvostudományban”. Úgy döntöttem, hogy „kölcsönveszem” a funkcionalitást, de megváltoztatom azt, ami nem tetszett. Kényelmes üzenetformátumot készítettem magamnak és másoknak, eltávolítva a felesleges információkat.
/tnls
Miután kipróbáltam az automatizálást egy Telegram bot segítségével, sokféle ötlet jelent meg, de én szigorúan szükséges dolgokat akartam megtenni. Elhatároztam, hogy vezetek kérésekre vonatkozó statisztikák. Ügyfeleink projektjeinek eléréséhez úgynevezett „jump szervert” vagy továbbító szervert építettünk be. VPN kapcsolatok épülnek rá, majd alkalmazás portok, adatbázisok és egyéb kiegészítő továbbítások ssh-n keresztül továbbíthatók a helyi hálózatunkba, hogy könnyen hozzáférjenek munkatársaink projektjeihez, VPN kapcsolati problémák nélkül. Mindössze annyit kell tennie, hogy VPN-kapcsolatot hoz létre vállalati hálózatunkhoz.
A kérések statisztikái azt mutatják, hogy gyakran az egyik alagút meghibásodása után (hálózati problémák esetén, például időtúllépés miatt) az emberek megkeresnek minket, hogy visszaállítsák a hozzáférést a projekthez. A legtöbb esetben elég a kapcsolat újraindítása, és minden rendben van. Csináljuk meg magunk. Íme a parancs:
Beleesel a kívánt menüpontba, kiválasztod a projekted, vársz egy percet és mindenki boldog és elégedett...
Parancs vételekor a bájtok és bitek enyhe mozgásával a bot csatlakozik a továbbító szerverhez, előre tudva, hogy melyik továbbítást kell újraindítani, és elvégzi a dolgát - helyreállítja a kapcsolatot a projekttel. Azért írtam utasításokat, hogy Ön is megoldhassa az ilyen problémákat. És az emberek csak akkor kerestek meg minket, ha a biztosított eszköz nem működött...
/ecp_to_pem
További statisztikák azt mutatták, hogy gyakran szükséges az átalakítás EDS Crypto Pro PEM formátumban() különféle integrációkhoz, és elég sok van belőlük. Feladat: vegyünk egy tárolót, másoljuk át egy Windows számítógépre, amelyen a P12FromGostCSP segédprogram telepítve van (egyébként fizetős), alakítsuk át pfx-re, majd a pfx-et OpenSSL-lel (GOST titkosítás támogatásával) pem-re. Nem túl kényelmes, de az ujjaid csattanásával szeretnéd.
A Google ismét a segítségére sietett. Megtalált . A README-ben leírtak szerint szereltem össze - működött. Megtanítottam a botot, hogy működjön együtt a segédprogrammal, és szinte azonnali konverziót kaptam.
A végleges megvalósítás idejére parancsot adtak ki az új titkosítási formátumra - gost-2012 - való átállásra. Amennyire emlékszem, a segédprogram abban a pillanatban csak a régi GOST-tal (2001) működött, talán egy másik hasonló segédprogram volt egy másik kedves embertől, nem emlékszem pontosan.
Az új GOST-ra való áttérés után biztonsági okokból eltávolították a bot funkcióit. Docker konténerben valósította meg.
Dockerfile, ha valakinek szüksége lenne rá:
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.shA konvertáláshoz el kell helyezni az eredeti tárolót (például az xxx.000 könyvtárat) a /srv/in könyvtárba, és a kész pemet át kell vinni a /srv/out könyvtárba.
Átalakít:
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 és /emstart
Egy nap egy nagyon menő Oracle DBA, aki nagy tapasztalattal rendelkezik a DBMS adminisztrációban és fejlesztésben, állást kapott cégünknél. És azonnal gondot okozott neki a DBMS szerverekhez való csatlakozás ssh-val: nem tudja hol és hogyan csatlakozzon, nincs egyértelműen leírva a hozzáférés, vagy nem tud továbbítani magának valamit, amire szüksége van. Nos, szívesen segítünk, elmondtuk neki, hogyan kell csatlakozni, és továbbítottuk neki az Enterprise Managert. De az ssh-val még mindig nem mentek a dolgok. Egyik kolléga egyszerűen elmagyarázta: egy fajtatiszta DBA :) Úgy döntöttünk, hogy ha valamit módosítani kell a szerveren, akkor azt mi magunk csináljuk.
Az EM néha nagy terhelés alatt összeomlik, és az újraindításhoz... ssh-n keresztül kell csatlakozni, és újra kell indítani a terminálon keresztül. „Az adminisztrátorok jók ebben” – döntötte el új kollégánk. Nálunk nem ritka a nagy terhelés a DBMS-en, és gyakoriak az EM újraindítására vonatkozó kérések is. Aztán ugyanaz a forgatókönyv: feszültség, ingerültség és megoldás keresése a problémára. Tehát ugyanabban a csoportos csevegésben a következő parancsok jelentek meg: /emstop és /emstart.
/megöl
Ha erős verseny van az adatbázison, és ez néha megtörténik, akkor gyorsan ki kell tölteni az adatbázist. A leggyorsabb módja a problémás folyamat megölése... Ehhez csatlakozz ssh-n keresztül, kill -9... A bot segít!
Alexey nagyra értékelte a csapatot, és szeretetteljes nevet adott neki - "Kilyalka" vagy fegyvert.
Egy nap, miután megnéztem, hogyan próbálkozott és szenvedett Alekszej, és minden egyes folyamatnál beírtam a /kill xxx parancsot, úgy döntöttem, hogy „több csövűt” adok a fegyverünkhöz:
Ez jobb! Minden neked szól, Alexey, csak dolgozz, kedves!
Természetesen egy ilyen fontos csapat korlátozott volt hozzáférés user_id - "bolondbiztos". Látva, ahogy Lesha ügyesen megöli a folyamatokat az adatbázis-kiszolgálón, többen megpróbáltak egy véletlenszerű folyamatszámú parancsot beírni, de nem lehet becsapni az okosbotomat, azonnal visszautasította.
/alertlog
Nos, minden esetre kiadtam a parancsot:
/alertlog — megkapja a megadott számú riasztási naplósort
A bot előhív egy riasztási naplót, és elküldi a szolgáltatásunknak, mint például a pastebin, pyste, és elküldi a beillesztésre mutató hivatkozást a kérés chatbe.
/ellenőrzi
Utána jött egy kérés alkalmazásunk valós teljesítményének nyomon követése. Eddig a projekt technikai támogatása manuálisan gyűjtötte ezeket az adatokat. Nem számít! Bátor tesztelőink erre teszteseteket fejlesztettek ki. Az eredményül kapott tesztnaplót nem túl kényelmes elolvasni; egy tapasztalatlan felhasználónak hosszú időbe telik, amíg megérti, és nem biztos, hogy kiemeli a szükséges információkat. És nem szeretjük a kezünkkel azt csinálni, amit a kezünkkel nem... Új feladat a botnak!
A /checks parancs egy egyszerű és egyértelmű menüt jelenít meg, srácaink ezúttal megtanulták, hogyan kell ezt a parancsot utasítások nélkül használni!
A kívánt elem kiválasztásakor a menü helyett egy értesítés jelenik meg a teszt kezdetéről, hogy a türelmetlen felhasználók ne futtassák le 100500 XNUMX-szor a tesztünket:
A kiválasztott menüponttól függően egy konkrét teszt indul a hálózatunkról, mégpedig arról a gépről, ahol a bot él (a jmeter előre be van állítva, ott találhatók a szükséges tesztek...) vagy közvetlenül az adatközpontból (egy előkészített gépet az alkalmazás mellett), hogy a hálózati kapcsolatokat a késések tesztelésekor kizárjuk, vagy minimálisra csökkentsük.
A teszt befejezése és a napló fogadása után a bot elemzi azt, és „ember által olvasható” formában elkészíti az eredményt:
Metrika gyűjtemény
Megérkezett a funkcionalitás, és az érdeklődő projektmenedzserek is kaptak ilyen funkciót régióik számára. És az egyik együttérző projektmenedzser azt mondta: „Szeretnék időstatisztikát!” Valaki a CIT-től azt mondta neki, hogy kényelmes lenne mindezt a Zabbixban figyelni. Zabbix, szóval Zabbix...
Arra gondoltam, hogy fel kell készülnöm a megoldás megismétlésére... Docker konténerbe tettem az ötletet. A konténerben a jmeter ütemezetten (10 percenként egyszer) elindul, a naplót egy adott helyre teszi, a php elemzi és weblap formájában megjeleníti a szükséges adatokat. A Zabbix a web.page.get kulcs használatával megkapja ezt az oldalt, rendszeresen kiválasztja a szükséges adatokat bizonyos függő elemekhez, és grafikont készít.
Szerintem nem lett rossz. A grafikon megfigyelésével először is az alkalmazás hozzávetőleges sebességét látjuk, és ha csúcsokat észlelünk a grafikonon, akkor hozzávetőlegesen tudjuk, hogy hol van a „dugó”. Ez egyszerű. Eddig csak egy régióban mutatkozott rá kereslet, de kész vagyok lemásolni az érdeklődőknek.
Alkalmazásfejlesztés
A hasonló feladatok statisztikája újabban újabb ötleteket adott a munka egyszerűsítésére és megkönnyítésére. Egyes projektekben, alkalmazásszervereken kulcsfontosságú Crypto Pro konténereket kell telepíteni, sok van belőlük, és a digitális aláírás idővel lejár. Néha 2 feladat érkezik egy nap. De nem tartottam biztonságosnak egy bot használatát ilyen célokra, és úgy döntöttem, hogy a funkcionalitást közvetlenül az alkalmazásban fogom létrehozni. Természetesen jogosultsággal és hozzáférési jogok ellenőrzésével. Ha rendelkezik a szükséges jogosultságokkal, egy további menüpont is elérhető lesz a digitális aláírások kezeléséhez, telepítéshez, törléshez, információk megtekintéséhez stb. A funkció jelenleg fejlesztés alatt áll. Mint kiderült, ez nem túl nehéz, csak egy kicsit el kell olvasni a meglévő utasításokat, megnézni a kódpéldákat, megkérdezni a fejlesztésben tapasztaltabb kollégákat, majd meg kell tenni. A kutatási folyamat során ötletek születtek, amelyekkel kiegészíthető a pályázat. Nem fogok napóleoni terveket készíteni – van fejlődés, mindenki foglalkozzon a saját dolgaival. De bár érdekes, én magam csinálom.
Tervek
Mint mondtam, sokféle ötlet született a botunk használatára, és nem csak - általában, mondjuk az "automatizálási pontokra" - sok közülük feledésbe merült, mivel nem volt időm leírni őket. Most megpróbálok mindent leírni, ami eszembe jut, és javaslom, hogy mások is tegyék ezt.
De Alexey nem felejti el teljesíteni a kívánságait. A legújabbból:
/kill_sql SQL_ID — az összes munkamenet leállítása ezzel az SQL_ID kéréssel
/kill_block - ölje meg a root blokkoló munkamenetet
/show_em — mutasson képet az EM teljesítményéről
Ravasz srác, DBA-t akar varrni a telefonjáról =)
Így dolgozunk a Szülőföld érdekében!
Hogyan szabadulsz meg a rutinszerű és érdektelen feladatoktól?
Remélem, hogy érdekes volt az olvasmány, és talán valakinek hasznos is volt, és nem volt időm untatni az olvasót... Sok sikert mindannyiunknak.
Forrás: will.com