První IT magazín psaný manažery z praxe.
Cloudová služba může obsluhovat požadavky, i když zrovna nelze vytvořit novou instanci, změnit pravidlo sítě nebo aktualizovat konfiguraci. Rozdíl mezi datovou a řídicí rovinou je provozně užitečný: při incidentu nechcete zjistit, že obnova běžící služby závisí právě na části cloudu, která přestala přijímat změny.
U každé důležité služby projděte start nové instance a přepnutí provozu. Potřebuje služba vytvořit VM nebo Pod, přidělit disk, změnit DNS, získat tajný klíč, načíst artefakt, vytvořit síťové pravidlo nebo přepnout databázi? Který krok je volání řídicího API a který běží z již připravené konfigurace? Inventář dostupnosti podle počtu zón nestačí, pokud obě zóny pro obnovu čekají na jedinou změnovou cestu.
Zvláštní pozornost si zaslouží konfigurace a identita. Aplikace může běžet na dostatečném počtu uzlů, ale po vypršení krátkodobých přihlašovacích údajů ztratí přístup k databázi. Nebo si při restartu musí stáhnout parametr z centrálního systému, který neodpovídá. Test statické stability proto zahrnuje celý životní cyklus během očekávané doby poruchy, nejen první minutu po odpojení řídicího API.
| Závislost služby | Co musí být připravené | Co se zkouší při výpadku |
|---|---|---|
| Výpočetní kapacita | Rezerva v přeživší zóně a pravidla degradace | Dokončené požadavky bez nových instancí |
| Konfigurace a identita | Použitelná poslední konfigurace a platné přístupy | Restart a pokračování po dobu poruchy |
| Směrování provozu | Předem připravená zdravá cesta | Přechod bez úpravy DNS či síťových pravidel |
| Obnova plné služby | Runbook pro návrat řídicí roviny | Bezpečné doplnění kapacity po incidentu |
KAPACITNÍ PRAVIDLO
Slibované důležité operace musí přeživší část služby dokončovat po předem určenou dobu bez vytvoření nového zdroje. Rezervu stanovte podle zákaznického SLO a skutečného bodu zlomu.
Typický runbook říká: vytvořte další instance, přepněte DNS, změňte síťové pravidlo a pošlete nový deployment. V běžném dni je to rozumná automatizace. Při širší poruše však každý krok přidává závislost na řídicím API, přístupu operátora a správné propagaci změny. Pokud příčina incidentu zasáhla právě tyto systémy, může pokus o opravu zhoršit stav, který by stávající instance ještě zvládly. Runbook by proto měl mít i cestu „změny teď neprovádět“ a seznam služeb, které mají dál fungovat ze stabilního stavu.
V praxi to znamená předem vytvořené kapacitní rezervy tam, kde je to ekonomicky přiměřené, lokálně dostupnou poslední dobrou konfiguraci a pravidla pro degradaci zátěže. Důležité tajné údaje a certifikáty musí vydržet očekávané okno poruchy, aniž by se musely okamžitě znovu vydat. Jinak se rozdíl mezi datovou a řídicí rovinou vytratí v nejméně nápadné závislosti.
PORUCHOVÝ TEST
V řízeném cvičení zakažte vytváření i změnu cloudových prostředků, vyřaďte jednu zónu a sledujte dokončené zákaznické operace. Zaznamenejte každý skrytý pokus o volání správního API.
Aplikace běží ve dvou zónách. Jedna začne mít problémy a provozní plán předpokládá, že autoscaler ve druhé vytvoří další uzly, nastaví jejich síť, stáhne konfiguraci a zapojí je do provozu. Jenže současně je omezená řídicí rovina poskytovatele. Stávající instance dál přijímají požadavky, ale nové nevznikají. Teoreticky redundantní architektura ztrácí dostupnost ve chvíli, kdy potřebuje změnit stav, aby redundanci teprve získala.
AWS tento rozdíl popisuje jako control plane pro vytváření a změny zdrojů a data plane pro každodenní práci už běžících zdrojů. Její princip statické stability říká, že služba má vydržet určitou poruchu bez okamžité potřeby dalších řídicích akcí. Nejde o pravidlo, že každá aplikace musí mít stále dvojnásobek zdrojů. Jde o návrh, který výslovně počítá s tím, co lze provozovat, když změny na chvíli nepůjdou.
POZNÁMKA Z PRAXE
Zdravá existující instance není rezerva, pokud při restartu čeká na nedostupnou konfiguraci nebo jí během poruchy vyprší přístup k databázi. Test musí trvat déle než životnost těchto závislostí.
Statická stabilita neznamená, že během poruchy lze dál rozvíjet službu nebo bezpečně provádět každou plánovanou změnu. Znamená, že vymezená důležitá práce pokračuje po předem dohodnutou dobu a při známém omezení. Měřte proto dokončené objednávky, dostupnost čtení důležitých dat a délku fronty odložené práce. Počet zdravých instancí sám neukáže, zda systém pro uživatele opravdu funguje. Toto měření také pomůže určit, které kapacitní rezervy mají obchodní smysl.
Při revizi architektury bych položil jednoduchou otázku: které konkrétní API musíme během incidentu zavolat, abychom splnili slíbené SLO? Pokud odpověď obsahuje řadu řídicích operací, tým má práci pro další test. Pokud služba zvládne základní provoz i bez nich a její návrat k plné kapacitě je řízený, redundance se změnila z obrázku v provozní vlastnost.
HRANICE DŮKAZU
Běžící instance dokazují pouze dostupnost části datové cesty. Neprokazují platnost všech identit, zásobování tajnými údaji, kapacitu zbývajících zón ani možnost bezpečně navázat po návratu řídicí roviny.
Předem připravená kapacita stojí peníze. Její hodnota se však má srovnávat s obchodním dopadem přerušení služby a s pravděpodobností, že při širším incidentu nebude možné pružně dokoupit další zdroje. Některé služby mohou v degradovaném režimu odmítat méně důležitou práci, zachovat zápisy a odložit dávky. Jiné musí mít rezervu pro plný provoz. Právě tato volba patří vlastníkovi služby, ne do implicitního předpokladu automatického škálování.
Rezerva má cenu a vlastník služby ji musí porovnat s dopadem nedokončené zákaznické práce. V některých systémech stačí odložit dávky a udržet zápisy; jiné potřebují plný výkon i po ztrátě zóny. Nosná teze zní: architektura je odolná tehdy, když po sjednanou dobu dokončuje důležitou práci i ve chvíli, kdy nelze přidat ani změnit infrastrukturu.
CIOmag.cz je magazín, a proto je veškerý obsah ve své podstatě reklamou.