Wy tochten oer it meitsjen fan in tafersjochsysteem yn it stadium fan it foarmjen fan produktteams. It waard dúdlik dat ús bedriuw - eksploitaasje - net yn dizze teams falt. Wêrom is dat?
It feit is dat al ús teams binne boud om yndividuele ynformaasjesystemen, mikrotsjinsten en fronten, sadat de teams de algemiene sûnens fan it heule systeem as gehiel net sjogge. Bygelyks, se meie net witte hoe't guon lyts part yn 'e djippe backend beynfloedet de foarkant. Harren omfang fan belang is beheind ta de systemen wêrmei harren systeem is yntegrearre. As in ploech en syn tsjinst A hast gjin ferbân hawwe mei tsjinst B, dan is sa'n tsjinst hast ûnsichtber foar it team.
Us team wurket op syn beurt mei systemen dy't tige sterk mei elkoar yntegreare binne: der binne in protte ferbiningen tusken har, dit is in heul grutte ynfrastruktuer. En de wurking fan 'e online winkel hinget ôf fan al dizze systemen (wêrfan wy, trouwens, in grut oantal hawwe).
Sa docht bliken dat ús ôfdieling by gjin team heart, mar in bytsje oan de kant leit. Yn dit hiele ferhaal is ús taak om wiidweidich te begripen hoe't ynformaasjesystemen wurkje, har funksjonaliteit, yntegraasjes, software, netwurk, hardware, en hoe't dit alles mei elkoar ferbûn is.
It platfoarm wêrop ús online winkels wurkje, sjocht der sa út:
- front
- middelste kantoar
- administraasje
Hoefolle wy ek wolle, it bart net dat alle systemen soepel en feilloos wurkje. It punt, wer, is it oantal systemen en yntegraasjes - mei sokssawat as ús binne guon ynsidinten ûnûntkomber, nettsjinsteande de kwaliteit fan testen. Boppedat, sawol binnen in apart systeem as yn termen fan harren yntegraasje. En jo moatte de steat fan it heule platfoarm wiidweidich kontrolearje, en net allinich in yndividueel diel dêrfan.
Idealiter soe platfoarmbrede sûnensmonitoring automatisearre wurde moatte. En wy kamen ta tafersjoch as in ûnûntkomber diel fan dit proses. Yn earste ynstânsje waard it allinich boud foar it frontline-diel, wylst netwurkspesjalisten, software- en hardwarebehearders har eigen laach-by-laach monitoringsystemen hienen en noch hawwe. Al dizze minsken folgen de monitoaring allinich op har eigen nivo; gjinien hie ek in wiidweidich begryp.
As bygelyks in firtuele masine crasht, witte yn 'e measte gefallen allinich de behearder ferantwurdlik foar de hardware en de firtuele masine derfan. Yn sokke gefallen seach it frontline-team it feit dat de applikaasje crashte, mar it hie gjin gegevens oer it crash fan 'e firtuele masine. En de behearder kin witte wa't de klant is en in rûch idee hawwe fan wat op dit stuit op dizze firtuele masine rint, op betingst dat it in soarte fan grut projekt is. Hy wit nei alle gedachten net oer de lytse bern. Yn alle gefallen moat de behearder nei de eigner gean en freegje wat der op dizze masine stie, wat moat wurde restaurearre en wat moat feroare wurde. En as der wat echt serieus bruts, begûnen se yn sirkels rûn te rinnen - om't gjinien it systeem as gehiel seach.
Uteinlik beynfloedzje sokke ferskillende ferhalen de heule frontend, brûkers en ús kearnbedriuwfunksje - online ferkeap. Om't wy gjin diel útmeitsje fan in team, mar dwaande binne mei de eksploitaasje fan alle e-commerce-applikaasjes as ûnderdiel fan in online winkel, namen wy de taak op om in wiidweidich tafersjochsysteem te meitsjen foar it e-commerce-platfoarm.
Systeem struktuer en stack
Wy binne begûn mei it identifisearjen fan ferskate tafersjochlagen foar ús systemen, wêryn wy metriken moatte sammelje. En dit alles moast kombinearre wurde, dat is wat wy diene yn 'e earste etappe. No yn dit stadium finalisearje wy de kolleksje fan metriken fan heechste kwaliteit oer al ús lagen om in korrelaasje op te bouwen en te begripen hoe't systemen inoar beynfloedzje.
It ûntbrekken fan wiidweidige monitoaring yn 'e earste fazen fan' e lansearring fan 'e applikaasje (sûnt wy it begon te bouwen doe't de measte systemen yn produksje wiene) late ta it feit dat wy signifikante technyske skuld hiene om tafersjoch op it heule platfoarm op te stellen. Wy koenen it net betelje om te fokusjen op it ynstellen fan tafersjoch foar ien IS en it útwurkjen fan tafersjoch dêrfoar yn detail, om't de rest fan 'e systemen in skoft sûnder tafersjoch bliuwe soe. Om dit probleem op te lossen, identifisearren wy in list mei de meast nedige metriken foar it beoardieljen fan 'e steat fan it ynformaasjesysteem foar laach en begon it te ymplementearjen.
Dêrom besleaten se de oaljefant yn dielen te iten.
Us systeem bestiet út:
- hardware;
- bestjoeringssysteem;
- software;
- UI-dielen yn 'e tafersjochapplikaasje;
- saaklike metriken;
- yntegraasjeapplikaasjes;
- ynformaasje feiligens;
- netwurken;
- ferkear balancer.
Yn it sintrum fan dit systeem is it tafersjoch op himsels. Om de steat fan it heule systeem algemien te begripen, moatte jo witte wat der bart mei applikaasjes op al dizze lagen en oer de heule set applikaasjes.
Dus, oer de stapel.
Wy brûke iepen boarne software. Yn it sintrum hawwe wy Zabbix, dat wy benammen brûke as warskôgingssysteem. Elkenien wit dat it ideaal is foar ynfrastruktuermonitoring. Wat betsjut dit? Krekt dy metriken op leech nivo dy't elk bedriuw dat syn eigen datasintrum ûnderhâldt hat (en Sportmaster hat syn eigen datasintra) - servertemperatuer, ûnthâldstatus, raid, metriken foar netwurkapparaten.
Wy hawwe Zabbix yntegrearre mei de Telegram-messenger en Microsoft Teams, dy't aktyf wurde brûkt yn teams. Zabbix beslacht de laach fan it eigentlike netwurk, hardware en guon software, mar it is gjin panacee. Wy ferrykje dizze gegevens fan guon oare tsjinsten. Bygelyks, op it hardwarenivo ferbine wy direkt fia API mei ús virtualisaasjesysteem en sammelje gegevens.
Wat oars. Neist Zabbix brûke wy Prometheus, wêrtroch wy metriken kinne kontrolearje yn in dynamyske omjouwingsapplikaasje. Dat is, wy kinne applikaasjemetriken ûntfange fia in HTTP-einpunt en gjin soargen meitsje oer hokker metriken dêryn moatte laden en hokker net. Op grûn fan dizze gegevens kinne analytyske fragen ûntwikkele wurde.
Gegevensboarnen foar oare lagen, bygelyks saaklike metriken, binne ferdield yn trije komponinten.
As earste binne dit eksterne bedriuwssystemen, Google Analytics, wy sammelje metriken út logs. Fan har krije wy gegevens oer aktive brûkers, konversaasjes en al it oare relatearre oan it bedriuw. Twadder is dit in UI-monitorsysteem. It moat wurde beskreaun yn mear detail.
Eartiids begûnen wy mei hânmjittich testen en it groeide út yn automatyske testen fan funksjonaliteit en yntegraasjes. Fan dit hawwe wy tafersjoch makke, allinich de wichtichste funksjonaliteit litten, en fertrouden op markers dy't sa stabyl mooglik binne en net faak feroarje oer de tiid.
De nije teamstruktuer betsjuttet dat alle tapassingsaktiviteiten beheind binne ta produktteams, dus binne wy ophâlden mei suver testen. Ynstee hawwe wy UI-monitoring makke fan 'e tests, skreaun yn Java, Selenium en Jenkins (brûkt as systeem foar it lansearjen en generearjen fan rapporten).
Wy hiene in protte tests, mar op it lêst besleaten wy nei de haadwei te gean, de metryske topnivo. En as wy in protte spesifike tests hawwe, sil it lestich wêze om de gegevens bywurke te hâlden. Elke folgjende release sil it heule systeem signifikant brekke, en alles wat wy sille dwaan is it reparearje. Dêrom rjochte wy ús op heul fûnemintele dingen dy't selden feroarje, en wy kontrolearje se allinich.
Uteinlik, as tredde, is de gegevensboarne in sintralisearre logsysteem. Wy brûke Elastic Stack foar logs, en dan kinne wy dizze gegevens yn ús tafersjochsysteem lûke foar saaklike metriken. Neist dit alles hawwe wy ús eigen Monitoring API-tsjinst, skreaun yn Python, dy't alle tsjinsten freget fia API en sammelet gegevens fan har yn Zabbix.
In oar ûnmisber attribút fan tafersjoch is fisualisaasje. Us is basearre op Grafana. It opfalt ûnder oare fisualisaasjesystemen yn dat it jo metriken kin fisualisearje fan ferskate gegevensboarnen op it dashboard. Wy kinne metriken op topnivo sammelje foar in online winkel, bygelyks it oantal oarders pleatst yn it lêste oere fan 'e DBMS, prestaasjesmetriken foar it OS wêrop dizze online winkel rint fan Zabbix, en metriken foar eksimplaren fan dizze applikaasje fan Prometheus. En dit alles sil op ien dashboard wêze. Dúdlik en tagonklik.
Lit my opmerke oer feiligens - wy finalisearje op it stuit it systeem, dat wy letter sille yntegrearje mei it globale tafersjochsysteem. Yn myn miening binne de wichtichste problemen dy't e-commerce op it mêd fan ynformaasjefeiligens te krijen hat, relatearre oan bots, parsers en brute krêft. Wy moatte dit yn 'e gaten hâlde, om't dit alles kritysk kin beynfloedzje op sawol de wurking fan ús applikaasjes as ús reputaasje út in saaklik eachpunt. En mei de keazen stap dekke wy dizze taken mei súkses.
In oar wichtich punt is dat de applikaasjelaach wurdt gearstald troch Prometheus. Hy sels is ek yntegrearre mei Zabbix. En wy hawwe ek sitespeed, in tsjinst wêrmei wy parameters kinne besjen lykas de laden snelheid fan ús side, knyppunten, side rendering, laden skripts, ensfh., it is ek API yntegrearre. Dat ús metriken wurde sammele yn Zabbix, en dêrom warskôgje wy dêr ek fanôf. Alle warskôgings wurde op it stuit stjoerd nei de wichtichste ferstjoermetoaden (foar no is it e-post en telegram, MS Teams is ek koartlyn ferbûn). D'r binne plannen om warskôging te ferbetterjen nei sa'n steat dat tûke bots as tsjinst wurkje en tafersjochynformaasje leverje oan alle ynteressearre produktteams.
Foar ús binne metriken net allinich wichtich foar yndividuele ynformaasjesystemen, mar ek algemiene metriken foar de heule ynfrastruktuer dy't applikaasjes brûke: klusters fan fysike servers wêrop firtuele masines rinne, ferkearsbalansers, Network Load Balancers, it netwurk sels, gebrûk fan kommunikaasjekanalen . Plus metriken foar ús eigen datasintra (wy hawwe ferskate fan har en de ynfrastruktuer is frij grut).
De foardielen fan ús tafersjochsysteem binne dat wy mei har help de sûnensstatus fan alle systemen sjogge en har ynfloed op elkoar en op dielde boarnen kinne beoardielje. En úteinlik lit it ús meidwaan oan boarneplanning, wat ek ús ferantwurdlikens is. Wy beheare serverboarnen - in swimbad binnen e-commerce, kommisje en ûntmanteling fan nije apparatuer, keapje ekstra nije apparatuer, fiere in kontrôle út fan it gebrûk fan boarnen, ensfh. Elk jier planne teams nije projekten, ûntwikkelje har systemen, en it is wichtich foar ús om har boarnen te foarsjen.
En mei help fan metriken sjogge wy de trend yn boarneferbrûk troch ús ynformaasjesystemen. En op basis fan harren kinne wy wat planne. Op it virtualisaasjenivo sammelje wy gegevens en sjogge ynformaasje oer de beskikbere hoemannichte boarnen troch datasintrum. En al binnen it datasintrum kinne jo de recycling, de eigentlike ferdieling en konsumpsje fan boarnen sjen. Boppedat, sawol mei standalone tsjinners as firtuele masines en klusters fan fysike tsjinners dêr't al dizze firtuele masines draaie krêftich.
Perspektiven
No hawwe wy de kearn fan it systeem as gehiel klear, mar der binne noch in protte dingen dêr't noch oan wurke wurde moat. Op syn minst is dit in laach fan ynformaasjefeiligens, mar it is ek wichtich om it netwurk te berikken, warskôging te ûntwikkeljen en it probleem fan korrelaasje op te lossen. Wy hawwe in protte lagen en systemen, en op elke laach binne d'r folle mear metriken. It blykt in matryoshka te wêzen yn 'e graad fan in matryoshka.
Us taak is om úteinlik de juste warskôgings te meitsjen. Bygelyks, as der wie in probleem mei de hardware, wer, mei in firtuele masine, en der wie in wichtige applikaasje, en de tsjinst waard net reservekopy op hokker wize. Wy fine út dat de firtuele masine is stoarn. Dan sille saaklike metriken jo warskôgje: brûkers binne earne ferdwûn, d'r is gjin konverzje, de UI yn 'e ynterface is net beskikber, software en tsjinsten binne ek stoarn.
Yn dizze situaasje sille wy spam ûntfange fan warskôgings, en dit past net mear yn it formaat fan in goed kontrôlesysteem. De fraach fan korrelaasje ûntstiet. Dêrom soe ideaal ús tafersjochsysteem sizze moatte: "Jongens, jo fysike masine is stoarn, en tegearre mei dizze applikaasje en dizze metriken," mei help fan ien warskôging, ynstee fan ús fûleindich te bombardearjen mei hûndert warskôgings. It moat rapportearje it wichtichste ding - de oarsaak, dy't helpt om fluch elimineren it probleem fanwege syn lokalisaasje.
Us notifikaasjesysteem en warskôgingsferwurking is boud om in XNUMX-oere hotline-tsjinst. Alle warskôgings dy't wurde beskôge as in must-have en binne opnommen yn 'e checklist wurde dêr stjoerd. Elke warskôging moat in beskriuwing hawwe: wat der bard is, wat it eins betsjut, wat it beynfloedet. En ek in keppeling nei it dashboard en ynstruksjes oer wat te dwaan yn dit gefal.
Dit is alles oer de easken foar it bouwen fan in warskôging. Dan kin de situaasje yn twa rjochtingen ûntwikkelje - of d'r is in probleem en moat wurde oplost, of d'r is in mislearring west yn it tafersjochsysteem. Mar yn alle gefallen moatte jo gean en it útfine.
Yn trochsneed krije wy no sa'n hûndert warskôgings deis, rekken hâldend mei it feit dat de korrelaasje fan warskôgings noch net goed ynsteld is. En as wy technysk wurk moatte útfiere, en wy twang wat útsette, nimt har oantal signifikant ta.
Neist it kontrolearjen fan de systemen dy't wy operearje en metriken sammelje dy't fan ús kant as wichtich wurde beskôge, lit it tafersjochsysteem ús gegevens sammelje foar produktteams. Se kinne ynfloed op de gearstalling fan metriken binnen de ynformaasjesystemen dy't wy kontrolearje.
Us kollega kin komme en freegje om wat metriken ta te foegjen dy't nuttich wêze sil foar sawol ús as it team. Of, bygelyks, it team hat miskien net genôch fan 'e basismetriken dy't wy hawwe; se moatte guon spesifike folgje. Yn Grafana meitsje wy in romte foar elk team en jouwe adminrjochten. Ek as in team dashboards nedich hat, mar se sels kinne/net witte hoe't se it dwaan moatte, helpe wy har.
Sûnt wy binne bûten de stream fan it team syn wearde skepping, harren releases en planning, wy komme stadichoan ta de konklúzje dat releases fan alle systemen binne naadloos en kinne wurde rôle út alle dagen sûnder koördinaasje mei ús. En it is wichtich foar ús om dizze releases te kontrolearjen, om't se mooglik de wurking fan 'e applikaasje kinne beynfloedzje en wat brekke, en dit is kritysk. Om releases te behearjen, brûke wy Bamboo, wêrfan wy gegevens krije fia API en kinne sjen hokker releases binne frijjûn yn hokker ynformaasjesystemen en har status. En it wichtichste is op hokker tiid. Wy lizze releasemarkers oer de wichtichste krityske metriken, wat visueel heul yndikatyf is yn gefal fan problemen.
Op dizze manier kinne wy de korrelaasje sjen tusken nije releases en opkommende problemen. It wichtichste idee is om te begripen hoe't it systeem wurket op alle lagen, fluch lokalisearje it probleem en reparearje it krekt sa fluch. It komt ommers faak foar dat wat de measte tiid kostet net it probleem oplosse, mar sykjen nei de oarsaak.
En op dit mêd wolle wy yn de takomst rjochtsje op proaktiviteit. It leafst soe ik graach witte wolle oer in oankommende probleem fan tefoaren, en net nei it feit, sadat ik it earder foarkomme kin as oplosse. Soms komme falske alaarms fan it tafersjochsysteem foar, sawol troch minsklike flaters as troch feroaringen yn 'e applikaasje. En wy wurkje hjir oan, debuggen it en besykje brûkers dy't it by ús brûke oer dit te warskôgjen foardat elke manipulaasje fan it tafersjochsysteem , of útfiere dizze aktiviteiten yn it technyske finster.
Dat, it systeem is lansearre en wurket mei súkses sûnt it begjin fan 'e maitiid ... en toant heul echte winsten. Fansels is dit net de definitive ferzje; wy sille in protte mear nuttige funksjes yntrodusearje. Mar op it stuit, mei safolle yntegraasjes en applikaasjes, is kontrôleautomatisearring echt net te ûntkommen.
As jo ek grutte projekten kontrolearje mei in signifikant oantal yntegraasjes, skriuw dan yn 'e opmerkingen hokker sulveren kûgel jo hjirfoar fûn hawwe.
Boarne: www.habr.com