V reálném světě všechno jednou selže — server umře, disk se zaplní, síť vypadne, závislost přestane odpovídat. Reliability (spolehlivost) není o tom, aby se nic nikdy nepokazilo (to nejde), ale o tom navrhovat systém tak, že přežije, když se něco pokazí. Tahle kapitola spojuje dohromady spoustu nástrojů z předchozích témat do jednoho způsobu myšlení.
Pár pojmů na úvod
- Reliability (spolehlivost) = jak moc se na systém můžeš spolehnout, že funguje, jak má.
- Availability (dostupnost) = jaký podíl času je systém k dispozici (měří se v procentech).
- SRE (Site Reliability Engineering) = přístup ke spolehlivosti jako k inženýrské disciplíně (zpopularizoval Google).
- Incident = situace, kdy je něco rozbité a řeší se to.
- SPOF (Single Point of Failure) = jediné místo, jehož výpadek položí celý systém.
Dostupnost a „devítky"
Dostupnost se udává v procentech a mluví se o „počtu devítek":
| Dostupnost | Výpadek za rok | Říká se |
|---|---|---|
| 99 % | ~3,65 dne | „dvě devítky" |
| 99,9 % | ~8,8 hodiny | „tři devítky" |
| 99,99 % | ~52 minut | „čtyři devítky" |
Každá další devítka je mnohem dražší než ta předchozí. Většina aplikací nepotřebuje pět devítek — ujasni si, jakou dostupnost reálně potřebuješ (SLO z Observability), a neplať za víc.
🧮 Klíčový a protiintuitivní výpočet: dostupnosti se v sériovém řetězci násobí. Když request projde 5 komponentami, každá s 99,9 %, výsledek je 0,999⁵ ≈ 99,5 % — z „tří devítek" jsou rázem „dvě a půl" (z ~8,8 h výpadku za rok je ~44 h za rok). Víc komponent v sérii = horší dostupnost. Přesně proto je řešením redundance: paralelně zapojené (zálohované) komponenty dostupnost naopak zvyšují. „Žádný SPOF" není fráze, je to matematika.
Navrhuj pro selhání (design for failure)
Základní posun v myšlení: nepředpokládej, že věci poběží — počítej s tím, že selžou, a měj plán.
- Žádný SPOF (single point of failure). Cokoli, co existuje jen jednou, je bomba. Měj věci redundantně (víc instancí, víc serverů), ať výpadek jedné nic nepoloží (horizontální škálování).
- Graceful degradation (půvabné degradování). Když spadne nějaká část, systém ať funguje aspoň částečně, ne aby celý zkolaboval. Spadl doporučovací systém? Ukaž stránku bez doporučení, ne chybu.
- Izoluj selhání. Jedna přetížená část nesmí stáhnout celek — k tomu slouží timeouty, retry, circuit breaker a bulkhead z Patternů. Tohle všechno jsou nástroje spolehlivosti.
Chaos engineering — rozbíjej naschvál
Jak zjistíš, jestli tvůj systém opravdu přežije výpadek? Schválně ho způsobíš — v řízených podmínkách vypneš server, zpomalíš síť, zabiješ službu, a sleduješ, jestli to systém ustojí. Tomu se říká chaos engineering (proslavil ho Netflix nástrojem „Chaos Monkey", který náhodně vypíná produkční servery). Lepší najít slabinu, když ji hledáš ty, než ve 3 ráno, když praskne sama.
Životní cyklus incidentu
Když přesto něco praskne, jde o rychlost a klid:
- Detekce — dobrý alerting tě upozorní dřív než zákazník.
- On-call — někdo má službu a incident vezme.
- Mitigace nejdřív, oprava potom — nejdřív zastav škodu (rollback, vypni vadnou funkci přes feature flag), teprve pak v klidu hledej a oprav příčinu.
- Runbook — návod „když tohle, udělej tamto" (ve 3 ráno nechceš vymýšlet).
- Blameless postmortem — po incidentu se pouč a oprav systém, ne potrestej člověka (Observability).
Error budget — kolik si můžeš dovolit
Z Observability: SLO ti dává error budget (kolik smíš být mimo). Dokud rozpočet máš, můžeš riskovat rychlé novinky; když dojde, zabrzdíš a stabilizuješ. Spolehlivost se tím řídí číslem, ne pocitem.
Failure modes — jak se spolehlivost podceňuje
- Single point of failure → jedna věc spadne a vezme s sebou všechno.
- Žádná degradace → vedlejší výpadek (doporučení) shodí celou hlavní funkci.
- Honba za pěti devítkami → utratíš majlant za dostupnost, kterou nepotřebuješ.
- Žádný plán na incident → když praskne, tým hasí chaoticky a ztrácí čas.
- Nikdy netestovaná obnova/výpadky → zjistíš, že to nefunguje, až v ostré krizi.
🛠️ Cvičení
- Najdi SPOF. Máš jeden load balancer → jednu instanci appky → jednu databázi. Označ všechna jediná místa selhání a navrhni, jak je zdvojit.
- Graceful degradation. Appka volá doporučovací službu, která občas spadne. Navrhni, jak stránku ukázat i bez doporučení místo chyby.
- Spočítej devítky. Kolik minut za měsíc smíš být mimo při SLO 99,9 %? A při 99,99 %?
- Chaos test. Vymysli tři „chaos" experimenty pro tvůj systém (co schválně rozbiješ) a co bys u každého sledoval.
- Mitigace vs oprava. Při incidentu zjistíš, že nová verze způsobuje chyby. Co uděláš jako první a proč (mitigace), a co až potom?
Náčrt řešení — rozbal, až si cvičení zkusíš sám
- Najdi SPOF — SPOF jsou všechny tři: load balancer, instance appky i databáze. Zdvoj je redundancí — víc LB (failover), víc instancí appky za nimi, databáze s replikou. Pozor: redundance zvyšuje dostupnost jen u opravdu nezávislých kopií — sdílené patro (jeden napájecí okruh, jedna zóna) je skrytý SPOF.
- Graceful degradation — kolem volání doporučovací služby dej timeout a fallback: když nedopoví nebo spadne, vykresli stránku bez doporučení místo chyby. Pozor: fallback musí být skutečně bez doporučení (prázdná sekce / skrytý blok), ne tichá chyba, která stejně shodí render hlavní stránky.
- Spočítej devítky — měsíc má ~30 dní; 99,9 % = 0,1 % mimo ≈ ~43 minut/měsíc, 99,99 % ≈ ~4,3 minuty/měsíc. Pozor: každá devítka navíc je řádově dražší — počítej, kolik dostupnosti reálně potřebuješ, ne kolik zní hezky.
- Chaos test — např. vypni jednu instanci appky (drží redundance?), zpomal/odstav databázi (zabere timeout a degradace?), zabij doporučovací službu (ukáže se stránka bez ní?). U každého sleduj, jestli systém ustojí výpadek a co hlásí alerting. Pozor: dělej to řízeně, ne naslepo v ostré špičce.
- Mitigace vs oprava — nejdřív zastav krvácení: rollback na předchozí verzi nebo vypnutí vadné funkce přes feature flag, aby uživatelé přestali dostávat chyby (otázka vteřin). Hledání a oprava skutečné příčiny počká, až systém zase funguje. Pozor: nepleť si pořadí — vyšetřování za běžící chyby jen prodlužuje škodu.
🧠 Otázky & odpovědi
Co znamená navrhovat systém pro selhání (design for failure)?
Že nepředpokládáš, že věci poběží, ale počítáš s tím, že selžou, a máš plán. Konkrétně: žádný single point of failure (vše redundantně), graceful degradation (při výpadku části funguj aspoň částečně) a izolace selhání pomocí timeoutů, retry, circuit breakeru a bulkheadu. V reálu všechno jednou spadne — spolehlivost je o tom přežít to, ne tomu zabránit.
Co je single point of failure a jak se mu bránit?
SPOF je jediné místo, jehož výpadek položí celý systém — jediný server, jediná databáze, jediný load balancer. Bráníš se redundancí: měj každou kritickou součást vícekrát (víc instancí, repliky databáze), aby výpadek jedné nic nepoložil. Pravidlo: cokoli, co existuje jen jednou, je riziko.
Co je graceful degradation?
Půvabné degradování: když spadne nějaká část systému, zbytek funguje aspoň částečně místo úplného kolapsu. Příklad: spadne doporučovací služba → ukážeš stránku bez doporučení, ne chybovou stránku. Uživatel dostane horší, ale použitelný zážitek místo „nic nefunguje". Vedlejší výpadek nesmí shodit hlavní funkci.
K čemu je chaos engineering?
K tomu, abys zjistil, jestli systém opravdu přežije výpadek — tím, že ho schválně způsobíš v řízených podmínkách (vypneš server, zpomalíš síť) a sleduješ, jestli to ustojí. Proslavil ho Netflix nástrojem Chaos Monkey, který náhodně vypíná produkční servery. Lepší slabinu najít, když ji hledáš ty, než když praskne sama v nejhorší chvíli.
Proč při incidentu nejdřív mitigovat a až potom opravovat příčinu?
Protože prioritou je zastavit škodu uživatelům, ne hned pochopit, proč to nastalo. Nejrychlejší mitigace (rollback, vypnutí vadné funkce přes feature flag) zastaví krvácení během chvíle; hledání a oprava skutečné příčiny může trvat dlouho a může počkat, až systém zase funguje. Nejdřív hasit, pak vyšetřovat.