O vzpostavitvi sistema spremljanja smo razmišljali že v fazi oblikovanja produktnih ekip. Postalo je jasno, da naš posel - izkoriščanje - ne sodi v te ekipe. Zakaj?
Dejstvo je, da so vse naše ekipe zgrajene okoli posameznih informacijskih sistemov, mikrostoritev in front, zato ekipe ne vidijo splošnega zdravja celotnega sistema kot celote. Na primer, morda ne vedo, kako majhen del v globokem ozadju vpliva na sprednji del. Njihovo področje zanimanja je omejeno na sisteme, s katerimi je njihov sistem integriran. Če ekipa in njena storitev A nimata skoraj nobene povezave s storitvijo B, potem je taka storitev ekipi skoraj nevidna.
Naša ekipa pa dela s sistemi, ki so med seboj zelo močno povezani: med njimi je veliko povezav, to je zelo velika infrastruktura. In od vseh teh sistemov (ki jih imamo, mimogrede, ogromno) je odvisno delovanje spletne trgovine.
Tako se izkaže, da naš oddelek ne pripada nobeni ekipi, ampak se nahaja malo ob strani. V vsej tej zgodbi je naša naloga celovito razumeti delovanje informacijskih sistemov, njihove funkcionalnosti, integracije, programsko opremo, omrežje, strojno opremo in kako je vse to med seboj povezano.
Platforma, na kateri delujejo naše spletne trgovine, izgleda takole:
- spredaj
- srednji urad
- back office
Kakorkoli bi si želeli, se ne zgodi, da vsi sistemi delujejo gladko in brezhibno. Bistvo je spet število sistemov in integracij - pri nečem, kot je naš, so nekateri incidenti neizogibni, kljub kakovosti testiranja. Poleg tega tako znotraj ločenega sistema kot v smislu njihove integracije. In celovito morate spremljati stanje celotne platforme in ne le katerega koli njenega posameznega dela.
V idealnem primeru bi moralo biti spremljanje zdravja na celotni platformi avtomatizirano. In prišli smo do spremljanja kot neizogibnega dela tega procesa. Sprva je bil zgrajen le za prvi del, medtem ko so omrežni specialisti, skrbniki programske in strojne opreme imeli in še imajo svoje sisteme za nadziranje po slojih. Vsi ti ljudje so spremljali spremljanje le na svojem nivoju, tudi nihče ni imel celovitega razumevanja.
Na primer, če se virtualni stroj zruši, v večini primerov za to ve le skrbnik, ki je odgovoren za strojno opremo in virtualni stroj. V takih primerih je prva ekipa videla samo dejstvo sesutja aplikacije, ni pa imela podatkov o sesutju virtualnega stroja. In skrbnik lahko ve, kdo je stranka, in ima približno predstavo o tem, kaj se trenutno izvaja na tem virtualnem stroju, pod pogojem, da gre za nekakšen velik projekt. Najverjetneje ne ve za male. V vsakem primeru mora skrbnik iti do lastnika in vprašati, kaj je bilo na tem stroju, kaj je treba obnoviti in kaj spremeniti. In če se je kaj res resno pokvarilo, so začeli tekati v krogu – saj nihče ni videl sistema kot celote.
Navsezadnje takšne različne zgodbe vplivajo na celotno frontend, uporabnike in našo osnovno poslovno funkcijo – spletno prodajo. Ker nismo del ekipe, ampak se ukvarjamo z delovanjem vseh ecommerce aplikacij v okviru spletne trgovine, smo prevzeli nalogo izdelave celovitega sistema spremljanja ecommerce platforme.
Sistemska struktura in sklad
Začeli smo z identifikacijo več nadzornih ravni za naše sisteme, znotraj katerih bi morali zbirati metrike. In vse to je bilo treba združiti, kar smo naredili na prvi stopnji. Zdaj na tej stopnji zaključujemo najkakovostnejšo zbirko meritev v vseh naših slojih, da bi zgradili korelacijo in razumeli, kako sistemi vplivajo drug na drugega.
Pomanjkanje celovitega spremljanja v začetnih fazah zagona aplikacije (saj smo jo začeli graditi, ko je bila večina sistemov v produkciji) je privedlo do tega, da smo imeli velik tehnični zadolženost za vzpostavitev spremljanja celotne platforme. Nismo si mogli privoščiti, da bi se osredotočili na vzpostavitev spremljanja enega IS in podrobno izdelavo spremljanja le-tega, saj bi ostali sistemi nekaj časa ostali brez spremljanja. Za rešitev tega problema smo identificirali seznam najbolj potrebnih metrik za ocenjevanje stanja informacijskega sistema po slojih in ga začeli izvajati.
Zato so se odločili, da bodo slona pojedli po delih.
Naš sistem sestavljajo:
- strojna oprema;
- operacijski sistem;
- programska oprema;
- deli uporabniškega vmesnika v aplikaciji za spremljanje;
- poslovne metrike;
- integracijske aplikacije;
- varnost informacij;
- omrežja;
- izravnavalec prometa.
V središču tega sistema je sam nadzor. Da bi na splošno razumeli stanje celotnega sistema, morate vedeti, kaj se dogaja z aplikacijami na vseh teh ravneh in v celotnem nizu aplikacij.
Torej, glede sklada.
Uporabljamo odprtokodno programsko opremo. V središču imamo Zabbix, ki ga uporabljamo predvsem kot sistem za opozarjanje. Vsi vedo, da je idealen za spremljanje infrastrukture. Kaj to pomeni? Točno tiste nizkonivojske metrike, ki jih ima vsako podjetje, ki vzdržuje svoj podatkovni center (in Sportmaster ima svoje podatkovne centre) - temperatura strežnika, stanje pomnilnika, raid, metrika omrežnih naprav.
Zabbix smo integrirali z messengerjem Telegram in Microsoft Teams, ki se aktivno uporabljata v timih. Zabbix pokriva plast dejanskega omrežja, strojne opreme in nekaj programske opreme, vendar ni rešitev. Te podatke obogatimo iz nekaterih drugih storitev. Na ravni strojne opreme se na primer neposredno povežemo prek API-ja z našim virtualizacijskim sistemom in zbiramo podatke.
Kaj drugega. Poleg Zabbixa uporabljamo Prometheus, ki nam omogoča spremljanje metrik v aplikaciji dinamičnega okolja. To pomeni, da lahko prejemamo metrike aplikacije prek končne točke HTTP in ne skrbimo, katere metrike naložiti vanjo in katere ne. Na podlagi teh podatkov je mogoče razviti analitične poizvedbe.
Viri podatkov za druge plasti, na primer poslovne metrike, so razdeljeni na tri komponente.
Prvič, to so zunanji poslovni sistemi, Google Analytics, zbiramo metrike iz dnevnikov. Od njih dobimo podatke o aktivnih uporabnikih, konverzijah in vsem ostalem, kar je povezano s poslom. Drugič, to je sistem za spremljanje uporabniškega vmesnika. Opisati ga je treba podrobneje.
Nekoč smo začeli z ročnim testiranjem, ki je preraslo v avtomatsko testiranje funkcionalnosti in integracij. Iz tega smo naredili spremljanje, pri čemer smo pustili samo glavno funkcionalnost in se zanašali na markerje, ki so čim bolj stabilni in se skozi čas ne spreminjajo pogosto.
Nova struktura ekipe pomeni, da so vse aplikacijske aktivnosti omejene na produktne ekipe, zato smo prenehali izvajati čisto testiranje. Namesto tega smo naredili nadzor uporabniškega vmesnika iz testov, napisanih v Javi, Selenu in Jenkinsu (ki se uporablja kot sistem za zagon in ustvarjanje poročil).
Imeli smo veliko testov, a na koncu smo se odločili, da gremo na glavno cesto, metriko najvišje ravni. In če imamo veliko specifičnih testov, bo podatke težko posodabljati. Vsaka naslednja izdaja bo močno pokvarila celoten sistem in vse, kar bomo storili, je, da ga popravimo. Zato smo se osredotočili na zelo temeljne stvari, ki se redko spreminjajo in jih le spremljamo.
Nazadnje, tretjič, vir podatkov je centraliziran sistem beleženja. Za dnevnike uporabljamo Elastic Stack, nato pa lahko te podatke potegnemo v naš nadzorni sistem za poslovne meritve. Poleg vsega tega imamo lastno storitev Monitoring API, napisano v Pythonu, ki poizveduje po kateri koli storitvi preko API-ja in iz njih zbira podatke v Zabbix.
Drug nepogrešljiv atribut spremljanja je vizualizacija. Naš temelji na Grafanu. Med drugimi vizualizacijskimi sistemi izstopa po tem, da omogoča vizualizacijo meritev iz različnih podatkovnih virov na nadzorni plošči. Za spletno trgovino lahko zbiramo metrike najvišje ravni, na primer število naročil, oddanih v zadnji uri iz DBMS, metrike zmogljivosti za operacijski sistem, v katerem se izvaja ta spletna trgovina, iz Zabbixa, in metrike za primerke te aplikacije od Prometeja. In vse to bo na eni armaturni plošči. Jasno in dostopno.
Naj povem glede varnosti - trenutno končujemo sistem, ki ga bomo kasneje integrirali v globalni nadzorni sistem. Po mojem mnenju so glavne težave, s katerimi se srečuje e-trgovina na področju informacijske varnosti, povezane z boti, razčlenjevalniki in surovo silo. Na to moramo biti pozorni, saj lahko vse to kritično vpliva tako na delovanje naših aplikacij kot tudi na naš ugled s poslovnega vidika. In z izbranim skladom te naloge uspešno pokrivamo.
Druga pomembna točka je, da aplikacijski sloj sestavi Prometheus. Tudi sam je integriran z Zabbixom. Imamo tudi sitespeed, storitev, ki nam omogoča ogled parametrov, kot so hitrost nalaganja naše strani, ozka grla, upodabljanje strani, nalaganje skriptov itd., prav tako je integriran API. Tako se naše meritve zbirajo v Zabbixu in v skladu s tem od tam tudi opozarjamo. Vsa opozorila se trenutno pošiljajo na glavne načine pošiljanja (zaenkrat sta to e-pošta in telegram, nedavno je bil povezan tudi MS Teams). Obstajajo načrti za nadgradnjo opozarjanja na takšno stanje, da pametni boti delujejo kot storitev in zagotavljajo informacije o spremljanju vsem zainteresiranim produktnim ekipam.
Za nas metrike niso pomembne le za posamezne informacijske sisteme, ampak tudi splošne metrike za celotno infrastrukturo, ki jo aplikacije uporabljajo: grozdi fizičnih strežnikov, na katerih tečejo virtualni stroji, izravnalniki prometa, izravnalniki obremenitve omrežja, samo omrežje, izkoriščenost komunikacijskih kanalov. . Plus meritve za lastne podatkovne centre (imamo jih več in infrastruktura je precej velika).
Prednosti našega nadzornega sistema so v tem, da z njegovo pomočjo vidimo zdravstveno stanje vseh sistemov in lahko ocenimo njihov vpliv drug na drugega in na skupne vire. In navsezadnje nam omogoča, da se vključimo v načrtovanje virov, kar je tudi naša odgovornost. Upravljamo strežniške vire - bazen v okviru e-poslovanja, naročamo in razgrajujemo novo opremo, dokupujemo novo opremo, izvajamo revizijo izkoriščenosti virov itd. Ekipe vsako leto načrtujejo nove projekte, razvijajo svoje sisteme in pomembno nam je, da jim zagotovimo vire.
In s pomočjo meritev vidimo trend porabe virov v naših informacijskih sistemih. In na njihovi podlagi lahko nekaj načrtujemo. Na nivoju virtualizacije zbiramo podatke in vidimo podatke o razpoložljivi količini virov po podatkovnih centrih. In že znotraj podatkovnega centra lahko vidite recikliranje, dejansko distribucijo in porabo virov. Še več, tako s samostojnimi strežniki kot z virtualnimi stroji in grozdi fizičnih strežnikov, na katerih se vsi ti virtualni stroji živahno vrtijo.
Obeti
Zdaj imamo pripravljeno jedro sistema kot celote, vendar je treba še veliko stvari dodelati. To je najmanj informacijska varnostna plast, pomembno pa je tudi doseči omrežje, razviti opozarjanje in rešiti vprašanje korelacije. Imamo veliko plasti in sistemov in na vsaki plasti je veliko več meritev. Izkazalo se je, da je matryoshka do stopnje matryoshka.
Naša naloga je, da na koncu naredimo prava opozorila. Na primer, če je prišlo do težave s strojno opremo, spet z navideznim strojem, in obstaja pomembna aplikacija, storitev pa ni bila na noben način varnostno kopirana. Ugotovimo, da je virtualni stroj umrl. Potem vas bodo opozorile poslovne metrike: uporabniki so nekam izginili, konverzije ni, uporabniški vmesnik v vmesniku ni na voljo, umrle so tudi programska oprema in storitve.
V tem primeru bomo prejemali neželeno pošto iz opozoril in to ne sodi več v obliko ustreznega nadzornega sistema. Postavlja se vprašanje korelacije. Zato bi v idealnem primeru moral naš nadzorni sistem reči: "Fantje, vaš fizični stroj je umrl, skupaj z njim pa ta aplikacija in te metrike," s pomočjo enega opozorila, namesto da nas besno zasipa s stotimi opozorili. Poročati mora o glavni stvari - vzroku, ki pomaga hitro odpraviti težavo zaradi svoje lokalizacije.
Naš sistem obveščanja in obdelava opozoril temelji na XNUMX-urni storitvi vroče linije. Tja se pošljejo vsa opozorila, ki veljajo za obvezna in so vključena v kontrolni seznam. Vsako opozorilo mora imeti opis: kaj se je zgodilo, kaj dejansko pomeni, na kaj vpliva. In tudi povezava do nadzorne plošče in navodila, kaj storiti v tem primeru.
To je vse o zahtevah za izdelavo opozorila. Takrat se lahko situacija razvije v dve smeri - ali obstaja težava in jo je treba rešiti, ali pa je prišlo do okvare v sistemu spremljanja. Toda v vsakem primeru morate iti in ugotoviti.
V povprečju zdaj prejmemo okoli sto opozoril na dan, upoštevajoč, da korelacija opozoril še ni pravilno nastavljena. In če moramo opraviti tehnično delo in nekaj prisilno izklopimo, se njihovo število znatno poveča.
Poleg spremljanja sistemov, ki jih upravljamo, in zbiranja metrik, ki se z naše strani zdijo pomembne, nam nadzorni sistem omogoča zbiranje podatkov za produktne ekipe. Lahko vplivajo na sestavo metrik v informacijskih sistemih, ki jih spremljamo.
Naš sodelavec lahko pride in prosi, da doda kakšno metriko, ki bo uporabna tako za nas kot za ekipo. Ali pa na primer ekipa morda nima dovolj osnovnih meritev, ki jih imamo; slediti morajo nekaterim specifičnim. V Grafani ustvarimo prostor za vsako ekipo in podelimo skrbniške pravice. Tudi, če ekipa potrebuje nadzorne plošče, pa sama tega ne more/ne zna narediti, ji pomagamo.
Ker smo izven toka ustvarjanja vrednosti ekipe, njihovih objav in načrtovanja, postopoma prihajamo do zaključka, da so izdaje vseh sistemov brezhibne in jih je mogoče uvajati dnevno brez usklajevanja z nami. In za nas je pomembno, da spremljamo te izdaje, ker lahko potencialno vplivajo na delovanje aplikacije in kaj pokvarijo, kar je ključnega pomena. Za upravljanje objav uporabljamo Bamboo, od koder preko API-ja prejemamo podatke in lahko vidimo, katere objave so bile izdane v katerem informacijskem sistemu in njihov status. In najpomembnejše je, ob kateri uri. Na glavne kritične metrike prekrivamo oznake izdaje, kar je vizualno zelo indikativno v primeru težav.
Tako lahko vidimo korelacijo med novimi izdajami in nastajajočimi težavami. Glavna ideja je razumeti, kako sistem deluje na vseh ravneh, hitro lokalizirati težavo in jo prav tako hitro odpraviti. Navsezadnje se pogosto zgodi, da največ časa ne vzame reševanje problema, temveč iskanje vzroka.
In na tem področju se v prihodnje želimo osredotočiti na proaktivnost. V idealnem primeru bi rad vedel za bližajočo se težavo vnaprej in ne naknadno, da jo lahko preprečim, namesto da bi jo rešil. Včasih pride do lažnih alarmov nadzornega sistema, tako zaradi človeške napake kot zaradi sprememb v aplikaciji.In na tem delamo, odpravljamo napake in na to poskušamo opozoriti uporabnike, ki ga uporabljajo pri nas, pred kakršno koli manipulacijo nadzornega sistema. , ali te dejavnosti izvajajte v tehničnem oknu.
Sistem je torej zagnan in že od začetka pomladi uspešno deluje... in kaže zelo realne dobičke. Seveda to ni njegova končna različica, uvedli bomo še veliko uporabnih funkcij. Toda trenutno, s toliko integracijami in aplikacijami, je avtomatizacija spremljanja res neizogibna.
Če spremljate tudi velike projekte s precejšnjim številom integracij, v komentarje zapišite, katero srebrno kroglo ste našli pri tem.
Vir: www.habr.com