Incident response playbook pre malé tímy

Keď v noci padne produkčný server, nie je čas vymýšľať postup. Minimálny incident response playbook pre malý tím: role, komunikácia, postupy.

Role počas incidentu

Jasne rozdelené role eliminujú chaos. Aj malý tím potrebuje aspoň:

Incident Commander (IC) - riadi incident, robí rozhodnutia a eskaluje. Sám nepíše kód.
Technical lead - človek, ktorý pozná problémovú oblasť. Píše opravu.
Communications lead - aktualizuje status page, informuje zákazníkov a manažment. V malom tíme to môže byť tá istá osoba ako IC.
Scribe - zapisuje timeline: kto, čo a kedy robil. Je to kľúčový podklad pre post-mortem.

V tíme do 5 ľudí sa zvyčajne oddelí IC a Technical lead, zvyšné role preberá IC.

Severity levels

Vopred si definujte 3 - 4 úrovne závažnosti:

SEV1 (Critical) - hlavná služba je úplne nedostupná. Reaguje sa okamžite, vrátane budenia v noci (paging).
SEV2 (Major) - významná degradácia (časť funkcionality, niektorí používatelia). Reakcia do 30 min počas pracovných hodín, do 1 h mimo nich.
SEV3 (Minor) - malý dopad, existuje workaround. Reakcia do nasledujúceho pracovného dňa.
SEV4 (Cosmetic) - bez dopadu na používateľa, rieši sa v bežnej queue.

Postup pri SEV1: prvých 15 minút

00:00 - Detekcia. Alert príde z monitoringu alebo od zákazníka. Niekto z on-call rotácie potvrdí, že je problém reálny.
00:02 - Aktivácia IC. Otvorí sa dedikovaný komunikačný kanál (Slack #incident-N alebo Discord) a zavolá sa Technical lead.
00:05 - Prvý status update. Na public status page: "Investigating reports of [problém]." Email tým interným ľuďom, ktorí by o tom mali vedieť.
00:10 - Initial diagnostics. Skontrolujte recent deploys, monitoring grafy a error logy. Čo sa zmenilo za posledných 30 - 60 min?
00:15 - Rozhodnutie: rollback, hotfix, alebo workaround? Ak to nie je hneď jasné, IC eskaluje alebo privolá ďalších inžinierov.

Komunikácia: pravidlo „5 + 30"

Status page aktualizujte počas SEV1 minimálne každých 30 minút, aj keď nemáte nové informácie. "Stále vyšetrujeme, ETA zatiaľ neznáma" je lepší update než ticho - zákazníci aspoň vedia, že na probléme niekto pracuje.

Prvý update musí prísť do 5 minút od detekcie, bez ohľadu na to, či už poznáte príčinu.

Rollback ako predvolená voľba

Pri SEV1, ktorý sa objavil krátko po nasadení, je rollback prvou voľbou, nie hotfix. Hotfix písaný v noci pod tlakom býva zdrojom ďalších bugov. Rollback obnoví známy funkčný stav a dá vám čas na pokojnú diagnostiku ráno.

Predpokladom rollbacku je:

Verziovanie nasadenia (Docker tagy, Git tagy, deployment artefakt)
Database migrations, ktoré sú backwards compatible (ak nová verzia zruší stĺpec, stará ho už neobnoví)
Dokumentovaný rollback postup (príkazy, ako dlho trvá, kto ho môže spustiť)

Post-mortem do 48 hodín

Po každom incidente SEV1/SEV2 napíšte dokument s touto štruktúrou:

Summary - 2 - 3 vety o tom, čo sa stalo, ako dlho to trvalo a koho to ovplyvnilo
Timeline - presné časy detekcie, kľúčových akcií a vyriešenia
Root cause - prečo k tomu došlo (technický aj procesný dôvod)
Impact - počet ovplyvnených zákazníkov a business dopad
What went well - čo sme spravili dobre (oceňte tím)
What went wrong - kde sme stratili čas
Action items - konkrétne úlohy s ownerom a deadline (nie "lepšie testovať", ale radšej "pridať integration test pre payment flow do 14 dní, owner: X")

Pravidlo blameless post-mortem: Nehľadáte vinníka, ale systémovú slabinu. "John nasadil zlú verziu" je nesprávny záver - správny znie "deploy proces neobsahoval canary fázu, ktorá by chybu zachytila pred plným rolloutom".

On-call rotácia

Pre tím s 24/7 produktom platí:

Týždenné rotácie sú ideálny kompromis - kratšie obdobia spôsobujú časté striedanie, dlhšie zaťažujú primárneho on-callera
Vždy majte primárneho aj sekundárneho on-call. Sekundárny preberá, keď primárny nereaguje do 5 min.
Kompenzujte nočné a víkendové paging (príplatok alebo náhradné voľno)
Zaveďte mesačný "on-call review" - koho budil pager najčastejšie a čo sa dá zautomatizovať

Nástroje

Monitoring (ePulz.io, Datadog, New Relic) - detekcia a alerting
Paging (PagerDuty, Opsgenie, Better Stack) - eskalácia, rotácia, SMS/voice
Status page (vlastná, ePulz.io, Statuspage.io) - externá komunikácia
Runbook hosting (Notion, GitHub Wiki, internal docs) - playbooks a runbooks
Postmortem template (Confluence, Notion template) - štandardizácia

Záver

Incident response sa pod tlakom nedá improvizovať. 30 minút investovaných do napísania playbooku sa vráti pri prvom väčšom výpadku - menej chaosu, kratšie MTTR, lepšia komunikácia so zákazníkmi a tím, ktorý vie, čo má robiť.

Začnite s automatickou detekciou

ePulz.io rieši prvé minúty incident response: detekciu a alerting cez e-mail, Telegram a webhook do Slacku, Discordu, Microsoft Teams či vlastného endpointu (napr. PagerDuty).

Spustiť monitoring →