Már a termékcsapatok kialakításának szakaszában gondolkodtunk egy monitoring rendszer létrehozásán. Világossá vált, hogy a mi üzletünk - a kizsákmányolás - nem tartozik ezekbe a csapatokba. Miert van az?
A helyzet az, hogy minden csapatunk egyedi információs rendszerek, mikroszolgáltatások és frontok köré épül, így a csapatok nem látják a teljes rendszer egészének állapotát. Előfordulhat például, hogy nem tudják, hogy a mély háttérprogram egy kis része hogyan hat az előtérre. Érdeklődési körük azokra a rendszerekre korlátozódik, amelyekkel rendszerük integrálva van. Ha egy csapatnak és A szolgáltatásának szinte semmi köze nincs a B szolgáltatáshoz, akkor egy ilyen szolgáltatás szinte láthatatlan a csapat számára.
Csapatunk viszont olyan rendszerekkel dolgozik, amelyek nagyon erősen integráltak egymással: sok kapcsolat van köztük, ez egy nagyon nagy infrastruktúra. Az online áruház működése pedig mindezen rendszereken múlik (amelyekből egyébként óriási számunk van).
Így kiderül, hogy osztályunk nem tartozik egyik csapathoz sem, hanem egy kicsit oldalt található. Ebben az egész történetben az a feladatunk, hogy átfogóan megértsük az információs rendszerek működését, azok funkcionalitását, integrációit, szoftverét, hálózatát, hardverét, és mindez hogyan kapcsolódik egymáshoz.
A platform, amelyen webáruházaink működnek, így néz ki:
- front
- középső iroda
- back office
Bármennyire is szeretnénk, nem fordul elő, hogy minden rendszer zökkenőmentesen és hibátlanul működjön. A lényeg ismét a rendszerek és az integrációk száma – a miénkhez hasonló dolgokkal a tesztelés minősége ellenére elkerülhetetlenek bizonyos incidensek. Sőt, mind külön rendszeren belül, mind azok integrációja szempontjából. És átfogóan figyelemmel kell kísérnie a teljes platform állapotát, és nem csak annak egyes részeit.
Ideális esetben a platformszintű állapotfigyelést automatizálni kell. És eljutottunk a monitorozáshoz, amely ennek a folyamatnak az elkerülhetetlen része. Kezdetben csak a front-line részre épült, míg a hálózati szakemberek, szoftver- és hardveradminisztrátorok saját rétegenkénti felügyeleti rendszerrel rendelkeztek és rendelkeznek. Mindezek az emberek csak a saját szintjén követték a monitorozást, átfogó megértése sem volt senkinek.
Például, ha egy virtuális gép összeomlik, a legtöbb esetben csak a hardverért és a virtuális gépért felelős rendszergazda tud róla. Ilyen esetekben a frontvonal csapata az alkalmazás összeomlásának tényét látta, de a virtuális gép összeomlásáról nem rendelkezett adatokkal. Az adminisztrátor pedig tudhatja, hogy ki az ügyfél, és hozzávetőleges elképzelése van arról, hogy jelenleg mi fut ezen a virtuális gépen, feltéve, hogy ez valamilyen nagy projekt. Valószínűleg nem tud a kicsikről. Mindenesetre az adminisztrátornak el kell mennie a tulajdonoshoz és megkérdezni, hogy mi volt ezen a gépen, mit kell visszaállítani és mit kell változtatni. És ha valami nagyon komoly elromlott, akkor körbe-körbe futni kezdtek – mert senki sem látta a rendszer egészét.
Az ilyen eltérő történetek végső soron az egész frontendet, a felhasználókat és az alapvető üzleti funkciónkat – az online értékesítést – érintik. Mivel nem vagyunk egy csapat részei, hanem az összes e-kereskedelmi alkalmazás működtetésével foglalkozunk egy webáruház részeként, ezért vállaltuk az e-kereskedelmi platform átfogó felügyeleti rendszerének elkészítését.
A rendszer felépítése és verem
Kezdetben több megfigyelési réteget azonosítottunk rendszereink számára, amelyeken belül mérőszámokat kell gyűjtenünk. És mindezt kombinálni kellett, amit az első szakaszban meg is tettünk. Most ebben a szakaszban véglegesítjük a legmagasabb minőségű mérőszám-gyűjteményt minden rétegünkben, hogy összefüggést építsünk ki, és megértsük, hogy a rendszerek hogyan hatnak egymásra.
Az átfogó felügyelet hiánya az alkalmazásindítás kezdeti szakaszában (mióta elkezdtük építeni, amikor a legtöbb rendszer már gyártásban volt) oda vezetett, hogy jelentős technikai adósságunk volt a teljes platform felügyeletének beállításához. Nem engedhettük meg magunknak, hogy egy IS monitorozásának felállítására és a monitorozás részletes kidolgozására koncentráljunk, mivel a többi rendszer egy ideig felügyelet nélkül maradna. A probléma megoldása érdekében meghatároztuk az információs rendszer állapotának rétegenkénti értékeléséhez legszükségesebb mérőszámok listáját, és megkezdtük annak megvalósítását.
Ezért úgy döntöttek, hogy az elefántot részenként eszik meg.
Rendszerünk a következőkből áll:
- hardver;
- operációs rendszer;
- szoftver;
- UI részek a megfigyelő alkalmazásban;
- üzleti mérőszámok;
- integrációs alkalmazások;
- információ biztonság;
- hálózatok;
- forgalom kiegyenlítő.
Ennek a rendszernek a középpontjában önmaga figyelése áll. A teljes rendszer állapotának általános megértéséhez tudnia kell, hogy mi történik az alkalmazásokkal ezeken a rétegeken és a teljes alkalmazáskészleten.
Szóval a veremről.
Nyílt forráskódú szoftvereket használunk. A központban a Zabbix található, amelyet elsősorban riasztórendszerként használunk. Mindenki tudja, hogy ideális az infrastruktúra megfigyelésére. Mit is jelent ez? Pontosan azok az alacsony szintű mérőszámok, amelyekkel minden saját adatközpontot fenntartó cég rendelkezik (a Sportmasternek pedig saját adatközpontja van) - szerver hőmérséklet, memória állapot, raid, hálózati eszközök mérőszámai.
Integráltuk a Zabbixot a Telegram messengerrel és a Microsoft Teams-szel, amelyeket aktívan használnak a csapatokban. A Zabbix lefedi a tényleges hálózat rétegét, a hardvert és néhány szoftvert, de ez nem csodaszer. Ezeket az adatokat néhány más szolgáltatásból gazdagítjuk. Például hardver szinten API-n keresztül közvetlenül csatlakozunk virtualizációs rendszerünkhöz, és adatokat gyűjtünk.
Mi más. A Zabbix mellett a Prometheust használjuk, amely lehetővé teszi a metrikák figyelését egy dinamikus környezeti alkalmazásban. Vagyis egy HTTP-végponton keresztül fogadhatjuk az alkalmazási metrikákat, és nem kell aggódnunk, hogy melyik metrikát töltsük be, és melyiket ne. Ezen adatok alapján elemző lekérdezések fejleszthetők.
Az egyéb rétegek adatforrásai, például az üzleti metrikák, három összetevőre vannak osztva.
Először is ezek külső üzleti rendszerek, a Google Analytics, naplókból gyűjtjük a mutatókat. Tőlük kapunk adatokat az aktív felhasználókról, a konverziókról és minden másról, ami az üzlettel kapcsolatos. Másodszor, ez egy UI megfigyelő rendszer. Részletesebben le kellene írni.
Valamikor a kézi teszteléssel kezdtük, és ez a funkcionalitás és az integráció automatikus tesztjévé nőtte ki magát. Ebből monitorozást készítettünk, csak a fő funkcionalitást meghagyva, és a lehető legstabilabb, idővel nem gyakran változó markerekre támaszkodtunk.
Az új csapatstruktúra azt jelenti, hogy minden alkalmazási tevékenység termékcsapatokra korlátozódik, ezért felhagytunk a puszta teszteléssel. Ehelyett Java, Selenium és Jenkins nyelven írt tesztekből UI monitorozást készítettünk (ezt rendszerként használják riportok indítására és generálására).
Rengeteg tesztünk volt, de végül úgy döntöttünk, hogy a főútra, a legfelső szintű mérőszámra megyünk. Ha pedig sok konkrét tesztünk van, akkor nehéz lesz naprakészen tartani az adatokat. Minden egyes következő kiadás jelentősen tönkreteszi az egész rendszert, mi pedig csak kijavítjuk. Ezért nagyon alapvető dolgokra koncentráltunk, amelyek ritkán változnak, és csak azokat figyeljük.
Végül, harmadszor, az adatforrás egy központi naplózórendszer. Az Elastic Stacket használjuk a naplókhoz, majd ezeket az adatokat az üzleti metrikák megfigyelőrendszerébe vonhatjuk be. Mindezek mellett van saját, Pythonban írt Monitoring API szolgáltatásunk, amely API-n keresztül lekérdezi az esetleges szolgáltatásokat, és begyűjti az adatokat a Zabbixba.
A monitorozás másik nélkülözhetetlen tulajdonsága a vizualizáció. A miénk a Grafana alapú. A többi vizualizációs rendszer közül kiemelkedik abban, hogy lehetővé teszi a különböző adatforrásokból származó metrikák megjelenítését az irányítópulton. Összegyűjthetünk egy online áruház legfelső szintű mérőszámait, például a DBMS-ből az elmúlt órában leadott rendelések számát, a Zabbixtól származó teljesítménymutatókat az operációs rendszerhez, amelyen ez az online áruház fut, és az alkalmazás példányaira vonatkozó mérőszámokat. Prométheusztól. És mindez egyetlen műszerfalon lesz. Világos és hozzáférhető.
A biztonsággal kapcsolatban hadd jegyezzem meg – jelenleg a rendszer véglegesítésénél tartunk, amit később integrálunk a globális felügyeleti rendszerbe. Véleményem szerint az e-kereskedelem fő problémái az információbiztonság területén a botokhoz, elemzőkhöz és a nyers erőhöz kapcsolódnak. Erre figyelnünk kell, mert mindez kritikusan befolyásolhatja mind alkalmazásaink működését, mind üzleti szempontból hírnevünket. A kiválasztott veremünkkel pedig ezeket a feladatokat sikeresen megoldjuk.
Egy másik fontos szempont, hogy az alkalmazási réteget a Prometheus állítja össze. Ő maga is integrálva van a Zabbix-szal. És van még a sitespeed, egy olyan szolgáltatásunk, amivel olyan paramétereket tekinthetünk meg, mint az oldalunk betöltési sebessége, szűk keresztmetszetek, oldalmegjelenítés, szkriptek betöltése stb., ez is API integrált. Tehát a mérőszámainkat a Zabbixban gyűjtjük, és ennek megfelelően onnan is riasztunk. Jelenleg minden riasztást a fő küldési módokra küldenek (egyelőre e-mail és távirat, az MS Teams is nemrégiben csatlakozott). A tervek szerint a riasztást olyan állapotra fejlesztik, hogy az intelligens robotok szolgáltatásként működjenek, és minden érdeklődő termékcsapat számára felügyeleti információkat nyújtsanak.
Számunkra a mérőszámok nemcsak az egyes információs rendszerek esetében fontosak, hanem az alkalmazások által használt teljes infrastruktúra általános mérőszámai is: fizikai szerverek klaszterei, amelyeken a virtuális gépek futnak, forgalomelosztók, hálózati terheléselosztók, maga a hálózat, kommunikációs csatornák kihasználtsága. . Plusz a saját adatközpontjaink mérőszámai (több ilyen van, és elég nagy az infrastruktúra).
Monitoring rendszerünk előnye, hogy segítségével minden rendszer egészségi állapotát látjuk, és fel tudjuk mérni egymásra és a megosztott erőforrásokra gyakorolt hatásukat. Végül pedig lehetővé teszi számunkra, hogy részt vegyünk az erőforrás-tervezésben, ami a mi felelősségünk is. Kezeljük a szerver erőforrásokat - egy készletet az e-kereskedelemben, új berendezéseket üzembe helyezünk és leállítunk, további új berendezéseket vásárolunk, auditáljuk az erőforrások felhasználását stb. A csapatok minden évben új projekteket terveznek, rendszereiket fejlesztik, nekünk pedig fontos, hogy erőforrásokat biztosítsunk számukra.
A mérőszámok segítségével pedig látjuk az információs rendszereink erőforrás-felhasználásának trendjét. És ezek alapján tudunk valamit tervezni. Virtualizációs szinten adatokat gyűjtünk, és adatközpontonként információt látunk a rendelkezésre álló erőforrásmennyiségről. És már az adatközponton belül látható az erőforrások újrahasznosítása, tényleges elosztása és felhasználása. Sőt, mind az önálló szerverek, mind a virtuális gépek és a fizikai kiszolgálók fürtjei esetében, amelyeken ezek a virtuális gépek erőteljesen pörögnek.
Kilátások
Most már készen áll a rendszer magja, mint egész, de van még sok minden, amin még dolgozni kell. Ez legalább egy információbiztonsági réteg, de fontos a hálózat elérése, a riasztás fejlesztése és a korrelációs probléma megoldása is. Sok rétegünk és rendszerünk van, és minden rétegen sokkal több mérőszám található. Kiderül, hogy matrjoska a matrjoska mértékére.
A mi feladatunk az, hogy végül megfelelő riasztásokat adjunk. Például, ha probléma volt a hardverrel, akkor megint egy virtuális géppel, és volt egy fontos alkalmazás, és a szolgáltatásról semmilyen módon nem készült biztonsági másolat. Megtudjuk, hogy a virtuális gép meghalt. Ekkor az üzleti mérőszámok riasztanak: a felhasználók eltűntek valahol, nincs konverzió, a kezelőfelület nem elérhető, a szoftverek és a szolgáltatások is elhaltak.
Ebben a helyzetben spameket fogunk kapni a figyelmeztetésektől, és ez már nem fér bele egy megfelelő felügyeleti rendszer formátumába. Felmerül a korreláció kérdése. Ezért ideális esetben a megfigyelőrendszerünknek azt kellene mondania: „Srácok, a fizikai gépetek meghalt, és vele együtt ez az alkalmazás és ezek a mérőszámok” egyetlen riasztás segítségével, ahelyett, hogy száz riasztással dühödten bombáznának bennünket. Jelenteni kell a fő dolgot - az okot, amely lokalizációja miatt segít gyorsan megszüntetni a problémát.
Értesítési rendszerünk és riasztáskezelésünk egy XNUMX órás forródrót szolgáltatás köré épül fel. Minden olyan figyelmeztetés, amely kötelezőnek minősül, és szerepel az ellenőrző listán, oda kerül. Minden riasztásnak tartalmaznia kell egy leírást: mi történt, mit jelent valójában, mit érint. Valamint egy hivatkozás az irányítópultra, valamint utasítások arra vonatkozóan, hogy mit kell tenni ebben az esetben.
Ez mind a riasztás létrehozásának követelményeiről szól. Ekkor két irányba fejlődhet a helyzet - vagy probléma van, és azt kell megoldani, vagy a megfigyelő rendszerben történt hiba. De mindenesetre el kell menned és ki kell találnod.
Naponta átlagosan körülbelül száz riasztást kapunk, figyelembe véve, hogy a riasztások korrelációja még nincs megfelelően konfigurálva. Ha pedig műszaki munkát kell végeznünk, és valamit erőszakkal kikapcsolunk, számuk jelentősen megnő.
Az általunk működtetett rendszerek monitorozása és a számunkra fontosnak tartott mérőszámok gyűjtése mellett a felügyeleti rendszer lehetővé teszi, hogy adatokat gyűjtsünk termékcsapatok számára. Befolyásolhatják a mérőszámok összetételét az általunk felügyelt információs rendszereken belül.
Előfordulhat, hogy kollégánk eljön és kéri, hogy adjunk hozzá valamilyen mérőszámot, ami hasznos lesz számunkra és a csapat számára is. Vagy például előfordulhat, hogy a csapatnak nem elég az alapvető mérőszámainkból, amivel rendelkezünk; nyomon kell követniük néhány konkrétat. A Grafanában minden csapat számára létrehozunk egy teret, és rendszergazdai jogokat biztosítunk. Továbbá, ha egy csapatnak szüksége van műszerfalakra, de ők maguk nem tudják/nem tudják, hogyan csinálják, akkor segítünk nekik.
Mivel kívül vagyunk a csapat értékteremtésének, kiadásainak és tervezésének folyamatán, fokozatosan arra a következtetésre jutunk, hogy az összes rendszer kiadása zökkenőmentes, és a velünk való egyeztetés nélkül naponta kiadható. És fontos számunkra, hogy figyeljük ezeket a kiadásokat, mert potenciálisan befolyásolhatják az alkalmazás működését, és eltörhetnek valamit, és ez kritikus. A kiadások kezeléséhez a Bamboo-t használjuk, ahonnan API-n keresztül adatokat kapunk, és láthatjuk, hogy mely kiadások melyik információs rendszerben jelentek meg, és azok állapotát. És a legfontosabb, hogy mikor. A fő kritikus mérőszámokra kibocsátási jelzőket helyezünk el, ami vizuálisan nagyon jelzésértékű problémák esetén.
Így láthatjuk az összefüggést az új kiadások és a felmerülő problémák között. A fő ötlet az, hogy megértsük a rendszer működését minden szinten, gyorsan lokalizáljuk a problémát, és ugyanolyan gyorsan kijavítjuk. Hiszen sokszor megesik, hogy nem a probléma megoldása, hanem az ok keresése veszi igénybe a legtöbb időt.
Ezen a területen pedig a jövőben a proaktivitásra szeretnénk összpontosítani. Ideális esetben szeretnék előre tudni egy közeledő problémáról, és nem utólag, hogy inkább megelőzhessem, mintsem megoldjam. Néha előfordulnak téves riasztások a felügyeleti rendszerben, mind emberi hiba, mind az alkalmazás változása miatt. Mi pedig ezen dolgozunk, debuggoljuk, és igyekszünk figyelmeztetni erre a velünk együtt használó felhasználókat, mielőtt bármilyen manipulációt végeznének a felügyeleti rendszerrel. , vagy végezze el ezeket a tevékenységeket a technikai ablakban.
Tehát a rendszer elindult és tavasz eleje óta sikeresen működik... és nagyon is valós nyereséget mutat. Természetesen ez nem a végleges verzió, számos további hasznos funkciót mutatunk be. De jelenleg, a sok integráció és alkalmazás mellett a felügyeleti automatizálás valóban elkerülhetetlen.
Ha Ön is figyeli a nagy projekteket, jelentős számú integrációval, írja meg kommentben, hogy milyen ezüst golyót talált erre.
Forrás: will.com