Incident response playbook pre malé tímy

V skratke: Keď v piatok o 23:30 padne produkčný server, nie je čas vymýšľať postup od nuly. Incident response playbook je dokument, ktorý definuje role, komunikáciu a postupy predtým, než ich potrebujete. Tu je minimálny playbook vhodný pre 5-20 osobný tím.

Role počas incidentu

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

• Incident Commander (IC) - manažuje incident, robí rozhodnutia, eskalulja. Nepíše kód.
• Technical lead - človek, ktorý poznáí problémovú oblasť. Píše opravu.
• Communications lead - aktualizuje status page, zákazníkov, manažment. Pre malý tím môže byť to isté ako IC.
• Scribe - zapisuje timeline, kto čo robí, kedy. Kľúčové pre post-mortem.

V tíme do 5 ľudí typicky IC + Technical lead = 2 role rozdelené, ostatné si vezme IC.

Severity levels

Definujte 3-4 úrovne závažnosti vopred:

• SEV1 (Critical) - hlavná služba úplne nedostupná. Reaguje sa okamžite, page aj v noci.
• SEV2 (Major) - významná degradácia (časť featur, niektorí používatelia). Reakcia do 30 min počas pracovných hodín, do 1 h mimo.
• SEV3 (Minor) - malý dopad, workaround existuje. Reakcia do nasledujúceho pracovného dňa.
• SEV4 (Cosmetic) - bez user-facing dopadu, ide do bežnej queue.

Postup pri SEV1: prvých 15 minút

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

Komunikácia: pravidlo "5 + 30"

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

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

Rollback ako default

Pri SEV1, ktorý začal krátko po nasadení, je rollback prvá voľba, nie hotfix. Hotfix pod tlakom v noci je zdroj ďalších bugov. Rollback obnoví známy dobrý stav a dáva čas na pokojnú diagnostiku ráno.

Pre rollback je nutné mať:

• Verziovanie nasadenia (Docker tagy, Git tagy, deployment artefakt)
• Database migrations backwards compatible (ak nová verzia drop-ne stĺpec, stará neopraví)
• Dokumentovaný rollback postup (príkazy, koľko trvá, kto ho môže spustiť)

Post-mortem do 48 hodín

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

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

On-call rotácia

Pre tím s 24/7 produktom:

• Týždenné rotácie - kratšie burnout-uje, dlhšie znamená kontinuitu kontextu
• Vždy primárny + sekundárny on-call. Sekundárny preberá, keď primárny nereaguje do 5 min.
• Kompenzácia (extra payment, time-off) za nočné a víkendové paging
• Mesačný "on-call review" - kto bol často budený, čo sa dá automatizovať

Nástroje

• Monitoring (ePulzio, Datadog, New Relic) - detekcia + alerting
• Paging (PagerDuty, Opsgenie, Better Stack) - eskalácia, rotácia, SMS/voice
• Status page (vlastná, ePulzio, 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 nedá improvizovať pod tlakom. 30 minút investovaných do napísania playbook-u 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 robiť.