Niaj projektoj estas kutime regionaj, kaj la klientoj kutime estas ministerioj. Sed, krom la publika sektoro, ankaŭ privataj organizaĵoj uzas niajn sistemojn. Estas preskaŭ neniuj problemoj kun ili.
Do, la ĉefaj projektoj estas regionaj, kaj foje estas problemoj kun ili. Ekzemple, kun rendimento, kiam en regionoj estas pli ol 20k el niaj altvaloraj uzantoj dum la periodo de lanĉo de novaj funkcioj sur produktaj serviloj. Ĝi estas doloro...
Mi nomiĝas Ruslan kaj mi subtenas la informsistemojn de BARS Group kaj evoluigante murdan roboton por perfortaj seriaj DBAoj. Ĉi tiu afiŝo ne estas por malfortuloj - estas multaj leteroj kaj bildoj.
/awr
Kelkaj el niaj aplikaĵoj funkcias per Oracle DBMS. Estas ankaŭ projektoj pri la PostgreSQL DBMS. Oracle havas mirindan aferon - kolektado de statistikoj pri la ŝarĝo sur la DBMS, kiu reliefigas ekzistantajn problemojn kaj eĉ faras rekomendojn por elimini - Aŭtomata Laborŝarĝa Deponejo (AWR). En unu momento (nome en la momento de doloro), la programistoj konstante petis kolekti AWR-raportoj por agado-analizo. Ni honeste iris al la DBMS-servilo, kolektis raportojn, prenis ilin al ni kaj sendis ilin al produktado por analizo. Post la 5-a fojo ĝi iĝis ĝena... post la 10-a ĝi iĝis incita...
Unu el miaj kolegoj iam esprimis la ideon, ke ĉio, kio estas farita pli ol unufoje, estu aŭtomatigita. Ĝis la momento de kolero, sincere, mi ne pensis pri tio kaj provis aŭtomatigi ĉion, kio povas esti aŭtomatigita, sed ofte ĝi ne postulis kaj estis pli esploro ol aplikata naturo.
Kaj tiam mi pensis: "Administrantoj ne bezonas por generi raporton...". Post ĉio, kolekti raporton signifas ekzekuti la sql-skripton @$ORACLE_HOME/rdbms/admin/awrrpt.sql kaj preni la raporton de la servilo al via loko... Ho jes, ni ne permesas disvolviĝon por produktado.
Poste mi Guglodis la necesajn informojn, kreis la funkcion el la artikolo pri la testa bazo, kuris la skripton kaj miraklon - la raporto estis kompilita kaj konserveblas loke. Kreis funkciojn kie AWR-raportoj ofte estis bezonataj kaj rakontis al programistoj kiel uzi ilin.
Ĉirkaŭ ĉi tiu tempo, en mia libertempo, post paroli kun @BotFather, mi kreis Telegram-roton por mi, nur por amuzo. Mi enŝraŭbis tie simplan funkcion - montru la nunan tempon, kurzojn, veteron, instruis ĝin sendi komplimentojn al mia edzino (tiam amatino) laŭ horaro. Eble, en tiu tempo, sendi komplimentojn estis la plej populara funkcio de mia bot, kaj mia edzino aprezis ĝin.
Do. Programistoj skribas al ni en Telegramo, ni sendas raporton al ili en Telegramo... Kaj se ili skribas ne al ni, sed al bot? Post ĉio, estos pli bone por ĉiuj, la raporto estos ricevita pli rapide, kaj plej grave, preterpasante nin. Jen kiel naskiĝis la ideo de la unua populara funkcio por mia bot.
Mi komencis efektivigon. Mi faris ĝin, kiel eble plej bone, en PHP (nia aplikaĵo mem estas en PHP, mi pli konas ĝin ol en Python). Mi ne estas bona kodisto, do mi ne montros al vi mian kodon :)
La bot vivas sur nia kompania reto kaj havas aliron al certaj projektoj, inkluzive de celdatumbazoj. Por ne ĝeni parametrojn en la teamo aŭ menuo, mi aldonis ĉi tiun funkcion al la grupa babilejo kun monitoraj sciigoj. Tiel la roboto tuj scias de kiu datumbazo kolekti la raporton.
Ricevinte ordonon kiel /awr N, kie N estas la nombro da plenaj horoj por kiuj raporto necesas (defaŭlte - 1 horo), eĉ dum semajno, se la datumbazo ne estis rekomencita, la bot tuj ekfunkcias, kolektas la raporton, publikigas ĝin kiel retpaĝo kaj tuj (preskaŭ ĝuste tie) provizas ligilon al la tre bezonata raporto.
Sekvu la ligilon kaj jen ĝi estas, la AWR-raporto:
Kiel atendite, la programistoj traktis tian raportgeneradon, kaj iuj eĉ dankis nin.
Estimis la oportunon de la teamo, projektestroj de aliaj regionoj deziris la samon, ĉar ili ricevas la plej grandan parton de la kliento kaj maltrankviliĝas pri la agado kaj havebleco de sistemoj. Mi aldonis la roboton al aliaj babilejoj. Ili ankoraŭ uzas ĝin, kaj mi ĝojas pri ĝi.
Poste, kolegoj de CIT eksciis pri kiel ni kolektas raportojn kaj ankaŭ volis fari ĝin. Mi ne aldonis ilin al niaj babilejoj, mi kreis apartan babilejon kun la generado de raportoj laŭ horaro kaj laŭpeto.
/pgBadger
Ni ankaŭ havas aliajn aplikojn en PHP kune kun PostgreSQL. Mi efektivigis la kolekton de pgBadger-raportoj por bezonantoj uzante la saman principon - en grupaj babilejoj. Komence ili uzis ĝin, sed poste ili ĉesis. La funkcieco estis eltranĉita kiel nenecesa.
/devo
Nia fako havas noktajn deĵorojn kaj, laŭe, havas horaron. Ĝi estas en Google Sheets. Ne ĉiam konvenas serĉi ligilon, malfermi diagramon, serĉi mem... Unu el miaj iamaj kolegoj ankaŭ ludis per sia Telegram-bot kaj enkondukis ĝin en la babilejon de nia fako. sciigoj pri la komenco de la devoŝanĝo por fakaj dungitoj. La roboto analizas la horaron, determinas la deĵoranton laŭ la aktuala dato kaj, laŭ la horaro aŭ laŭpeto, raportas, kiu deĵoras hodiaŭ. Ĝi rezultis bonega kaj oportuna. Vere, mi ne tre ŝatis la formaton de la mesaĝoj. Ankaŭ por dungitoj de alia fako (ekzemple BC "Medicino"), informoj pri deĵorantoj en aliaj direktoj ne vere bezonas, sed vi devas scii, kiu deĵoras en "Medicino" en kazo de problemoj. Mi decidis "prunti" la funkciecon, sed ŝanĝi tion, kion mi ne ŝatis. Mi faris mesaĝformaton oportunan por mi kaj aliaj, forigante nenecesajn informojn.
/tnls
Post provi aŭtomatigon per Telegram-bot, multaj malsamaj ideoj aperis, sed mi volis fari strikte necesajn aferojn. Mi decidis gvidi statistiko pri petoj. Por aliri la projektojn de niaj klientoj, ni efektivigis tiel nomatan "salta servilo" aŭ plusenda servilo. VPN-konektoj estas levitaj sur ĝi, tiam aplikaj havenoj, datumbazoj kaj aliaj helpaj plusendoj estas plusenditaj al nia loka reto per ssh, por facila aliro al la projektoj de niaj dungitoj, sen problemoj kun VPN-konektoj. Ĉio, kion vi bezonas fari, estas agordi VPN-konekton al nia kompania reto.
La statistiko de petoj montris, ke ofte, post kiam unu el la tuneloj malsukcesas (kaze de retaj problemoj, pro tempodaŭro, ekzemple), homoj kontaktas nin pri restarigo de aliro al la projekto. Plejofte, nur rekomenci la konekton sufiĉas kaj ĉio estas en ordo. Ni faru ĝin mem. Jen la komando:
Vi "falas" en la deziratan menueron, elektu vian projekton, atendu momenton kaj ĉiuj estas feliĉaj kaj kontentaj...
Ricevinte komandon, kun eta movo de la bajtoj kaj bitoj, la roboto konektas al la plusenda servilo, sciante anticipe, kiu plusendado devas esti rekomencita, kaj faras sian laboron - restarigas la konekton al la projekto. Mi skribis instrukciojn por ke vi mem solvi tiajn problemojn. Kaj homoj kontaktis nin nur se la provizita ilo ne funkciis...
/ecp_to_pem
Pliaj statistikoj montris, ke ofte necesas konverti EDS Crypto Pro en formato pem() por diversaj integriĝoj, kaj ni havas sufiĉe multajn el ili. Tasko: prenu ujon, kopiu ĝin al Vindoza komputilo kun la ilo P12FromGostCSP instalita (pagita, cetere), konverti ĝin al pfx, kaj poste konverti pfx per OpenSSL (kun subteno por GOST-ĉifrado) al pem. Ĝi ne estas tre oportuna, sed vi volas ĝin je la klako de viaj fingroj.
Guglo denove venis al la savo. Trovita . Mi kunvenis ĝin kiel skribite en la README - ĝi funkciis. Mi instruis la roboton labori kun la utileco kaj ricevis preskaŭ tujan konvertiĝon.
Je la tempo de fina efektivigo, ordono estis eligita ŝanĝi al nova ĉifrada formato - gost-2012. Kiom mi memoras, la utileco en tiu momento funkciis nur kun la malnova GOST (2001), eble ĝi estis alia simila utileco de alia afabla homo, mi ne precize memoras.
Post la transiro al la nova GOST, la funkcieco de la bot estis forigita pro sekurecaj kialoj. Efektivigis ĝin en docker-ujo.
Dockerfile, se iu bezonas ĝin:
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.shPor konverti, vi devas meti la originalan ujon (dosierujon kiel xxx.000) en la dosierujon /srv/in, kaj prenu la finitan pem al /srv/out.
Por konverti:
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 kaj /emstart
Iun tagon, tre bonega Oracle DBA, kun multe da sperto en DBMS-administrado kaj evoluo, ricevis laboron ĉe nia firmao. Kaj li tuj havis problemojn por konekti al la DBMS-serviloj per ssh: li ne scias kie aŭ kiel konekti, la aliro ne estas klare priskribita, aŭ li ne povas plusendi ion, kion li bezonas al si. Nu, ni volonte helpas, ni diris al li kiel konekti, kaj plusendis al li Enterprise Manager. Sed aferoj ankoraŭ ne funkciis kun ssh. Unu el miaj kolegoj klarigis ĝin simple: purrasa DBA :) Ni decidis, ke se ni bezonas ĝustigi ion en la servilo, ni mem faros.
EM foje kraŝas sub peza ŝarĝo, kaj por rekomenci ĝin... vi devas konekti per ssh kaj rekomenci per la terminalo. "Administoj estas bonaj pri tio," decidis nia nova kolego. Pezaj ŝarĝoj sur la DBMS ne estas maloftaj por ni, kaj petoj por rekomenci EM ankaŭ estas oftaj. Tiam la sama scenaro: streĉiĝo, kolero kaj serĉado de solvo al la problemo. Do en la sama grupa babilado aperis jenaj komandoj: /emstop kaj /emstart.
/mortigi
Se estas forta konkurenco en la datumbazo, kaj tio foje okazas, necesas rapide malŝarĝi la datumbazon. La plej rapida maniero estas mortigi la probleman procezon... Por fari tion, konekti per ssh, kill -9... La bot helpos!
Alexey aprezis la teamon kaj donis al ĝi aman nomon - "Kilyalka" aŭ pafilon.
Iun tagon, post kiam mi rigardis kiel Alexey provis kaj suferis, enirante /kill xxx ĉiufoje por ĉiu el la procezoj, mi decidis aldoni "mult-tubon" al nia pafilo:
Tio estas pli bona! Ĉio estas por vi, Aleksej, nur laboru, kara!
Kompreneble tia grava teamo estis limigita aliro per user_id - "falsa". Vidante kiel Lesha lerte mortigas procezojn sur la datumbaza servilo, pluraj homoj provis enigi komandon kun hazarda proceznumero, sed vi ne povas trompi mian inteligentan roboton, li tuj rifuzis.
/alertlog
Nu, ĉiaokaze, mi faris la ordonon:
/alertlog — akiri la specifitan nombron da alertlog-linioj
La bot tiras alertlog kaj sendas ĝin al nia servo, kiel pastebin, nomita pyste, kaj sendas ligon al la pasto al la peta babilejo.
/ĉekoj
Poste venis peto por monitorante la realan agadon de nia aplikaĵo. Ĝis nun, projekta teknika subteno kolektis ĉi tiujn datumojn permane. Ne gravas! Niaj kuraĝaj testistoj evoluigis provojn por ĉi tio. La rezulta testprotokolo ne estas tre oportuna por legi; nesperta uzanto bezonos longan tempon por kompreni kaj ne certas, ke li reliefigos la necesajn informojn. Kaj ni ne ŝatas fari per niaj manoj tion, kion ni ne povas fari per niaj manoj... Nova tasko por la bot!
La komando /checks montras simplan kaj malambiguan menuon; ĉi-foje niaj infanoj lernis kiel uzi ĉi tiun komandon sen instrukcioj!
Kiam vi elektas la deziratan eron, anstataŭ menuo, aperas sciigo pri la komenco de la testo, por ke senpaciencaj uzantoj ne rulu nian teston 100500 XNUMX fojojn:
Depende de la elektita menuero, specifa testo estas lanĉita de nia reto, nome de la maŝino, kie loĝas la bot (jmeter estas antaŭ-agordita tie, la necesaj testoj troviĝas...) aŭ rekte de la datumcentro (de preta maŝino apud la aplikaĵo), por ekskludi retajn konektojn dum testado de prokrastoj, aŭ redukti ilin al minimumo.
Post kompletigi la teston kaj ricevi la protokolon, la roboto analizas ĝin kaj produktas la rezulton en "hom-legebla" formo:
Kolekto de metrikoj
La funkcieco alvenis kaj interesitaj projektestroj ricevis tian funkcion por siaj regionoj. Kaj unu kompata Projektestro diris: "Mi volas havi tempostatistikojn!" Iu el CIT diris al ŝi, ke estus oportune kontroli ĉion ĉi en Zabbix. Zabbix, do Zabbix...
Mi pensis, ke mi bezonas prepari por la neceso reprodukti la solvon... Mi metis la ideon en docker-ujo. En la ujo, jmeter estas lanĉita laŭ horaro (unufoje ĉiujn 10 minutojn), metas la protokolon en certan lokon, php analizas ĝin kaj montras la necesajn datumojn en la formo de retpaĝo. Zabbix, uzante la ŝlosilon web.page.get, ricevas ĉi tiun paĝon, regule elektas la necesajn datumojn por certaj dependaj elementoj kaj konstruas grafikaĵon.
Mi pensas, ke ĝi rezultis ne malbona. Observante la grafeon, ni unue vidas la proksimuman rapidecon de la aplikaĵo, kaj se pintoj estas detektitaj sur la grafeo, ni scias proksimume kie estas la "ŝtopilo". Ĝi estas simpla. Ĝis nun ĝi montriĝis postulata nur por unu regiono, sed mi pretas reprodukti ĝin por interesitoj.
Disvolviĝo de aplikaĵo
Statistikoj pri similaj taskoj naskis lastatempe pli da ideoj por simpligi kaj faciligi laboron. En iuj projektoj, en aplikaĵserviloj, necesas instali ŝlosilajn ujojn de Crypto Pro, estas multaj el ili, kaj la cifereca subskribo eksvalidiĝas kun la tempo. Foje 2 taskoj alvenas tage. Sed mi konsideris nesekura uzi roboton por ĉi tiuj celoj kaj decidis, ke mi kreos la funkciojn rekte en la aplikaĵo. Nature kun rajtigo kaj kontrolado de alirrajtoj. Se vi havas la necesajn privilegiojn, plia menuero estos disponebla por labori kun ciferecaj subskriboj, instalo, forigo, vidi informojn, ktp. La funkcio estas nuntempe evoluanta. Kiel evidentiĝis, ĉi tio ne estas tre malfacila, vi nur bezonas iomete legi la ekzistantajn instrukciojn, rigardi kodekzemplojn, demandi kolegojn pli spertajn en evoluo, kaj poste fari ĝin. Dum la esplorprocezo, ideoj aperis por aldoni al la aplikaĵo. Mi ne faros napoleonajn planojn - estas evoluo, ĉiu zorgu pri siaj propraj aferoj. Sed kvankam ĝi estas interesa, mi mem faras ĝin.
Planoj
Kiel mi diris, multaj malsamaj ideoj naskiĝis por uzi nian roboton kaj ne nur - ĝenerale, ni diru, ideoj por "aŭtomatigaj punktoj", multaj el ili estis forgesitaj, ĉar mi ne havis tempon por skribi ilin. Nun mi provas noti ĉion, kio venas al la menso, kaj mi rekomendas, ke aliaj faru la samon.
Sed Alexey ne forgesas doni siajn dezirojn. El la plej nova:
/kill_sql SQL_ID — mortigu ĉiujn sesiojn kun ĉi tiu SQL_ID-peto
/mortig_bloko - mortigu la radikblokan sesion
/montri_ilin — montru bildon de EM-agado
Li estas ruza ulo, li volas kudri DBA de sia telefono =)
Tiel ni laboras por la profito de la Patrujo!
Kiel vi liberigas vin de rutinaj kaj neinteresaj taskoj?
Mi esperas, ke la legado montriĝis interesa, kaj eble eĉ utila al iu, kaj mi ne havis tempon por enuigi la leganton... Bonŝancon al ni ĉiuj.
fonto: www.habr.com