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

Role během incidentu

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

• Incident Commander (IC) - řídí incident, dělá rozhodnutí a eskaluje. Sám nepíše kód.
• Technical lead - člověk, který zná problémovou oblast. Píše opravu.
• Communications lead - aktualizuje status page, informuje zákazníky a management. V malém týmu to může být táž osoba jako IC.
• Scribe - zapisuje timeline: kdo co dělá a kdy. Klíčový podklad pro post-mortem.

V týmu do 5 lidí se obvykle oddělí IC a Technical lead, zbylé role převezme IC.

Severity levels

Předem si definujte 3-4 úrovně závažnosti:

• SEV1 (Critical) - hlavní služba je úplně nedostupná. Reaguje se okamžitě, page i v noci.
• SEV2 (Major) - významná degradace (část funkcí, někteří uživatelé). Reakce do 30 min během pracovních hodin, do 1 h mimo ně.
• SEV3 (Minor) - malý dopad, existuje workaround. Reakce do následujícího pracovního dne.
• SEV4 (Cosmetic) - bez dopadu na uživatele, 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 z on-call rotace potvrdí, že je problém reálný.
2. 00:02 - Aktivace IC. Otevře se dedikovaný komunikační kanál (Slack #incident-N nebo Discord) a 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 o tom měli vědět.
4. 00:10 - Initial diagnostics. Zkontrolujte recent deploys, monitoring grafy a error logy. Co se změnilo za posledních 30-60 min?
5. 00:15 - Rozhodnutí: rollback, hotfix, nebo workaround? Pokud to není hned jasné, IC eskaluje nebo přivolá další inženýry.

Komunikace: pravidlo "5 + 30"

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

První update musí přijít do 5 minut od detekce, bez ohledu na to, zda už znáte příčinu.

Rollback jako výchozí volba

U SEV1, který se objevil krátce po nasazení, je rollback první volbou, ne hotfix. Hotfix psaný v noci pod tlakem bývá zdrojem dalších bugů. Rollback obnoví známý funkční stav a dá vám čas na klidnou diagnostiku ráno.

Předpokladem rollbacku je:

• Verzování nasazení (Docker tagy, Git tagy, deployment artefakt)
• Database migrations, které jsou backwards compatible (pokud nová verze zruší sloupec, stará ho už neobnoví)
• Dokumentovaný rollback postup (příkazy, jak dlouho trvá, kdo ho může spustit)

Post-mortem do 48 hodin

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

1. Summary - 2-3 věty o tom, co se stalo, jak dlouho to trvalo a koho to ovlivnilo
2. Timeline - přesné časy detekce, klíčových akcí a vyřešení
3. Root cause - proč se to stalo (technický i procesní důvod)
4. Impact - počet ovlivněných zákazníků a 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", ale raději "přidat integration test pro payment flow do 14 dní, owner: X")

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

On-call rotace

Pro tým s 24/7 produktem platí:

• Týdenní rotace jsou ideální kompromis - kratší vedou k vyhoření, delší zatěžují primárního on-callera
• Vždy mějte primárního i sekundárního on-call. Sekundární přebírá, když primární nereaguje do 5 min.
• Kompenzujte noční a víkendové paging (příplatek nebo náhradní volno)
• Zaveďte měsíční "on-call review" - koho budil pager nejčastěji a co se dá zautomatizovat

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 pod tlakem nedá improvizovat. 30 minut investovaných do napsání playbooku 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 →