Incident response playbook kis és közepes csapatoknak

Röviden: Amikor pénteken 23:30-kor leesik a produkciós szerver, nincs idő nulláról kitalálni az eljárást. Az incident response playbook olyan dokumentum, ami a szerepeket, kommunikációt és eljárásokat azelőtt definiálja, hogy szükséged lenne rájuk. Itt egy minimális playbook, ami megfelel egy 5-20 fős csapatnak.

Szerepek incidens során

A világos szerepek megszüntetik a káoszt. Egy kis csapatnak is legalább kell:

• Incident Commander (IC) - kezeli az incidenst, hoz döntéseket, eszkalál. Nem ír kódot.
• Technical lead - aki ismeri a problémás területet. Megírja a fix-et.
• Communications lead - frissíti a status page-et, ügyfeleket, menedzsmentet. Kis csapatnál lehet ugyanaz mint IC.
• Scribe - írja a timeline-t, ki mit csinál, mikor. Kulcsfontosságú post-mortemhez.

5 fős csapatban tipikusan IC + Technical lead = 2 szerep felosztva, a többit IC veszi.

Severity szintek

Definiálj 3-4 súlyossági szintet előre:

• SEV1 (Critical) - a fő szolgáltatás teljesen elérhetetlen. Azonnal reagálni, paging éjszaka is.
• SEV2 (Major) - jelentős degradáció (a funkciók egy része, néhány felhasználó). Reakció 30 percen belül munkaidőben, 1 órán belül azon kívül.
• SEV3 (Minor) - kis hatás, workaround létezik. Reakció a következő munkanapig.
• SEV4 (Cosmetic) - user-facing hatás nélkül, normál sorba megy.

SEV1 eljárás: az első 15 perc

1. 00:00 - Észlelés. Riasztás jön monitorozásból vagy ügyféltől. Valaki on-call rotációban megerősíti, hogy a probléma valódi.
2. 00:02 - IC aktiválás. Dedikált kommunikációs csatorna nyílik (Slack #incident-N vagy Discord). Hívják a Technical lead-et.
3. 00:05 - Első status update. Publikus status page-en: "Investigating reports of [probléma]." Email azoknak a belső embereknek, akiknek tudniuk kell.
4. 00:10 - Initial diagnostics. Ellenőrizd a legutóbbi deploy-okat, monitoring grafikonokat, error logokat. Mi változott az utóbbi 30-60 percben?
5. 00:15 - Döntés: rollback, hotfix vagy workaround? Ha nem azonnal egyértelmű, az IC eszkalál vagy hív további mérnököket.

Kommunikáció: az "5 + 30" szabály

A status page frissítése legalább 30 percenként SEV1 alatt, akkor is, ha nincs új infód. "Még vizsgáljuk, ETA még ismeretlen" jobb update mint a csend - az ügyfelek legalább tudják, hogy valaki dolgozik a problémán.

Az első update az észleléstől 5 percen belül kell legyen. Függetlenül attól, hogy ismered-e az okot.

Rollback mint alapértelmezett

SEV1-nél, ami egy deploy után röviddel kezdődött, a rollback az első választás, nem a hotfix. Nyomás alatt éjjel hotfix további bugok forrása. A rollback visszaállít egy ismert jó állapotot és időt ad nyugodt reggeli diagnosztikára.

Rollbackhez szükséges:

• Deployment verziókezelés (Docker tag-ek, Git tag-ek, deployment artefakt)
• Database migrációk backwards compatible-ek (ha új verzió drop-ol egy oszlopot, a régi nem helyreáll)
• Dokumentált rollback eljárás (parancsok, mennyi ideig tart, ki futtathatja)

Post-mortem 48 órán belül

Minden SEV1/SEV2 incidens után írj dokumentumot ezzel a struktúrával:

1. Summary - 2-3 mondat mi történt, mennyi ideig tartott, kit érintett
2. Timeline - pontos idők az észleléstől, kulcs akciókról, megoldásról
3. Root cause - miért történt (technikai ok + eljárási ok)
4. Impact - érintett ügyfelek száma, business hatás
5. What went well - amit jól csináltunk (értékeljük a csapatot)
6. What went wrong - hol vesztettünk időt
7. Action items - konkrét feladatok ownerrel és határidővel (nem "jobban tesztelni" - inkább "integráció teszt hozzáadása payment flow-hoz 14 napon belül, owner: X")

Blameless post-mortem szabály: Nem bűnöst keresel, hanem rendszerszintű gyengeséget. "John rossz verziót deploy-olt" rossz következtetés - a helyes az, hogy "a deploy folyamat nem tartalmazott canary fázist, ami a hibát teljes rollout előtt elkapta volna".

On-call rotáció

24/7 termékkel rendelkező csapatnak:

• Heti rotációk - rövidebb kiég, hosszabb a kontextus folytonosságát jelenti
• Mindig elsődleges + másodlagos on-call. A másodlagos átveszi, amikor az elsődleges nem reagál 5 percen belül.
• Kompenzáció (extra fizetés, time-off) éjszakai és hétvégi pagingért
• Havi "on-call review" - kit ébresztettek gyakran, mi automatizálható

Eszközök

• Monitoring (ePulz.io, Datadog, New Relic) - észlelés + alerting
• Paging (PagerDuty, Opsgenie, Better Stack) - eszkaláció, rotáció, SMS/hang
• Status page (saját, ePulz.io, StatusPage.io) - külső kommunikáció
• Runbook hosting (Notion, GitHub Wiki, internal docs) - playbookok és runbookok
• Postmortem sablon (Confluence, Notion template) - sztenderdizálás

Következtetés

Az incident response-ot nem lehet nyomás alatt improvizálni. 30 perc befektetve egy playbook írásába megtérül az első nagyobb kiesésnél - kevesebb káosz, rövidebb MTTR, jobb kommunikáció az ügyfelekkel és egy csapat, ami tudja mit csinálni.

Kezdd automatikus észleléssel

Az ePulz.io megoldja az incident response első perceit: észlelés + alerting e-mailen, Telegramon és webhookon Slack / Discord / PagerDuty-ba.

Monitoring indítása →