Incident Response & SRE
Produkce spadne. Otázka je, jak rychle vstanete.
Budujeme SRE kulturu a incident response procesy — runbooks, on-call rotace, blameless postmortemy, SLO/SLA a error budgets. Systematický přístup ke spolehlivosti.
Proč SRE¶
Každý systém selže. Otázka není jestli, ale kdy, jak rychle to zjistíte a jak rychle to opravíte.
Tradiční přístup: ops tým sleduje dashboardy, devs píšou kód, mezi nimi zeď. Když něco spadne, začne ping-pong — „to není náš bug”, „to je infrastruktura”, „funguje mi lokálně”. MTTR (Mean Time to Recovery) se měří v hodinách.
SRE přístup: Spolehlivost je feature. Měříme ji (SLOs), rozpočtujeme (error budgets), automatizujeme (runbooks), učíme se z chyb (postmortemy). Výsledek: MTTR v minutách, ne hodinách. Proaktivní, ne reaktivní.
Google vytvořil SRE, aby provozoval služby pro miliardy uživatelů. Ale SRE principy fungují pro firmu s 5 vývojáři stejně dobře jako pro firmu s 5 000. Škáluje se přístup, ne headcount.
SLO/SLA — měření spolehlivosti¶
Bez měření je spolehlivost jen pocit. „Systém funguje dobře” není metrika. SLO ano.
Service Level Indicators (SLI)¶
SLI je metrika, která měří uživatelskou zkušenost:
- Availability SLI: Podíl úspěšných requestů.
successful_requests / total_requests - Latency SLI: Podíl requestů pod latency thresholdem.
requests_under_500ms / total_requests - Freshness SLI: Podíl dat aktualizovaných v časovém limitu. Pro async systémy, data pipelines.
- Correctness SLI: Podíl správných výstupů. Pro výpočetní služby, ML inference.
Service Level Objectives (SLO)¶
SLO je cíl pro SLI: „99.9% requestů bude úspěšných” nebo „95% requestů bude mít latenci pod 200ms”.
Jak nastavujeme SLO:
- Měříme baseline — jaká je současná reálná spolehlivost?
- Definujeme uživatelské expectace — co uživatelé považují za přijatelné?
- Nastavíme SLO — mírně nad baseline, pod dokonalost. 100% není realistické SLO.
- Iterujeme — zpřísňujeme nebo uvolňujeme na základě dat a feedbacku.
Příklad: API má aktuální availability 99.95%. Uživatelé si stěžují při výpadcích delších než 10 minut. Nastavíme SLO na 99.9% (43 min downtime/měsíc) — dostatečně přísné pro uživatele, dostatečně realistické pro tým.
Service Level Agreements (SLA)¶
SLA je smluvní závazek — SLO s důsledky. Porušení SLA = penalizace, kredity, smluvní dopady. SLA je vždy volnější než interní SLO. Pokud interní SLO je 99.95%, SLA je 99.9% — máte buffer.
Error budgets — data-driven rozhodování¶
Error budget přeměňuje abstraktní tradeoff „rychlost vs. spolehlivost” na konkrétní číslo.
Jak to funguje¶
SLO 99.9% availability = 0.1% error budget = 43.2 minuty downtime za měsíc.
Error budget > 0: Tým má prostor riskovat. Deploye, experimenty, velké refaktoringy — jdeme na to. Rychlost je priorita.
Error budget ≈ 0: Zpomalíme. Žádné rizikové deploye. Focus na stabilitu, bug fixes, reliability improvements. Dokud se budget neobnoví.
Error budget < 0: SLO porušeno. Incident review. Akční plán na obnovení spolehlivosti. Freeze na nové features, dokud se situace nestabilizuje.
Error budget policies¶
Definujeme dopředu, co se stane při různých úrovních error budgetu:
- >50% zbývá: Business as usual. Rychlé deploye, experimenty povoleny.
- 25-50% zbývá: Zvýšená opatrnost. Canary deploye povinné. Extra review pro rizikové změny.
- <25% zbývá: Reliability sprint. Žádné nové features. Focus na stabilitu.
- Vyčerpáno: Feature freeze. Postmortem pro každý incident. Obnovení budgetu je top priorita.
Incident response — když to hoří¶
Každý incident má lifecycle: detekce → triage → mitigation → resolution → postmortem. Definujeme procesy pro každou fázi dopředu — ne uprostřed paniky.
Severity levels¶
SEV1 — Critical: Systém nedostupný nebo ztráta dat. Celý tým mobilizován. Komunikace zákazníkům. Resolution target: < 1 hodina.
SEV2 — Major: Významná degradace služby. Část funkcionality nedostupná. On-call + eskalace. Resolution target: < 4 hodiny.
SEV3 — Minor: Menší degradace. Workaround existuje. On-call řeší v pracovní době. Resolution target: < 24 hodin.
SEV4 — Low: Kosmetické problémy, minor bugs. Backlog, řeší se v rámci běžného sprintu.
On-call rotace¶
Princip: Vždy je někdo zodpovědný. 24/7 coverage, rotace po týdnu, jasné eskalační cesty.
Co on-call dostane: - Alert s kontextem (co se děje, odkdy, jaký impact) - Runbook (co dělat krok po kroku) - Eskalační kontakt (koho zavolat, když to nezvládne) - Přístup k dashboardům, logům, traces
Co on-call nedostane: Vágní alert „CPU high” bez kontextu. Alert fatigue — desítky alertů, z nichž 90% je false positive. Nedokumentované systémy, kde nikdo neví, co dělat. To řešíme předtím.
Runbooks¶
Runbook je step-by-step průvodce řešením konkrétního incidentu. Propojený přímo z alertu — kliknu na alert, otevře se runbook.
Dobrý runbook obsahuje: - Symptomy: Co vidíte? Jak poznáte, že se jedná o tento typ incidentu? - Impact: Co je postiženo? Kdo je ovlivněn? - Diagnostika: Jaké dashboardy otevřít? Jaké dotazy spustit? - Mitigation: Jak zastavit krvácení? (restart, rollback, feature flag off) - Resolution: Jak opravit root cause? - Eskalace: Kdy a komu eskalovat?
Runbooks nejsou statické. Po každém incidentu je aktualizujeme. Ideálně automatizujeme — runbook jako skript, ne jako dokument.
Blameless postmortemy¶
Po každém SEV1/SEV2 incidentu proběhne postmortem. Cíl: porozumět, co se stalo, a zabránit opakování. Ne najít viníka.
Struktura¶
Timeline: Minutu po minutě, co se stalo. Objektivní fakta, ne interpretace.
Root cause analysis: 5 Whys nebo fishbone diagram. Proč se to stalo? Proč to nebylo zachyceno dřív? Proč mitigation trvala tak dlouho?
Impact: Kolik uživatelů postiženo? Jak dlouho? Finanční dopad?
What went well: Co fungovalo? Jaké procesy pomohly? Kdo reagoval výborně?
What went wrong: Co selhalo? Jaké procesy chyběly? Co zpomalilo resolution?
Action items: Konkrétní, přiřazené, termínované. „Přidat alert pro connection pool exhaustion” (owner: Jana, deadline: pátek), ne „zlepšit monitoring” (nikdo, nikdy).
Blameless kultura¶
Lidé dělají chyby. Systémy by měly být navržené tak, aby jedna lidská chyba nezpůsobila katastrofu. Postmortem hledá systémové příčiny:
- Proč systém dovolil deploy bez canary?
- Proč neexistoval rollback mechanismus?
- Proč alert nepřišel dřív?
- Proč runbook neexistoval?
Když lidé vědí, že nebudou trestaní, reportují problémy otevřeně. Near-missy se stávají learning opportunities, ne skrývanými tajemstvími.
Jak implementujeme SRE¶
- Assessment — zmapujeme současné procesy, metriky, incident handling
- SLO workshop — definujeme SLIs a SLOs s product a engineering týmy
- Error budgets — nastavíme tracking, policies, reporting
- On-call setup — rotace, eskalace, runbooks, tooling (PagerDuty/OpsGenie)
- Postmortem process — šablona, facilitace, action item tracking
- Iterace — quarterly SLO review, runbook updates, process improvement
Stack¶
On-call: PagerDuty, OpsGenie, Grafana OnCall.
Incident management: Incident.io, Rootly, Jira.
Status pages: Statuspage, Instatus, Cachet.
Monitoring: Prometheus + Grafana, Datadog.
Communication: Slack incident channels, bridge calls.
Runbooks: Notion, Confluence, Backstage, nebo přímo v git.
Časté otázky
Site Reliability Engineering je disciplína, která aplikuje softwarové inženýrství na operační problémy. Místo reaktivního 'hasíme požáry' zavádí proaktivní procesy — SLOs pro měření spolehlivosti, error budgets pro řízení rizika, automatizaci pro eliminaci toilu. Výsledek: spolehlivější systémy s menší námahou.
Pokud máte SLO 99.9% availability, máte 0.1% 'rozpočtu na chyby' — to je 43 minut downtime za měsíc. Dokud máte error budget, můžete deployovat rychle a riskovat. Když se vyčerpá, zpomalíte a soustředíte se na stabilitu. Error budget přeměňuje reliability vs. velocity tradeoff na datově řízené rozhodnutí.
Ne nutně. Pro menší organizace zavedeme SRE principy do existujících dev týmů — shared on-call, runbooks, postmortemy, SLOs. Dedikovaný SRE tým dává smysl od ~50 vývojářů nebo pro kritické systémy (fintech, zdravotnictví, e-commerce).
Po každém významném incidentu proběhne strukturovaný review: timeline, root cause, impact, co fungovalo, co ne, action items. Klíčové: hledáme systémové příčiny, ne viníky. 'Proč systém dovolil, aby se to stalo?' místo 'kdo to udělal?'. Výsledek: opravujeme procesy a systémy, ne lidi.
Na základě uživatelských expectací a business požadavků. Měříme skutečné uživatelské zkušenosti (latence, error rate, availability). Iterujeme — začneme konzervativně, zpřísňujeme na základě dat. SLO není aspirace, je to kontrakt s uživateli.