Výpadky cloudu 2025–2026: co z post-mortemů plyne pro vaši architekturu

Co se stalo: čtyři incidenty za sedm týdnů

Následující přehled vychází výhradně z oficiálních post-mortemů poskytovatelů. Stojí za to přečíst je celé – jsou to nejlepší dostupné učebnice provozu distribuovaných systémů.

AWS: prázdný DNS záznam a to, co přišlo po něm

Shrnutí AWS popisuje příčinu jako „latent race condition“ v systému správy DNS pro DynamoDB: dva automatizované procesy se sešly tak, že výsledkem byl prázdný záznam pro dynamodb.us-east-1.amazonaws.com, který automatizace sama neopravila a který vyžadoval ruční zásah operátorů. Chybovost API DynamoDB trvala od 23:48 PDT 19. 10. do 2:40 PDT 20. 10. – v Česku tedy pondělní ráno a dopoledne.

Důležitější je druhá polovina příběhu. Subsystém EC2, který spravuje fyzické servery (DWFM), se po obnovení DynamoDB dostal do stavu, který AWS nazývá „congestive collapse“, a inženýři museli omezit příchozí práci a restartovat jeho hosty. Spouštění nových instancí EC2 se plně zotavilo až ve 13:50 PDT, chyby Network Load Balanceru skončily ve 14:09 PDT. Původní závada trvala necelé tři hodiny, její důsledky přes čtrnáct.

A jeden detail pro každého, kdo běží v jiném regionu: podle AWS měli zákazníci přihlašující se rootem nebo přes federaci nastavenou na signin.aws.amazon.com potíže s přihlášením do konzole i mimo us-east-1.

Azure Front Door: když spadne vstupní brána, nedostanete se ani k ovládání

Post Incident Review Microsoftu (tracking ID YKYN-BWZ) uvádí, že mezi 15:41 UTC 29. října a 00:05 UTC 30. října zákazníci Azure Front Door a Azure CDN zažívali timeouty a chyby DNS. Chyba prošla validací, protože ne všechny funkce se testovaly napříč různými verzemi control plane. Návrat k „last known good“ konfiguraci nepomohl přímo – vadná metadata už v ní byla – a konfigurace se musela čistit ručně. Mezi zasaženými službami PIR jmenuje i Azure Portal, Entra ID a Microsoft 365.

Cloudflare: dvakrát konfigurace, ne kód

Listopadový post-mortem: změna oprávnění v ClickHouse způsobila, že dotaz vracel duplicitní řádky a soubor s příznaky pro Bot Management narostl. Proxy měla pevný limit 200 příznaků (běžně jich používala kolem 60) a při jeho překročení zpanikařila. Prosincový post-mortem: při mitigaci zranitelnosti React Server Components (CVE-2025-55182) byla vypnuta interní testovací funkce WAF globálním konfiguračním systémem bez postupného nasazení, což ve starší verzi proxy vyvolalo roky neodhalenou chybu.

Společný vzorec: selhává řízení, ne železo

Ve všech čtyřech případech se opakují tři věci.

• Spouštěčem byla změna nebo automatizace, ne hardware. DNS automatizace, konfigurační metadata, generovaný soubor, globální přepínač.
• Změna se šířila rychleji, než ji bylo možné zastavit. U Cloudflare šla prosincová změna globálním konfiguračním systémem, který postupné nasazení neprovádí. Cloudflare i Microsoft v nápravných opatřeních shodně uvádějí zavedení postupného nasazování a delšího ověřování konfiguračních změn.
• Obnova trvala déle než příčina, protože systémy potřebné k obnově závisely na tom, co bylo rozbité.

To odpovídá širším datům. Uptime Institute ve zprávě Annual Outage Analysis 2026 (květen 2026) uvádí, že četnost výpadků na jedno datové centrum klesá pátý rok po sobě, ale 57 % respondentů vyčíslilo svůj poslední významný výpadek na více než 100 000 dolarů a každý pátý na více než milion. Poskytovatelé IT a datacentrových služeb třetích stran mají podle Uptime za devět let sledování na svědomí přibližně dvě třetiny veřejně hlášených výpadků.

Lekce 1: skryté závislosti na jednom regionu a na globálních službách

Workload v Frankfurtu nebo v Západní Evropě neznamená, že nemáte závislost jinde. Typická místa, kde se schovává:

• Identita a přihlášení – přihlašovací endpointy, federace, IdP hostovaný u stejného poskytovatele nebo za stejnou CDN.
• Globální vstupní vrstva – CDN, WAF, globální load balancer, DNS. Jedna služba pro všechny regiony je z definice jeden failure domain.
• Dodavatelé vašich dodavatelů – CI/CD jako služba, registry image, monitoring, status stránka, nástroj pro incidenty, platební brána. Pokud běží ve stejném regionu nebo za stejnou CDN jako vy, vypadnou ve stejnou chvíli.
• Nástroje pro obnovu – pipeline, ze které nasazujete, úložiště Terraform state, trezor s tajemstvími, dokumentace s runbooky.

Rozumný první krok je jednoduchý registr závislostí u každé kritické služby. Nemusí to být nástroj, stačí soubor v repozitáři:

service: objednavky-api
rto: 60m
rpo: 5m
dependencies:
  - name: primární databáze
    scope: region (eu-central-1), multi-AZ
    failure_mode: read-only režim z repliky
  - name: CDN / WAF
    scope: globální, jeden dodavatel
    failure_mode: přepnutí DNS přímo na origin (runbook RB-12)
  - name: přihlášení (IdP)
    scope: globální SaaS
    failure_mode: platné session dobíhají, nové přihlášení nejde
  - name: CI/CD
    scope: SaaS, hostováno v us-east-1
    failure_mode: ruční nasazení z break-glass účtu (runbook RB-07)
recovery_requires_control_plane: true   # kandidát na přepracování
last_restore_test: 2026-06-18

Pořádek v infrastruktuře je předpokladem – co není popsané jako kód, se do takového registru dostává těžko. Více v článku o chaosu v infrastruktuře.

Lekce 2: statická stabilita místo hrdinské obnovy

AWS definuje statickou stabilitu jako stav, kdy systém při selhání závislosti funguje dál beze změn. Doporučení z téhož dokumentu: místo spoléhání na control plane EC2, který má po výpadku zóny spustit nové instance, mít kapacitu předem zřízenou – a závislosti na control plane z cesty obnovy odstranit.

Říjnový incident je přesná ilustrace. Kdo měl 20. října v us-east-1 dost běžících instancí, přečkal. Kdo se spoléhal, že autoscaling při zátěži nebo po selhání přidá další, čekal hodiny, protože spouštění nových instancí nefungovalo.

Cena je zřejmá: předzřízená kapacita stojí peníze i ve chvíli, kdy se nevyužívá. Pro interní systém s tolerancí výpadku v řádu hodin se to nevyplatí a je legitimní to tak rozhodnout – ale vědomě a písemně.

Lekce 3: multi-AZ, multi-region, multi-cloud – co který krok řeší

U AWS globální tabulky DynamoDB během incidentu fungovaly: zákazníci se podle post-mortemu k replikám v jiných regionech připojili, jen replikace z us-east-1 a do něj měla zpoždění. Multi-region tedy pomohl těm, kdo ho měli připravený na úrovni dat i provozu.

U výpadků globální vstupní vrstvy by multi-region nepomohl vůbec. Řešením je alternativní cesta provozu, ale sám Microsoft v architektonické příručce k redundanci před Azure Front Door varuje, že nepečlivě navržené řešení vysoké dostupnosti může dostupnost zhoršit, protože přidává body selhání a provozní složitost, a že většina aplikací takovou architekturu nepotřebuje.

Kdy plný multi-cloud nedává smysl: téměř vždy, pokud ho nevyžaduje regulace nebo konkrétní obchodní důvod. Druhý cloud nasazený jen formálně je nejdražší forma falešného bezpečí – failover, který se nikdy nezkoušel, se při incidentu chová jako žádný.

Lekce 4: RTO a RPO jsou rozhodnutí, obnova je dovednost

RTO (za jak dlouho služba znovu poběží) a RPO (o kolik dat lze přijít) nejsou technické parametry, ale obchodní rozhodnutí s cenovkou. Bez nich se nedá říct, zda je multi-AZ málo, nebo multi-region moc. Stanovte je po službách, ne za celou firmu, a nechte je podepsat vlastníkem služby.

Druhá půlka je ověření. Post-mortemy ukazují, že i poskytovatelé s nejlepšími týmy narazili na cesty obnovy, které nikdo dlouho neprošel – AWS mezi opatřeními uvádí doplnění testů obnovy pro DWFM, Microsoft zkrácení doby obnovy data plane přibližně na hodinu.

K poslednímu bodu se hodí článek o monitoringu a logování; k tomu, jak nasazovat změny bez dopadu na provoz, pak zero-downtime deployment v Kubernetes.

Co k tomu říká regulace

Následující není právní výklad, jen orientace, kde požadavky hledat.

DORA (finanční sektor)

Nařízení (EU) 2022/2554 se použije od 17. ledna 2025. Článek 11 odst. 6 ukládá testovat plány kontinuity provozu IKT a plány reakce a obnovy alespoň jednou ročně a po podstatných změnách systémů podporujících kritické nebo důležité funkce; testovací plány mají (mimo mikropodniky) zahrnovat i scénáře přepnutí mezi primární infrastrukturou a redundantní kapacitou. Článek 12 odst. 6 ukládá při stanovení cílů doby obnovy a bodu obnovy pro každou funkci zohlednit, zda jde o kritickou nebo důležitou funkci. Článek 28 odst. 8 požaduje pro služby IKT podporující kritické nebo důležité funkce strategie ukončení (exit strategie).

DORA nenařizuje multi-cloud. Vyžaduje umět doložit, že riziko závislosti na dodavateli znáte, řídíte a že plán odchodu a obnovy je otestovaný. Jak přísně to dohled v konkrétním případě vyloží, je otázka pro compliance a právníky.

NIS2 a český zákon o kybernetické bezpečnosti

Směrnice NIS2 v čl. 21 odst. 2 písm. c) řadí mezi povinná opatření kontinuitu činností včetně správy záloh a obnovy po havárii a v písm. d) bezpečnost dodavatelského řetězce. V Česku je promítnuta do zákona č. 264/2025 Sb. a prováděcích vyhlášek. Podle výkladového materiálu NÚKIB k vyhlášce č. 409/2025 Sb. (režim vyšších povinností) upravuje řízení kontinuity činností § 15: povinná osoba stanovuje minimální úroveň poskytovaných služeb, dobu obnovení chodu a bod obnovení dat a pravidelně testuje plány kontinuity a plány obnovy. Tedy přesně to, co popisuje předchozí sekce – jen s povinností to doložit.

Rozsah povinností se liší podle režimu (vyšší a nižší) a přesné lhůty pro zavedení opatření závisí na datu registrace konkrétní organizace; ověřte si je v zákoně a u NÚKIB.

Co udělat v pondělí

1. Vyberte tři až pět služeb, jejichž výpadek firmu skutečně bolí, a u každé zapište RTO, RPO a vlastníka.
2. Sepište jejich závislosti včetně globálních služeb, SaaS nástrojů a dodavatelů. U každé označte rozsah (zóna, region, globální) a co se stane, když vypadne.
3. Projděte plán obnovy a podtrhněte každý krok, který vyžaduje funkční control plane poskytovatele, CI/CD nebo SSO. To jsou kandidáti na předzřízení nebo náhradní cestu.
4. Naplánujte jeden test obnovy na nejbližší čtvrtletí – začněte obnovou databáze ze zálohy s měřením času.
5. Rozhodněte o vstupní vrstvě: buď vědomě akceptujete riziko výpadku CDN/WAF, nebo máte runbook pro obejití a víte, jaká bezpečnostní opatření tím dočasně ztrácíte.
6. Zkontrolujte vlastní konfigurační změny: nasazují se postupně a dají se rychle vrátit?

Až poté má smysl otevírat debatu o druhém regionu nebo druhém dodavateli. Bez prvních čtyř kroků by šlo o investici naslepo.

Klíčové poznatky

• Velké výpadky 2025 spustila automatizace a konfigurace, ne selhání hardwaru; šířily se globálně během sekund až minut.
• Obnova trvala déle než příčina: u AWS necelé tři hodiny závady na DNS, přes čtrnáct hodin dopadů na EC2 a NLB.
• Multi-AZ je základ, ne cíl. Neřeší regionální službu, globální vstupní vrstvu ani ztrátu více zón.
• Statická stabilita: plán obnovy, který během výpadku nic nevytváří ani nemění, je nejspolehlivější.
• Redundance má cenu a může škodit. Nenacvičený failover a zdvojená konfigurace přidávají body selhání.
• RTO, RPO a testy obnovy jsou zároveň to, co po regulovaných subjektech chtějí DORA i český zákon o kybernetické bezpečnosti.