Produktu taldeak osatzeko fasean jarraipen-sistema bat sortzea pentsatu genuen. Argi geratu zen gure negozioa -esplotazioa- ez dela talde horietan erortzen. Zergatik da hori?
Kontua da gure talde guztiak banakako informazio sistemen, mikrozerbitzuen eta fronteen inguruan eraikita daudela, beraz, taldeek ez dute sistema osoaren osasun orokorra ikusten. Esate baterako, baliteke ez jakitea backend sakoneko zati txiki batek aurrealdean nola eragiten dion. Haien interes-esparrua beren sistema integratuta dagoen sistemetara mugatzen da. Talde batek eta bere A zerbitzuak ia ez badute B zerbitzuarekin loturarik, orduan horrelako zerbitzu bat ia ikusezina da taldearentzat.
Gure taldeak, berriz, elkarren artean oso integratuta dauden sistemekin lan egiten du: haien artean lotura asko daude, hau oso azpiegitura handia da. Eta lineako dendaren funtzionamendua sistema horien guztien araberakoa da (horietatik, bide batez, kopuru itzela dugu).
Beraz, gure saila ez da inongo talde batekoa, baina apur bat alboan kokatzen da. Istorio honetan, gure zeregina informazio-sistemek nola funtzionatzen duten, haien funtzionaltasuna, integrazioak, softwarea, sarea, hardwarea eta hori guztia elkarren artean nola konektatzen den ulertzea da.
Gure lineako dendek funtzionatzen duten plataformak honela dauka:
- aurrean
- erdiko bulegoa
- back office
Nahiko genukeen arren, ez da gertatzen sistema guztiek ondo eta akatsik gabe funtzionatzen dutenik. Kontua, berriro ere, sistema eta integrazio kopurua da - gurea bezalako zerbaitekin, gertakari batzuk saihestezinak dira, proben kalitatea izan arren. Gainera, bai sistema bereizi baten barruan, bai haien integrazioari dagokionez. Eta plataforma osoaren egoera modu integralean kontrolatu behar duzu, eta ez edozein zati indibidual.
Egokiena, plataforma osorako osasunaren jarraipena automatizatu behar da. Eta jarraipenera prozesu honen parte saihestezin gisa heldu ginen. Hasieran, lehen lerroko zatirako bakarrik eraiki zen, sareko espezialistek, software eta hardware-administratzaileek beren geruzaz geruza kontrolatzeko sistema propioak zituzten eta oraindik ere badute. Pertsona hauek guztiek beren mailan bakarrik jarraitu zuten jarraipena; inork ere ez zuen ulermen osorik.
Adibidez, makina birtual batek huts egiten badu, kasu gehienetan hardwareaz arduratzen den administratzaileak eta makina birtualak bakarrik dakite horren berri. Kasu horietan, lehen lerroko taldeak aplikazioaren hutsegitearen egia ikusi zuen, baina ez zuen makina birtualaren hutsegiteari buruzko daturik. Eta administratzaileak bezeroa nor den jakin dezake eta gaur egun makina birtual honetan exekutatzen ari denaren ideia gutxi gorabehera izan dezake, baldin eta proiektu handi bat bada. Seguruenik ez daki txikien berri. Nolanahi ere, administratzaileak jabearengana joan behar du eta galdetu zer zegoen makina honetan, zer berreskuratu behar den eta zer aldatu behar den. Eta zerbait benetan larria apurtzen bazen, biribilka hasi ziren, inork ez zuelako sistema osorik ikusten.
Azken finean, halako istorio desberdinek frontend osoa, erabiltzaileak eta gure negozio-funtzio nagusia - lineako salmentak eragiten dituzte. Talde baten parte ez garenez, baina merkataritza elektronikoko aplikazio guztien funtzionamenduan dihardugun lineako denda baten parte gisa, merkataritza elektronikoko plataformaren jarraipen sistema integral bat sortzeko ardura hartu genuen.
Sistemaren egitura eta pila
Gure sistemetarako hainbat monitorizazio-geruza identifikatzen hasi ginen, eta horien barruan neurketak bildu beharko genituzke. Eta hori guztia uztartu beharra zegoen, horixe egin genuen lehen etapan. Orain fase honetan gure geruza guztietan kalitate goreneko metrika bilduma amaitzen ari gara, korrelazio bat eraikitzeko eta sistemek elkarri nola eragiten dioten ulertzeko.
Aplikazioak abiarazteko hasierako faseetan jarraipen integralik ez izateak (sistema gehienak ekoizpenean zeudenean eraikitzen hasi ginenetik) plataforma osoaren jarraipena ezartzeko zor tekniko handia geneukala ekarri zuen. Ezin genuen ordaindu IS bakar baten monitorizazioa konfiguratzen eta horren monitorizazioa zehatz-mehatz lantzen zentratu, gainerako sistemak denbora batez monitorizatu gabe geratuko baitziren. Arazo hori konpontzeko, informazio-sistemaren egoera geruzaka ebaluatzeko beharrezkoak diren metrika zerrenda bat identifikatu eta inplementatzen hasi ginen.
Horregatik, elefantea zatika jatea erabaki zuten.
Gure sistema hauek osatzen dute:
- hardwarea;
- sistema eragilea;
- softwarea;
- UI zatiak monitorizazio aplikazioan;
- negozio-neurriak;
- integrazio aplikazioak;
- informazioaren segurtasuna;
- sareak;
- trafiko-orekatzailea.
Sistema honen erdian monitorizazioa bera dago. Sistema osoaren egoera orokorrean ulertzeko, geruza guzti hauetan eta aplikazio multzo osoan aplikazioekin zer gertatzen ari den jakin behar duzu.
Beraz, pilari buruz.
Kode irekiko softwarea erabiltzen dugu. Zentroan Zabbix dugu, batez ere alerta sistema gisa erabiltzen duguna. Mundu guztiak daki azpiegituren jarraipena egiteko aproposa dela. Zer esan nahi du honek? Zehazki, bere datu-zentroa mantentzen duten enpresa bakoitzak (eta Sportmaster-ek bere datu-zentroak ditu) dituen maila baxuko metrika horiek: zerbitzariaren tenperatura, memoria-egoera, raid-a, sareko gailuen neurketak.
Zabbix Telegram messenger eta Microsoft Teams-ekin integratu dugu, taldeetan aktiboki erabiltzen direnak. Zabbix-ek benetako sarearen, hardwarearen eta software batzuen geruza estaltzen du, baina ez da panazea bat. Datu hauek beste zerbitzu batzuetatik aberasten ditugu. Adibidez, hardware mailan, zuzenean API bidez konektatzen gara gure birtualizazio sistemara eta datuak biltzen ditugu.
Zer gehiago. Zabbix-ez gain, Prometheus erabiltzen dugu, ingurune dinamikoko aplikazio batean metrikak kontrolatzeko aukera ematen diguna. Hau da, aplikazioaren neurketak HTTP amaierako puntu baten bidez jaso ditzakegu eta ez kezkatu zein neurketa bertan kargatu eta zein ez. Datu horietatik abiatuta, kontsulta analitikoak garatu daitezke.
Beste geruzetarako datu-iturriak, adibidez, negozio-neurriak, hiru osagaitan banatzen dira.
Lehenik eta behin, hauek kanpoko negozio sistemak dira, Google Analytics, erregistroetatik neurketak biltzen ditugu. Horietatik erabiltzaile aktiboei, bihurketei eta negozioarekin lotutako beste guztiari buruzko datuak lortzen ditugu. Bigarrenik, hau UI monitorizatzeko sistema bat da. Xehetasun gehiagorekin deskribatu beharko litzateke.
Bazen behin eskuzko testekin hasi ginen eta funtzionaltasun eta integrazioen proba automatikoetara hazi zen. Hortik jarraipena egin genuen, funtzionalitate nagusia bakarrik utziz, eta ahalik eta egonkorrenak diren eta denboran zehar askotan aldatzen ez diren markatzaileetan oinarritu ginen.
Talde-egitura berriak aplikazio-jarduera guztiak produktu-taldeetara mugatzen direla esan nahi du, beraz, proba hutsak egiteari utzi diogu. Horren ordez, testetatik UI monitorizazioa egin genuen, Java, Selenium eta Jenkins-en idatzita (txostenak abiarazteko eta sortzeko sistema gisa erabiltzen da).
Proba asko egin genituen, baina azkenean errepide nagusira joatea erabaki genuen, maila goreneko metrika. Eta proba zehatz asko baditugu, zaila izango da datuak eguneratuta mantentzea. Ondorengo bertsio bakoitzak sistema osoa nabarmen hautsiko du, eta egingo dugun guztia konpontzea da. Hori dela eta, oso gutxitan aldatzen diren funtsezko gauzetan zentratu ginen, eta haien jarraipena baino ez dugu egiten.
Azkenik, hirugarrenik, datu-iturria erregistro-sistema zentralizatua da. Erregistroetarako Elastic Stack erabiltzen dugu eta, ondoren, datu hauek gure monitorizazio sistemara eraman ditzakegu negozio-neurrietarako. Honetaz guztiaz gain, gure Monitoring API zerbitzu propioa dugu, Python-en idatzia, edozein zerbitzu API bidez kontsultatu eta haien datuak Zabbix-en biltzen dituena.
Jarraipenaren ezinbesteko beste atributu bat bistaratzea da. Gurea Grafanan oinarritzen da. Beste bistaratze sistemen artean nabarmentzen da, datu-iturri ezberdinetako neurketak aginte-panelean bistaratzeko aukera ematen duelako. Lineako denda baterako goi-mailako neurketak bil ditzakegu, adibidez, azken orduan DBMS-tik egindako eskaera kopurua, lineako denda hau Zabbix-etik exekutatzen ari den sistema eragilearen errendimendu-neurriak eta aplikazio honen instantzien neurketak. Prometeoren eskutik. Eta hori guztia aginte-panel batean egongo da. Argia eta eskuragarria.
Utzidazu ohartu segurtasunari buruz - une honetan sistema amaitzen ari gara, gerora monitorizazio sistema globalarekin integratuko duguna. Nire ustez, merkataritza elektronikoak informazioaren segurtasunaren arloan dituen arazo nagusiak botekin, analizatzaileekin eta indar gordinarekin lotuta daude. Horri begira egon behar dugu, horrek guztiak modu kritikoan eragin dezakeelako bai gure aplikazioen funtzionamenduan, bai gure ospea negozioaren ikuspuntutik. Eta aukeratutako pilarekin lan hauek ongi betetzen ditugu.
Beste puntu garrantzitsu bat aplikazio-geruza Prometheus-ek muntatzen duela da. Bera ere Zabbixekin integratuta dago. Eta sitespeed ere badugu, gure orriaren karga-abiadura, botila-lepoak, orriak errendatzea, kargatzeko script-ak, etab. bezalako parametroak ikusteko aukera ematen duen zerbitzua, API integratua ere bada. Beraz, gure neurketak Zabbixen biltzen dira, eta horren arabera, hortik ere abisatzen dugu. Alerta guztiak bidalketa-metodo nagusietara bidaltzen dira momentuz (oraingoz posta elektronikoa eta telegrama da, MS Teams ere duela gutxi konektatu da). Bot adimendunek zerbitzu gisa funtzionatzen duten eta interesa duten produktu-talde guztiei jarraipen-informazioa eskaintzeko abisuak berritzeko planak daude.
Guretzat, neurketak garrantzitsuak dira informazio-sistem indibidualentzat ez ezik, aplikazioek erabiltzen duten azpiegitura osoaren neurri orokorrak ere: makina birtualak exekutatzen dituzten zerbitzari fisikoen multzoak, trafiko-orekatzaileak, sareko karga-orekatzaileak, sarea bera, komunikazio-kanalen erabilera. . Gehiago neurriak gure datu-zentroetarako (hainbat ditugu eta azpiegitura nahiko handia da).
Gure monitorizazio sistemaren abantailak hauek dira, bere laguntzarekin sistema guztien osasun-egoera ikusten dugula eta elkarrengan eta partekatutako baliabideetan duten eragina ebaluatu dezakegula. Eta azken finean, baliabideen plangintzan aritzeko aukera ematen digu, hori ere gure ardura baita. Zerbitzariaren baliabideak kudeatzen ditugu: merkataritza elektronikoko igerilekua, ekipamendu berriak enkargatu eta kentzea, ekipamendu berriak erostea, baliabideen erabileraren auditoria egiten dugu, etab. Urtero, taldeek proiektu berriak planifikatzen dituzte, sistemak garatzen dituzte, eta guretzat garrantzitsua da baliabideak hornitzea.
Eta metrikoen laguntzaz, gure informazio sistemek baliabideen kontsumoaren joera ikusten dugu. Eta horietan oinarrituta zerbait planifikatu dezakegu. Birtualizazio mailan, datuak biltzen ditugu eta datu-zentroaren arabera erabilgarri dagoen baliabide kopuruari buruzko informazioa ikusten dugu. Eta datu-zentroaren barruan dagoeneko ikus daitezke baliabideen birziklapena, benetako banaketa eta kontsumoa. Gainera, bai zerbitzari autonomoekin, bai makina birtualekin eta zerbitzari fisikoen multzoekin, zeinetan makina birtual hauek guztiak biziki biraka ari diren.
Itxaropenak
Orain prest daukagu ββsistema osoaren muina, baina oraindik gauza asko daude landu beharrekoak. Gutxienez, informazioaren segurtasun-geruza bat da, baina garrantzitsua da sarera heltzea, alertak garatzea eta korrelazioaren arazoa konpontzea ere. Geruza eta sistema asko ditugu, eta geruza bakoitzean hainbat metrika gehiago daude. Matryoshka bat bihurtzen da matrioska baten mailan.
Gure zeregina azken finean alerta egokiak egitea da. Adibidez, hardwarearekin arazoren bat bazegoen, berriro ere, makina birtual batekin, eta aplikazio garrantzitsu bat bazegoen, eta zerbitzuaren babeskopia ez zen inola ere egin. Makina birtuala hil dela jakin dugu. Orduan, negozio-neurriek ohartaraziko zaituzte: erabiltzaileak nonbait desagertu dira, ez dago bihurketarik, interfazearen interfazea ez dago erabilgarri, softwarea eta zerbitzuak ere hil egin dira.
Egoera honetan, abisuen spam-a jasoko dugu, eta hori ez da jada kontrol-sistema egoki baten formatuan sartzen. Korrelazioaren auzia sortzen da. Hori dela eta, hobeki, gure monitorizazio-sistemak esan beharko luke: "Mutilak, zure makina fisikoa hil egin da, eta horrekin batera aplikazio hau eta metrika hauek", alerta baten laguntzaz, ehun alertarekin amorruz bonbardatu beharrean. Gauza nagusia jakinarazi beharko luke - kausa, eta horrek arazoa azkar kentzen laguntzen du bere lokalizazioa dela eta.
Gure jakinarazpen-sistema eta alerta-prozesamendua XNUMX orduko telefono-zerbitzu baten inguruan eraikita dago. Beharrezkoak diren eta kontrol-zerrendan sartzen diren alerta guztiak bertan bidaltzen dira. Alerta bakoitzak deskribapen bat izan behar du: zer gertatu den, zer esan nahi duen benetan, zertan eragiten duen. Eta aginte-panelaren esteka eta kasu honetan zer egin behar den argibideak ere bai.
Hau guztia alerta bat eraikitzeko eskakizunei buruzkoa da. Orduan, egoera bi norabidetan garatu daiteke: arazo bat dago eta konpondu behar da, edo monitorizazio sisteman porrot bat egon da. Baina, nolanahi ere, joan eta asmatu behar duzu.
Batez beste, gaur egun ehun alerta inguru jasotzen ditugu egunean, kontuan izanda abisuen korrelazioa oraindik behar bezala konfiguratuta ez dagoela. Eta lan teknikoa egin behar badugu, eta zerbait indarrez itzaltzen badugu, haien kopurua nabarmen handitzen da.
Funtzionatzen ditugun sistemen jarraipenaz eta gure aldetik garrantzitsutzat jotzen diren neurketak biltzeaz gain, monitorizazio sistemak produktu-taldeentzako datuak biltzeko aukera ematen digu. Kontrolatzen ditugun informazio sistemen neurketen osaeran eragin dezakete.
Baliteke gure lankidea etortzea eta guri zein taldearentzat baliagarriak izango zaizkigun metrika batzuk gehitzeko eska dezake. Edo, adibidez, baliteke taldeak ditugun oinarrizko neurketetatik nahikoa ez izatea; zehatz batzuen jarraipena egin behar dute. Grafanan, talde bakoitzeko espazio bat sortzen dugu eta administratzaile eskubideak ematen ditugu. Gainera, talde batek aginte-panelak behar baditu, baina beraiek ezin edo ez dakite nola egin, laguntzen diegu.
Taldearen balio-sorkuntzatik, kaleratzetik eta plangintzatik kanpo gaudenez, pixkanaka-pixkanaka sistema guztien bertsioak bateragarriak direla eta gurekin koordinatu gabe egunero zabaldu daitezkeela ondorioztatzen ari gara. Eta guretzat garrantzitsua da bertsio hauek kontrolatzea, aplikazioaren funtzionamenduan eragina izan dezaketelako eta zerbait apurtu dezaketelako, eta hori ezinbestekoa da. Argitalpenak kudeatzeko, Bamboo erabiltzen dugu, bertatik datuak API bidez jasotzen ditugun eta zein bertsio kaleratu diren zein informazio sistematan eta haien egoera ikus dezakegu. Eta garrantzitsuena zein ordutan da. Askapen-markak gainjartzen ditugu metrika kritiko nagusietan, eta hori bisualki oso adierazgarria da arazoen kasuan.
Horrela argitalpen berrien eta sortzen ari diren arazoen arteko korrelazioa ikusi ahal izango dugu. Ideia nagusia sistemak geruza guztietan nola funtzionatzen duen ulertzea da, arazoa azkar lokalizatu eta bezain azkar konpontzea. Azken finean, askotan gertatzen da denbora gehien behar duena ez dela arazoa konpontzea, kausa bilatzea baizik.
Eta arlo honetan etorkizunean proaktibitatean jarri nahi dugu arreta. Egokiena, hurbiltzen den arazo baten berri aldez aurretik ezagutzea gustatuko litzaidake, eta ez ondoren, konpondu beharrean saihestu ahal izateko. Batzuetan monitorizazio sistemaren alarma faltsuak gertatzen dira, bai giza akatsengatik, bai aplikazioan egindako aldaketengatik.Eta horretan lan egiten dugu, arazketan, eta gurekin erabiltzen duten erabiltzaileei honetaz ohartarazten saiatzen gara monitorizazio sistemaren edozein manipulazio aurretik. , edo jarduera horiek leiho teknikoan egin.
Beraz, sistema martxan jarri da eta arrakastaz funtzionatzen du udaberri hasieratik... eta oso benetako irabaziak erakusten ari da. Jakina, hau ez da azken bertsioa; funtzio erabilgarria gehiago sartuko ditugu. Baina oraintxe bertan, hainbeste integrazio eta aplikaziorekin, automatizazioa kontrolatzea saihestezina da.
Integrazio kopuru handia duten proiektu handiak ere kontrolatzen badituzu, idatzi iruzkinetan zer zilarrezko bala aurkitu duzun horretarako.
Iturria: www.habr.com