Blue-green a canary: jak omezit riziko nasazení

01Vymezte, co má během nasazení zůstat dostupné

Nejdřív pojmenujte důležité zákaznické úlohy. Může jít o přihlášení, uložení rozpracovaného dokumentu, objednávku nebo přijetí zprávy z integrace. Dostupná hlavní stránka sama neprokazuje dostupný systém. U každé úlohy určete potřebné služby, závislosti a způsob ověření během změny.

Zmapujte aplikaci, databázi, cache, úložiště souborů, fronty i externí partnery. Nasazení může přepnout jen jednu vrstvu, zatímco ostatní zůstávají společné. Právě tato hranice rozhoduje, zda lze skutečně spustit starou a novou verzi současně. Bez ní bude výraz druhé prostředí znamenat pro různé členy týmu něco jiného.

Předem domluvte toleranci zpomalení a chyb, pravidlo zastavení a odpovědného člověka. Nevycházejte z univerzálního procenta v cizím příkladu. Jiný dopad má krátké zpoždění obrázku a jiný odmítnutý platební požadavek. U důležitého systému potřebujete rozhodnutí spojené se skutečným provozním rizikem.

Nasazení a zpřístupnění funkce mohou být oddělené kroky. Kód lze připravit před zapnutím konkrétní části nabídky, pokud to aplikace podporuje. Tím získáte další možnost kontroly, zároveň ale vzniká povinnost spravovat přepínače a jejich kombinace. Název strategie neřeší automaticky všechny stavy produktu.

V modelovém českém B2B portálu může uživatel rozpracovat nabídku před změnou a uložit ji až po ní. Zahrňte tento přechod do ověření. Nová verze má zachovat domluvený význam rozpracovaných údajů a navazujících kroků. Tím testujete život skutečné úlohy, ne jen dvě oddělená otevření úvodní stránky. Uveďte, které kombinace verzí byly prověřeny a které zůstávají mimo podporovaný rozsah.

02Blue-green připraví druhou verzi před přepnutím

AWS popisuje blue-green jako přesun provozu mezi dvěma prostředími s různými verzemi aplikace. Běžící verze dál obsluhuje zákazníky, zatímco druhou připravíte a ověříte. Potom přepnete směrování podle zvoleného mechanismu. Je to způsob omezení rizik, nikoli obecná záruka nulového výpadku.

Výhodou může být příprava nové aplikace bez přímé výměny aktivních instancí. Ověříte konfiguraci, závislosti a vybrané funkce před hlavním přepnutím. Potřebujete však kapacitu pro souběh a jistotu, že náhled odpovídá podmínkám produkce. Pouhé nastartování procesu nestačí.

Argo Rollouts pro blue-green rozlišuje aktivní a volitelnou náhledovou službu. Dokumentace řeší také zpoždění propagace směrování a odložení vypnutí starých instancí. Konkrétní chování závisí na infrastruktuře. Ověřte svůj balancer a integraci, místo abyste předpokládali okamžité přepnutí všude.

V pracovním plánu určete, jak dlouho stará verze zůstává použitelná a co je potřeba pro návrat. Musí mít správná tajemství, konfiguraci i kapacitu. Pokud ji ihned vypnete nebo odstraníte potřebné podklady, rychlý návrat bude pouze teoretickou možností. Po dobu souběhu kontrolujte také procesy na pozadí.

03Canary přidává provoz po kontrolovaných krocích

Canary nasazení zpřístupní novou verzi nejprve omezené části produkčního provozu. Po vyhodnocení pokračujete nebo změnu zastavíte. Tento přístup pomáhá omezit rozsah počátečního dopadu, pokud výběr provozu a kontrolní pravidla odpovídají skutečné aplikaci. Současně déle provozujete více verzí.

Dokumentace canary v Argo Rollouts ukazuje řízení váhy a pauz. Bez samostatného řízení provozu může podíl vznikat jen přibližně podle počtu replik. Podíl nových instancí proto není automaticky přesným podílem požadavků. Potřebujete znát možnosti svého směrování.

Zvolte skupinu nebo způsob rozdělení podle otázky, kterou ověřujete. U firemního systému může být vhodné držet celou firmu na stejné verzi, aby se její uživatelé nepotkávali s různým chováním. U jiného produktu se hodí jiný klíč. Náhodné střídání verzí při každém požadavku může komplikovat stav relace.

První skupina musí obsahovat relevantní používání. Interní účet bez nákupů neprověří celý zákaznický proces. U malého provozu může sběr podkladu trvat déle a vzácná chyba se nemusí projevit. Pauza podle hodin sama nepotvrzuje dostatečný vzorek ani správný výsledek.

04Databáze rozhoduje o skutečné možnosti návratu

Přepnutí aplikace zpět nevrátí automaticky změněná data. Nová verze mohla založit záznamy, odeslat platbu nebo změnit význam pole. Před nasazením ověřte, zda stará verze dokáže takový stav bezpečně číst a používat. Jinak může návrat služby vyvolat další chybu.

AWS doporučuje oddělit změny schématu a kódu a zachovat potřebnou kompatibilitu. Praktický návrh může nejdřív přidat novou strukturu, následně přizpůsobit aplikaci a až později odstranit starou část. Destruktivní úklid patří za jasně určené okno návratu, ne automaticky do prvního přepnutí.

V modelovém scénáři se název jednoho pole nahrazuje jiným. Okamžité odstranění původního pole může rozbít stále běžící starou verzi. Tým potřebuje plán přechodného čtení, zápisu a doplnění dat. Tento příklad vysvětluje otázky návrhu; není příslibem, že libovolná migrace půjde provést stejným postupem.

Záloha patří do širšího plánu obnovy, ale její návrat může odstranit nové legitimní operace. Nespojujte proto automaticky aplikační rollback s obnovou starého snapshotu. Pro konkrétní změnu určete, co lze vrátit, co vyžaduje opravu vpřed a kdo rozhodne o řešení nevratného vedlejšího účinku.

05Kontrolní brány musí rozlišovat chybu a chybějící data

Vyberte metriky spojené s důležitými úlohami: chybovost, dobu odpovědi, úspěšné dokončení a stav front. Sledujte je podle verze a vhodného kontextu. Celkový průměr může schovat problém nové malé skupiny, zatímco rozdílné složení uživatelů může vytvořit zdánlivý rozdíl bez stejného zatížení.

Předem určete pravidlo pokračování, zastavení a ručního posouzení. Argo analysis rozlišuje úspěšný, neúspěšný a nerozhodný výsledek. Prázdný nebo chybný podklad musí mít výslovně navržené zacházení. Nula nalezených chyb není důkaz zdraví, pokud ve skutečnosti žádný požadavek neproběhl.

Zkontrolujte, že monitoring zachytí nové instance a označí správnou verzi. Při pilotu si ověřte i samotné upozornění a reakci týmu. Metrika, kterou nikdo neuvidí, není účinná provozní brána. Automatické zastavení má být otestované, stejně jako cesta k řízenému dalšímu kroku.

Kontrolu doplňte o reálné funkční scénáře. Přihlášení, uložení a předání důležité operace mají ukázat skutečný výsledek. Technický health check může být zelený, přestože obchodní úloha selhává. Zaznamenejte konkrétní omezení testu, aby se jeho výsledek nepoužíval jako důkaz pro neověřenou část systému.

Tým si má vyzkoušet i ztrátu samotného zdroje metrik. Rozhodnutí o pokračování musí odpovídat předem domluvené politice. Dostupnost monitoringu a dostupnost aplikace jsou různé skutečnosti; když nevidíte výsledek, nenahrazujte jej předpokladem, že vše funguje.

06Nezapomeňte na relace, fronty a externí účinky

Dlouhá spojení, rozpracované požadavky a lokální stav mohou přežít okamžik změny směrování. Připravte dokončení běžící práce a dohodnuté vypínání instancí. U relací ověřte, zda obě verze rozumějí stejnému uloženému stavu. Rozdílný formát může způsobit potíže až při druhém kroku uživatele.

Procesy na pozadí posuzujte samostatně. Dvě prostředí nemají bez pravidel současně odesílat stejnou fakturu nebo spouštět tutéž plánovanou úlohu. Fronty a zprávy potřebují kompatibilitu konzumentů i ochranu před opakovaným účinkem. Přepnutí webové vrstvy takovou práci automaticky neřídí.

U externích systémů počítejte s odpovědí opožděnou za hranici nasazení. Nový konzument musí rozumět události vytvořené starší verzí a naopak podle skutečného scénáře návratu. Do kontroly zahrňte platební bránu, e-mail, dokumenty a partnerské API, které jsou pro vaši úlohu podstatné.

Při migraci do cloudu navíc řešíte přesun prostředí a dat. Nasazování verzí je samostatná provozní disciplína. Po úspěšném přesunu připravte opakovatelný publikační postup, aby další běžná úprava nevyžadovala improvizované přepínání a ruční porovnávání serverů.

07První zavedení proveďte s nacvičeným zastavením

Začněte změnou s dobře pochopeným dopadem. Připravte artefakt, konfiguraci, kompatibilitu a záznam očekávaného chování. Vyberte dostupné období a lidi, kteří zvládnou rozhodnout o návratu. Smyslem je ověřit opakovatelný provozní postup, nikoli jen jednou úspěšně spustit nástroj.

1. Zmapujte hranice aplikace, data a vedlejší účinky.
2. Připravte směrování, kapacitu a kompatibilní verze.
3. Vyzkoušejte kontrolní brány, zastavení i návrat.
4. Proveďte řízené nasazení a uchovejte důkazy vyhodnocení.

Po nasazení zaznamenejte skutečný průběh, nalezené mezery a nutné úpravy. Dohodněte okamžik úklidu starých instancí i odstranění přechodných struktur. Rozsah nástroje přizpůsobte týmu a riziku. Malá aplikace nemusí potřebovat celý orchestrátor, ale potřebuje rozumět dostupnosti, kompatibilitě a obnově.

Uchovejte identifikaci vydaného artefaktu a konfigurace. Při návratu potřebujete přesně tu verzi, jejíž chování znáte, nikoli nově sestavený balík ze stejného názvu větve. Změna závislosti či tajemství může výsledek ovlivnit. V publikačním záznamu proto spojte aplikaci, infrastrukturu a potřebné datové kroky do dohledatelného celku.

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