Postmortem incydentu to krótka pisemna analiza awarii: co się stało, jak wpłynęło to na użytkowników, dlaczego do tego doszło i co zmienisz, aby się nie powtórzyło. Postmortem bez szukania winnych (blameless) skupia się na systemach i procesach, a nie na tym, kto popełnił błąd. Podstawowy szablon ma sześć części: podsumowanie, wpływ, oś czasu, przyczynę źródłową, co poszło dobrze, a co źle, oraz działania naprawcze z właścicielami i terminami.
Poniżej znajdziesz, kiedy go pisać, zasady, dzięki którym pozostaje użyteczny, pełny szablon do skopiowania, wypełniony przykład oraz sposób, by przerobić go na podsumowanie dla klientów.
Kiedy pisać postmortem
Nie każde chwilowe zakłócenie wymaga dokumentu. Ustal jasne kryteria, żeby decyzja nie zapadała pod presją. Najczęstsze z nich:
Klienci przez więcej niż kilka minut nie mogli korzystać z kluczowej funkcji, takiej jak składanie zamówień, logowanie czy API.
Dane zostały utracone, uszkodzone lub ujawnione.
Incydent zużył dużą część miesięcznego budżetu błędów.
Klienci lub zleceniodawca zgłosili problem, zanim wykrył go monitoring.
Podobny incydent zdarzył się już wcześniej.
Napisz go w ciągu kilku dni roboczych, póki wspomnienia i logi są świeże. Postmortem pisany trzy tygodnie później to w dużej mierze zgadywanie.
Zasady analizy bez szukania winnych
Postmortem bez szukania winnych zakłada, że każdy działał rozsądnie na podstawie informacji, które miał w danej chwili. Jeśli jedna osoba mogła położyć stronę jednym poleceniem, problemem jest to, że jedno polecenie mogło położyć stronę. Obwinianie sprawia, że ludzie ukrywają szczegóły, a to właśnie szczegółów potrzebujesz.
Opisuj działania, nie ludzi. „Import uruchomiono w godzinach szczytu” zamiast „Anna uruchomiła import w złym momencie”.
Pytaj „jak”, nie „kto”. Jak system na to pozwolił? Jak się o tym dowiedzieliśmy? Jak mogliśmy dowiedzieć się wcześniej?
Szukaj kilku przyczyn. Incydenty rzadko mają jedną przyczynę źródłową. Zwykle wyzwalacz trafia na słaby punkt, którego nie wyłapało brakujące zabezpieczenie.
Opieraj się na faktach i znacznikach czasu. Dane z monitoringu, logi i historia czatu są lepsze niż pamięć.
Trzymaj listę działań krótką. Dwie albo trzy zmiany, które zostaną wdrożone, są lepsze niż dziesięć, które nie zostaną.
Szablon postmortemu
Skopiuj go do swojej wiki, repozytorium albo edytora dokumentów. Pod każdym nagłówkiem jest podpowiedź, co tam wpisać.
# Postmortem: [krótki tytuł]
Data incydentu: [RRRR-MM-DD]
Autor(zy): [imiona i nazwiska]
Status: [szkic / w przeglądzie / ostateczny]
Waga: [np. SEV1 / SEV2 / SEV3]
## Podsumowanie
[Dwa lub trzy zdania: co przestało działać, jak długo i jak to naprawiono.]
## Wpływ
– Usługi i komponenty, których dotyczył incydent:
– Czas trwania (od początku do przywrócenia):
– Użytkownicy lub klienci, których dotyczył:
– Wpływ biznesowy (zamówienia, rejestracje, SLA):
– Komunikacja z klientami (strona statusu, e-maile, zgłoszenia):
## Wykrycie
– Jak wykryto incydent? (monitor, klient, członek zespołu)
– Czas od początku do alertu:
– Czas od alertu do potwierdzenia:
## Oś czasu
[Wszystkie godziny w jednej strefie czasowej. Jedna linia na zdarzenie.]
GG:MM zdarzenie
GG:MM zdarzenie
## Przyczyna źródłowa i czynniki sprzyjające
– Wyzwalacz:
– Przyczyna leżąca u podstaw:
– Dlaczego zabezpieczenia tego nie wyłapały:
## Rozwiązanie
[Co zrobiono, aby przywrócić działanie usługi, i kto to zrobił (rola, nie wina).]
## Co poszło dobrze
–
## Co poszło źle
–
## Gdzie mieliśmy szczęście
–
## Działania naprawcze
| Działanie | Typ (zapobieganie / wykrywanie / reakcja) | Właściciel | Termin | Zgłoszenie |
|———–|——————————————-|————|——–|————|
| | | | | |
## Podsumowanie dla klientów
[Krótka wersja na stronę statusu lub do e-maila do klienta.]
Sekcję „Gdzie mieliśmy szczęście” łatwo pominąć, a często jest najcenniejsza. Wychwytuje sytuacje, które niewiele brakowało, by skończyły się gorzej: incydent zdarzył się w nocy, kopia zapasowa wykonała się godzinę wcześniej, jedyna osoba znająca system akurat nie spała.
Wypełniony przykład
Oto szablon zastosowany do fikcyjnego incydentu w sklepie internetowym northwind.shop. Szczegóły są zmyślone na potrzeby przykładu, ale struktura odpowiada temu, jak powinien wyglądać prawdziwy postmortem.
Podsumowanie
Od 03:12 do 03:19 CET proces zamówienia w northwind.shop zwracał 503 Service Unavailable. Nocny import produktów zajął wszystkie workery PHP-FPM, więc żądania składania zamówień były odrzucane. Dyżurny programista zatrzymał import i zrestartował PHP-FPM. Łączny czas niedostępności: 7 minut.
Wpływ
Proces zamówienia i koszyk były niedostępne przez 7 minut. Strony produktów były serwowane z cache i działały.
Logi serwera pokazują w tym czasie 23 nieudane żądania złożenia zamówienia (liczba przykładowa).
Od 03:13 strona statusu pokazywała „Składanie zamówień: poważna awaria”. Nie wpłynęło żadne zgłoszenie do wsparcia.
Oś czasu
03:00 Rozpoczyna się nocny import produktów.
03:12 Sprawdzenie dostępności northwind.shop/checkout zwraca 503.
03:13 Drugie sprawdzenie potwierdza awarię. Otwiera się incydent, dyżurny programista dostaje alert na Telegramie, a szczegóły trafiają na kanał zespołu w Slacku. Strona statusu oznacza składanie zamówień jako niedziałające.
03:15 Dyżurny potwierdza alert w Slacku i otwiera panel serwera. Pamięć i CPU na web-01 są mocno obciążone.
03:17 Status PHP-FPM pokazuje, że wszystkie workery są zajęte żądaniami importu. Import zostaje zatrzymany.
03:18 PHP-FPM zostaje zrestartowany.
03:19 Sprawdzenia znów przechodzą. Wysyłane jest powiadomienie o przywróceniu działania z łącznym czasem niedostępności 7 minut.
Przyczyna źródłowa i czynniki sprzyjające
Wyzwalacz: po aktualizacji katalogu plik od dostawcy był trzy razy większy niż zwykle.
Przyczyna leżąca u podstaw: import działa w tej samej puli PHP-FPM co sklep. Duże importy mogą zająć wszystkie workery.
Brakujące zabezpieczenie: import nie ma limitu równoległych żądań i nie było alertu o wysyceniu workerów.
Dlaczego wyczerpane workery objawiają się właśnie tym błędem, wyjaśnia nasz poradnik o błędzie 503 Service Unavailable.
Co poszło dobrze, co źle i gdzie mieliśmy szczęście
Dobrze: wykrycie zajęło minutę, a potwierdzenie dwie. Strona statusu zaktualizowała się bez ręcznej pracy.
Źle: znalezienie przyczyny zajęło cztery minuty, bo nic nie łączyło importu z serwerami WWW.
Szczęście: stało się to o 03:12, a nie w wieczornym szczycie.
Działania naprawcze
DziałanieTypWłaścicielTerminUruchamiać import w osobnej puli workerów z limitem równoległościZapobieganieLider backenduW ciągu 2 tygodniAlert, gdy pamięć na web-01 utrzymuje się powyżej 85%WykrywanieOpsW tym tygodniuDodać heartbeat, który zgłasza zakończenie importuWykrywanieLider backenduW tym tygodniuDodać do monitora runbook „503 w procesie zamówienia”ReakcjaRotacja dyżurówW tym tygodniu
Publikowanie podsumowania dla klientów
Wewnętrzny postmortem jest dla zespołu. Klienci potrzebują krótszej wersji bez nazw serwerów: co się stało, jak długo trwało, czy ich dane są bezpieczne i co zmieniasz. Opublikuj ją na swojej stronie statusu i linkuj do niej z każdego e-maila o incydencie czy aktualizacji dla klienta. W Uptimecheck analizę incydentu piszesz bezpośrednio przy incydencie, obok jego osi czasu, i możesz zdecydować, czy pokazać ją pod incydentem na stronie statusu.
Składanie zamówień niedostępne, 03:12–03:19 CET
Między 03:12 a 03:19 CET klienci nie mogli finalizować zakupów
w northwind.shop. Przeglądanie produktów działało normalnie, a żadne
zamówienia ani dane płatnicze nie zostały utracone.
Przyczyną była zaplanowana aktualizacja produktów, która zużyła więcej
zasobów serwera, niż zakładaliśmy. Zatrzymaliśmy ją, a składanie
zamówień wróciło do działania o 03:19.
Przenosimy te aktualizacje na osobne zasoby, aby nie mogły ponownie
wpłynąć na składanie zamówień, i dodaliśmy wcześniejsze ostrzeżenia
o tego typu obciążeniu.
Zachowaj rzeczowy ton i konkretne obietnice. „Traktujemy niezawodność poważnie” nic nie mówi; „importy działają teraz na osobnych zasobach” mówi coś konkretnego. Nasz poradnik jak stworzyć stronę statusu szerzej omawia, jak formułować aktualizacje o incydentach.
Warto też wiedzieć, ile osób zauważyło problem. Uptimecheck oferuje analitykę strony statusu przy każdej stronie statusu – wizyty dziennie oraz według kraju, źródła odesłań i urządzenia z ostatnich 30 dni – więc możesz dopisać do postmortemu, ile osób sprawdzało stronę w dniu incydentu. W połączeniu z osią czasu incydentu daje to początek, alert, potwierdzenie, przywrócenie działania i zasięg bez przekopywania logów. Incydenty stron WWW zawierają też nieudaną odpowiedź wraz ze zrzutem ekranu albo traceroute, co jest dobrym punktem wyjścia do sekcji o wykryciu i przyczynie źródłowej.
Śledzenie działań naprawczych
Postmortem bez zrealizowanych działań naprawczych to opowieść, a nie naprawa. Traktuj te działania jak każdą inną pracę:
Utwórz zgłoszenie dla każdego działania w narzędziu, którego zespół już używa, i podlinkuj je w postmortemie.
Każdemu przypisz jednego właściciela i termin.
Oznaczaj działania według typu: zapobieganie, wykrywanie lub reakcja. Jeśli każde działanie brzmi „bądźmy ostrożniejsi”, analiza nie została dokończona.
Przeglądaj otwarte działania z postmortemów na regularnym spotkaniu, na przykład co dwa tygodnie.
Oznacz postmortem jako ostateczny dopiero wtedy, gdy wszystkie działania są zrealizowane lub świadomie porzucone z podaniem powodu.
Z czasem same postmortemy stają się danymi. Policz, ile incydentów wykrył monitoring, a ile klienci, i śledź czasy wykrycia i reakcji od incydentu do incydentu. Nasz artykuł o MTTR, MTTA i MTBF wyjaśnia, jak je obliczać.
Jak prowadzić spotkanie analityczne
Przy większych incydentach pomaga spotkanie trwające od 30 do 45 minut. Udostępnij szkic wcześniej, poproś osobę, która kierowała reakcją, o przejście przez oś czasu, a większość czasu poświęć czynnikom sprzyjającym i działaniom. Neutralny moderator, który nie pracował przy incydencie, pilnuje, by rozmowa była wolna od szukania winnych i mieściła się w czasie. Na koniec potwierdź właścicieli i terminy każdego działania naprawczego.
Znaczniki czasu do kolejnego postmortemu możesz mieć automatycznie. Wypróbuj Uptimecheck za darmo przez 14 dni, bez karty kredytowej.