Jelenleg a DevOps téma van a középpontban. A folyamatos integráció és szállítás csatornája mostanra már mindenki bevezeti, akinek kedve tartja. De a legtöbben nem mindig fordítanak megfelelő figyelmet az informatikai rendszerek megbízhatóságának biztosítására a CI/CD Pipeline különböző szakaszaiban. Ebben a cikkben az én szoftverminőségi ellenőrzések automatizálásáról és a rendszeres „ön-helyreállítással” kapcsolatos lehetséges forgatókönyvekről szeretnék beszélni.
Mérnökként dolgozom az IT-szolgáltatások menedzsment osztályán a A szakterületem a különböző teljesítmény- és elérhetőségi monitorozó rendszerek bevezetése. Gyakran beszélgetek IT-megrendelőkkel a piacon különböző szegmensekből a szolgáltatásaik minőségi monitorozásának aktuális problémáiról. A fő feladat – minimalizálni a kiadási ciklus idejét és növelni a kiadások gyakoriságát. Ez természetesen mind szép és jó: több kiadás – több új funkciók – több elégedett felhasználó – nagyobb jövedelem. De a valóságban nem mindig alakulnak így a dolgok. Nagy telepítési sebességeknél azonnal felmerül a kérdés a kiadások minőségéről. Még egy teljesen automatizált csatornával is az egyik legnagyobb probléma a szolgáltatások átvitele a tesztelésből a termelésbe anélkül, hogy az befolyásolná a megbízhatóságot és a felhasználók interakcióját az alkalmazással.
Számos megbeszélés után a megrendelőkkel elmondhatom, hogy a kiadások minőségi ellenőrzése, az alkalmazás megbízhatósági problémája és az „ön-helyreállítás” lehetősége (például a stabil verzióra való visszaállás) a CI/CD csatorna különböző szakaszaiban - a legizgalmasabb és legaktuálisabb témák közé tartozik.
Nemrég én magam is a megrendelő oldalán dolgoztam - egy online bank alkalmazásának támogatási osztályán. Az alkalmazásunk architektúrájában sok házi mikroservice volt. A legszomorúbb, hogy nem minden fejlesztő tudta tartani a magas fejlesztési sebességet, néhány mikroservice minősége szenvedett, ami vicces beceneveket eredményezett számukra és alkotóiknak. Megjelentek legendák arról, hogy milyen anyagokból készülnek ezek a termékek.
Feladat meghatározása
A gyakori kiadási frekvencia és a sok mikroservice megnehezíti az alkalmazás működésének megértését, mind a tesztelési, mind a működési szakaszban. A változások folyamatosan zajlanak, és nehéz őket jó monitorozó eszközök nélkül kontrollálni. Gyakran a reggeli kibocsátás után a fejlesztők feszülten ülnek, mint a lőporos hordón, és várják, hogy ne legyen probléma, bár a tesztelés során minden ellenőrzés sikeres volt.
Van még egy szempont. A tesztelési szakaszban ellenőrzik a szoftver működését: az alkalmazás fő funkcióinak végrehajtását és a hibák hiányát. A teljesítmény minőségi értékelései vagy hiányoznak, vagy nem veszik figyelembe az alkalmazás és az integrációs réteg összes aspektusát. Egyes metrikákat egyáltalán nem ellenőriznek. Ennek eredményeként, ha hiba lép fel a termelési környezetben, a műszaki támogatás csak akkor értesül róla, amikor a valós felhasználók panaszkodni kezdenek. Minimálisra szeretnénk csökkenteni a gyenge minőségű szoftver végfelhasználókra gyakorolt hatását.
A probléma megoldásának egyik módja a szoftverminőség-ellenőrzési folyamatok bevezetése a CI/CD Pipeline különböző szakaszaiban, valamint különböző helyreállítási forgatókönyvek hozzáadása vészhelyzetek esetén. Ne feledjük, hogy DevOps-szal dolgozunk. Az üzlet várja a lehető leggyorsabb új termékek bevezetését. Ezért minden ellenőrzésünknek és forgatókönyvünknek automatizáltnak kell lennie.
A feladat két összetevőre oszlik:
- a tesztelési szakaszban történő minőségellenőrzés (a gyenge minőségű építmények észlelésének automatizálása);
- a szoftver minőségének ellenőrzése a termelési környezetben (automatikus problémadetektáló mechanizmusok és lehetséges forgatókönyvek önálló helyreállításukhoz).
Eszköz a monitorozáshoz és a metrikák gyűjtéséhez
A kitűzött feladatok megvalósításához olyan monitorozórendszerre van szükség, amely képes észlelni a problémákat és továbbítani azokat az automatizáló rendszereknek a CI/CD folyamat különböző szakaszaiban. Pozitív fejlemény lesz, ha a rendszer hasznos metrikákat biztosít különböző csapatok számára: fejlesztés, tesztelés, üzemeltetés. És igazán nagyszerű lenne, ha a vállalkozás számára is.
A metrikák gyűjtésére különböző rendszerek kombinációját használhatjuk (Prometheus, ELK Stack, Zabbix stb.), de véleményem szerint a legjobban az APM (Application Performance Management) osztályba tartozó megoldások felelnek meg ezeknek a feladatoknak.), amelyek jelentősen megkönnyíthetik az életét.
A támogatói szolgálat keretében egy hasonló projektet kezdtem el, a Dynatrace APM osztályú megoldásával. Jelenleg az integrátornál dolgozva jól ismerem a megfigyelőrendszerek piacát. Személyes véleményem: a Dynatrace a legmegfelelőbb a hasonló feladatokhoz.
A Dynatrace megoldás horizontális áttekintést nyújt minden felhasználói műveletről, mély részletezettséggel a kód végrehajtásáig. Nyomon követhetjük a különböző informatikai szolgáltatások közötti interakciós láncot: a frontend web- és mobilalkalmazások szintjeitől, a backend alkalmazásszerverekig, az integrációs buszig és egészen a konkrét adatbázis-hívásig.
. Automatikusan felépíti a rendszer komponensei közötti összes függőséget.
. Automatikusan meghatározza és felépíti a szolgáltatás műveletével kapcsolatos útvonalat.
Ne feledjük, hogy be kell integrálnunk különböző automatizálási eszközökkel. Itt a megoldás rendelkezik egy kényelmes API-val, amely lehetővé teszi a különböző metrikák és események átadását és fogadását.
Most pedig térjünk át részletesebben arra, hogyan oldhatjuk meg a feladatokat a Dynatrace rendszer segítségével.
Feladat 1. A minőségellenőrzés automatizálása a tesztelési szakaszban.
Az első feladat az, hogy a problémákat minél korábban észleljük az alkalmazás szállítópipeline szakaszaiban. Csak a "jó" kódmegjelenítések juthatnak el a termelési környezetbe. Ehhez a pipeline-ra további monitorokat kell beépíteni a szolgáltatások minőségének ellenőrzésére a tesztelési szakaszban.
Nézzük lépésről lépésre, hogyan valósítható meg és automatizálható ez a folyamat:
A képen az automatizált szoftverminőség-ellenőrzési lépések folyamata látható:
- a megfigyelőrendszer telepítése (ügynökök telepítése);
- a szoftver minőségének értékeléséhez szükséges események (metrikák és küszöbértékek) meghatározása és azok továbbítása a megfigyelőrendszerbe;
- terhelésgenerálás és teljesítménytesztek futtatása;
- teljesítmény- és elérhetőségi adatok gyűjtése a megfigyelőrendszerben;
- az eseményekre alapozott szoftverminőség-értékelési tesztek adatainak átadása a megfigyelő rendszerből a CI/CD rendszerbe. Az építmények automatikus elemzése.
1. lépés. A megfigyelő rendszer telepítése
Először is telepítenie kell az ügynököket a tesztkörnyezetébe. A Dynatrace megoldásának egy szép tulajdonsága, hogy egy univerzális ügynököt, a OneAgent-et használ, amely az OS példányra (Windows, Linux, AIX) telepíthető, automatikusan észleli a szolgáltatásait, és elkezdi gyűjteni az azokkal kapcsolatos megfigyelési adatokat. Nincs szüksége külön ügynököt beállítani minden egyes folyamat számára. Hasonló helyzet áll fenn a felhő- és konténerplatformok esetében is. Az ügynökök telepítési folyamatát is automatizálhatja. A Dynatrace kiválóan illeszkedik az „infrastruktúra mint kód” koncepcióba (): már léteznek kész szkriptek és útmutatók minden népszerű platformhoz. Az ügynököt beépíti a szolgáltatása konfigurációjába, és annak telepítésekor azonnal kap egy új szolgáltatást már működő ügynökkel.
2. lépés. A szoftverminőség-értékelési események meghatározása
Most meg kell határoznia a szolgáltatások és üzleti műveletek listáját. Fontos figyelembe venni azokat a felhasználói műveleteket, amelyek üzletileg kritikusak a szolgáltatása számára. Javaslom, hogy konzultáljon üzleti és rendszerelemzőkkel.
Ezután meg kell határoznia, hogy mely metrikákat szeretne bevonni az ellenőrzésbe minden szinten. Például ezek lehetnek a végrehajtási idő (átlag, medián, percentilisek stb. bontásával), hibák (logikai, szolgáltatásbeli, infrastrukturális stb.) és különféle infrastrukturális metrikák (memóriahalom, szemétgyűjtő, szálak száma stb.).
Az automatizálás és a DevOps csapat számára a kényelmes használat érdekében megjelenik a „Megfigyelés mint kód” koncepció. Amit ezzel értek, az az, hogy a fejlesztő/tesztelő egy egyszerű JSON fájlt írhat, amely meghatározza a szoftverminőség-ellenőrzési mutatókat.
Nézzük meg egy ilyen JSON-fájl példáját. A kulcs/érték párként a Dynatrace API objektumait használjuk (az API leírását itt találja: ).
{
"timeseries": [
{
"timeseriesId": "service.ResponseTime",
"aggregation": "avg",
"tags": "Frontend",
"severe": 250000,
"warning": 1000000
},
{
"timeseriesId": "service.ResponseTime ",
"aggregation": "avg",
"tags": "Backend",
"severe": 4000000,
"warning": 8000000
},
{
"timeseriesId": "docker.Container.Cpu",
"aggregation": "avg",
"severe": 50,
"warning": 70
}
]
}A fájl egy időszakok (timeseries) definícióinak tömbje.
- timeseriesId – a mérték, amelyet ellenőrzünk, például Válaszidő, Hiba szám, Használatban lévő memória stb.;
- aggregation — a metrikák aggregálásának szintje, ebben az esetben avg, de bármilyen szükséges szint (avg, min, max, sum, count, percentile) használható.
- tags – az objektum címkéje a monitorozó rendszerben, vagy megadható egy adott objektum azonosítója;
- severe és warning – ezek az értékek szabályozzák metrikáink küszöbértékeit. Ha a teszt értéke meghaladja a severe küszöböt, akkor a gyűjtésünk sikertelennek minősül.
A következő ábrán bemutatásra kerül egy ilyen küszöb használata.
3. lépés: Terhelés generálása
Miután meghatároztuk a szolgáltatásunk minőségi szintjeit, generálnunk kell egy teszt-terhelést. Bármilyen, Ön által preferált tesztelési eszközt használhat, például Jmeter, Selenium, Neotys, Gatling stb.
A Dynatrace monitorozó rendszer lehetővé teszi a különböző metaadatok rögzítését a tesztjeiből, és képes megkülönböztetni, hogy melyik teszt melyik kiadási ciklushoz és melyik szolgáltatáshoz tartozik. Ajánlott kiegészítő fejléceket hozzáadni a teszt HTTP-kéréséhez.
A következő ábrán látható példa, ahol az X-Dynatrace-Test kiegészítő fejléccel jelöljük, hogy ez a teszt a termék kosárba helyezésének teszteléséhez kapcsolódik.
Minden terhelési teszt indításakor kiegészítő kontextuális információt küld a Dynatrace rendszernek a CI/CD szerver esemény API-ján keresztül. Így a rendszer megkülönböztetheti a különböző teszteket egymástól.
. A tesztelési rendszer eseménye a terhelési teszt indításáról
4-5. lépés: Teljesítményadatok gyűjtése és az adatok átadása a CI/CD rendszernek
A generált teszttel együtt egy eseményt is továbbítunk a monitorozó rendszerbe, amely jelzi a szolgáltatás minőségi mutatóinak ellenőrzésére vonatkozó adatok gyűjtésének szükségességét. A JSON-fájlunkat is megadjuk, amely tartalmazza a kulcsfontosságú metrikákat.
Az CI/CD szerveren generált szoftverminőségi ellenőrzésről szóló esemény, amelyet a monitorozó rendszerbe küldenek.
Példánkban a minőségellenőrzés eseménye az alábbi neveket kapta: perfSigDynatraceReport (Performance_Signature) – készen áll a Jenkins-szel való integrációra, amelyet a T-Systems Multimedia Solutions csapata fejlesztett ki. Minden egyes ellenőrzési esemény tartalmaz információt a szolgáltatásról, a build számáról és a tesztelés időpontjáról. A plugin összegyűjti a teljesítményértékeket a build során, értékeli azokat, és összehasonlítja az eredményeket az előző build-ekkel és a nem funkcionális követelményekkel.
A rendszer monitorozásának eseménye a build minőségi ellenőrzésének megkezdésekor.
A teszt befejezése után minden szoftverminőségi érték visszakerül a folyamatos integráció rendszerébe, például a Jenkins-be, amely a teszt eredményeit tartalmazó jelentést állít elő.
Statisztikai eredmények a CI/CD szerver build-jeiről.
Minden egyes build esetében látjuk az általunk meghatározott metrikák statisztikáit a teszt futása alatt. Jó látni, ha bizonyos küszöbértékek (figyelmeztetések és súlyos küszöbök) megsértésre került. Az összesített mutatók alapján az egész buildet stabilnak, instabilnak vagy sikertelennek jelöljük. Az Ön kényelme érdekében a jelentéshez hozzáadhatjuk a aktuális build és az előző közötti összehasonlító mutatószámokat is.
Részletes statisztika megtekintése a CI/CD szerver build-jeiről.
Két build részletes összehasonlítása
Szükség esetén áttérhet a Dynatrace interfészére, ahol részletesebben megtekintheti minden build statisztikáját és összehasonlíthatja őket.
A build-ek statisztikájának összehasonlítása a Dynatrace-ban.
Következtetések
Végül egy "monitorozás mint szolgáltatás" rendszert kapunk, amely automatizálva van a folyamatos integrációs folyamatban. A fejlesztőnek vagy tesztelőnek csupán meg kell határoznia a metrikák listáját egy JSON-fájlban, a többi automatikusan történik. Átlátható minőségellenőrzést kapunk a kiadásokban: minden teljesítmény-értesítés, erőforráshasználat vagy architekturális visszaesés biztosítva van.
Feladat 2. A szoftverminőség automatizált ellenőrzése a produkciós környezetben.
Tehát megoldottuk azt a feladatot, hogyan automatizálhatjuk a nyomkövető folyamatot a Pipeline tesztelési szakaszában. Így minimalizáljuk a gyenge minőségű build-ek arányát, amelyek eljutnak a produkciós környezetbe.
De mi a teendő, ha a rossz szoftver mégis eljutott a termelésbe, vagy egyszerűen valami elromlik? Utopikus módon azt szerettük volna, ha léteznek automatikus problémadetektáló mechanizmusok, és ha lehetséges, a rendszer önállóan helyreállítja a működőképességét, legalább éjszaka.
Ehhez hasonlóan az előző szakaszhoz, automatikus szoftverminőség-ellenőrző eljárásokat kell terveznünk a termelési környezetben, és ezt alátámasztó ön-helyreállító forgatókönyveket kell kidolgoznunk.
Ön-helyreállítás kód formájában
A legtöbb vállalatnál már létezik egy felhalmozott tudásbázis a különböző típusú gyakori problémákról, és egy cselekvési lista az azok megoldására, például folyamatok újraindítása, erőforrások tisztítása, verziók visszaállítása, helytelen konfigurációs módosítások helyreállítása, a klaszter komponenseinek számának növelése vagy csökkentése, valamint kék vagy zöld réteg váltása stb.
Annak ellenére, hogy ezek a használati esetek már sok éve ismertek sok csapat számára, akikkel beszélgettem, csak néhányan gondolkodtak el és fektettek be az automatizálásukba.
Ha átgondoljuk, a működőképesség automatikus helyreállítási folyamatainak megvalósítása nem olyan bonyolult, fontos, hogy a már ismert rendszereket, amelyeket az adminisztrátorok használnak, kód forgatókönyvek formájában ábrázoljuk (az "önerősítés mint kód" koncepció), amelyeket előre megírtál az egyes esetekhez. Az automatikus helyreállítási forgatókönyveknek a probléma gyökerének megszüntetésére kell irányulniuk. Magad állítod be a megfelelő válaszreakciókat az incidensre.
A forgatókönyv elindításának kiváltó impulzusaként bármilyen metrika szolgálhat a monitoring rendszeredből, a fontos az, hogy ezek a metrikák pontosan meghatározzák, hogy minden rosszul áll, mert nem lenne jó, ha hamis riasztások lennének a termelési környezetben.
Bármilyen rendszert vagy rendszerek összességét használhatod: Prometheus, ELK Stack, Zabbix stb. De néhány példát fogok mondani az APM megoldása alapján (példaként ismét a Dynatrace-t hozom), amely szintén megkönnyítheti az életed.
Először is, itt minden a működőképességről szól az alkalmazás szempontjából. A megoldás több száz metrikát biztosít különböző szinteken, amelyeket kiváltó impulzusokként használhatsz:
- felhasználói szint (böngészők, mobilalkalmazások, IoT-eszközök, felhasználói viselkedés, konverzió stb.);
- szolgáltatási és működési szint (teljesítmény, elérhetőség, hibák stb.);
- alkalmazás infrastruktúrájának szintje (OS-metrikák, JMX, MQ, web-szerver stb.);
- platformok szintje (virtualizáció, felhő, konténer stb.).
Monitorozási szintek a Dynatrace-ban.
Második lépésként, ahogy korábban említettem, a Dynatrace nyílt API-t kínál, ami lehetővé teszi a különböző külső rendszerekkel való kényelmes integrációt. Például értesítés küldése az automatizálási rendszerbe, ha a kontroll paraméterek átlépésre kerülnek.
Az alábbiakban bemutatok egy példát az Ansible-lal való interakcióra.
Ezután néhány példát hozok arra, hogy milyen automatizálásokat lehet végezni. Ezek csupán esettanulmányok, listájuk a környezetedben csupán a fantáziád és a monitorozó eszközeid lehetőségei révén korlátozódik.
1. Rossz deploy – verzió visszaállítása
Még ha mindent nagyon alaposan ellenőrzünk is a tesztkörnyezetben, mindig van esély arra, hogy az új kiadás megöli az alkalmazásodat a termelési környezetben. Ugyanis a humán faktor senkitől sem mentes.
A következő ábrán látható, hogy hirtelen megugrik az operációk végrehajtási ideje a szolgáltatásban. Ennek az ugrásnak a kezdete egybeesik az alkalmazásra való deploy időpontjával. Mindezt eseményekként továbbítjuk az automatizálási rendszerbe. Ha a szolgáltatás működése nem normalizálódik az általunk megadott idő elteltével, automatikusan egy script hívódik meg, amely visszaállítja a verziót a régi állapotra.
A műveletek teljesítményének csökkenése a deploy után.
2. 100%-os erőforrás-használat — csomópont hozzáadása az irányításhoz
A következő példában a monitorozó rendszer meghatározza, hogy az egyik komponensnél a CPU terhelése 100%-ra értékelhető.
CPU terhelés 100%
Egy adott eseményhez több különböző forgatókönyv is kapcsolódik. Például a monitorozó rendszer ellenőrzi, hogy a forráshiány összefügg-e a szolgáltatás terhelésének növekedésével. Ha igen, egy script fut, amely automatikusan hozzáad egy csomópontot az irányításhoz, ezáltal helyreállítva a rendszer működőképességét.
Skálázás incidens után
3. Nincs hely a merevlemezen – lemez tisztítása
Azt gondolom, hogy ezek a folyamatok sokaknál már automatizáltak. Az APM segítségével a lemezalrendszer szabad helyét is nyomon lehet követni. Helyhiány vagy lassú lemezműködés esetén futtatunk egy tisztító szkriptet, vagy bővítjük a helyet.
A lemezterhelés 100%
4. Alacsony felhasználói aktivitás vagy alacsony konverzió – váltás a kék és zöld ág között
Gyakran találkozom megrendelőkkel, akik két vonalat (blue-green deploy) használnak a termelési környezetben lévő alkalmazásokhoz. Ez lehetővé teszi a gyors váltást a vonalak között az új verziók telepítésekor. Gyakran a telepítés után jelentős változások következhetnek be, amelyeket nem észlelünk azonnal. Eközben a teljesítmény- és elérhetőségi degradáció nem figyelhető meg. Az ilyen változásokra való gyors reagálás érdekében érdemes különböző metrikákat használni, amelyek a felhasználók viselkedését tükrözik (ülések és felhasználói műveletek száma, konverzió, bounce rate). A következő ábrán egy példa látható, amely során a konverzió csökkenése miatt váltás történik a szoftver ágai között.
A konverzió csökkenése a szoftver ágai közötti váltás után.
Automatikus problémafelismerési mechanizmusok
A végén megosztok még egy példát, amiért a legjobban szeretem a Dynatrace-t.
Az előadásom részében a tesztkörnyezetben az építmények minőségének ellenőrzésének automatizálásáról minden küszöbértéket manuálisan határoztunk meg. A tesztkörnyezetben ez normális, a tesztelő készít elő minden mutatót a terhelés függvényében. A termelési környezetben célszerű, hogy a problémákat automatikusan észleljük a különböző baseline mechanizmusok figyelembevételével.
A Dynatrace érdekes beépített mesterséges intelligencia eszközöket tartalmaz, amelyek az anomális metrikák (baselining) meghatározásának mechanizmusai és az összes komponens közötti interakciós térkép elkészítése alapján, összehasonlítva és korrelálva az eseményeket, az Ön szolgáltatásának működésében anomáliákat határoznak meg és részletes információkat nyújtanak minden problémáról és gyökérokáról.
A Dynatrace automatikus elemzése révén a rendszer nemcsak azt állapítja meg, hogy a problémás szolgáltatás a fő ok-e, hanem azt is, hogy milyen mértékben függ más szolgáltatásoktól. Az alább bemutatott példában a Dynatrace automatikusan követi és értékeli az egyes szolgáltatások működőképességét a tranzakciók végrehajtása során, azonosítva a Golang szolgáltatást mint a fő okot.
A hiba gyökérokának meghatározásának példája.
A következő ábrán látható, hogyan figyeli a rendszer a problémákat az alkalmazásoddal az incidens kezdetétől.
A felmerült probléma vizualizálása, amely az összes összetevő és az azokhoz kapcsolódó események megjelenítését tartalmazza.
A megfigyelőrendszer teljes időrendben gyűjtötte a problémával kapcsolatos eseményeket. Az időgrafikon alatti ablakban láthatjuk a legfontosabb eseményeket minden összetevőnél. Ezek alapján eljárási kód-szkripteket hozhatunk létre az automatikus javítás érdekében.
Javaslom, hogy integrálj egy megfigyelőrendszert a Service Desk-el vagy a hibakövetővel. Probléma esetén a fejlesztők gyorsan megkapják a teljes információt a kód szintjén történő elemzéshez a termelési környezetben.
Zárás
Végül létrejött egy CI/CD csővezetékünk beépített automatizált szoftverminőség-ellenőrzésekkel a Pipeline-ben. Minimalizáljuk a gyenge minőségű összesítések számát, javítjuk a rendszer megbízhatóságát összességében, és ha a rendszer működése mégis megszakad, elindítjuk a helyreállítási mechanizmusokat.
Az automatizált szoftverminőség-ellenőrzésbe való befektetés mindenképpen megéri, nem mindig gyors folyamat, de idővel kifizetődik. Javaslom, hogy egy új incidens megoldása után azonnal gondolkodj el azon, hogy milyen megfigyelőket szeretnél hozzáadni a tesztkörnyezetben, hogy elkerüld a gyenge minőségű összesítések bejutását a termelésbe, valamint készíts egy szkriptet a problémák automatikus javítására.
Remélem, hogy a példáim segítenek neked a próbálkozásaidban. Szívesen látnám a saját példáidat is a rendszerek önjavító működésének megvalósításához használt metrikákról.
Forrás: habr.com
