Tesztelés Prod: Canary Deployment rendszeren

A kanári egy kis madár, amely folyamatosan énekel. Ezek a madarak érzékenyek a metánra és a szén-monoxidra. Még a levegőben lévő felesleges gázok kis koncentrációjától is elvesztik eszméletüket vagy meghalnak. Aranyásók és bányászok vitték a madarakat a bányába: amíg a kanárik énekelnek, dolgozhatsz, ha csendben vagy - gáz van a bányában, és ideje indulni. A bányászok feláldoztak egy kis madarat, hogy élve kijussanak a bányákból.

Hasonló gyakorlat tapasztalható az informatika területén is. Például egy szolgáltatás vagy alkalmazás új verziójának üzembe helyezése az éles környezetben, ezt megelőző teszteléssel. A tesztkörnyezet túl drága lehet, az automatizált tesztek nem fednek le mindent, amit akarsz, a tesztelés elmaradása és a minőség feláldozása pedig kockázatos. Itt jön jól a Canary Deployment megközelítés, ahol a valódi éles forgalom az új verzió felé irányul. A megközelítés segít biztosan ellenőrizze az új verziót gyártáshoz, feláldozni egy kicsit egy nagy ügyért. További részletek a megközelítés működéséről, mi hasznos és hogyan valósíthatók meg Andrej Markelov (Andrey_V_Markelov), az Infobip vállalatnál történő megvalósítás példáján.

Andrej Markelov - Vezető szoftvermérnök az Infobipnél, 11 éve fejleszt Java alkalmazásokat a pénzügy és a telekommunikáció területén. Nyílt forráskódú termékeket fejleszt, aktívan részt vesz az Atlassian közösségben és bővítményeket ír az Atlassian termékekhez. Prometheus evangélistája, Docker és Redis.

Az Infobipről

Ez egy globális távközlési platform, amely lehetővé teszi a bankok, kereskedők, online áruházak és közlekedési vállalatok számára, hogy SMS-ben, push-ban, levélben és hangüzenetben üzeneteket küldjenek ügyfeleiknek. Egy ilyen üzletben fontos a stabilitás és a megbízhatóság, hogy az ügyfelek időben megkapják az üzeneteket.

Infobip IT infrastruktúra számokban:

• 15 adatközpont szerte a világon;
• 500 egyedi szolgáltatás működik;
• 2500 szolgáltatáspéldány, ami sokkal több, mint parancsok;
• 4,5 TB havi forgalom;
• 4,5 milliárd telefonszám;

Az üzlet növekszik, és ezzel együtt a megjelenések száma is. ráköltünk 60 kiadás napontamert az ügyfelek több funkcióra és teljesítményre vágynak. De ez nehéz - sok szolgáltatás van, de kevés parancs. Gyorsan meg kell írnia a kódot, aminek hiba nélkül kell működnie a termelésben.

Kiadások

Egy tipikus kiadás így megy. Például vannak A, B, C, D és E szolgáltatások, mindegyiket külön csapat fejleszti.

Egy ponton az A szolgáltatás csapata úgy dönt, hogy telepít egy új verziót, de a B, C, D és E szolgáltatás csapatai nem tudnak róla. Az A szervizcsapat két lehetőség közül választhat.

Tartani fog növekményes felszabadulás: először cserélje ki az egyik verziót, majd a másodikat.

De van egy második lehetőség: a parancs további kapacitásokat és gépeket fog találni, telepítse az új verziót, majd váltson útválasztót, és a verzió elkezd működni az éles verzióban.

Mindenesetre a telepítés után szinte mindig vannak problémák, még akkor is, ha a verziót tesztelik. Tesztelheti manuálisan, megteheti automatikusan, nem tesztelheti - problémák minden esetben felmerülnek. Ezek megoldásának legegyszerűbb és leghelyesebb módja a működő verzióra való visszatérés. Csak ezután lehet kezelni a károkat, az okokat és kijavítani azokat.

Szóval mit akarunk?

Nincs szükségünk problémákra. Ha az ügyfelek gyorsabban megtalálják őket, mint mi, az árt a hírnevüknek. Ezért muszáj gyorsabban találja meg a problémákat, mint az ügyfelek. Proaktív munkával minimalizáljuk a károkat.

Ugyanakkor szeretnénk gyorsítsa fel a telepítésthogy ez gyorsan, egyszerűen, természetesen és a csapat nyomása nélkül történjen. A mérnököket, a DevOps mérnököket és a programozókat védeni kell – az új verzió megjelenése megterhelő. A csapat nem pazarló, törekszünk az emberi erőforrások ésszerű felhasználása.

Telepítési problémák

Az ügyfélforgalom kiszámíthatatlan. Lehetetlen megjósolni, hogy mikor lesz a legalacsonyabb az ügyfélforgalom. Nem tudjuk, hol és mikor kezdik el kampányaikat az ügyfelek – talán ma este Indiában, holnap Hongkongban. Tekintettel a nagy időeltolódásra, még hajnali 2-kor sem garantálja, hogy ez az ügyfeleket nem érinti.

Problémák a szolgáltatóval. Messengerek és szolgáltatók a partnereink. Néha előfordulnak olyan összeomlások, amelyek hibákat okoznak az új verziók telepítése során.

Elosztott csapatok. A kliens oldalt és a háttérrendszert fejlesztő csapatok különböző időzónákban vannak. Emiatt gyakran nem tudnak megegyezni egymás között.

Az adatközpontok nem ismételhetők meg a színpadon. Egy adatközpontban 200 állvány található – ezt még csak megközelítőleg sem lehet megismételni egy homokozóban.

Leállásokelfogadhatatlan! Hibaköltségvetésünk van, ha például az idő 99,99%-ában dolgozunk, a fennmaradó százalék pedig „hibamarzs”. A 100%-os megbízhatóság elérése lehetetlen, de fontos a leesések és az állásidő folyamatos figyelése.

Klasszikus megoldások

Írj kódot hibák nélkül. Fiatal fejlesztő koromban a menedzserek megkerestek azzal a kéréssel, hogy adják ki hiba nélkül, de ez nem mindig lehetséges.

Írj teszteket. A tesztek működnek, de néha nem úgy, ahogy a vállalkozás szeretné. A pénzkeresés nem a tesztek feladata.

Teszt a színpadon. Az Infobipnél végzett munkám 3,5 éve alatt soha nem láttam, hogy a színpad állapota legalább részben egybeesne a produkcióval.

Még ezt az ötletet is megpróbáltuk továbbfejleszteni: először volt színpad, majd előgyártás, majd előgyártás. De ez sem segített – még a hatalomban sem értek egyet. A színpaddal garantálni tudjuk az alapvető funkcionalitást, de nem tudjuk, hogyan fog működni terhelés alatt.

A kiadást az készíti, aki kifejlesztette. Ez egy jó gyakorlat: ha valaki megváltoztatja a megjegyzés nevét, azonnal hozzáadja a produkcióhoz. Ez segít a felelősségvállalás kialakításában, és nem feledkezik meg a végrehajtott változtatásokról.

Vannak további komplikációk is. A fejlesztő számára megterhelő, ha sok időt tölt azzal, hogy mindent manuálisan ellenőriz.

Megállapodott kiadások. Ezt a lehetőséget általában a vezetőség ajánlja fel: "Egyezzünk meg abban, hogy minden nap tesztel és új verziókat ad hozzá." Nem működik: mindig mindenki másra vár egy parancs, vagy fordítva.

Füstvizsgálatok

Egy másik módja a telepítési problémáink megoldásának. Fontolja meg, hogyan működnek a füsttesztek az előző példában, amikor az A csapat új verziót szeretne telepíteni.

Először a csapat egy példányt telepít a termelésbe. Üzenetek a példánynak gúnyokból valós forgalmat szimulálhogy megfeleljen a normál napi forgalomnak. Ha minden rendben van, a csapat átállítja az új verziót a felhasználói forgalomra.

A második lehetőség a telepítés extra vasalóval. A csapat teszteli a gyártást, majd kapcsol, és minden működik.

A füstteszt hátrányai:

• A tesztekben nem lehet megbízni. Hol lehet ugyanazt a forgalmat elérni, mint a gyártásnál? Használhatja tegnap vagy egy héttel ezelőtt, de nem mindig egyezik a jelenlegivel.
• Nehéz karbantartani. Fenn kell tartania a tesztfiókokat, és folyamatosan alaphelyzetbe kell állítania azokat minden egyes telepítés előtt, amikor az aktív rekordokat elküldi a tárolóba. Ez nehezebb, mint tesztet írni a saját homokozóban.

Az egyetlen bónusz itt az teljesítménye tesztelhető.

Kanári kiadások

A füsttesztek hiányosságai miatt elkezdtük a kanári kioldók használatát.

A bányászok kanárikkal a gázszint jelzéséhez hasonló gyakorlat került be az informatikába. Hagytuk némi valódi gyártási forgalmat az új verzióhozmiközben megpróbálja teljesíteni a szolgáltatási szint megállapodást (SLA). Az SLA a "hibázási jogunk", amelyet évente egyszer (vagy más ideig) használhatunk. Ha minden jól megy, növeljük a forgalmat. Ha nem, akkor visszaküldjük a korábbi verziókat.

Megvalósítás és árnyalatok

Hogyan valósítottuk meg a kanári kiadásokat? Például ügyfelek egy csoportja küld üzeneteket a szolgáltatásunkon keresztül.

A telepítés a következőképpen zajlik: eltávolítunk egy csomópontot a kiegyenlítő alól (1), megváltoztatjuk a verziót (2) és külön engedünk egy kis forgalmat (3).

Általában mindenki boldog lesz a csoportban, még akkor is, ha egy felhasználó boldogtalan. Ha minden rendben van, minden verziót lecserélünk.

Sematikusan megmutatom, hogyan néz ki a legtöbb esetben a mikroszolgáltatások esetében.

Van Service Discovery és még két szolgáltatás: S1N1 és S2. Az első szolgáltatás (S1N1) értesíti a Service Discovery-t, amikor elindul, és a Service Discovery emlékszik rá. A második szolgáltatás két csomóponttal (S2N1 és S2N2) szintén értesíti a Service Discovery-t, amikor elindul.

Az első második szolgáltatása szerverként működik. Az első információt kér a Service Discoverytől a szervereiről, majd amikor megkapja, megkeresi és ellenőrzi azokat („állapot-ellenőrzés”). Amikor ellenőrzi, üzeneteket küld nekik.

Amikor valaki a második szolgáltatás új verzióját akarja üzembe helyezni, közli a Service Discovery-vel, hogy a második csomópont egy kanári csomópont lesz: kevesebb forgalom lesz ráirányítva, mert a telepítés most megtörténik. Kivesszük a kanári csomópontot a kiegyenlítő alól, és az első szolgáltatás nem küld rá forgalmat.

Megváltoztatjuk a verziót, és a Service Discovery tudja, hogy a második csomópont már kanári – kevesebb terhelést adhat neki (5%). Ha minden rendben van, változtatjuk a verziót, visszaadjuk a terheléseket és dolgozunk tovább.

Mindezek megvalósításához szükségünk van:

• kiegyensúlyozás;
• megfigyelésmert fontos tudni, hogy az egyes felhasználók mit várnak el, és hogyan működnek szolgáltatásaink részletesen;
• verzióelemzésmegérteni, hogy az új verzió mennyire fog működni a termelésben;
• automatizálás - megírjuk a telepítési sorrendet (deployment pipeline).

kiegyensúlyozó

Ez az első, amire gondolnunk kell. Két egyensúlyozási stratégia létezik.

A legegyszerűbb lehetőség, amikor az egyik csomópont mindig kanári. Ez a csomópont mindig kevesebb forgalmat kap, és ebből kezdjük a telepítést. Probléma esetén a bevetés előtti és közbeni munkáját összehasonlítjuk. Például, ha 2-szer több hiba van, akkor a kár 2-szeresére nőtt.

A Kanári csomópont beállítása a telepítési folyamat során történik. Amikor a telepítés véget ér, és eltávolítjuk róla a kanári csomópont állapotát, a forgalmi egyensúly helyreáll. Kevesebb autóval igazságos elosztást kapunk.

megfigyelés

A kanári elengedések alapköve. Pontosan meg kell értenünk, miért tesszük ezt, és milyen mutatókat akarunk gyűjteni.

Példák a szolgáltatásainkból gyűjtött mérőszámokra.

• A hibák száma, amelyek a naplókba vannak írva. Ez egyértelműen jelzi, hogy minden úgy működik, ahogy kell. Általában ez egy jó mérőszám.
• Lekérdezés végrehajtási ideje (késleltetés). Mindenki figyeli ezt a mérőszámot, mert mindenki gyorsan akar dolgozni.
• Sor mérete (áteresztőképesség).
• Sikeres válaszok száma másodpercenként.
• Az összes kérelem 95%-ának végrehajtási ideje.
• Üzleti mutatók: mennyi pénzt keres egy vállalkozás adott idő vagy felhasználói lemorzsolódás alatt. Ezek a mérőszámok az új verziónknál fontosabbak lehetnek, mint a mérnökök által hozzáadottak.

Példák a mérőszámokra a legnépszerűbb megfigyelőrendszerekben.

Számláló. Ez egy növekvő érték, például a hibák száma. Ez a mérőszám könnyen interpolálható és tanulmányozható a diagramon: tegnap 2 hiba volt, ma pedig 500, ami azt jelenti, hogy valami elromlott.

A percenkénti vagy másodpercenkénti hibák száma a legfontosabb mutató, amely a Counter segítségével kiszámítható. Ezek az adatok világos képet adnak a rendszer távolról történő működéséről. Tekintsük a másodpercenkénti hibák számának grafikonját a termelési rendszer két változatánál.

Az első verzióban kevés volt a hiba, talán nem sikerült az audit. A második verzióban minden sokkal rosszabb. Biztosan állíthatjuk, hogy vannak problémák, ezért ezt a verziót vissza kell állítani.

Nyomtáv. A mutatók hasonlóak a számlálóhoz, de olyan értékeket rögzítünk, amelyek növekedhetnek vagy csökkenhetnek. Például a lekérdezés végrehajtási ideje vagy a sor mérete.

A grafikon egy példát mutat a késleltetésre. A grafikonon látható, hogy a verziók hasonlóak, lehet velük dolgozni. De ha alaposan megnézed, láthatod, hogyan változik az érték. Ha a lekérdezés végrehajtási ideje megnövekszik a felhasználók hozzáadásakor, akkor azonnal világossá válik, hogy problémák vannak – ez korábban nem volt így.

Összefoglaló. A vállalkozások számára az egyik legfontosabb mutató a percentilis. A mérőszám ezt mutatja Az esetek 95% -a rendszerünk úgy működik, ahogy szeretnénk. El tudjuk fogadni, ha valahol gondok vannak, mert értjük az általános trendet, hogy minden mennyire jó vagy rossz.

Tools

ELK Stack. Az Elasticsearch segítségével megvalósíthatja a canary-t - események bekövetkezésekor hibákat írunk rá. A legegyszerűbb API-hívással bármikor lekérheti a hibák számát, és összehasonlíthatja a korábbi szegmensekkel: GET /applg/_cunt?q=level:errr.

Prométheusz. Jól mutatta magát az Infobipben. Lehetővé teszi többdimenziós metrikák megvalósítását, mivel címkéket használnak.

Tudjuk használni level, instance, service, egyesítse őket egy rendszerben. Segítséggel offset megtekintheti például egy héttel ezelőtti érték értékét egyetlen paranccsal GET /api/v1/query?query={query}Ahol {query}:

rate(logback_appender_total{ 
    level="error",  
    instance=~"$instance" 
}[5m] offset $offset_value)

Verzióelemzés

Számos verziókezelési stratégia létezik.

Csak a Kanári csomópontok mutatóinak megtekintése. Az egyik legegyszerűbb lehetőség: telepítsen egy új verziót, és csak a munkát tanulmányozza. De ha a mérnök ebben az időben elkezdi tanulmányozni a naplókat, és folyamatosan idegesen tölti újra az oldalakat, akkor ez a megoldás nem különbözik a többitől.

A Kanári csomópontot bármely más csomóponthoz hasonlítják. Ez összehasonlítás más, teljes forgalommal működő példányokkal. Például, ha a dolgok rosszabbak kis forgalom mellett, vagy nem jobbak, mint a valós példányokon, akkor valami nincs rendben.

A Kanári csomópontot önmagához hasonlítják a múltban. A kanárihoz kiosztott csomópontok összehasonlíthatók a korábbi adatokkal. Például, ha egy héttel ezelőtt minden rendben volt, akkor ezekre az adatokra koncentrálhatunk, hogy megértsük a jelenlegi helyzetet.

automatizálás

Szeretnénk megszabadítani a mérnököket a kézi összehasonlítástól, ezért fontos az automatizálás megvalósítása. A telepítési folyamat általában így néz ki:

• kezdünk;
• távolítsa el a csomópontot a kiegyenlítő alól;
• Kanári csomópont felállítása;
• kapcsolja be a kiegyensúlyozót korlátozott mennyiségű forgalom mellett;
• összehasonlítani.

Ebben a szakaszban megvalósítjuk automatikus összehasonlítás. Hogyan nézhet ki, és miért jobb, mint a telepítés utáni ellenőrzés, nézzünk meg egy példát a Jenkinstől.

Ez a vezeték Groovyba.

while (System.currentTimeMillis() < endCanaryTs) {
    def isOk = compare(srv, canary, time, base, offset, metrics)
    if (isOk) {
        sleep DEFAULT SLEEP
    }   else {
        echo "Canary failed, need to revert"  
        return false
    }
}

Itt a ciklusban beállítottuk, hogy egy órán keresztül összehasonlítjuk az új csomópontot. Ha a kanári folyamat még nem fejezte be a folyamatot, hívjuk a függvényt. Azt jelenti, hogy minden rendben van-e vagy sem: def isOk = compare(srv, canary, time, base, offset, metrics).

Ha minden jó - sleep DEFAULT SLEEPpéldául egy másodpercre, és folytassa. Ha nem, lépjen ki – a telepítés meghiúsult.

A mérőszám leírása. Nézzük meg, hogyan nézhet ki a függvény compare a DSL példáján.

metric(
    'errorCounts',
    'rate(errorCounts{node=~"$canaryInst"}[5m] offset $offset)',
    {   baseValue, canaryValue ->
        if (canaryValue > baseValue * 1.3) return false 
        return true
    }
)

Tegyük fel, hogy összehasonlítjuk a hibák számát, és tudni akarjuk, hogy az elmúlt 5 percben mennyi volt a másodpercenkénti hibák száma.

Két értékünk van: alap és kanári csomópont. A kanári csomópont értéke az aktuális. Alapvető - baseValue bármely más nem kanári csomópont értéke. Az értékeket összehasonlítjuk egymással a képlet alapján, amelyet tapasztalataink és megfigyeléseink alapján állítunk be. Ha az érték canaryValue rossz, akkor a telepítés nem sikerült, és visszagurulunk.

Miért van szükség erre?

Egy személy nem képes több száz és ezer mérőszámot ellenőriznipláne gyorsan csinálni. Az automatikus összehasonlítás segít az összes mérőszám ellenőrzésében, és gyorsan értesíti a problémákról. A riasztás időzítése kritikus: ha valami történt az utolsó 2 másodpercben, a kár nem lesz akkora, mint ha 15 perccel ezelőtt történt. Mindaddig, amíg valaki észreveszi a problémát, ír a támogatásnak, és támogatja, hogy visszaállítsuk, elveszítheti az ügyfeleket.

Ha a folyamat sikerült, és minden rendben van, automatikusan telepítjük az összes többi csomópontot. Ezalatt a mérnökök semmit sem csinálnak. Csak amikor elindítják a kanárit, döntik el, hogy milyen mérőszámokat alkalmazzanak, mennyi ideig végezzék az összehasonlítást, milyen stratégiát alkalmazzanak.

Ha problémák merülnek fel, automatikusan visszaállítjuk a kanári csomópontot, dolgozunk a korábbi verziókon, és kijavítjuk a talált hibákat. A mérőszámok alapján könnyen megtalálhatóak és láthatóak az új verzió okozta károk.

Akadályok

Ezt persze nem könnyű megvalósítani. Először is szüksége van általános felügyeleti rendszer. A mérnökök saját mérőszámokkal rendelkeznek, a támogatás és az elemzők más, a vállalkozások pedig harmadikat. A közös rendszer az a közös nyelv, amelyet az üzlet és a fejlesztés beszél.

A gyakorlatban tesztelni kell metrikus stabilitás. Az ellenőrzés segít megérteni mi a minimális mérőszám a minőség biztosításához.

Hogyan lehet ezt elérni? Ne használja a kanári szolgáltatást a telepítéskor. A régi verzióhoz hozzáadunk egy bizonyos szolgáltatást, amely bármikor bármely dedikált csomópontot igénybe vehet, és telepítés nélkül csökkentheti a forgalmat. Összehasonlítás után: tanulmányozzuk a hibákat, és keressük azt a vonalat, amikor minőséget érünk el.

Milyen hasznot húztunk a kanári kibocsátásokból?

Minimálisra csökkentette a hibák okozta károk százalékos arányát. A legtöbb telepítési hiba bizonyos adatok vagy prioritások következetlenségéből adódik. Sokkal kevesebb az ilyen hiba, mert már az első másodpercekben meg tudjuk oldani a problémát.

Optimalizált csapatmunka. A kezdőknek „joguk van hibázni”: a hibázástól való félelem nélkül bevehetik magukat a gyártásba, van egy további kezdeményezés, munkaösztönzés. Ha eltörnek valamit, akkor az nem lesz kritikus, és aki hibázik, azt nem rúgják ki.

Automatizált telepítés. Ez már nem manuális folyamat, mint korábban, hanem valódi automatizált. De ez tovább tart.

Kiemelte a fontos mutatókat. Az egész cég az üzlettől és a mérnököktől kezdve érti, hogy mi az igazán fontos termékünkben, milyen mérőszámok, például a felhasználók ki- és beáramlása. Mi irányítjuk a folyamatot: teszteljük a mérőszámokat, újakat vezetünk be, megnézzük, hogyan működnek a régiek, hogy egy olyan rendszert építsünk ki, amely produktívabb pénzt termel.

Rengeteg klassz gyakorlatunk és rendszerünk van a segítségünkre. Ennek ellenére törekszünk arra, hogy professzionálisak legyünk és jól végezzük a munkánkat, függetlenül attól, hogy van-e olyan rendszerünk, ami segít nekünk vagy sem.

Mérnöki megközelítések és gyakorlatok - a TechLead Conf fő fókusza. Ha sikereket ért el a technikai kiválóság felé vezető úton, és kész megmondani, mi segített ebben, jelentést kérni.

Azt tervezzük Tech Lead Conf június 8. Megértjük, hogy most nehéz döntést hozni a konferencián való részvételről. Ugyanakkor úgy gondoljuk, hogy a karantén nem ok a szakmai kommunikáció és fejlődés leállítására. Ezért minden esetben meg fogjuk találni a módját, hogy megbeszéljük egy műszaki vezető feladatait és megoldási módjait - ha szükséges, akkor felkeressük a netet, és ott felállítjuk a hálózatot!

Forrás: will.com