Apie stebėjimo sistemos sukūrimą galvojome formuodami produktų komandas. Tapo aišku, kad mūsų verslas – išnaudojimas – į šias komandas nepatenka. Kodėl taip?
Faktas yra tas, kad visos mūsų komandos yra sukurtos aplink atskiras informacines sistemas, mikropaslaugas ir frontus, todėl komandos nemato visos sistemos kaip visumos bendros būklės. Pavyzdžiui, jie gali nežinoti, kaip tam tikra nedidelė giliosios užpakalinės dalies dalis veikia priekinę dalį. Jų interesų sritis apsiriboja sistemomis, su kuriomis jų sistema yra integruota. Jei komanda ir jos paslauga A beveik neturi ryšio su tarnyba B, tai tokia paslauga komandai yra beveik nematoma.
Mūsų komanda savo ruožtu dirba su sistemomis, kurios yra labai stipriai tarpusavyje integruotos: tarp jų daug jungčių, tai labai didelė infrastruktūra. O internetinės parduotuvės veikimas priklauso nuo visų šių sistemų (kurių, beje, turime labai daug).
Taip išeina, kad mūsų skyrius nepriklauso jokiai komandai, o yra įsikūręs šiek tiek nuošalyje. Visoje šioje istorijoje mūsų užduotis yra visapusiškai suprasti, kaip veikia informacinės sistemos, jų funkcionalumas, integracijos, programinė įranga, tinklas, techninė įranga ir kaip visa tai yra tarpusavyje susiję.
Platforma, kurioje veikia mūsų internetinės parduotuvės, atrodo taip:
- priekio
- vidurinis biuras
- galinis biuras
Kad ir kaip norėtume, nebūna taip, kad visos sistemos veiktų sklandžiai ir nepriekaištingai. Esmė vėlgi yra sistemų ir integracijų skaičius – naudojant kažką panašaus į mūsų, kai kurie incidentai yra neišvengiami, nepaisant testavimo kokybės. Be to, tiek atskiroje sistemoje, tiek jų integracijos prasme. Ir reikia visapusiškai stebėti visos platformos būseną, o ne tik atskirą jos dalį.
Idealiu atveju sveikatos stebėjimas visoje platformoje turėtų būti automatizuotas. Ir mes priėjome prie stebėjimo kaip neišvengiamos šio proceso dalies. Iš pradžių jis buvo sukurtas tik priekinei daliai, o tinklo specialistai, programinės ir techninės įrangos administratoriai turėjo ir tebeturi savo sluoksnio stebėjimo sistemas. Visi šie žmonės stebėjo tik savo lygiu, visapusiško supratimo taip pat niekas neturėjo.
Pavyzdžiui, jei virtuali mašina sugenda, dažniausiai apie tai žino tik administratorius, atsakingas už aparatinę įrangą ir virtualią mašiną. Tokiais atvejais priekinės linijos komanda matė patį programos gedimo faktą, tačiau neturėjo duomenų apie virtualios mašinos gedimą. Ir administratorius gali žinoti, kas yra klientas, ir apytiksliai įsivaizduoti, kas šiuo metu veikia šioje virtualioje mašinoje, jei tai yra kažkoks didelis projektas. Greičiausiai jis nežino apie mažuosius. Bet kokiu atveju administratoriui reikia nueiti pas savininką ir pasiteirauti, kas buvo šioje mašinoje, ką reikia atkurti ir ką keisti. O jei kas nors tikrai rimto sugesdavo, imdavo lakstyti ratais – nes niekas nematė visos sistemos.
Galiausiai tokios skirtingos istorijos paliečia visą sąsają, vartotojus ir pagrindinę mūsų verslo funkciją – pardavimą internetu. Kadangi nesame komandos nariai, bet užsiimame visų elektroninės prekybos programų valdymu kaip internetinės parduotuvės dalis, ėmėmės užduoties sukurti išsamią elektroninės prekybos platformos stebėjimo sistemą.
Sistemos struktūra ir kaminas
Pradėjome nustatydami kelis mūsų sistemų stebėjimo sluoksnius, kuriuose turėtume rinkti metrikas. Ir visa tai reikėjo sujungti, ką mes padarėme pirmajame etape. Dabar šiame etape baigiame rinkti aukščiausios kokybės metrikos rinkinį visuose mūsų sluoksniuose, kad sukurtume ryšį ir suprastume, kaip sistemos veikia viena kitą.
Visapusiško stebėjimo trūkumas pradiniuose programos paleidimo etapuose (nuo tada, kai pradėjome ją kurti, kai dauguma sistemų buvo gaminamos), lėmė tai, kad turėjome didelių techninių skolų, kad būtų galima nustatyti visos platformos stebėjimą. Negalėjome sau leisti susitelkti ties vienos IS stebėjimo nustatymu ir detaliu jos stebėjimu, nes likusios sistemos kurį laiką liktų be stebėjimo. Norėdami išspręsti šią problemą, nustatėme būtiniausių informacinės sistemos būklei įvertinti metrikų sąrašą pagal sluoksnius ir pradėjome jį diegti.
Todėl jie nusprendė dramblį valgyti dalimis.
Mūsų sistemą sudaro:
- aparatinė įranga;
- Operacinė sistema;
- programinė įranga;
- UI dalys stebėjimo programoje;
- verslo metrika;
- integravimo programos;
- informacijos saugumas;
- tinklai;
- eismo balansavimo priemonė.
Šios sistemos centre yra savęs stebėjimas. Norėdami apskritai suprasti visos sistemos būseną, turite žinoti, kas vyksta su programomis visuose šiuose sluoksniuose ir visame programų rinkinyje.
Taigi, apie krūvą.
Mes naudojame atvirojo kodo programinę įrangą. Centre turime „Zabbix“, kurią pirmiausia naudojame kaip įspėjimo sistemą. Visi žino, kad jis idealiai tinka infrastruktūros stebėjimui. Ką tai reiškia? Būtent tos žemo lygio metrikos, kurias turi kiekviena įmonė, kuri prižiūri savo duomenų centrą (o „Sportmaster“ turi savo duomenų centrus) – serverio temperatūra, atminties būsena, reidas, tinklo įrenginių metrika.
Integravome Zabbix su Telegram Messenger ir Microsoft Teams, kurios aktyviai naudojamos komandose. „Zabbix“ apima tikrojo tinklo, aparatinės įrangos ir kai kurios programinės įrangos sluoksnį, tačiau tai nėra panacėja. Šiuos duomenis praturtiname iš kai kurių kitų paslaugų. Pavyzdžiui, aparatūros lygiu per API tiesiogiai jungiamės prie virtualizacijos sistemos ir renkame duomenis.
Kas dar. Be „Zabbix“, naudojame „Prometheus“, kuri leidžia stebėti metriką dinaminėje aplinkoje. Tai reiškia, kad galime gauti programos metriką per HTTP galutinį tašką ir nesijaudinti, kurią metriką į jį įkelti, o kurią ne. Remiantis šiais duomenimis, galima sukurti analitines užklausas.
Kitų sluoksnių duomenų šaltiniai, pavyzdžiui, verslo metrika, yra suskirstyti į tris komponentus.
Pirma, tai yra išorinės verslo sistemos, Google Analytics, mes renkame metrikas iš žurnalų. Iš jų gauname duomenis apie aktyvius vartotojus, konversijas ir visa kita, kas susiję su verslu. Antra, tai yra vartotojo sąsajos stebėjimo sistema. Tai turėtų būti aprašyta išsamiau.
Kažkada pradėjome nuo rankinio testavimo ir jis išaugo į automatinius funkcionalumo ir integracijų testus. Iš to atlikome stebėjimą, palikdami tik pagrindinį funkcionalumą ir pasikliovėme kuo stabilesniais ir laikui bėgant dažnai nesikeičiančiais žymekliais.
Naujoji komandos struktūra reiškia, kad visa taikomųjų programų veikla apsiriboja produktų komandomis, todėl nustojome atlikti tik testavimą. Vietoj to, mes sukūrėme UI stebėjimą iš testų, parašytų Java, Selenium ir Jenkins (naudojama kaip sistema ataskaitoms paleisti ir generuoti).
Turėjome daug bandymų, bet galiausiai nusprendėme eiti į pagrindinį kelią – aukščiausio lygio metriką. O jei turėsime daug konkrečių testų, bus sunku nuolat atnaujinti duomenis. Kiekvienas paskesnis leidimas gerokai sugadins visą sistemą, o mes padarysime tik ją sutvarkyti. Todėl orientavomės į labai esminius dalykus, kurie retai keičiasi, ir tik juos stebime.
Galiausiai, trečia, duomenų šaltinis yra centralizuota registravimo sistema. Žurnalams naudojame Elastic Stack, o tada galime įtraukti šiuos duomenis į verslo metrikos stebėjimo sistemą. Be viso to, mes turime savo stebėjimo API paslaugą, parašytą Python, kuri užklausa bet kokių paslaugų per API ir renka duomenis iš jų į Zabbix.
Kitas nepakeičiamas stebėjimo atributas yra vizualizacija. Mūsų sukurtas Grafana pagrindu. Iš kitų vizualizavimo sistemų jis išsiskiria tuo, kad leidžia prietaisų skydelyje vizualizuoti skirtingų duomenų šaltinių metrikas. Galime rinkti aukščiausio lygio internetinės parduotuvės metrikas, pavyzdžiui, užsakymų, pateiktų per paskutinę valandą iš DBVS, OS, kurioje veikia ši internetinė parduotuvė, našumo metrikas iš „Zabbix“ ir šios programos atvejų metriką. iš Prometėjo. Ir visa tai bus viename prietaisų skydelyje. Aiškus ir prieinamas.
Norėčiau atkreipti dėmesį į saugumą – šiuo metu baigiame kurti sistemą, kurią vėliau integruosime su pasauline stebėjimo sistema. Mano nuomone, pagrindinės problemos, su kuriomis susiduria elektroninė prekyba informacijos saugumo srityje, yra susijusios su robotais, analizatoriais ir brutalia jėga. Turime į tai stebėti, nes visa tai gali labai paveikti mūsų programų veikimą ir mūsų reputaciją verslo požiūriu. Ir su pasirinktu krūva sėkmingai įveikiame šias užduotis.
Kitas svarbus dalykas yra tai, kad aplikacinį sluoksnį surenka „Prometheus“. Jis pats taip pat yra integruotas su Zabbix. Taip pat turime sitespeed – paslaugą, kuri leidžia peržiūrėti tokius parametrus kaip mūsų puslapio įkėlimo greitis, kliūtys, puslapio atvaizdavimas, scenarijų įkėlimas ir kt., ji taip pat yra integruota API. Taigi mūsų metrika renkama „Zabbix“, todėl iš ten taip pat įspėjame. Šiuo metu visi įspėjimai siunčiami pagrindiniais siuntimo būdais (kol kas tai el. paštas ir telegrama, neseniai prijungta ir MS Teams). Planuojama perspėjimą atnaujinti iki tokios būsenos, kad išmanieji robotai veiktų kaip paslauga ir teiktų stebėjimo informaciją visoms suinteresuotoms produktų komandoms.
Mums metrika yra svarbi ne tik atskiroms informacinėms sistemoms, bet ir bendroji metrika visai infrastruktūrai, kurią naudoja programos: fizinių serverių klasteriai, kuriuose veikia virtualios mašinos, srauto balansuotojai, tinklo apkrovos balansuotojai, pats tinklas, ryšio kanalų išnaudojimas. . Plius mūsų pačių duomenų centrų metrika (jų turime keletą ir infrastruktūra gana didelė).
Mūsų stebėjimo sistemos privalumai yra tai, kad jos pagalba matome visų sistemų sveikatos būklę ir galime įvertinti jų poveikį viena kitai ir bendriems ištekliams. Ir galiausiai tai leidžia mums planuoti išteklius, o tai taip pat yra mūsų atsakomybė. Tvarkome serverių išteklius – elektroninės prekybos telkinį, paleidžiame ir išjungiame naują įrangą, įsigyjame papildomos naujos įrangos, atliekame išteklių panaudojimo auditą ir kt. Kiekvienais metais komandos planuoja naujus projektus, kuria savo sistemas, o mums svarbu aprūpinti jas ištekliais.
O metrikų pagalba matome mūsų informacinių sistemų išteklių vartojimo tendencijas. Ir pagal juos galime kažką planuoti. Virtualizavimo lygiu renkame duomenis ir matome informaciją apie turimą išteklių kiekį pagal duomenų centrus. Ir jau duomenų centro viduje galite matyti išteklių perdirbimą, faktinį paskirstymą ir suvartojimą. Be to, tiek su atskirais serveriais, tiek virtualiomis mašinomis ir fizinių serverių grupėmis, kuriose visos šios virtualios mašinos energingai sukasi.
Перспективы
Dabar visos sistemos branduolys yra paruoštas, tačiau dar yra daug dalykų, su kuriais dar reikia padirbėti. Tai bent jau informacijos saugumo sluoksnis, tačiau taip pat svarbu pasiekti tinklą, sukurti įspėjimus ir išspręsti koreliacijos problemą. Turime daug sluoksnių ir sistemų, o kiekviename sluoksnyje yra daug daugiau metrikų. Pasirodo, kad tai matrioška iki matrioškos.
Mūsų užduotis yra galiausiai pateikti tinkamus įspėjimus. Pavyzdžiui, jei kilo problemų dėl aparatinės įrangos, vėlgi, su virtualia mašina ir buvo svarbi programa, o paslaugos atsarginė kopija nebuvo sukurta niekaip. Sužinome, kad virtuali mašina mirė. Tada verslo metrika įspės: vartotojai kažkur dingo, nėra konvertavimo, sąsajos vartotojo sąsaja nepasiekiama, programinė įranga ir paslaugos taip pat mirė.
Esant tokiai situacijai, gausime šlamštą iš įspėjimų, o tai nebetelpa į tinkamos stebėjimo sistemos formatą. Kyla koreliacijos klausimas. Todėl idealiu atveju mūsų stebėjimo sistema turėtų pasakyti: „Vaikinai, jūsų fizinė mašina mirė, o kartu su ja ir ši programa bei šie rodikliai“, o ne įnirtingai bombardavusi mus šimtu įspėjimų. Ji turėtų pranešti apie pagrindinį dalyką - priežastį, kuri padeda greitai pašalinti problemą dėl jos lokalizacijos.
Mūsų pranešimų sistema ir įspėjimų apdorojimas yra sukurti remiantis 24 valandas per parą veikiančia karštosios linijos paslauga. Ten siunčiami visi įspėjimai, kurie laikomi privalomais ir yra įtraukti į kontrolinį sąrašą. Kiekvienas įspėjimas turi turėti aprašymą: kas atsitiko, ką jis iš tikrųjų reiškia, ką paveikia. Taip pat nuoroda į prietaisų skydelį ir instrukcijos, ką tokiu atveju daryti.
Tai viskas apie įspėjimo kūrimo reikalavimus. Tada situacija gali vystytis dviem kryptimis – arba yra problema ir ją reikia spręsti, arba įvyko gedimas stebėjimo sistemoje. Bet bet kuriuo atveju reikia eiti ir išsiaiškinti.
Vidutiniškai dabar gauname apie šimtą įspėjimų per dieną, atsižvelgiant į tai, kad įspėjimų koreliacija dar nėra tinkamai sukonfigūruota. O jei reikia atlikti techninius darbus, o kažką priverstinai išjungiame, jų gerokai padaugėja.
Stebėjimo sistema leidžia ne tik stebėti mūsų valdomas sistemas ir rinkti metriką, kuri laikoma svarbia mūsų pusėje, bet ir leidžia rinkti duomenis produktų komandoms. Jie gali paveikti mūsų stebimų informacinių sistemų metrikų sudėtį.
Mūsų kolega gali ateiti ir paprašyti pridėti kokį nors rodiklį, kuris bus naudingas ir mums, ir komandai. Arba, pavyzdžiui, komandai gali nepakakti pagrindinės mūsų turimos metrikos; ji turi sekti kai kurias konkrečias. Grafana sukuriame erdvę kiekvienai komandai ir suteikiame administratoriaus teises. Taip pat, jei komandai reikia prietaisų skydelių, bet jie patys negali/nemoka to padaryti, mes padedame.
Kadangi esame už komandos vertės kūrimo, jų išleidimo ir planavimo ribų, pamažu darome išvadą, kad visų sistemų leidimai yra sklandūs ir gali būti išleidžiami kasdien be derinimo su mumis. Ir mums svarbu stebėti šiuos leidimus, nes jie gali turėti įtakos programos veikimui ir ką nors sugadinti, o tai labai svarbu. Leidimams valdyti naudojame Bamboo, iš kurio gauname duomenis per API ir matome, kokiose informacinėse sistemose išleisti leidimai ir jų būsena. O svarbiausia kokiu laiku. Išleidimo žymeklius uždedame ant pagrindinių kritinių rodiklių, o tai vizualiai labai parodo problemų atveju.
Tokiu būdu galime pamatyti ryšį tarp naujų leidimų ir kylančių problemų. Pagrindinė mintis yra suprasti, kaip sistema veikia visuose sluoksniuose, greitai lokalizuoti problemą ir taip pat greitai ją išspręsti. Juk dažnai nutinka taip, kad daugiausiai laiko atima ne problemos sprendimas, o priežasties paieška.
Ir šioje srityje ateityje norime sutelkti dėmesį į iniciatyvumą. Idealiu atveju apie artėjančią problemą norėčiau žinoti iš anksto, o ne po to, kad galėčiau jai užkirsti kelią, o ne išspręsti. Kartais įvyksta klaidingi stebėjimo sistemos aliarmai, tiek dėl žmogiškos klaidos, tiek dėl aplikacijos pakeitimų. Ir mes tai dirbame, deriname ir bandome apie tai perspėti vartotojus, kurie naudojasi šia sistema prieš bet kokius manipuliavimus stebėjimo sistema. , arba atlikti šias veiklas techniniame lange.
Taigi, sistema paleista ir sėkmingai veikia nuo pavasario pradžios... ir rodo labai realų pelną. Žinoma, tai nėra galutinė versija; pristatysime daug daugiau naudingų funkcijų. Tačiau šiuo metu, kai yra tiek daug integracijų ir programų, stebėjimo automatizavimas yra tikrai neišvengiamas.
Jei taip pat stebite didelius projektus su daugybe integracijų, komentaruose parašykite, kokią sidabrinę kulką radote.
Šaltinis: www.habr.com