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

W skrócie: Gdy w piątek o 23:30 padnie serwer produkcyjny, to nie czas wymyślać procedury od zera. Playbook reakcji na incydenty to dokument definiujący role, komunikację i procedury zanim ich potrzebujesz. Oto minimalny playbook odpowiedni dla 5-20 osobowego zespołu.

Role podczas incydentu

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

• Incident Commander (IC) - zarządza incydentem, podejmuje decyzje, eskaluje. Nie pisze kodu.
• Technical lead - osoba, która zna obszar problemowy. Pisze poprawkę.
• Communications lead - aktualizuje status page, klientów, management. Dla małego zespołu może być tym samym co IC.
• Scribe - zapisuje timeline, kto co robi, kiedy. Kluczowe dla post-mortem.

W zespole do 5 osób typowo IC + Technical lead = 2 role podzielone, pozostałe 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.
• SEV3 (Minor) - mały wpływ, workaround istnieje. Reakcja do następnego dnia roboczego.
• SEV4 (Cosmetic) - bez wpływu user-facing, idzie do zwykłej kolejki.

Procedura przy SEV1: pierwsze 15 minut

1. 00:00 - Detekcja. Alert przychodzi z monitoringu lub od klienta. Ktoś na rotacji on-call potwierdza, że problem jest prawdziwy.
2. 00:02 - Aktywacja IC. Otwiera się dedykowany kanał komunikacji (Slack #incident-N lub Discord). 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 wiedzieć.
4. 00:10 - Initial diagnostics. Sprawdź ostatnie deploye, wykresy monitoringu, error logi. Co się zmieniło w ostatnich 30-60 min?
5. 00:15 - Decyzja: rollback, hotfix czy workaround? Jeśli nie od razu jasne, IC eskaluje lub wzywa kolejnych inżynierów.

Komunikacja: reguła "5 + 30"

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

Pierwszy update musi być do 5 minut od detekcji. Bez względu na to, czy znasz przyczynę.

Rollback jako default

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

Dla rollbacku trzeba mieć:

• Wersjonowanie wdrożenia (Docker tagi, Git tagi, artefakt wdrożenia)
• Database migrations backwards compatible (jeśli nowa wersja drop-uje kolumnę, stara nie naprawi)
• Udokumentowana procedura rollbacku (komendy, ile trwa, kto może uruchomić)

Post-mortem do 48 godzin

Po każdym incydencie SEV1/SEV2 napisz dokument ze strukturą:

1. Summary - 2-3 zdania co się stało, ile trwało, kogo dotknęło
2. Timeline - dokładne czasy detekcji, kluczowych akcji, rozwiązania
3. Root cause - dlaczego to się stało (powód techniczny + proceduralny)
4. Impact - liczba dotkniętych klientów, 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ć" - raczej "dodać test integracyjny dla payment flow w ciągu 14 dni, owner: X")

Reguła blameless post-mortem: Nie szukasz winnego, szukasz systemowej słabości. "John wdrożył złą wersję" to zły wniosek - prawidłowy to "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:

• Rotacje tygodniowe - krótsze wypalają, dłuższe oznaczają ciągłość kontekstu
• Zawsze primary + secondary on-call. Secondary przejmuje, gdy primary nie reaguje do 5 min.
• Kompensacja (extra payment, time-off) za nocne i weekendowe paging
• Miesięczny "on-call review" - kto był często budzony, 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 →