Nic se ti nevryje do paměti tak jako pořádná katastrofa. Tahle kapitola je sbírka slavných reálných výpadků velkých firem — co se stalo, proč, a hlavně co si z toho odnést. Většina z nich není o exotické technologii, ale o banalitě, na kterou se v téhle učebnici dívá celá kapitola. Čti to jako „takhle to dopadne, když se podcení X".
Knight Capital (2012) — špatný deploy za 440 milionů dolarů
Co se stalo: Nová verze se nasadila na 7 z 8 serverů — na osmém zůstal starý kód. Tým navíc
znovupoužil starý feature flag, který dřív zapínal dávno mrtvou funkci (Power Peg). Když se ten
flag zapnul, na sedmi serverech aktivoval novou funkcionalitu, ale na tom osmém spustil ten dávný
mrtvý kód, který začal chrlit šílené objednávky. Za 45 minut firma přišla o ~440 milionů dolarů —
zhruba čtyřnásobek svého ročního zisku — a musela být narychlo zachráněna akvizicí (nezkrachovala
pádem, ale přišla o nezávislost).
Proč: nekonzistentní nasazení (stará verze na 1 z 8 serverů) + kolize znovupoužitého feature flagu (stejný přepínač znamenal na staré a nové verzi něco úplně jiného) + žádný rychlý „kill switch".
Poučení: bezpečné deploy strategie (ať všude běží stejná verze), feature flags s pořádkem, a hlavně mít čím to okamžitě zastavit (rollback / kill switch). Mitigace musí být na vteřiny (Reliability).
AWS S3 (2017) — překlep, který položil kus internetu
Co se stalo: Inženýr během údržby zadal příkaz s překlepem a omylem odstavil víc serverů, než chtěl. Spadla velká část úložiště S3 — a s ním tisíce webů a služeb, které na něm závisely (včetně mnoha „statusových" stránek, takže ani nešlo hlásit výpadek).
Proč: mocný nástroj bez pojistek (jeden příkaz mohl odstavit příliš mnoho), obří blast radius (jedna služba táhne za sebou půlku internetu).
Poučení: nástroje na nebezpečné operace potřebují pojistky (limit, potvrzení, postupnost) a mysli na blast radius — co všechno spadne, když spadne tohle. A závislost na jedné službě je single point of failure.
GitLab (2017) — smazaná produkční databáze a zálohy, co nefungovaly
Co se stalo: Unavený inženýr v noci řešil problém a omylem spustil mazání na produkční databázi místo na záložní. Smazal stovky GB dat. Pak přišel ten horší šok: většina záloh nefungovala — backupy se tiše roky nepořizovaly správně a nikdo to nezkusil obnovit.
Proč: žádná pojistka proti destruktivnímu příkazu na produkci, a hlavně netestované zálohy.
Poučení: to z Databází: záloha, kterou neumíš obnovit, není záloha — obnovu pravidelně zkoušej. A destruktivní operace na produkci ať mají pojistky (těžko zaměnit prod a staging).
Cloudflare (2019) — jeden regulární výraz položil službu globálně
Co se stalo: Do systému se nasadilo jediné špatně napsané pravidlo (regex), které začalo žrát extrémně moc CPU. Během chvíle vytížilo procesory po celém světě a Cloudflare (a weby za ním) na půl hodiny spadly.
Proč: nasazení rizikové změny všude naráz, bez limitu na to, kolik zdrojů smí spotřebovat.
Poučení: postupné nasazení (canary — pusť na malé % a sleduj, viz Infra), resource limity (nic nesmí sežrat všechno) a chaos/testování rizikových změn.
Společná nit
Všimni si, že ani jeden z těch miliardových průšvihů nebyl o nějaké geniální technologii. Vždy to byla banalita z téhle učebnice: nasazení, rollback, zálohy, blast radius, postupné vypouštění změn. To je celá pointa — senioritu nedělá znalost exotiky, ale disciplína v základech.
A ještě jedna: u žádné firmy se vinou neházelo po jednom „blbci, co zadal překlep". Vždy selhal systém (chyběla pojistka, test, postupnost). Proto blameless postmortem — viník není člověk, ale chybějící zábradlí.
🛠️ Cvičení
- Najdi chybějící zábradlí. U Knight Capital vyjmenuj tři konkrétní opatření z této učebnice, která by katastrofu zastavila nebo zmírnila.
- Blast radius. Pro svůj (klidně smyšlený) systém urči, co všechno spadne, když spadne databáze, a jak ten dopad zmenšit.
- Otestuj zálohu. Navrhni postup, jak ověříš, že tvoje zálohy jdou opravdu obnovit (a jak často).
- Canary by pomohl? U Cloudflare regexu vysvětli, jak by postupné nasazení omezilo škodu.
- Napiš postmortem. Vyber jeden z incidentů a sepiš krátký blameless postmortem (co, proč, co změnit), bez ukazování na člověka.
Náčrt řešení — rozbal, až si cvičení zkusíš sám
- Najdi chybějící zábradlí — tři opatření: bezpečná deploy strategie, aby všude běžela stejná verze (ne stará na 1 z 8 serverů); pořádek ve feature flagách, aby se neznovupoužil flag s jiným významem; a rychlý kill switch / rollback na vteřiny. Pozor: chyběl právě ten kill switch — bez něj se 45 minut jen přihlíželo, jak to chrlí objednávky.
- Blast radius — vyjmenuj, co na databázi visí (přihlášení, objednávky, profily…), a co z toho přestane fungovat, když spadne. Dopad zmenši graceful degradací (části, co DB nepotřebují, ať jedou dál), cache pro čtení a replikou, ať není jediná. Pozor: cílem je, aby lokální výpadek netáhl celý systém — žádný jeden bod, co položí všechno.
- Otestuj zálohu — postup: pravidelně (např. týdně) automaticky obnov zálohu do izolovaného prostředí a ověř, že data sedí (počty řádků, namátkové kontroly), a měř, jak dlouho obnova trvá (to je tvé reálné RTO). Pozor: záloha, kterou nikdy nezkusíš obnovit, není záloha — GitLab zjistil, že nefungují, až když je potřeboval.
- Canary by pomohl — vadný regex se nasadil všude naráz, takže vystřelil CPU globálně. Přes canary by šel nejdřív na malé % provozu, špička CPU by se ukázala na malém vzorku a změna by se zastavila dřív, než zasáhne všechny. Pozor: canary funguje jen se sledováním metrik a automatickým zastavením — pustit na 1 % a nekoukat nepomůže.
- Napiš postmortem — vyber incident a sepiš: co se stalo, proč (které zábradlí chybělo), a co změnit, aby se to neopakovalo — bez jména viníka. Pozor: hledej chybějící systémovou pojistku (test, postupnost, potvrzení), ne člověka — to je celý smysl blameless postmortemu.
🧠 Otázky & odpovědi
Co spojuje Knight Capital, S3, GitLab i Cloudflare?
Že žádná z těch miliardových katastrof nebyla o exotické technologii — vždy šlo o banalitu ze základů: nekonzistentní nasazení, chybějící rollback/kill switch, netestované zálohy, příliš velký blast radius, riziková změna nasazená všude naráz. Pointa: senioritu nedělá znalost exotiky, ale disciplína v základech, které tahle učebnice probírá.
Co se učíme z pádu GitLabu (2017)?
Dvě věci. Za prvé: destruktivní operace na produkci potřebují pojistky, aby nešlo snadno zaměnit produkci za zálohu/staging. Za druhé a hlavně: záloha, kterou nikdy nezkusíš obnovit, ti v krizi nepomůže — GitLabu se zálohy tiše roky nepořizovaly správně a zjistili to až ve chvíli, kdy je potřebovali. Obnovu pravidelně testuj.
Co je blast radius a proč na něm záleží (AWS S3)?
Blast radius je „dosah výbuchu" — co všechno spadne, když spadne jedna věc. U S3 jeden překlep odstavil úložiště, na kterém viselo tisíce dalších služeb, takže výpadek se rozlil po internetu. Mysli proto na to, kolik toho táhne za sebou každá součást, a omezuj závislost na jednom bodě (single point of failure), aby lokální problém nezpůsobil globální pád.
Jak by canary deploy pomohl u Cloudflare regexu?
Špatné pravidlo (regex) se nasadilo všude naráz, takže během chvíle vytížilo CPU po celém světě. Kdyby šlo přes canary — nasadit nejdřív na malé procento provozu a sledovat metriky — vystřelené využití CPU by se ukázalo na malém vzorku a změna by se zastavila dřív, než zasáhne všechny. Postupné nasazení omezuje škodu rizikové změny.
Proč se u těchto incidentů neházela vina na konkrétního člověka?
Protože u každého z nich selhal systém, ne člověk: chyběla pojistka proti záměně prod/staging, netestovaly se zálohy, nebylo postupné nasazení. Překlep nebo unavený inženýr je jen poslední kapka — opravit se musí zábradlí, ne potrestat člověk. To je princip blameless postmortemu: hledáš chybějící ochranu, ne viníka, protože jen tak lidé chyby přiznávají a systém se zlepšuje.