Když firma testuje odolnost, kterou nemá: jak milion eur ročně mizí v plánovaných výpadcích

Každé dva týdny na hodinu spadne Git, sestavovací linka i interní wiki. Vedení tomu říká „testování odolnosti“. Vývojáři tomu říkají jinak.

Petr si ve čtvrtek odpoledne odkládá kafe vedle klávesnice a otevírá žádost o sloučení kódu, na které pracoval dva dny. Kód je hotový, testy prošly lokálně, zbývá sloučení a nasazení. Klikne na tlačítko — a dostane časový limit. GitLab neodpovídá. Slack hlásí výpadek. Jenkins je mrtvý. Výstupy sestavení nedostupné. Za chvíli přijde lakonická zpráva na nástěnce: plánovaný test odolnosti datového centra.

Petr zavírá notebook. Za hodinu se vrátí, restartuje sestavovací řetězec, znovu ověří stav úložiště kódu, obnoví kontext. Ale hodina neplánované pauzy neznamená hodinu ztráty — přepnutí kontextu, synchronizace s kolegy a obnovení soustředěné práce ho stojí dalších čtyřicet minut. Násobeno šesti sty vývojáři ve firmě.

Vedení to dělá v dobré víře. Každé dva týdny vypne na hodinu jedno datové centrum, aby ověřilo, že zákaznické služby — vyhledávání, e-mail, zpravodajství — přežijí výpadek. A ony přežijí. Zákaznická infrastruktura je na to připravená, redundantní, otestovaná. Jenže interní systémy — Git, průběžná integrace a nasazování, wiki, komunikační nástroje, sestavovací farma — redundantní nejsou. Při každém testu prostě spadnou. A šest set lidí čeká.

Firmě se to jeví jako drobná nepříjemnost ve jménu vyššího dobra. Ve skutečnosti jde o inverzi jedné z nejdůležitějších inženýrských disciplín posledních patnácti let. A ta inverze firmu stojí přes milion eur ročně.

Příběh testování odolnosti řízeným selháváním začíná kolem roku 2010 v Los Gatos v Kalifornii, kde Netflix uprostřed migrace z vlastních datových center do cloudu Amazonu řeší zásadní inženýrský problém. Migrace, zahájená po rozsáhlém výpadku v roce 2008, potrvá celkem sedm let — dokončena bude až v lednu 2016. Ale už v její první fázi si inženýři uvědomují nepříjemnou pravdu: v cloudu se nedá spoléhat na to, že infrastruktura bude fungovat. Instance padají, zóny vypadávají, síť ztrácí pakety. Nedá se to předvídat — dá se na to ale připravit.

Greg Orzell a jeho tým vytvoří nástroj, který pojmenují Chaos Monkey. Během pracovních hodin náhodně ukončuje produkční instance. Nikoli proto, aby škodil, ale proto, aby přinutil inženýry navrhovat služby tak, aby přežily selhání jednotlivých součástí. Klíčový detail, který se často přehlíží: Netflix nejprve vybudoval redundantní architekturu na cloudu Amazonu — a teprve poté ji začal testovat pomocí Chaos Monkey. Opice neukončovala instance v systému bez záchranné sítě. Ukončovala je v systému, který měl záchrannou síť, aby ověřila, že síť drží.

Z Chaos Monkey postupně vyrostla celá sada nástrojů nazvaná Simian Army — Latency Monkey simuloval síťové zpomalení, Chaos Gorilla vypínal celé zóny dostupnosti, Chaos Kong simuloval výpadek celého regionu. Ale Netflix rychle zjistil, že i tato sada má zásadní problém: některé nástroje ovlivňovaly všechny služby bez rozlišení, což způsobovalo nezamýšlené dopady na zákazníky.

V říjnu 2014 proto Kolton Andrus a jeho tým vytvořili FIT — testování řízeným vstřikováním selhání (Failure Injection Testing). Principiálně odlišný přístup: místo plošného chaosu přesně cílené vstřikování selhání na konkrétní službu, s postupným rozšiřováním. Nejprve jeden testovací účet, poté jedno procento provozu, teprve po ověření celá produkce. Nikoli náhodná destrukce, ale řízený experiment s měřitelným výstupem.

Netflix formální tým pro testování odolnosti vybudoval přibližně v roce 2015 pod vedením Caseyho Rosenthala — pět let po Chaos Monkey. Vývoj disciplíny trval roky. A začal redundancí, nikoli testováním.

V roce 2017 publikoval Rosenthal s kolegy principy testování odolnosti řízeným selháváním (manifest byl dále aktualizován v roce 2019 na webu principlesofchaos.org). Definuje disciplínu pěti principy. Stojí za to je projít jeden po druhém — protože většina organizací, které tvrdí, že „dělají chaos engineering“, porušuje minimálně tři z nich.

Princip první: definuj ustálený stav. Než začneš systém rozbíjet, musíš vědět, jak vypadá jeho normální chování. To znamená metriky — odezva, míra chyb, propustnost, dostupnost. Bez měření ustáleného stavu nemůžeš vědět, jestli experiment něco odhalil. Pokud firma nemá cíle úrovně služeb pro interní systémy, nemá co testovat.

Princip druhý: formuluj hypotézu. Experiment s odolností není „vypneme to a uvidíme, co se stane“. Je to vědecký experiment: „Hypotéza: při výpadku datového centra A bude GitLab dostupný přes datové centrum B s odezvou pod 200 ms.“ Pokud předem víš, že GitLab spadne, protože nemá repliku, neprovádíš experiment — provádíš plánovaný výpadek.

Princip třetí: simuluj reálné události. Simuluj skutečné typy selhání — rozpad síťové konektivity, saturaci procesoru, plné disky, pomalý překlad doménových jmen. Kompletní vypnutí datového centra je legitimní scénář, ale patří na konec eskalační pyramidy, ne na její začátek.

Princip čtvrtý: spouštěj experimenty v produkci. Tohle firmy rády slyší. Ale manifest zároveň říká —

Princip pátý: minimalizuj rozsah dopadu. A tohle už slyší méně rády. Je odpovědností inženýra zajistit, aby dopady experimentů byly ohraničeny. Začni jedním kontejnerem, pokračuj jednou službou, pak jednou zónou. Celé datové centrum je finální úroveň, nikoli výchozí bod.

Google provozuje program DiRT — testování obnovy po havárii (Disaster Recovery Testing) — přibližně od roku 2006. Vedla ho Kripa Krishnanová a program se stal jedním z pilířů kultury zajištění spolehlivosti provozu v Googlu. DiRT testy zahrnují i vypínání celých budov datových center — ale s disciplínou, které by mise na Mars záviděly.

Každý DiRT test vyžaduje formální plán testu schválený vedením. Musí existovat plán návratu — co přesně uděláme, když test odhalí kritický problém. Skutečné produkční incidenty mají vždy přednost; pokud během testu vznikne reálný výpadek, test se okamžitě zastavuje. Celý program má řídicí centrum, které dokumentuje průběh.

Při jednom DiRT testu Google zjistil, že infrastruktura pro rozesílání upozornění — systém, který posílá výstražné notifikace inženýrům — se nachází ve středisku, které právě vypnuli. Upozornění se řadila do fronty a nikdo je nedostával. Přesně ten typ poučení, pro který testování odolnosti existuje. Ale poučení, které vyplynulo z řízeného experimentu s připraveným návratem do původního stavu, nikoli z plošné destrukce.

Amazon má koncept „herního dne“ — GameDay —, který v roce 2004 vytvořil Jesse Robbins. Jeho pracovní pozice nesla přezdívku „Mistr katastrof“ (Master of Disaster). Herní den trvá dvě až čtyři hodiny, začíná ověřením zdraví prostředí, má jasně definovaná kritéria pro přerušení a končí společným rozborem bez hledání viníků. Werner Vogels, technický ředitel Amazonu, to shrnul větou, která se stala mantrou celého odvětví: „Všechno selže pořád.“ (Everything fails all the time.) Ale Amazon z toho vyvodil nikoli „tak to vypínejme a uvidíme“, nýbrž „tak to navrhněme, aby to přežilo selhání — a pak ověřme, že přežilo“.

Společný vzorec všech tří společností je jednoznačný: nejprve vybuduj odolnost, pak ji testuj. Netflix nepoužíval Chaos Monkey na systémech bez náhradního řešení. Google testuje pouze systémy s plány návratu. Amazon začíná herní den ověřením zdraví prostředí.

Vraťme se k Petrovi a jeho firmě. Co přesně se děje, když vedení každé dva týdny vypne datové centrum?

Zákaznické služby přežijí — jsou redundantní, distribuované, navržené pro tento scénář. Test potvrzuje to, co všichni vědí. Interní nástroje spadnou — protože nejsou redundantní. Test potvrzuje to, co taky všichni vědí. Nikdo se nic nového nedozví. Šest set lidí přijde o hodinu produktivní práce plus čtyřicet minut na obnovení kontextu. A za dva týdny znovu.

Profesorka Gloria Marková z Kalifornské univerzity v Irvine ve svém výzkumu zjistila, že návrat k přerušené úloze trvá průměrně 23 minut — mezi přerušením a návratem člověk obvykle projde dvěma jinými úkoly, které ho dále vykolejí. Při šesti stech vývojářích to při každém testu znamená přibližně 230 člověkohodin jen na znovunabytí kontextu — nezapočítáme-li samotnou hodinu výpadku.

Spočítejme to. Plně zatížená hodinová sazba vývojáře v české technologické firmě se pohybuje kolem 40 eur (včetně odvodů, režie a nástrojů). Při dvou testech měsíčně s dvouhodinovým efektivním dopadem (hodina výpadku plus obnovení kontextu) přichází firma o přibližně 24 000 eur za jednu hodinu výpadku na přímé produktivitě, plus dalších 9 200 eur na přepnutí kontextu. Ročně je to zhruba 1,0 až 1,2 milionu eur.

Studie společnosti Splunk z roku 2024 kontext potvrzuje: firmy z žebříčku Global 2000 přicházejí o 400 miliard dolarů ročně kvůli neplánovaným výpadkům. Stagnace produktivity vývojářů patří mezi nejvýznamnější skryté náklady.

Petrův zaměstnavatel utrácí přes milion eur ročně za testování hypotézy, jejíž výsledek zná předem.

Řešení není přestat testovat odolnost — je to přestat testovat neexistující odolnost. Cesta od současného stavu k zralému programu testování odolnosti má čtyři fáze a na kontejnerové infrastruktuře je technicky dobře zmapovaná.

Fáze nula — záchranná síť (týdny, minimální náklady). Automatizované zálohy kritických služeb do druhého datového centra. Zrcadlení klíčových úložišť kódu pomocí pravidelných úloh. Snížení doby platnosti záznamů překladu doménových jmen na 60 sekund pro rychlejší přesměrování. Provozní příručky pro ruční přepnutí na záložní systém. Interní stavová stránka. Tohle stojí dva inženýry na dva týdny a dramaticky snižuje dopad výpadků — při selhání datového centra existuje alespoň přístup ke čtení úložišť a dokumentace.

Fáze jedna — základní redundance (měsíce). Průběžná replikace PostgreSQL do druhého datového centra. Replikace objektového úložiště pro výstupy sestavení a přílohy. GitLab Geo pro replikaci úložišť kódu a sestavovacích výstupů — sekundární uzel slouží jako teplá záloha s přístupem ke čtení a možností povýšení na primární při výpadku. Infrastruktura definovaná kódem pro všechny interní nástroje, aby se daly obnovit v kterémkoli datovém centru.

Fáze dvě — automatické přepnutí na zálohu (čtvrtletí). Sestavovací stroje v obou datových centrech. Komunikační nástroje ve vysoce dostupné konfiguraci — Mattermost s replikací databáze, nebo Matrix/Synapse, který je architektonicky decentralizovaný a při výpadku jednoho datového centra přirozeně pokračuje na druhém. Wiki jako bezstavová služba s replikou databáze ke čtení. Přepínání založené na překladu doménových jmen pomocí k8gb nebo ExternalDNS. V této fázi většina interních služeb přežije výpadek datového centra s minimálním dopadem.

Fáze tři — skutečné testování odolnosti řízeným selháváním. Teprve nyní, s redundantní infrastrukturou, má smysl nasadit nástroje jako Litmus Chaos nebo Chaos Mesh a začít formulovat hypotézy. Postupná eskalace: ukončení jednoho kontejneru, selhání služby, výpadek zóny, výpadek celého datového centra. Každý experiment s definovaným ustáleným stavem, měřitelnými metrikami a kritérii pro přerušení. Čtvrtletní herní dny inspirované programem DiRT v Googlu — s formálním plánem, řídicím centrem a společným rozborem bez hledání viníků.

Celkové náklady implementace se pohybují kolem 800 000 eur v prvním roce (infrastruktura, licence, inženýrský čas), od druhého roku přibližně 470 000 eur ročně na provoz. Při ročních ztrátách produktivity přes milion eur se investice vrátí do osmnácti měsíců a od druhého roku dosahuje trojnásobné návratnosti. A to nezapočítává těžko kvantifikovatelný, ale reálný faktor: udržení vývojářů. Vývojář, kterému dvakrát měsíčně padá pracovní prostředí, hledá jiné pracovní prostředí.

Bylo by pohodlné vyprávět příběh černobíle: vedení dělá testování odolnosti špatně, ať to dělá správně. Realita má nuance.

Za prvé, samotné rozhodnutí testovat odolnost zákaznických služeb vypínáním datového centra je legitimní a progresivní. Většina českých technologických firem nedělá ani to. Kultura, která považuje plánované výpadky za přijatelné, je zdravější než kultura, která předstírá, že k výpadkům nedochází. Problém není v tom, že se testuje, ale v tom, co se při testu obětuje.

Za druhé, plná redundance interních systémů není triviální. Nasazení ve více datových centrech na kontejnerové platformě vyžaduje řešení síťové vrstvy (Cilium Cluster Mesh, Submariner), datové vrstvy (replikace PostgreSQL, distribuované databáze) a orchestrační vrstvy (ArgoCD, GitOps). Projekt KubeFed (Kubernetes Federation v2) je od dubna 2023 archivovaný — žádné řešení „na jedno kliknutí“ pro více clusterů neexistuje. Implementace vyžaduje kvalifikované inženýry zajištění spolehlivosti, kterých je na českém trhu nedostatek.

Za třetí, existuje argument, že výpadky interních systémů jsou „užitečný tlak“ na vývojáře, aby navrhovali vlastní nástroje odolněji. Tento argument selhává ve chvíli, kdy vývojáři nemají nad architekturou interních nástrojů žádnou kontrolu — nemohou GitLab udělat redundantním sami, to je úkol pro platformní tým.

I po zohlednění těchto námitek zůstává klíčový bod platný: testování systému, o kterém víme, že selže, není experiment — je to plánovaný výpadek s předem známým výsledkem. Testování odolnosti řízeným selháváním vyžaduje hypotézu, která může být vyvrácena. Pokud nikdy není, neučíme se nic nového.

Je čtvrtek odpoledne, dva týdny po posledním testu. Petr otevírá žádost o sloučení kódu, kód je hotový, testy prošly. Ví, že dnes je den testu. Čeká. Za chvíli přijde zpráva na nástěnce.

Ale tentokrát je jiná. GitLab přepne na sekundární uzel, přístup ke čtení běží do patnácti sekund. Sestavovací stroje v druhém datovém centru převezmou řetězec. Slack přejde na záložní instanci. Petr žádost o sloučení odloží o dvě minuty — nikoli o dvě hodiny.

Vedení se dívá na přehled: přepnutí proběhlo za 47 sekund, tři služby překročily cíl odezvy o 12 %, jedna interní služba vrátila dvě chybové odpovědi, než se přepnula. Tohle jsou data. Tohle je experiment s vyvrátitelnou hypotézou. Tohle jsou zjištění, která stojí za to opravit.

Netflix nepustil Chaos Monkey na systémy bez záchranné sítě. Google neshazuje datová centra bez plánu návratu. Amazon nezačíná herní den bez ověření zdraví prostředí. Všichni tři nejprve vybudovali odolnost — a teprve potom ji začali rozbíjet.

Petr mezitím slučuje svůj kód. Sestavení projde na první pokus.

Autor pracuje jako vývojář infrastrukturních systémů v české technologické firmě. Článek vychází z osobní zkušenosti a veřejně dostupných zdrojů o testování odolnosti řízeným selháváním.

Zdroje:

Transparentnost tvorby

Koncepce, struktura a redakční linie článku jsou dílem autora, který vypracoval obsahovou skicu, stanovil klíčové teze a řídil celý proces tvorby. Generativní AI (Claude Opus 4.6, Anthropic) byla využita jako nástroj pro rešerši, ověřování faktů a rozepsání autorovy předlohy.

Autor ověřil klíčová zjištění a schválil finální znění. Žádná část textu nebyla publikována bez vědomé autorské kontroly. Faktické údaje byly ověřeny proti veřejně dostupným zdrojům uvedeným v textu.

Postup odpovídá principům transparentnosti Nařízení EU 2024/1689 (AI Act). #poweredByAI