Postmortem — co to jest i jak analizować incydenty?

Postmortem to narzędzie uczenia się z awarii — bez obwiniania, z fokusem na systemy. Poznaj strukturę 8 sekcji, metodę 5 Whys i blameless culture Google SRE.

Czym jest postmortem?

Postmortem to ustrukturyzowany dokument tworzony po każdym poważnym incydencie — opisuje co się stało, jaki był wpływ, jakie były przyczyny źródłowe i jakie działania naprawcze zostaną podjęte. Filozofia blameless postmortem: incydenty są wynikiem systemowych słabości, nie indywidualnych błędów.

Google SRE Book definiuje cel postmortem: "Zapewnić, że incydent jest zdokumentowany, że wszystkie przyczyny są zrozumiane i że działania zapobiegające powtórzeniu incydentu są podjęte."

Blameless Culture — zasada kluczowa:

"Nie pytamy KTO zawinił — pytamy DLACZEGO system pozwolił na to, żeby to się stało."

Struktura postmortem — 8 sekcji

Metadata

Data incydentu, autor/autorzy postmortem, severity (P0/P1/P2), status (draft/review/final), data spotkania review

Executive Summary

2-3 zdania: co się stało, jak długo trwało, jaki był wpływ na klientów i biznes. Dla osób które nie czytają całości.

Impact (Wpływ)

Czas trwania awarii, % dotkniętych klientów/requestów, szacowany wpływ finansowy, wpływ na SLA, komunikaty wysłane do klientów

Timeline

Chronologiczny zapis zdarzeń od pierwszego alarmu do rozwiązania — z timestampami. Kto co zrobił i kiedy. Czas wykrycia vs. czas rozwiązania.

Root Cause (Przyczyna źródłowa)

Wynik 5 Whys lub innej RCA. Co NAPRAWDĘ spowodowało incydent — nie symptom, ale systemowa słabość która na to pozwoliła.

Contributing Factors

Czynniki które przyczyniły się do incydentu lub pogorszyły jego skutki — nawet jeśli nie były bezpośrednią przyczyną.

What Went Well

Co zadziałało dobrze — szybka detekcja, dobra komunikacja, skuteczny rollback. Wzmacniaj pozytywne zachowania.

Action Items

Konkretne działania naprawcze: właściciel, termin, tracking ID. Podzielone na: immediate (do 48h), short-term (1-2 tygodnie), long-term (1+ miesiąc).

Metoda 5 Whys — przykład root cause analysis

Pytaj 'Dlaczego?' pięć razy — każda odpowiedź prowadzi głębiej, aż do prawdziwej przyczyny systemowej.

Dlaczego 1: Dlaczego API zwracało błędy 500?

→ Bo baza danych była niedostępna.

Dlaczego 2: Dlaczego baza danych była niedostępna?

→ Bo wyczerpały się połączenia w connection pool.

Dlaczego 3: Dlaczego wyczerpały się połączenia?

→ Bo nowy release zawierał memory leak w handling requestów.

Dlaczego 4: Dlaczego memory leak nie był wykryty przed releasem?

→ Bo testy obciążeniowe nie obejmowały scenariusza z długotrwałym ruchem.

Dlaczego 5 (Root Cause): Dlaczego testy obciążeniowe nie obejmowały tego scenariusza?

→ Bo nie mamy zdefiniowanych standardów testów obciążeniowych ani procesu ich przeglądu przed releasem.

FAQ — postmortem i RCA

Co to jest postmortem (analiza po incydencie)?

Postmortem (analiza post-incydentowa) to ustrukturyzowany dokument tworzony po każdym poważnym incydencie (awaria, breach, znacząca degradacja), który opisuje co się stało, jaki był wpływ, jakie były przyczyny źródłowe (root cause) i jakie działania naprawcze zostaną podjęte. Celem postmortem nie jest wskazanie winnych — to narzędzie do systemowego uczenia się. Kultura blameless postmortem (bez szukania kozłów ofiarnych) jest kluczem do budowania kultury bezpieczeństwa i ciągłego doskonalenia.

Czym jest blameless postmortem?

Blameless postmortem (postmortem bez obwiniania) to podejście spopularyzowane przez Google SRE i Etsy, zakładające że incydenty są wynikiem systemowych słabości — nie indywidualnych błędów. Zamiast pytać 'Kto zawinił?' pytamy 'Dlaczego system na to pozwolił?' Blameless kultura buduje psychologiczne bezpieczeństwo — inżynierowie nie ukrywają błędów, otwarcie raportują o incydentach i dzielą się learningami. To jedyna droga do realnej poprawy niezawodności.

Jak szybko przeprowadzić postmortem?

Best practice: postmortem powinien być gotowy w ciągu 24-48 godzin po rozwiązaniu incydentu. Optymalny timeline: natychmiast po incydencie — zapisz timeline events na bieżąco; w ciągu 24h — wstępny draft; w ciągu 48-72h — spotkanie review z kluczowymi osobami; w ciągu tygodnia — finalna wersja z action items i właścicielami. Im więcej czasu mija, tym więcej szczegółów się traci i tym trudniej zidentyfikować root cause.

Co to jest Root Cause Analysis (RCA)?

Root Cause Analysis (analiza przyczyn źródłowych) to systematyczna metoda identyfikacji fundamentalnej przyczyny incydentu — nie symptomów, ale głębokiej przyczyny która pozwoliła na wystąpienie problemu. Popularne techniki: 5 Whys (5 Dlaczego) — pytaj 'dlaczego?' pięć razy by dotrzeć do przyczyny źródłowej; Fishbone Diagram (Ishikawa) — wizualna mapa kategorii przyczyn (human, process, technology, environment); Fault Tree Analysis — drzewo logiczne możliwych kombinacji przyczyn.

Jak śledzić action items z postmortem?

Action items z postmortem muszą być traktowane jak priorytety — nie sugestie. Best practices: każdy action item ma właściciela (imię, nie 'team'), termin realizacji, status trackowany w JIRA/Linear lub osobnym rejestrze postmortemów, review na następnym spotkaniu team lub w kolejnym postmortem. Niektóre organizacje mają 'Reliability Review' miesięcznie, gdzie przegląda się status wszystkich otwartych action items z postmortemów.

Czytaj dalej