Incident response playbook pro malé a střední týmy

Ve zkratce: Když v pátek o 23:30 padne produkční server, není čas vymýšlet postup od nuly. Incident response playbook je dokument, který definuje role, komunikaci a postupy předtím, než je potřebujete. Tady je minimální playbook vhodný pro 5-20 osobní tým.

Role během incidentu

Jasné role eliminují chaos. I malý tým potřebuje alespoň:

• Incident Commander (IC) - spravuje incident, dělá rozhodnutí, eskalulja. Nepíše kód.
• Technical lead - člověk, který zná problémovou oblast. Píše opravu.
• Communications lead - aktualizuje status page, zákazníky, management. Pro malý tým může být totéž jako IC.
• Scribe - zapisuje timeline, kdo co dělá, kdy. Klíčové pro post-mortem.

V týmu do 5 lidí typicky IC + Technical lead = 2 role rozdělené, ostatní si vezme IC.

Severity levels

Definujte 3-4 úrovně závažnosti předem:

• SEV1 (Critical) - hlavní služba úplně nedostupná. Reaguje se okamžitě, page i v noci.
• SEV2 (Major) - významná degradace (část featur, někteří uživatelé). Reakce do 30 min během pracovních hodin, do 1 h mimo.
• SEV3 (Minor) - malý dopad, workaround existuje. Reakce do následujícího pracovního dne.
• SEV4 (Cosmetic) - bez user-facing dopadu, jde do běžné queue.

Postup při SEV1: prvních 15 minut

1. 00:00 - Detekce. Alert přijde z monitoringu nebo od zákazníka. Někdo na on-call rotaci potvrdí, že je problém reálný.
2. 00:02 - Aktivace IC. Otevře se dedicated komunikační kanál (Slack #incident-N nebo Discord). Zavolá se Technical lead.
3. 00:05 - První status update. Na public status page: "Investigating reports of [problém]." Email tým interním lidem, kteří by měli vědět.
4. 00:10 - Initial diagnostics. Zkontrolujte recent deploys, monitoring grafy, error logs. Co se změnilo v posledních 30-60 min?
5. 00:15 - Rozhodnutí: rollback, hotfix nebo workaround? Pokud není hned jasné, IC eskalulja nebo zavolá další inženýry.

Komunikace: pravidlo "5 + 30"

Aktualizace status page minimálně každých 30 minut během SEV1, i když nemáte nové info. "Stále vyšetřujeme, ETA stále neznámá" je lepší update než ticho - zákazníci alespoň ví, že na problému někdo pracuje.

První update musí být do 5 minut od detekce. Bez ohledu na to, zda znáte příčinu.

Rollback jako default

Při SEV1, který začal krátce po nasazení, je rollback první volba, ne hotfix. Hotfix pod tlakem v noci je zdroj dalších bugů. Rollback obnoví známý dobrý stav a dá čas na klidnou diagnostiku ráno.

Pro rollback je nutné mít:

• Verzování nasazení (Docker tagy, Git tagy, deployment artefakt)
• Database migrations backwards compatible (pokud nová verze drop-ne sloupec, stará neopraví)
• Dokumentovaný rollback postup (příkazy, kolik trvá, kdo ho může spustit)

Post-mortem do 48 hodin

Po každém SEV1/SEV2 incidentu napište dokument se strukturou:

1. Summary - 2-3 věty co se stalo, kolik trvalo, koho ovlivnilo
2. Timeline - přesné časy detekce, klíčových akcí, vyřešení
3. Root cause - proč se to stalo (technický důvod + procesní důvod)
4. Impact - počet ovlivněných zákazníků, business dopad
5. What went well - co jsme udělali dobře (ocenit tým)
6. What went wrong - kde jsme ztratili čas
7. Action items - konkrétní úkoly s ownerem a deadlinem (ne "lépe testovat" - raději "přidat integration test pro payment flow do 14 dní, owner: X")

Pravidlo blameless post-mortem: Nehledáte viníka, hledáte systémovou slabinu. "John nasadil špatnou verzi" je nesprávný závěr - správný je "deploy proces neobsahoval canary fázi, která by chybu zachytila před plným rollout-em".

On-call rotace

Pro tým s 24/7 produktem:

• Týdenní rotace - kratší burnout-uje, delší znamená kontinuitu kontextu
• Vždy primární + sekundární on-call. Sekundární přebírá, když primární nereaguje do 5 min.
• Kompenzace (extra payment, time-off) za noční a víkendové paging
• Měsíční "on-call review" - kdo byl často buzen, co se dá automatizovat

Nástroje

• Monitoring (ePulz.io, Datadog, New Relic) - detekce + alerting
• Paging (PagerDuty, Opsgenie, Better Stack) - eskalace, rotace, SMS/voice
• Status page (vlastní, ePulz.io, StatusPage.io) - externí komunikace
• Runbook hosting (Notion, GitHub Wiki, internal docs) - playbooks a runbooks
• Postmortem template (Confluence, Notion template) - standardizace

Závěr

Incident response se nedá improvizovat pod tlakem. 30 minut investovaných do napsání playbook-u se vrátí při prvním větším výpadku - méně chaosu, kratší MTTR, lepší komunikace se zákazníky a tým, který ví co dělat.

Začněte s automatickou detekcí

ePulz.io řeší první minuty incident response: detekci + alerting přes e-mail, Telegram a webhook do Slack / Discord / PagerDuty.

Spustit monitoring →