Ne kemi filluar të mendojmë për krijimin e një sistemi monitorimi gjatë formimit të ekipeve të produktit. U bë e qartë se puna jonë - operimi - nuk përfshihet në këto ekipe. Pse ndodh kështu?
Kjo ndodh sepse të gjitha ekipet tona janë ndërtuar rreth sistemeve të veçanta informacioni, mikroshërbimeve dhe fronteve, prandaj gjendja e përgjithshme shëndetësore e sistemit si një tërësi nuk është e dukshme për ekipet. Për shembull, ata mund të mos dinë se si një pjesë e vogël në backend të thellë ndikon në pjesën e frontit. Rrethi i interesave të tyre kufizohet me sistemet me të cilat është integruar sistemi i tyre. Nëse ekipi dhe shërbimi i tij A nuk janë të lidhur pothuajse fare me shërbimin B, atëherë ky shërbim është pothuajse i padukshëm për ekipin.
Ekipi ynë, nga ana tjetër, punon me sisteme që janë shumë të integruara me njëra-tjetrën: midis tyre ekzistojnë shumë lidhje, kjo është një infrastrukthrë mjaft e madhe. Dhe nga të gjitha këto sisteme (të cilat, për të thënë të drejtën, janë një numër i madh), varet funksionimi i dyqanit online.
Pra sa është, që departamenti ynë nuk i përket asnjë ekipi, por ndodhet paksa në anë. Në tërë këtë histori, detyra jonë është të kuptojmë në mënyrë të plotë se si funksionojnë sistemet informative, funksionalitetet e tyre, integrimet, softueri, rrjeti, hardueri, dhe si lidhen të gjitha këto me njëra-tjetrën.
Platforma, në të cilën funksionojnë dyqanet tona në internet, duket kështu:
- front
- middle-office
- back-office
Sa do që të donim, nuk ka asnjë rast që të gjitha sistemet të funksionojnë pa probleme dhe pa gabime. Problemi, sërish, është numri i sistemeve dhe integrimeve — në situatën tonë, ndodhin disa incidente të papërshtatshme, pavarësisht cilësisë së testimit. Kështu, ndodhin si brenda një sistemi të veçantë, ashtu edhe në lidhje me integrimin e tyre. Është e nevojshme të monitorohet gjendja e gjithë platformës në mënyrë komplekse, dhe jo vetëm një pjese të saj të veçantë.
Në idealin e saj, monitorimi i shëndetit të gjithë platformës duhet të automatizohet. Dhe ne arritëm te monitorimi si një pjesë e paevitueshme e këtij procesi. Fillimisht, ai u ndërtua vetëm për pjesën e parë, ndërsa sistemet tona të monitorimit në nivele ishin dhe janë ende të pranishme tek rrjetistët, administratorët e softuerit dhe të harduerit. Të gjithë këta individë e ndiqnin monitorimin vetëm në nivelin e tyre, pa pasur një kuptim kompleks të situatës.
Për shembull, nëse një makinë virtuale ka rënë, në shumicën e rasteve, për këtë e di vetëm administratori që është përgjegjës për harduerin dhe makinën virtuale. Ekipi i front-end në raste të tilla sheh vetëm faktin e rënies së aplikacionit, por nuk ka të dhëna për rënien e makinës virtuale. Ndërsa administratori mund të di se kush është klienti dhe të ketë një ide të përafërt se çfarë po funksionon aktualisht në këtë makinë virtuale, në rast se është një projekt i madh. Për projektet e vogla, nuk do të dijë ndoshta asgjë. Në çdo rast, administratori duhet të shkojë te pronari, të pyesë se çfarë kishte në këtë makinë, çfarë duhet të rikuperohet dhe çfarë duhet ndryshuar. Dhe nëse diçka ishte prishur shumë seriozisht, fillonte një shëtitje rreth e rrotull — sepse askush nuk e kishte parë sistemin në tërësi.
Në fund të fundit, këto histori të ndara ndikon në tërë front-end-in, te përdoruesit dhe funksionin tonë kryesor të biznesit — shitjet në internet. Duke qenë se ne nuk jemi pjesë e ekipeve dhe merremi me operimin e të gjitha aplikacioneve ecommerce brenda dyqanit online, e kemi marrë detyrën për të krijuar një sistem tërësor monitorimi për platformën ecommerce.
Struktura e sistemit dhe stoku
Ne filluam duke identifikuar disa nivele monitorimi për sistemet tona, nëpërmjet të cilave na nevojitet të mbledhim metrika. Dhe e gjithë kjo duhej të ishte e bashkuar, që arritëm ta realizojmë në fazën e parë. Tani, në këtë fazë, po punojmë për të siguruar mbledhjen sa më cilësore të metrikeve në të gjitha nivelet tona, për të ndërtuar korelacion dhe për të kuptuar se si sistemet ndikojnë njëra-tjetrën.
Mungesa e monitorimit të gjithanshëm në fazat e para të lançimit të aplikacioneve (sepse filluam ta ndërtojmë atë kur pjesa më e madhe e sistemeve ishte në përdorim) solli në krijimin e një borxhi të konsiderueshëm teknik lidhur me konfigurimin e monitorimit të gjithë platformës. Nuk mund të përqendroheshim në konfigurimin e monitorimit për një informacion të caktuar dhe ta zhvillojmë atë në detaje, pasi sistemet e tjera do të mbeteshin një kohë pa monitorim. Për të zgjidhur këtë problem, ne përcaktuam një listë të metrikeve më të nevojshme për vlerësimin e gjendjes së informacionit sipas niveleve dhe filluam ta implementojmë atë.
Prandaj, vendosëm ta kalojmë njëherë një copë nga elefanti.
Sistemi ynë përbëhet nga:
- hardware;
- sistemi operativ;
- software;
- Elementet UI në aplikacionin e monitorimit;
- metrikat e biznesit;
- aplikacione integrimi;
- siguria informative;
- rrjetet;
- balancuesi i trafikut.
Qendra e këtij sistemi është monitorimi për vete. Për të kuptuar gjendjen e përgjithshme të të gjithë sistemit, është e nevojshme të dimë se çfarë po ndodh me aplikacionet në të gjitha këto nivele dhe në kontekstin e gjithë shumllojshmërisë së aplikacioneve.
Kështu, për sa i përket stek.
Përdorim softuer me burim të hapur. Në qendër kemi Zabbix, të cilin e përdorim kryesisht si sistem alertrimi. Të gjithëve u është e njohur se ai është perfekt për monitorimin e infrastrukturës. Çfarë do të thotë kjo? Janë pikërisht ato metrika të nivelit të ulët që ka çdo kompani që ka qendrën e saj të të dhënave (dhe Sportmaster ka qendrat e veta të të dhënave) - temperatura e serverëve, gjendja e memories, RAID-it, metrikat e pajisjeve të rrjetit.
Ne kemi integruar Zabbix me mesazherin Telegram dhe Microsoft Teams, të përdorura aktivisht në ekipe. Zabbix pokriva nivelin e rrjetit aktual, harduerit dhe pjesërisht të softuerit, por nuk është panacea. Ne e pasurojmë këtë informacion nga disa shërbime të tjera. Për shembull, në nivelin e harduerit, ne lidhim drejtpërdrejt përmes API në sistemin tonë të virtualizimit dhe marrim të dhëna.
Çfarë tjetër. Përveç Zabbix, ne përdorim Prometheus, i cili lejon monitorimin e metrikave në aplikacione të mjedisit dinamik. Kështu, ne mund të marrim metrika të aplikacionit përmes HTTP endpoint dhe të mos shqetësohemi për ata që duhet t'i ngarkojmë në të, dhe ata që jo. Në bazë të këtyre të dhënave, mund të përpunojmë kërkesat analitike.
Burimet e të dhënave për shtresat e tjera, për shembull, metrikat biznesore, ndahen në tri përbërës.
Së pari, janë sistemet e jashtme të biznesit, Google Analytics, nga të cilat mbledhim metrikat nga log-et. Nga to, ne marrim të dhëna për përdoruesit aktivë, konversionet dhe gjithçka tjetër të lidhur me biznesin. Së dyti, është sistemi i monitorimit të UI. Për këtë duhet të flasim më në detaje.
Njëherë ne kemi filluar me testimin manual dhe e kemi zhvilluar në teste automatike për funksionalitetin dhe integrimet. Nga kjo, ne kemi krijuar monitorimin, duke lënë vetëm funksionalitetin kryesor dhe duke u lidhur me shenjat që janë sa më të qëndrueshme dhe që nuk ndryshojnë shpesh me kalimin e kohës.
Struktura e re e ekipeve parashikon që të gjitha aktivitetet në aplikacione të mbyllen brenda ekipeve produktive, prandaj ne kurrë nuk merremi më me testimin e pastër. Në vend të kësaj, ne kemi bërë monitorim UI, të shkruar në Java, Selenium dhe Jenkins (i përdorur si sistem për ekzekutimin dhe krijimin e raporteve).
Ne kishim shumë teste, por përfundimisht vendosëm të dalim në rrugën kryesore, metrikat e nivelit të lartë. Dhe nëse do të kesh shumë teste specifike, do të ishte e vështirë të mbaje të dhënat aktuale. Çdo lëshim i mëpasshëm do të prishte ndjeshëm të gjithë sistemin, dhe ne vetëm do të merreshim me riparimin e tij. Prandaj, ne u lidhëm vetëm me gjërat thelbësore, që ndryshojnë rrallë dhe monitorojmë vetëm ato.
Së fundi, në tretin vend, burimi i të dhënave është një sistem i centralizuar i regjistrimit. Për log-et përdorim Elastic Stack, dhe më pas mund t'i sjellim këto të dhëna në sistemin tonë të monitorimit të metricave të biznesit. Përveç gjithçkaje tjetër, funksionon edhe shërbimi ynë Monitoring API, i shkruar në Python, i cili pyet përmes API çdo shërbim dhe merr të dhënat nga ata në Zabbix.
Një tjetër atribut i paçmuar i monitorimit është vizualizimi. Kjo realizohet mbi bazën e Grafana-s. Ndër sistemet e tjera të vizualizimit, ajo dallohet për faktin se në dashboard mund të vizualizosh metrika nga burime të ndryshme të dhënash. Mund të mbledhim metrika në nivel të lartë të një dyqani online, për shembull, numrin e porosive të bëra në orën e fundit nga DBMS, metrika të performancës së OS-së mbi të cilën është aktivizuar ky dyqan online nga Zabbix, dhe metrika të instancave të kësaj aplikacioni nga Prometheus. Dhe e gjithë kjo do të jetë në një dashboard. E qartë dhe e qasshme.
Dua të flas për sigurinë — për momentin po përfundojmë një sistem që më vonë do ta integrojmë me një sistem global të monitorimit. Sipas mendimit tim, problemet kryesore me të cilat përballet e-commerce në fushën e sigurisë informative lidhen me robotët, parserët dhe brute force. Është e rëndësishme të monitorohet kjo, sepse gjithçka mund të ndikojë ndjeshëm si në funksionimin e aplikacioneve tona, ashtu edhe në reputacionin e biznesit. Me stack-un e zgjedhur, i mbulojmë me sukses këto sfida.
Një pikë tjetër e rëndësishme është se niveli i aplikacioneve mblidhet nga Prometheus. Ai gjithashtu është i integruar me Zabbix. Po ashtu, kemi sitespeed, një shërbim që na lejon të shohim parametra të tillë si shpejtësia e ngarkesës së faqes tonë, ngushticat, vizualizimi i faqes, ngarkimi i skripteve dhe të tjera, gjithashtu i integruar përmes API. Kështu që metrikat mblidhen në Zabbix, dhe ne gjithashtu alertojmë nga aty. Të gjitha alarmin dergohen përmes mënyrave kryesore të dërgimit (për momentin, këto janë email dhe telegram, dhe së fundmi kemi lidhur gjithashtu MS Teams). Në planet tona është përmirësimi i alertimit deri në një gjendje ku robotët inteligjentë do të punojnë si shërbim dhe do të ofrojnë informacion mbi monitorimin për të gjitha ekipet produktive që janë të interesuara.
Për ne janë të rëndësishme metrikat jo vetëm të sistemeve informacioni të veçuara, por edhe metrikat e përgjithshme për të gjithë infrastrukturën që aplikacionet përdorin: klasterët serverëve fizikë, mbi të cilët funksionojnë virtualkat, balancuesit e trafikut, Network Load Balancer-at, vetë rrjeti, përdorimi i kanaleve të komunikimit. Përveç kësaj, metrikat për qendrat tona të të dhënave (kemi disa dhe infrastruktura është mjaft e madhe).
Avantazhet e sistemit tonë të monitorimit janë se me ndihmën e tij ne shohim gjendjen e funksionimit të të gjitha sistemeve, mund të vlerësojmë ndikimin e tyre mbi njëri-tjetrin dhe mbi burimet e përbashkëta. Dhe në fund, ajo na lejon të merremi me planifikimin e burimeve, që gjithashtu është pjesë e përgjegjësisë sonë. Ne menaxhojmë burimet serverike - një basen brenda e-commerce, futim-dalim nga përdorimi pajisje të reja, blejmë të reja, kryejmë auditimin e riciklimit të burimeve dhe të tjera. Çdo vit ekipet planifikojnë projekte të reja, zhvillojnë sistemet e tyre, dhe është e rëndësishme për ne të sigurojmë burime për to.
Dhe me ndihmën e metrikave ne shohim tendencën e konsumit të burimeve nga sistemet tona informuese. Dhe bazuar në to, mund të planifikojmë diçka. Në nivelin e virtualizimit grumbullojmë të dhëna dhe shohim informacionin në lidhje me sasinë e burimeve të disponueshme në mënyrë të ndarë për qendrat e të dhënave. Dhe brenda qendrës së të dhënave shikohet si riciklimi ashtu edhe shpërndarja faktike, konsumimi i burimeve. Kjo ndodh si me serverët standalone ashtu edhe me makinat virtuale dhe klasteret e serverëve fizikë, mbi të cilat të gjitha këto virtuale funksionojnë lehtësisht.
Perspektivat
Tani kemi një sistem të gatshëm në përgjithësi, por ka ende disa çështje mbi të cilat duhet të punojmë. Të paktën kjo përfshin layers e sigurisë informative, ndërsa është gjithashtu e rëndësishme të arrijmë në rrjet, të zhvillojmë alarmet dhe të zgjidhim çështjen e korrelacionit. Kemi shumë nivele dhe sisteme, dhe në çdo nivel ka gjithashtu shumë metrika. Kështu krijohet një matryoshka në shkallën e matryoshkës.
Detyra jonë është në fund të fundit për të krijuar alarmet e duhura. Për shembull, nëse ka ndodhur një problem me komponentin hardware, gjithashtu me makinat virtuale, ku kishte një aplikacion të rëndësishëm dhe shërbimi nuk ishte ashtu siç duhej. Ne do të zbulojmë se makina virtuale ka vdekur. Më pas, do të alarmojmë metrikat e biznesit: përdoruesit janë humbur diku, nuk ka konversion, UI në ndërfaqe nuk është i aksesueshëm, gjithashtu programet dhe shërbimet kanë vdekur.
Me këto rrethana, do të marrim spam nga alarmet, dhe kjo nuk përputhet me formatin e duhur të një sistemi monitorimi. Lind pyetja e korelacionit. Prandaj, në mënyrë ideale, sistemi ynë i monitorimit duhet të thotë: "Djem, makina fizike vdiq, dhe me të shkuan kjo aplikacion dhe këto metrika", me një alarm të vetëm në vend që të na bombardohet me njëqind alarmet. Ai duhet të raportojë të rëndësishmen — shkakun, që ndihmon në përshpejtimin e zgjidhjes së problemit përmes lokalizimit të tij.
Sistemi ynë i njoftimeve dhe përpunimi i alarmet janë ndërtuar në rrethin e shërbimit telefonik të nxehtë njëzet e katër orë. Të gjitha alarmet që ne i konsiderojmë si një domosdoshmëri dhe përfshihen në listën e kontrollit, dërgohen atje. Çdo alarm duhet të ketë patjetër një përshkrim: çfarë ndodhi, çfarë do të thotë, për çfarë ndikon. Dhe gjithashtu një lidhje për panelin e kontrollit dhe një udhëzim se çfarë duhet të bëjmë në këtë rast.
Këto janë të gjitha kërkesat për ndërtimin e alarmimit. Situata më pas mund të zhvillohet në dy drejtime — ose ka një problem dhe duhet të zgjidhet, ose ka ndodhur një dështim në sistemin e monitorimit. Por në çdo rast, duhet të shkojmë dhe të hetojmë.
Në mesatare, tani na bien rreth njëqind alerte në ditë, duke marrë parasysh se korelacioni i alerteve ende nuk është konfiguruar siç duhet. Dhe nëse duhet të kryhen punë teknike, dhe ne disablokojmë diçka me forcë, numri i tyre rritet shumëfish.
Përveç monitorimit të sistemeve që ne operojmë dhe mbledhjes së metrikave, të cilat në anën tonë përbëjnë informacion të rëndësishëm, sistemi i monitorimit lejon mbledhjen e të dhënave për ekipet e produktit. Ato mund të ndikojnë në përmbajtjen e metrikave brenda sistemeve informative që monitorohen nga ne.
Kolegu ynë mund të vijë dhe të kërkojë të shtohet ndonjë metrikë, e cila do të jetë e dobishme si për ne, ashtu edhe për ekipin. Ose, për shembull, ekipi mund të mos jetë i kënaqur me metrikat bazë që kemi, ata mund të duan të ndjekin ndonjë specifike. Në Grafana krijojmë një hapësirë për çdo ekip dhe ofrojmë të drejtat e adminit. Po ashtu, nëse ekipi ka nevojë për panelë, por ata vetë nuk mund/din si ta bëjnë këtë, ne i ndihmojmë.
Duke jemi jashtë fluxit të krijimit të vlerave të ekipit, publikimeve të tyre dhe planifikimit, po arrijmë gradualisht në një situatë ku të gjitha publikimet e sistemeve janë pa ndërprerje dhe mund të lëshohen çdo ditë, pa u koordinuar me ne. Është e rëndësishme për ne që të ndjekim këto publikime, pasi ato potencialisht mund të ndikojnë në funksionimin e aplikacionit dhe të shkaktojnë ndonjë problem, gjë që është kritike. Për menaxhimin e publikimeve përdorim Bamboo, nga ku marrim të dhëna përmes API-t dhe mund të shohim se cilat publikime kanë dalë në cilat sisteme informacioni dhe statusin e tyre. Dhe më e rëndësishmja — në çfarë kohe. Ne vendosim tregues për publikimet në metrikat tona kryesore, që vizualisht janë shumë treguese në rast të problemeve.
Kështu, ne mund ta shohim korrelacionin mes publikimeve të reja dhe problemeve që shfaqen. Ideja kryesore është të kuptojmë se si funksionon sistemi në të gjitha nivelet, të lokalizojmë shpejt problemin dhe ta riparojmë po ashtu shpejt. Sepse shpesh ndodh që më shumë kohë shkon për të gjetur shkakun, sesa për të zgjidhur problemin.
Në këtë drejtim, në të ardhmen do të dëshirojmë të fokusojmë mbi proaktivitetin. Ideali do të ishte të dijmë paraprakisht për një problem që po afron, e jo pas faktit, për të parandaluar atë, jo për ta zgjidhur. Ndonjëherë ndodhin alarmime të rreme nga sistemi i monitorimit, si për shkak të gabimeve njerëzore, ashtu edhe për shkak të ndryshimeve në aplikacion. Po punojmë mbi këtë, duke e rregulluar, dhe përpiqemi që para çdo manipulimi me sistemin e monitorimit të paralajmërojmë përdoruesit që e përdorin atë me ne, ose të kryejmë këto aktivitete në një dritare teknike.
Pra, sistemi është lançuar dhe funksionon me sukses që nga fillimi i pranverës… dhe tregon një fitim të dukshëm. Sigurisht, kjo nuk është versioni përfundimtar, ne do të integrojmë shumë funksionalitete të tjera. Por në këtë moment, me kaq shumë integrime dhe aplikacione, pa automatizimin e monitorimit, në fakt, nuk mund të kalojmë.
Nëse ju gjithashtu monitoroni projekte të mëdha me një numër serioz integrimesh — shkruani në komentet se çfarë zgjidhje të shkëlqyer keni gjetur për këtë.
Burimi: habr.com
