Šetříme čas, nervy a člověkohodiny

Naše projekty jsou většinou regionální a klienty jsou většinou ministerstva. Kromě veřejného sektoru ale naše systémy využívají i soukromé organizace. Nejsou s nimi prakticky žádné problémy.

Hlavní projekty jsou tedy regionální a někdy jsou s nimi problémy. Například s výkonem, kdy je v regionech více než 20 tisíc našich vzácných uživatelů během období zavádění nových funkcí na produktové servery. Je to bolest…

Jmenuji se Ruslan a podporuji informační systémy BARS Group a vývoj zabijáckého bota pro násilné sériové DBA. Tento příspěvek není pro slabé povahy - je tam spousta dopisů a obrázků.

/awr

Některé z našich aplikací běží na Oracle DBMS. Existují také projekty na PostgreSQL DBMS. Oracle má skvělou věc – sbírá statistiky o zátěži na DBMS, která upozorňuje na existující problémy a dokonce dává doporučení k odstranění – Automatic Workload Repository (AWR). V jednom okamžiku (konkrétně v okamžiku bolesti) vývojáři neustále žádali o sbírání AWR zprávy pro analýzu výkonu. Poctivě jsme chodili na server DBMS, sbírali zprávy, odnášeli je k nám a odeslali do výroby k analýze. Po 5. době to začalo být otravné... po 10. to začalo být dráždivé...

Jeden z mých kolegů jednou vyslovil myšlenku, že vše, co se dělá vícekrát, by mělo být automatizováno. Až do okamžiku podráždění, abych byl upřímný, jsem o tom nepřemýšlel a snažil jsem se zautomatizovat vše, co automatizovat šlo, ale často to nebylo žádané a bylo to spíše výzkum než aplikovaný charakter.

A pak mě napadlo: „Ke vygenerování přehledu nejsou potřeba administrátoři...“. Koneckonců, shromažďování zprávy znamená spuštění skriptu SQL @$ORACLE_HOME/rdbms/admin/awrrpt.sql a přenesení zprávy ze serveru k vám... Ach ano, vývoj pro produkci nepovolujeme.

Pak jsem vygoogloval potřebné informace, vytvořil funkci z článku na testovací bázi, spustil skript a zázrak – sestava byla sestavena a lze ji lokálně uložit. Vytvořené funkce, kde byly často potřeba zprávy AWR, a řekli vývojářům, jak je používat.

V této době, ve svém volném čase, po rozhovoru s @BotFather, jsem si pro sebe vytvořil telegramového robota, jen tak pro zábavu. Našrouboval jsem tam jednoduchou funkcionalitu – ukázat aktuální čas, směnné kurzy, počasí, naučil jsem to posílat komplimenty manželce (tehdejší přítelkyni) podle plánu. Možná v té době bylo posílání komplimentů nejoblíbenější funkcí mého robota a moje žena to ocenila.

Tak. Vývojáři nám píší v Telegramu, my jim posíláme zprávu v Telegramu... Co když nepíší nám, ale botovi? Bude to přeci pro všechny lepší, hlášení se dostane rychleji a hlavně nás obejde. Tak se zrodila myšlenka první populární funkce pro mého robota.

Začal jsem s implementací. Udělal jsem to, jak nejlépe jsem mohl, v PHP (naše aplikace samotná je v PHP, jsem v něm zběhlejší než v Pythonu). Nejsem dobrý kodér, takže vám svůj kód neukážu :)

Robot žije v naší podnikové síti a má přístup k určitým projektům, včetně cílových databází. Abych se neobtěžoval s parametry v týmu nebo menu, přidal jsem tuto funkcionalitu do skupinového chatu s upozorněním na monitoring. Tímto způsobem bot okamžitě ví, ze které databáze má zprávu shromáždit.

Po obdržení příkazu jako /awr N, kde N je počet celých hodin, po které je potřeba zpráva (ve výchozím nastavení - 1 hodina), a to i na týden, pokud databáze nebyla restartována, bot okamžitě začne pracovat, shromáždí zprávu, publikuje ji jako a okamžitě (téměř přímo tam) poskytuje odkaz na tolik potřebnou zprávu.

Klikněte na odkaz a zde je zpráva AWR:

Podle očekávání si vývojáři s takovým generováním reportů poradili a někteří nám dokonce poděkovali.

Projektoví manažeři z jiných regionů, kteří ocenili pohodlí týmu, chtěli totéž, protože dostávají od zákazníka nejvíce a obávají se o výkon a dostupnost systémů. Přidal jsem robota do jiných chatů. Stále to používají a jsem za to rád.

Později se kolegové z CIT dozvěděli, jak sbíráme reporty, a chtěli to udělat také. Nepřidával jsem je do našich chatů, vytvořil jsem samostatný chat s generováním reportů podle plánu a na vyžádání.

/pgBadger

Máme i další aplikace v PHP ve spojení s PostgreSQL. Implementoval jsem sběr zpráv pgBadger pro potřebné pomocí stejného principu - ve skupinových chatech. Nejdřív to používali, ale pak přestali. Funkce byla vyškrtnuta jako nepotřebná.

/povinnost

Naše oddělení má noční směny a podle toho má i rozvrh. Je to v Tabulkách Google. Ne vždy je vhodné hledat odkaz, otevřít graf, hledat sami sebe... Jeden z mých bývalých kolegů si také pohrál se svým telegramovým botem a uvedl ho do chatu našeho oddělení oznámení o zahájení směny pro zaměstnance oddělení. Bot analyzuje rozvrh, určí osobu ve službě podle aktuálního data a podle rozvrhu nebo na požádání nahlásí, kdo je dnes ve službě. Ukázalo se to skvělé a pohodlné. Pravda, formát zpráv se mi moc nelíbil. Také pro zaměstnance jiného oddělení (například BC „Medicine“) nejsou informace o těch, kteří jsou ve službě v jiných směrech, opravdu potřeba, ale musíte vědět, kdo má službu v „Medicine“ v případě problémů. Rozhodl jsem se, že si funkci „vypůjčím“, ale změním to, co se mi nelíbí. Vytvořil jsem formát zprávy vhodný pro sebe i ostatní a odstranil nepotřebné informace.

/tnls

Po vyzkoušení automatizace pomocí telegramového bota se objevilo mnoho různých nápadů, ale já jsem chtěl dělat nezbytně nutné věci. Rozhodl jsem se vést statistiky žádostí. Pro přístup k projektům našich zákazníků jsme implementovali takzvaný „jump server“ neboli forwardovací server. Jsou na něm navázána VPN připojení, poté jsou aplikační porty, databáze a další pomocné forwardy přes ssh předávány do naší lokální sítě, pro snadný přístup k projektům našich zaměstnanců, bez problémů s VPN připojením. Vše, co musíte udělat, je nastavit VPN připojení k naší firemní síti.

Statistika požadavků ukázala, že často po selhání jednoho z tunelů (v případě problémů se sítí, například kvůli timeoutu) nás lidé kontaktují ohledně obnovení přístupu k projektu. Ve většině případů stačí jen restartovat připojení a vše je v pořádku. Udělejme to sami. Zde je příkaz:


„Propadnete“ do požadované položky menu, vyberete svůj projekt, chvilku počkáte a všichni jsou šťastní a spokojení...

Po obdržení příkazu, s mírným pohybem bajtů a bitů, se bot připojí k předávacímu serveru, předem ví, které předávání je třeba restartovat, a udělá svou práci – obnoví připojení k projektu. Napsal jsem návod, abyste takové problémy mohli vyřešit sami. A lidé nás kontaktovali pouze v případě, že poskytnutý nástroj nefungoval...

/ecp_to_pem

Další statistiky ukázaly, že je často nutné převádět EDS Crypto Pro ve formátu pem(64. základna) pro různé integrace a máme jich poměrně hodně. Úkol: vezměte kontejner, zkopírujte jej do počítače se systémem Windows s nainstalovanou utilitou P12FromGostCSP (mimochodem placenou), převeďte jej na pfx a poté převeďte pfx pomocí OpenSSL (s podporou šifrování GOST) na pem. Není to příliš pohodlné, ale chcete to lusknutím prstů.

Google opět přišel na pomoc. Nalezeno užitek nějakého laskavého člověka. Sestavil jsem to, jak je napsáno v README - fungovalo to. Naučil jsem robota pracovat s nástrojem a získal téměř okamžitou konverzi.


V době konečné implementace byl vydán příkaz k přechodu na nový formát šifrování - gost-2012. Pokud si pamatuji, nástroj v tu chvíli fungoval pouze se starým GOST (2001), možná to byl další podobný nástroj od jiného laskavého člověka, přesně si nepamatuji.
Po přechodu na nový GOST byla funkčnost bota z bezpečnostních důvodů odstraněna. Implementováno v dokovacím kontejneru.

Dockerfile, kdyby ho někdo potřeboval:

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.sh

Chcete-li převést, musíte umístit původní kontejner (adresář jako xxx.000) do adresáře /srv/in a přenést hotový pem do /srv/out.

Převést:

 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 a /emstart

Jednoho dne v naší společnosti získal práci velmi cool Oracle DBA s mnoha zkušenostmi v administraci a vývoji DBMS. A okamžitě měl problémy s připojením k serverům DBMS pomocí ssh: neví, kam a jak se připojit, přístup není jasně popsán nebo si nemůže přeposlat něco, co potřebuje. No, rádi pomůžeme, řekli jsme mu, jak se připojit, a předali mu Enterprise Manager. Ale s ssh to stále nefungovalo. Jeden z mých kolegů to vysvětlil jednoduše: čistokrevný DBA :) Rozhodli jsme se, že když budeme potřebovat něco na serveru vyladit, uděláme to sami.

EM občas při velké zátěži spadne a pro jeho restart... je potřeba se připojit přes ssh a restartovat přes terminál. "Administrátoři jsou v tom dobří," rozhodl náš nový kolega. Velké zatížení DBMS u nás není nic neobvyklého a běžné jsou i požadavky na restart EM. Pak stejný scénář: napětí, podráždění a hledání řešení problému. Takže ve stejných skupinových chatech se objevily následující příkazy: /emstop a /emstart.

/zabít

Pokud je na databázi silná konkurence, a to se občas stává, je nutné databázi rychle vyložit. Nejrychlejší způsob je zabít problematický proces... Chcete-li to provést, připojte se přes ssh, zabijte -9... Pomůže bot!

Alexey ocenil tým a dal mu láskyplné jméno - "Kilyalka" nebo zbraň.
Jednoho dne, poté, co jsem viděl, jak se Alexey snažil a trpěl a pokaždé zadával /kill xxx pro každý z procesů, jsem se rozhodl přidat do naší zbraně „multi-barrel“:

To je lepší! Všechno je pro tebe, Alexey, jen pracuj, drahá!

Tak důležitý tým byl přirozeně omezený přístup pomocí user_id – „spolehlivý“. Když Lesha viděl, jak obratně zabíjí procesy na databázovém serveru, několik lidí se pokusilo zadat příkaz s náhodným číslem procesu, ale mého chytrého robota neoklamete, okamžitě odmítl.

/alertlog

No, pro případ, udělal jsem příkaz:
/alertlog <počet řádků> — získat zadaný počet řádků protokolu výstrah
Robot stáhne záznam výstrah a odešle jej do naší služby, jako je pastebin s názvem pyste, a pošle odkaz na vložení do chatu žádosti.

/kontroluje

Dále přišla žádost o sledování skutečného výkonu naší aplikace. Až dosud technická podpora projektu sbírala tato data ručně. Nezáleží! Naši stateční testeři pro to vyvinuli testovací případy. Výsledný protokol testu se nečte příliš pohodlně, nezkušenému uživateli bude trvat dlouho, než pochopí a není si jistý, že zvýrazní potřebné informace. A my neradi děláme rukama to, co rukama neumíme... Nový úkol pro robota!

Příkaz /checks zobrazí jednoduché a jednoznačné menu, tentokrát se naši kluci naučili tento příkaz používat bez návodu!

Když vyberete požadovanou položku, místo nabídky se zobrazí oznámení o zahájení testu, aby netrpěliví uživatelé nespustili náš test 100500 XNUMXkrát:

V závislosti na zvolené položce menu se konkrétní test spouští z naší sítě, a to ze stroje, kde bot žije (je tam předkonfigurován jmeter, potřebné testy jsou umístěny...) nebo přímo z datového centra (z připravený stroj vedle aplikace), aby se při testování zpoždění vyloučila síťová připojení nebo je snížila na minimum.

Po dokončení testu a obdržení protokolu jej robot analyzuje a vytvoří výsledek v podobě „čitelné pro člověka“:

Sbírka metrik

Funkce dorazila a zainteresovaní projektoví manažeři takovou funkci pro své regiony dostali. A jeden soucitný projektový manažer řekl: "Chci mít časové statistiky!" Někdo z CIT jí řekl, že by bylo vhodné toto vše sledovat v Zabbixu. Zabbix, takže Zabbix...

Myslel jsem, že se musím připravit na potřebu replikovat řešení... Vložil jsem myšlenku do kontejneru dockeru. V kontejneru se jmeter spustí podle plánu (jednou za 10 minut), vloží log na určité místo, php jej rozebere a zobrazí potřebná data ve formě webové stránky. Zabbix pomocí klíče web.page.get tuto stránku obdrží, pravidelně vybírá potřebná data pro určité závislé prvky a sestavuje graf.

Myslím, že to nedopadlo špatně. Pozorováním grafu nejprve vidíme přibližnou rychlost aplikace, a pokud jsou na grafu detekovány špičky, víme přibližně, kde je „zástrčka“. Je to jednoduché. Zatím se ukázalo, že je poptávaný pouze pro jeden region, ale jsem připraven ho pro zájemce replikovat.

Vývoj aplikací

Statistiky o podobných úkolech v poslední době přinesly další nápady na zjednodušení a usnadnění práce. U některých projektů, na aplikačních serverech, je potřeba nainstalovat klíčové kontejnery Crypto Pro, je jich mnoho a digitální podpis časem vyprší. Někdy přijdou 2 úkoly za den. Považoval jsem ale za nebezpečné používat pro tyto účely bota a rozhodl jsem se, že funkcionalitu vytvořím přímo v aplikaci. Samozřejmě s autorizací a kontrolou přístupových práv. Pokud máte potřebná oprávnění, bude k dispozici další položka nabídky pro práci s digitálními podpisy, instalaci, mazání, prohlížení informací atd. Funkce je v současné době ve vývoji. Jak se ukázalo, není to příliš obtížné, stačí si trochu přečíst stávající návod, podívat se na příklady kódu, zeptat se kolegů zkušenějších ve vývoji a pak to udělat. Během výzkumného procesu se objevily nápady, jak aplikaci přidat. Nebudu dělat napoleonské plány - existuje vývoj, ať si každý myslí své. Ale i když je to zajímavé, dělám to sám.

Plány

Jak jsem řekl, zrodilo se mnoho různých nápadů pro použití našeho robota a nejen - obecně, řekněme, nápady na „automatizační body“, mnoho z nich bylo zapomenuto, protože jsem neměl čas si je zapsat. Nyní se snažím zapisovat vše, co mě napadne, a doporučuji, aby to udělali i ostatní.

Ale Alexey nezapomene splnit svá přání. Z nejnovějších:
/kill_sql SQL_ID — ukončete všechny relace s tímto požadavkem SQL_ID
/kill_block - zabijte relaci blokování root
/show_em — zobrazit obrázek výkonu EM
Je to chytrák, chce si šít DBA z telefonu =)

Takto pracujeme ve prospěch vlasti!

Jak se zbavujete rutinních a nezajímavých úkolů?

Doufám, že čtení bylo zajímavé, a možná pro někoho i užitečné a nestihla jsem čtenáře nudit... Hodně štěstí nám všem.

Zdroj: www.habr.com