Playbook reakcji na incydenty dla małych i średnich zespołów

Role podczas incydentu

Jasno przydzielone role eliminują chaos. Nawet mały zespół potrzebuje przynajmniej:

• Incident Commander (IC) - zarządza incydentem, podejmuje decyzje i eskaluje. Sam nie pisze kodu.
• Technical lead - osoba, która zna obszar problemowy. Pisze poprawkę.
• Communications lead - aktualizuje status page, informuje klientów i management. W małym zespole może to być ta sama osoba co IC.
• Scribe - zapisuje timeline: kto co robi i kiedy. Kluczowy materiał do post-mortem.

W zespole do 5 osób zwykle oddziela się IC i Technical lead, a pozostałe role bierze IC.

Poziomy severity

Zdefiniuj 3-4 poziomy ważności z wyprzedzeniem:

• SEV1 (Critical) - główna usługa całkowicie niedostępna. Reaguje się natychmiast, paging również w nocy.
• SEV2 (Major) - znacząca degradacja (część funkcji, niektórzy użytkownicy). Reakcja do 30 min w godzinach pracy, do 1 h poza nimi.
• SEV3 (Minor) - mały wpływ, istnieje workaround. Reakcja do następnego dnia roboczego.
• SEV4 (Cosmetic) - bez wpływu na użytkownika, trafia do zwykłej kolejki.

Procedura przy SEV1: pierwsze 15 minut

1. 00:00 - Detekcja. Alert przychodzi z monitoringu lub od klienta. Ktoś z rotacji on-call potwierdza, że problem jest prawdziwy.
2. 00:02 - Aktywacja IC. Otwiera się dedykowany kanał komunikacji (Slack #incident-N lub Discord) i wzywany jest Technical lead.
3. 00:05 - Pierwszy status update. Na publicznej status page: "Investigating reports of [problem]." Email do osób wewnętrznych, które powinny o tym wiedzieć.
4. 00:10 - Initial diagnostics. Sprawdź ostatnie deploye, wykresy monitoringu i error logi. Co się zmieniło w ostatnich 30-60 min?
5. 00:15 - Decyzja: rollback, hotfix czy workaround? Jeśli nie jest to od razu jasne, IC eskaluje lub wzywa kolejnych inżynierów.

Komunikacja: reguła "5 + 30"

Status page aktualizuj podczas SEV1 co najmniej co 30 minut, nawet jeśli nie masz nowych informacji. "Wciąż badamy, ETA wciąż nieznana" to lepszy update niż cisza - klienci przynajmniej wiedzą, że ktoś pracuje nad problemem.

Pierwszy update musi pojawić się do 5 minut od detekcji, bez względu na to, czy znasz już przyczynę.

Rollback jako opcja domyślna

Przy SEV1, który pojawił się krótko po wdrożeniu, rollback jest pierwszym wyborem, nie hotfix. Hotfix pisany w nocy pod presją bywa źródłem kolejnych bugów. Rollback przywraca znany dobry stan i daje czas na spokojną diagnostykę rano.

Warunkiem rollbacku jest:

• Wersjonowanie wdrożenia (Docker tagi, Git tagi, artefakt wdrożenia)
• Database migrations, które są backwards compatible (jeśli nowa wersja usuwa kolumnę, stara jej już nie przywróci)
• Udokumentowana procedura rollbacku (komendy, ile trwa, kto może uruchomić)

Post-mortem do 48 godzin

Po każdym incydencie SEV1/SEV2 napisz dokument o następującej strukturze:

1. Summary - 2-3 zdania o tym, co się stało, ile trwało i kogo dotknęło
2. Timeline - dokładne czasy detekcji, kluczowych akcji i rozwiązania
3. Root cause - dlaczego do tego doszło (powód techniczny i proceduralny)
4. Impact - liczba dotkniętych klientów i wpływ na business
5. What went well - co zrobiliśmy dobrze (doceń zespół)
6. What went wrong - gdzie straciliśmy czas
7. Action items - konkretne zadania z ownerem i deadlinem (nie "lepiej testować", a raczej "dodać test integracyjny dla payment flow w ciągu 14 dni, owner: X")

Reguła blameless post-mortem: Nie szukasz winnego, lecz systemowej słabości. "John wdrożył złą wersję" to zły wniosek - prawidłowy brzmi "proces deploy nie zawierał fazy canary, która złapałaby błąd przed pełnym rolloutem".

Rotacja on-call

Dla zespołu z produktem 24/7 obowiązuje:

• Rotacje tygodniowe są optymalnym kompromisem - krótsze prowadzą do wypalenia, dłuższe nadmiernie obciążają primary on-callera
• Zawsze miej primary + secondary on-call. Secondary przejmuje, gdy primary nie reaguje do 5 min.
• Kompensuj nocne i weekendowe paging (dodatek lub dzień wolny)
• Wprowadź miesięczny "on-call review" - kogo pager budził najczęściej i co można zautomatyzować

Narzędzia

• Monitoring (ePulz.io, Datadog, New Relic) - detekcja + alerting
• Paging (PagerDuty, Opsgenie, Better Stack) - eskalacja, rotacja, SMS/voice
• Status page (własna, ePulz.io, Statuspage.io) - komunikacja zewnętrzna
• Hosting runbooków (Notion, GitHub Wiki, internal docs) - playbooki i runbooki
• Szablon postmortem (Confluence, Notion template) - standaryzacja

Wnioski

Reakcji na incydent nie da się improwizować pod presją. 30 minut zainwestowane w napisanie playbooka zwróci się przy pierwszej większej awarii - mniej chaosu, krótszy MTTR, lepsza komunikacja z klientami i zespół, który wie, co robić.

Zacznij od automatycznej detekcji

ePulz.io rozwiązuje pierwsze minuty reakcji na incydent: detekcja + alerting przez e-mail, Telegram i webhook do Slack / Discord / PagerDuty.

Uruchom monitoring →