Blue-green a canary: ako riadiť nasadenie bez výpadku

01Nasadenie posudzujte cez zákaznícky výsledok

Pri firemnej aplikácii sa výpadok nemusí prejaviť nedostupnou úvodnou stránkou. Môže prestať fungovať platba, odoslanie dopytu alebo spracovanie úlohy na pozadí. Pred návrhom nasadenia určte kritické cesty a prijateľnú reakciu na problém. Úspešne spustený proces ešte nepotvrdzuje, že zákazník dokončí prácu.

Zmapujte webové požiadavky, API, databázu, úložisko, fronty a externé služby. Zmena môže zasiahnuť viac vrstiev naraz. Spôsob prepínania návštevnosti musí zodpovedať tomu, čo skutočne meníte. Ak vymeníte len webovú vrstvu, spoločná databáza zostáva významným bodom rizika.

Cieľom je znížiť rozsah problému, rýchlo ho zachytiť a mať vykonateľnú nápravu. Označenie „bez výpadku“ nie je zárukou akejkoľvek zmeny. Výsledok závisí od kompatibility, riadenia spojení, kapacity aj prevádzkových pravidiel. Pri návrhu pomenujte, ktoré scenáre sa dajú pokryť a čo vyžaduje osobitný postup.

Dohodnite aj čas nasadenia a dostupnosť ľudí. Pokojnejšie obdobie môže znížiť okamžitý dopad, no nie vždy poskytne dosť skutočnej prevádzky na overenie. Zvolený čas má zodpovedať riziku a možnosti reagovať. Neplánujte dôležitú zmenu iba podľa toho, kedy je voľný kalendár.

02Blue-green pripraví druhé prostredie pred prepnutím

AWS opisuje blue-green nasadenie cez dve prostredia s rozdielnymi verziami aplikácie a presmerovanie návštevnosti. Pôvodná verzia obsluhuje prevádzku, kým nová prejde prípravou a kontrolou. Následne zmeníte smerovanie podľa podporovaného mechanizmu.

Výhodou je oddelená príprava novej verzie a dostupnosť predchádzajúcej aplikácie pre návrat. Neznamená to však automatické zdvojenie všetkých služieb ani bezpečnú obnovu údajov. Hranicu prostredia musíte navrhnúť: čo je samostatné a čo používajú obe verzie spoločne.

Pred prepnutím overte konfiguráciu, prístupy, závislosti a pripravenosť novej verzie. Kontrola musí používať relevantné scenáre, pričom nesmie nechtiac vytvoriť skutočné platby alebo odoslať zákaznícke správy. Náhľad novej aplikácie a produkčná prevádzka majú mať presne určené oprávnenia.

Po presmerovaní ponechajte pôvodnú verziu dostupnú po dohodnutý čas a sledujte výsledky. Rozhodnite, čo sa stane s otvorenými spojeniami, reláciami a rozpracovanými požiadavkami. Rýchle ukončenie starej vrstvy môže narušiť práve operácie, ktoré začali pred prepnutím.

Preverte aj kapacitu spoločných služieb pri súbehu. Dve aplikácie môžu vytvoriť viac databázových spojení alebo požiadaviek na externé API. Pripravenosť novej vrstvy preto neposudzujte izolovane. Do skúšky zahrňte očakávaný súbeh a overte, či zdieľaná závislosť neobmedzí obe prostredia.

Pri nákladoch počítajte s dočasnou kapacitou navyše a so správou oboch prostredí. Udržiavajte ich rovnakým automatizovaným postupom, aby sa neskryté rozdiely konfigurácie neobjavili až pri nasadení. Cena bezpečnej zmeny zahŕňa aj monitoring a odovzdanie reakcie.

03Canary rozširuje novú verziu podľa výsledkov

Google Cloud definuje canary ako postupné nasadenie, pri ktorom novú verziu dostane časť prevádzky pred úplným rozšírením. Medzi etapami sledujete dohodnuté signály. Pri probléme ďalší krok zastavíte a podľa návrhu presmerujete prevádzku.

Etapy určte podľa citlivosti služby, objemu prevádzky a kvality merania. Univerzálne percentá a čas pauzy neexistujú. Malá vzorka môže byť bezpečnejšia z pohľadu rozsahu zásahu, ale neposkytne dosť informácií o zriedkavom probléme. Rozhodnutie má zohľadniť oba pohľady.

Pri etape si uložte aj identifikáciu verzie v prevádzkových záznamoch. Bez nej sa chyba môže objaviť v spoločnom súčte a zostane nejasné, ktorú aplikáciu zasiahla. Zároveň obmedzte množstvo osobných údajov v diagnostike. Rozlíšenie verzií nevyžaduje zverejnenie celého zákazníckeho obsahu.

Zvážte, koho nová verzia zasiahne. Náhodné rozdelenie požiadaviek, výber používateľov alebo organizácií má rozdielne dôsledky. Jeden používateľ môže potrebovať konzistentnú verziu počas celej operácie. Pri firemnom systéme môže byť vhodné držať spolu všetkých ľudí jednej organizácie podľa návrhu aplikácie.

Canary nasadenie odlíšte od marketingového A/B testu. Jeho hlavným účelom je prevádzkové overenie novej verzie. Zlepšenie obchodnej metriky môže byť zaujímavé, ale samo nepreukáže bezpečnosť ani kauzálny účinok zmeny. Skupiny a metodika musia zodpovedať zvolenej otázke.

04Databáza rozhoduje, či je návrat skutočne možný

AWS pri zmenách schémy zdôrazňuje kompatibilitu medzi kódom a databázou a oddelenie týchto zmien. Obe aplikácie musia pracovať s údajmi, ktoré vznikajú počas nasadenia. Návrat smerovania nezmaže nové zápisy ani nezrekonštruuje odstránené pole.

Pri rozšírení databázy najprv pridajte potrebnú štruktúru kompatibilnú so starou verziou. Nasleduje aplikácia, ktorá s ňou vie pracovať, a overenie prechodu údajov. Odstránenie starej časti vykonajte až vtedy, keď už nie je potrebná pre dostupnú predchádzajúcu verziu a návratový postup.

Pri každej zmene napíšte kompatibilitu starého kódu s novými údajmi aj nového kódu so starými údajmi. Preverte prázdne hodnoty, rozdielny význam polí a súbežné zápisy. Doplnenie stĺpca nie je automaticky bezrizikové; správanie môže ovplyvniť aplikáciu alebo samotnú databázovú prevádzku.

Ak máte oddelené databázy, potrebujete riešiť synchronizáciu a autoritu zápisov. Kopírovanie pred nasadením neposkytne samo aktuálny stav pre neskorší návrat. Obnova zálohy môže stratiť novšie transakcie. Postup obnovy musí byť dohodnutý s vedomím dopadu na obchodné údaje.

05Relácie, fronty a vedľajšie účinky neprehliadnite

Používateľská relácia má zostať použiteľná pri prechode medzi verziami podľa navrhnutého mechanizmu. Ak aplikácia drží stav iba v jednej inštancii, prepnutie môže odhlásiť používateľa alebo prerušiť proces. Preverte aj kompatibilitu podpísaných tokenov a údajov uložených v relácii.

Úlohy na pozadí a konzumenti fronty môžu bežať v oboch verziách. Dohodnite, ktorá verzia spracúva ktoré správy, a overte ich formát. Zmena producenta nesmie nechtiac vytvoriť správu, ktorú starý konzument nedokáže prečítať. Sledujte aj čakanie a opakované spracovanie.

Pri pravidelne plánovaných úlohách zabráňte neplánovanému dvojitému spusteniu. Dve prostredia môžu odoslať rovnakú správu, vytvoriť duplicitný doklad alebo opakovať externú operáciu. Návrh má určiť vedenie úlohy a ochranu pred opakovaným obchodným účinkom, nie iba úspešný beh procesu.

Platba, e-mail a zásah v externom systéme môžu zostať vykonané aj po návrate aplikácie. Pripravte postup nápravy a dohľadateľné identifikátory. Vypnutie novej verzie neopraví chybný obsah už odoslanej správy. Podmienky návratu preto zahŕňajú aj tieto dôsledky.

Prejdite staré stránky otvorené v prehliadači počas zmeny. Môžu posielať požiadavky na nové API, zatiaľ čo nové stránky používajú iný formát. Dostupnosť statických súborov a kompatibilita rozhraní má pokryť primeraný prechod. Nesúlad sa nemusí objaviť pri čerstvom otvorení webu.

06Rozhodovanie podložte metrikami a zastavovacími pravidlami

Pred nasadením určte sledované výsledky, porovnávací základ a hranicu zastavenia. Sledujte chyby, čas odpovedí a kritické obchodné kroky podľa aplikácie. Samotná dostupnosť procesu alebo zelená úvodná stránka nestačí. Nová verzia môže vracať úspešnú odpoveď a súčasne ukladať nesprávny údaj.

Argo Rollouts dokumentuje analýzu, ktorá môže ovplyvniť pokračovanie, zastavenie alebo pozastavenie nasadenia. Pri vlastnom nastavení preto rozlišujte úspech, zlyhanie a nedostatok informácií. Chýbajúce meranie nemá automaticky znamenať bezproblémovú verziu.

Porovnávajte vhodné skupiny a rozsah. Nová verzia môže dostávať odlišný typ používateľov alebo iné požiadavky. Súhrnný priemer dokáže prekryť problém na kritickom kroku. Pri menšom objeme použite aj kontrolované testy a odbornú kontrolu, pričom záver ponechajte primerane neistý.

Každý signál má mať vlastníka a konkrétnu reakciu. Určte, kto smie zastaviť rozšírenie, kto prejde údaje a kto komunikuje incident. Automatické presmerovanie musí byť samo overené. Návratový mechanizmus, ktorý nikto nevyskúšal, je stále iba predpoklad.

Ak súčasne zmeníte viac nesúvisiacich častí, zhoršíte dohľadanie príčiny. Rozsah vydania udržujte zrozumiteľný a pripravte poznámku o každej významnej zmene. Pri závisiacich službách naplánujte poradie tak, aby jedna etapa nepredpokladala rozhranie, ktoré sa má objaviť až neskôr.

Sledujte aj obdobie po úplnom rozšírení. Niektoré problémy sa prejavia neskôr, napríklad v dávke alebo plánovanej úlohe. Ukončenie nasadenia a odstránenie pôvodného prostredia preto viažte na dohodnuté potvrdenie, nie iba na posledné úspešné prepnutie.

07Pripravte opakovateľný postup nasadenia

Používajte dohľadateľnú verziu aplikácie, konfigurácie a migračného kroku. Zmeny prostredia pripravujte rovnakým riadeným postupom. Náhodné ručné opravy komplikujú porovnanie aj návrat. Keď sa dá úspešné nasadenie zopakovať, tím vie lepšie odlíšiť rozdiel verzie od rozdielu prostredia.

1. Zmapujte kritické cesty a závislosti.
2. Overte kompatibilitu kódu, schémy a správ.
3. Pripravte novú verziu aj meranie.
4. Nacvičte presmerovanie a návrat na skúšobnom prostredí.
5. Spustite etapy s dohodnutými pravidlami.
6. Overte dokončené operácie a stav údajov.
7. Po potvrdení ukončite dočasné prostredie.

Pri širšej zmene infraštruktúry nadviažte na migráciu do cloudu bez výpadku. Začnite menšou aplikáciou alebo zmenou, pri ktorej dokážete overiť celý postup. Nástroj zjednoduší kroky, no hranice a zodpovednosť musí navrhnúť tím.

Po každom vydaní prejdite zistenia: čo fungovalo, čo chýbalo a či bol návrat stále možný. Upravte kontrolné scenáre a pravidlá podľa dôkazov. Tak sa bezpečnosť nasadenia zlepšuje opakovaným preverovaním skutočných predpokladov.

08Časté otázky k blue-green a canary