Incident response playbook kis és közepes csapatoknak

Szerepek incidens során

A világos szerepek megszüntetik a káoszt. Egy kis csapatnak is legalább a következőkre van szüksége:

• Incident Commander (IC) - kezeli az incidenst, döntéseket hoz és eszkalál. Maga 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, tájékoztatja az ügyfeleket és a menedzsmentet. Kis csapatnál ez lehet ugyanaz a személy, mint az IC.
• Scribe - vezeti a timeline-t: ki, mit és mikor csinál. Kulcsfontosságú alap a post-mortemhez.

5 fős csapatban tipikusan az IC-t és a Technical lead-et választják külön, a többi szerepet az IC viszi.

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, létezik workaround. Reakció a következő munkanapig.
• SEV4 (Cosmetic) - user-facing hatás nélkül, a normál sorba megy.

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

1. 00:00 - Észlelés. Riasztás jön a monitorozásból vagy ügyféltől. Valaki az 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), és hívják a Technical lead-et.
3. 00:05 - Első status update. A 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, a monitoring grafikonokat és az 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 további mérnököket hív.

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

Frissítsd a status page-et SEV1 alatt legalább 30 percenként, akkor is, ha nincs új infód. A "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-nek az észleléstől számított 5 percen belül kell megérkeznie, függetlenül attól, hogy ismered-e már az okot.

Rollback mint alapértelmezett

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

A rollback feltétele:

• Deployment verziókezelés (Docker tag-ek, Git tag-ek, deployment artefakt)
• Backwards compatible database migrációk (ha az új verzió drop-ol egy oszlopot, a régi azt már nem állítja vissza)
• 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 arról, mi történt, mennyi ideig tartott, kit érintett
2. Timeline - az észlelés, a kulcsakciók és a megoldás pontos időpontjai
3. Root cause - miért történt (technikai és 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 a payment flow-hoz 14 napon belül, owner: X")

Blameless post-mortem szabály: Nem bűnöst keresel, hanem rendszerszintű gyengeséget. A "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 a teljes rollout előtt elkapta volna".

On-call rotáció

24/7 termékkel rendelkező csapatnál:

• A heti rotációk az ideális kompromisszum - a rövidebbek kimerítőek, a hosszabbak túlterhelik az elsődleges on-callert
• Mindig legyen elsődleges + másodlagos on-call. A másodlagos átveszi, amikor az elsődleges nem reagál 5 percen belül.
• Kompenzáld az éjszakai és hétvégi paginget (pótlék vagy szabadidő)
• Vezess be havi "on-call review"-t - kit ébresztettek a leggyakrabban, és 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. Egy playbook megírásába fektetett 30 perc megtérül az első nagyobb kiesésnél - kevesebb káosz, rövidebb MTTR, jobb kommunikáció az ügyfelekkel és egy csapat, amely tudja, mit kell tennie.

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 →