Oleme mõelnud jälgimissüsteemi loomisele juba tootemeeskondade kujunemise etapis. Sai selgeks, et meie ala — hooldus — ei puutu nende meeskondadega absoluutselt kokku. Miks see nii on?
Asi on selles, et kõik meie meeskonnad on üles ehitatud üksikute infotehnoloogiliste süsteemide, mikroteenuste ja fassaadide ümber, mistõttu nad ei näe süsteemi üldist terviseseisundit. Näiteks võivad nad mitte teada, kuidas mõni väike osa sügavates tagumise poole süsteemides mõjutab fassaadi osa. Nende huvid on piiratud süsteemidega, millega nende süsteem on integreeritud. Kui meeskond ja tema teenus A ei ole praktiliselt seotud teenusega B, siis on see teenus meeskonnale peaaegu nähtamatu.
Meie meeskond töötab omalt poolt süsteemidega, mis on omavahel tugevalt integreeritud: nende vahel on palju seoseid, see on väga suur infrastruktuur. Ja kõik need süsteemid (mida meil on, muide, tohutult palju) määravad internetipoe toimimise.
Nii et meie osakond ei kuulu ühegi meeskonna hulka, vaid paikneb veidi kõrvale. Kogu selle loo kontekstis on meie ülesanne mõista tervikuna, kuidas toimivad infosisüsteemid, nende funktsionaalsus, integratsioonid, tarkvara, võrk, riistvara ning kuidas kõik see omavahel seotud on.
Platvorm, millel meie veebipoed tegutsevad, näeb välja selline:
- front
- middle-office
- back-office
Kuigi me tahaksime, et kõik süsteemid töötaksid sujuvalt ja veatult, ei juhtu see kunagi. Asi on taas süsteemide ja integratsioonide hulgast — meie puhul on mõningad intsidentid paratamatud, hoolimata testimise kvaliteedist. Probleem võib esineda nii üheainsa süsteemi sees kui ka nende integratsioonide osas. Seetõttu tuleb kogu platvormi staatust jälgida terviklikult, mitte ainult mõne üksiku osa.
Ideaalis tuleb kogu platvormi tervise jälgimist automatiseerida. Seetõttu oleme jõudnud järeldusele, et monitooring on selle protsessi vältimatu osa. Alguses oli see rajatud vaid esiosale, samas omasid ja omavad võrguinfrastruktuuri, tarkvara- ja riistvaraadministraatorid oma monitooringusüsteeme erinevatel tasanditel. Need inimesed jälgisid monitooringut vaid oma tasemel, mistõttu ei olnud kellelgi ka terviklikku arusaama.
Näiteks, kui virtuaalmasin on kokku kukkunud, teab sellest enamasti vaid hardware'i ja virtuaalmasina eest vastutav administraator. Eesrind töötab sellistel juhtudel välja vaid rakenduse kokkuvarisemise fakti, kuid tal ei ole andmeid virtuaalmasina kokkuvarisemise kohta. Administrator võib teada, kes on tellija, ja omada umbkaudset ettekujutust, mis just sel hetkel sellel virtuaalmasinal töötab, eeldusel et tegemist on suure projektiga. Väikeste projektide kohta tal tõenäoliselt teavet ei ole. Igatahes peab administraator minema omaniku juurde ja küsima, mis sellel masinal oli, mida tuleb taastada ja mida muuta. Kui midagi tõeliselt tõsist katki läheb, algab ringjooks — sest keegi ei ole süsteemi tervikuna näinud.
Lõppkokkuvõttes mõjutavad sellised killustatud lood kogu eesrinda, kasutajaid ja meie põhiäritegevust — internetimüüki. Kuna me ei kuulu meeskondadesse ja tegeleme kõigi e-kaubanduse rakendustega internetipoe raames, oleme endale võtnud ülesande luua terviklik jälgimissüsteem e-kaubanduse platvormi jaoks.
Süsteemi struktuur ja teknoloogia
Alustuseks tõmbasime välja mitmeid jälgimiskihti, mille põhjal pidime koguma mõõdikud. Kõik see tuli kokku viia, ja me tegime selle esimeses etapis. Praegu tegeleme selle etapiga, et viia ellu kõrgekvaliteetset mõõdikutega kogumist kõigis meie kihtides, et luua korrelatsioon ja mõista, kuidas süsteemid omavahel mõjutavad.
Kohapealsete rakenduste käivitamise algfaasis kompleksse jälgimise puudumine (kuna alustasime selle loomist, kui enamik süsteeme oli juba kasutuses) on põhjustanud suure tehnilise võla tekkimise kogu platvormi jälgimise seadistamise osas. Me ei saanud endale lubada keskenduda mingi üksiku teabe süsteemi jälgimise seadistamisele, pidime üksikasjalikult töötama selle jaoks, kuna muud süsteemid jääksid mingiks ajaks ilma jälgimiseta. Selle probleemi lahendamiseks määrasime kõige olulisemate mõõdikute loendi informatsioonisüsteemi seisundi hindamiseks kihtide kaupa ja alustasime selle rakendamist.
Seetõttu otsustasime elevandi süüa tükkide kaupa.
Meie süsteem koosneb järgmistest:
- riistvarast;
- operatsioonisüsteemist;
- tarkvarast;
- Rakenduse jälgimise UI-osa;
- ärimeetrikad;
- integratsiooni rakendused;
- teabe turvalisus;
- võrgud;
- koormuse tasakaalustaja.
Selle süsteemi keskmes on jälgimise protsess ise. Et paremini mõista kogu süsteemi seisukorda, tuleb teada, mis toimub rakendustega kõigil neil kihtidel ja laiemas rakenduste kogumis.
Nii et, räägime kuhjast.
Kasutame avatud lähtekoodiga tarkvara. Meie keskmes on Zabbix, mida kasutame peamiselt häirete süsteemina. Kõigile on teada, et see sobib ideaalselt infrastruktuuri jälgimiseks. Mida siin silmas peetakse? Just madala taseme mõõdikud, mis on olemas igal ettevõttel, kellel on oma andmekeskus (ja Sportmasteri oma andmekeskused) — serveri temperatuur, mälu seisund, RAID-olek, võrgu seadmete mõõdikud.
Oleme integreerinud Zabbixi Telegrami ja Microsoft Teamsiga, mis on aktiivselt kasutusel meeskondades. Zabbix katab reaalse võrgu, riistvara ja osaliselt tarkvara kihi, kuid see ei ole imeravim. Rikastame neid andmeid teiste teenuste abiga. Näiteks riistvara tasemel ühendame otse API kaudu meie virtualiseerimissüsteemiga ja toome andmed välja.
Veelgi rohkem. Peale Zabbixi kasutame Prometheust, mis võimaldab jälgida dünaamilise keskkonna rakenduse mõõdikuid. See tähendab, et saame rakenduse mõõdikuid saada HTTP lõpp-punkti kaudu ja ei pea muretsema selle üle, milliseid mõõdikuid sinna laadida ja milliseid mitte. Nende andmete põhjal saab töötada välja analüütilisi päringuid.
Ülejäänud tasandite andmeallikad, näiteks ärimõõdikud, jagunevad meil kolme ossa.
Esiteks, need on välishariduslikud ärisüsteemid, nagu Google Analytics, kus kogume mõõdikuid logidest. Nendest saame andmeid aktiivsete kasutajate, konversioonide ja kõigi muude äriga seotud asjade kohta. Teiseks, see on UI-monitooringusüsteem. Sellest peaksime rääkima põhjalikumalt.
Kord, kui me alustasime manuaalsest testimisest, arenes see välja funktsionaalsetesse ja integreerimistestidesse. Nendest saime me monitooringu, jättes alles ainult põhifunktsionaalsuse ja keskendudes markeritele, mis on võimalikult stabiilsed ja ei muutu aja jooksul sageli.
Uus meeskonna struktuur eeldab, et kogu rakendustega seotud tegevus koondub toote meeskondadesse, mistõttu oleme puhta testimisega lõpetanud. Selle asemel oleme loonud kasutajaliidese monitooringu, mis on kirjutatud Java, Seleniumi ja Jenkinsiga (kasutatakse käitamise ja raportite genereerimise süsteemina).
Meil oli palju teste, kuid lõpuks otsustasime keskenduda kõrgtasemelisele mõõdikule. Kui meil on palju spetsiifilisi teste, on andmete ajakohasena hoidmine keeruline. Iga järgmine versioon purustab kogu süsteemi oluliselt ning me saame ainult selle parandamisega tegeleda. Seetõttu keskendume täiesti fundamentaalsetele asjadele, mis harva muutuvad, ja monitooring teeme ainult nendele.
Lõpuks, kolmandaks, on andmeallikaks tsentraliseeritud logimissüsteem. Logide jaoks kasutame Elastic Stack'i, mille kaudu saame need andmed viia meie ärimeetrite jälgimise süsteemi. Lisaks sellele töötab meie oma Monitoring API teenus, mis on kirjutatud Pythonis ja küsib API kaudu mistahes teenuseid, et tuua Zabbixisse nende andmed.
Veel üks hädavajalik jälgimise element on visualiseerimine. Meie visualiseerimine on rajatud Grafanale. Teiste visualiseerimissüsteemide seas eristub see selle poolest, et armatuurlaud suudab visualiseerida mõõdikuid erinevatest andmeallikatest. Saame koguda ülevaatlikud mõõdikud e-poest, näiteks viimase tunni jooksul tehtud tellimuste arv andmebaasist, operatsioonisüsteemi jõudluse mõõdikud, millega see e-pood töötab, Zabbixist ja rakenduse instantside mõõdikud Prometheusest. Ja kõik see on ühel armatuurlaud. Selge ja kergesti arusaadav.
Rõhutan, et turvalisuse osas — me täiustame praegu süsteemi, mille hiljem integreerime globaalsete jälgimissüsteemidega. Minu arvates on peamised probleemid, millega e-kaubanduse valdkond infojulgeoleku osas silmitsi seisab, seotud robotite, andmete kogumise ja bruteforce'i rünnakutega. Sellega tuleb pidevalt silma peal hoida, kuna need võivad kriitiliselt mõjutada meie rakenduste toimimist ning ärireputatsiooni. Meie valitud tehnoloogiaga katame need väljakutsed edukalt.
Veel tähtsam punkt on see, et rakenduste taseme mõõtmine toimub Prometheuse kaudu. Meie süsteem on integreeritud ka Zabbixiga. Lisaks on meil sitespeed, teenus, mis võimaldab meil jälgida selliseid parameetreid nagu meie lehe laadimiskiirus, pudelikaelad, lehe renderdamine, skriptide laadimine jne, ja see on samuti API kaudu integreeritud. Seega kogume mõõdikud Zabbixis ja saadame häireid samuti sealt. Kõik häired saadetakse praegu põhiliste edastusmeetoditega (praegu on see email ja telegramm, samuti oleme hiljuti lisanud MS Teamsi). Plaan on arendada häirete süsteem selliseks, et nutikad botid töötaksid teenusena ja pakuksid jälgimise teavet kõigile soovijatele tootmismeeskondadele.
Meie jaoks on olulised mõõdikud mitte ainult eraldi infosisüsteemide, vaid ka kogu infrastruktuuri üldised mõõdikud, mida rakendused kasutavad: klastrid füüsilise serveri, kus töötavad virtuaalmasinad, koormuse tasakaalustajad, Network Load Balancerid, ise võrk, sidekanalite kasutamine. Lisaks meie enda andmekeskuste mõõdikud (meil on neid mitu ja infrastruktuur on üsna suur).
Meie jälgimissüsteemi eeliseks on see, et selle abil saame jälgida kõigi süsteemide tööolekut, hinnata nende omavahelist mõju ja mõju üldistele ressurssidele. Lõppkokkuvõttes võimaldab see planeerida ressursse, mis on samuti meie vastutusala. Me haldame serveriressursse - e-kaubanduse raames oleme vastutavad uue seadme sissetoomise ja väljastamise ning olemasolevate seadmete uuendamise eest. Igal aastal plaanivad meeskonnad uusi projekte, arendavad oma süsteeme ja meie jaoks on oluline tagada, et nad saaksid vajalikke ressursse.
Metrike abil näeme meie infosüsteemide ressursi kasutamise suundumusi. Juba nende põhjal saame midagi planeerida. Virtualiseerimise tasandil kogume andmeid ja näeme teavet kättesaadavate ressursside kohta andmekeskustes. Andmekeskuse sees on nähtav nii ressursside tarbimine kui ka tegelik jaotus. See puudutab nii iseseisvaid serve kui ka virtuaalmasinaid ja füüsiliste serverite klastreid, millel kõik need virtuaalmasinad sujuvalt töötavad.
Perspektiivid
Meil on nüüd süsteemi peamine tuum valmis, kuid on veel piisavalt aspekte, mille kallal tuleb tööd teha. Vähemalt vajab tähelepanu teabe turvakiht, kuid oluline on ka jõuda võrku, arendada häirete süsteemi ja lahendada korrelatsiooni küsimus. Meil on palju kihte ja süsteeme, igas kihis on veel palju näitajaid. Tulemuseks on matrjoška, mis on veelgi keerukam.
Meie ülesanne on lõpuks luua õiged häired. Näiteks, kui on probleem riistvaraga, näiteks virtuaalmasinaga, kus asus oluline rakendus ja teenus polnud mingil moel reserveeritud. Saame teada, et virtuaalmasin on välja langenud. Seejärel teavitatakse äri näitajatest: kasutajad on kuskile kadunud, konversioone ei ole, kasutajaliides ei ole kergesti ligipääsetav, samuti on tarkvara ja teenused välja langenud.
Sellise olukorra puhul saame me häirete põhjal spam'i, mis ei sobitu korraliku jälgimissüsteemi formaati. Tõuseb küsimus seose kohta. Seetõttu peaks meie jälgimissüsteem ideaalis ütlema: „Kallid, teie füüsiline masin on surnud ja koos sellega ka see rakendus ja sellised näitajad“, ühe häire abil, selle asemel et meid kiusataks sajaga häiretega. Ta peaks teavitama peamisest — põhjusest, mis aitab probleemide kiirelt lahendada nende lokaliseerimise kaudu.
Meie teavitussüsteem ja häirete käitlemine on rajatud ööpäevaringsele abitelefonile. Kõik häired, mida peame hädavajalikuks ja mis sisalduvad kontrollnimekirjas, edastatakse sinna. Iga häire peab kindlasti sisaldama kirjeldust: mis juhtus, mida see tegelikult tähendab, millele see mõju avaldab. Lisaks link armatuurlaudadele ja juhised, mida sellisel juhul teha.
Need on kõik nõuded häirete ehitusele. Edasi võib olukord areneda kahes suunas — kas probleem on olemas ja seda tuleb lahendada, või on juhtunud tõrge jälgimissüsteemis. Igatahes tuleb minna ja asja uurida.
Praegusel hetkel saame keskmiselt päevas umbes sada hoiatust, arvestades, et hoiatused ei ole veel korralikult kooskõlastatud. Kui on vajalik tehniline töö ja me midagi sunniviisiliselt välja lülitame, suureneb nende arv mitu korda.
Lisaks meie kasutatavate süsteemide jälgimisele ja oluliste mõõdikute kogumisele, mis meie arvates on tähtsad, võimaldab jälgimissüsteem koguda andmeid tootmismeeskondade jaoks. Need võivad mõjutada mõõdikute koostist meie jälgitavates infosüsteemides.
Meie kolleeg võib tulla ja paluda lisada mõne mõõdiku, mis osutub kasulikuks nii meie jaoks kui ka meeskonna jaoks. Või näiteks võib meeskonnale jääda puudu neist põhimõõdikest, mis meil olemas on, nad vajavad midagi spetsiifilisemat. Grafanas loome iga meeskonna jaoks ruumi ja anname adminõigused. Samuti, kui meeskond vajab armatuurlaudu, kuid nad ei oska seda teha, aitame neid.
Kuna oleme väärtuste loomise voo väljas, nende väljalaskmisel ja planeerimisel, jõuame järk-järgult olukorda, kus kõik süsteemide väljalasked on sujuvad ja neid saab igapäevaselt tutvustada ilma meiega kooskõlastamata. Meie jaoks on oluline jälgida neid väljalaseid, kuna need võivad potentsiaalselt mõjutada rakenduse toimimist ja midagi rikkuda, mis on kriitiline. Väljalaste haldamiseks kasutame Bamboo't, kust saame API kaudu andmeid ja näeme, millised väljalasked on millistes infosüsteemides toimunud ja nende olekut. Ja kõige tähtsam on — millisel ajal. Väljalaskemarkerid seome peamiste kriitiliste metrikatega, mis on visuaalselt üsna kõnekas probleemide korral.
Nii saame näha korrelatsiooni uute väljalaskete ja tekkivate probleemide vahel. Peamine idee on mõista, kuidas süsteem töötab kõigil tasanditel, kiiresti probleemi lokaliseerida ja sama kiiresti see lahendada. Sest sageli kulub kõige rohkem aega mitte probleemi lahendamisele, vaid põhjuse leidmisele.
Ja tulevikus soovime keskenduda proaktiivsusele. Ideaalne oleks eelnevalt teada saada lähenevast probleemist, mitte pärast, et tegeleda selle ennetamisega, mitte lahendamisega. Mõnikord juhtub valehäireid jälgimissüsteemis nii inimlike eksimuste kui ka rakenduse muudatuste tõttu. Me tegeleme selle küsimusega, viimistleme seda ning püüame enne jälgimissüsteemiga manipuleerimist hoiatada kasutajaid, kes kasutavad seda koos meiega, või viia need tegevused läbi hooldusakna.
Nii et süsteem on käivitatud ja töötab edukalt alates kevade algusest… ning toob vägagi reaalse kasumi. Loomulikult ei ole see lõplik versioon, me kavandame veel palju kasulikke funktsioone. Kuid praegu, arvestades sellist suurt hulka integreerimisi ja rakendusi, ei saa jälgimise automatiseerimisest tõeliselt puudu olla.
Kui te ka jälgite suuri projekte, kus on tõsine arv integreerimisi — kirjutage kommentaaridesse, millist hõbedast kuulikut selleks leidsid.
Allikas: habr.com
