Większość postmortemów to archeologia: dokładny zapis czegoś, czego nikt nie zmieni. Użyteczny produkuje niewielką liczbę rzeczy, które faktycznie zostaną zrobione.
Celem postmortemu nie jest udokumentowanie tego, co się stało. Celem jest sprawienie, by kolejny incydent był mniej prawdopodobny albo mniej szkodliwy. Wszystko w dokumencie powinno temu służyć, a co nie służy — jest ceremonią.
Bez obwiniania to mechanizm, a nie maniery
Postmortemy bez obwiniania tłumaczy się często jako uprzejmość. To ich zaniża. Istnieją dlatego, że ludzie spodziewający się winy zatrzymują informacje — a zatrzymana informacja to dokładnie ta, która zapobiegłaby powtórce.
Struktura, która działa
- Streszczenie — trzy zdania: co się zepsuło, na jak długo, kogo dotknęło. Większość czytelników kończy tutaj, więc musi bronić się samo.
- Wpływ — czas trwania, dotknięci użytkownicy, konsekwencje przychodowe albo dla danych, w liczbach tam, gdzie się da
- Oś czasu — fakty ze znacznikami czasu, od pierwszego objawu do rozwiązania, wraz z momentem, gdy ludzie się dowiedzieli
- Czynniki współprzyczyniające — w liczbie mnogiej i uczciwie także o procesowych, nie tylko o technicznym wyzwalaczu
- Co poszło dobrze — naprawdę przydatne, by wzmocnić wykrycie albo reakcję, które zadziałały
- Zadania — każde z właścicielem i datą
Przyczyna źródłowa to zwykle historia, a nie jedna linijka
«Wdrożenie spowodowało awarię» to miejsce, w którym analiza się kończy, gdy spotkanie się spieszy. Prawdziwe czynniki wyglądają zwykle tak:
| Warstwa | Przykładowe ustalenie |
|---|---|
| Wyzwalacz | Wdrożono zmianę konfiguracji |
| Dlaczego się zepsuło | Zmiana była poprawna składniowo, ale błędna semantycznie |
| Dlaczego nic tego nie złapało | Żadne środowisko staging nie odpowiadało konfiguracji produkcyjnej |
| Dlaczego zauważenie zajęło 40 minut | Alerty pilnowały CPU, a nie skuteczności płatności |
| Dlaczego odzyskiwanie było wolne | Rollback nigdy nie był testowany dla zmian wyłącznie konfiguracyjnych |
Cztery z tych pięciu to problemy procesowe. Napraw sam wyzwalacz, a ta sama klasa incydentów wróci w innym przebraniu.
Zadania: część, która decyduje, czy cokolwiek z tego miało znaczenie
- Maksymalnie trzy do pięciu pozycji — lista dwudziestu to lista zera
- Każda z imiennym właścicielem, nie z zespołem
- Każda z datą, śledzona w tym samym systemie co normalna praca
- Preferuj pozycje usuwające całą klasę awarii (barierkę) nad tymi, które naprawiają jeden przypadek
- Przejrzyj je na kolejnym postmortemie — niedokończone punkty z poprzedniego razu to najważniejszy punkt agendy
Postmortem bez ukończonych zadań do kolejnego incydentu nie jest procesem. Jest nawykiem archiwizowania.
Moment i odbiorcy
- Szkic w ciągu 48 godzin — dokładność szybko się psuje
- Spotkanie na 30-45 minut, nie dłużej; większość pracy wykonuje dokument
- Zaproś wszystkich zaangażowanych plus jedną osobę, która nie była (zadaje oczywiste pytania, które wtajemniczeni pomijają)
- Udostępnij szeroko — wewnętrzna przejrzystość wobec porażek to sposób, w jaki organizacje stają się w tym lepsze
Weryfikuj działania zapobiegawcze
Postmortem powinien zmieniać kontrolę lub decyzję. Każde działanie wymaga dowodu zakończenia oprócz terminu.
- Oddziel fakty, hipotezy i czynniki współtworzące awarię.
- Powiąż działanie z mechanizmem błędu, który usuwa.
- Zweryfikuj testem, ćwiczeniem alarmowym lub próbą odtworzenia.
Najczęstsze pytania
Jak szybko po incydencie powinien powstać postmortem?
Szkic w ciągu 48 godzin, spotkanie w ciągu tygodnia. Pamięć dokładnej sekwencji i rozumowania psuje się szybko, a najważniejsze szczegóły — w co ktoś wtedy wierzył i dlaczego — znikają pierwsze.
Co w praktyce czyni postmortem wolnym od obwiniania?
Pytanie o to, jak system dopuścił awarię, a nie kto ją spowodował. W praktyce: brak nazwisk przy błędach w dokumencie, pytania sformułowane o mechanizmy zamiast o decyzje, oraz zadania dodające barierki zamiast proszenia ludzi o większą ostrożność.
Ile zadań powinien wyprodukować postmortem?
Trzy do pięciu, każde z imiennym właścicielem i datą. Dłuższe listy to niezawodny znak, że nic nie zostanie zrobione — a niedokończone pozycje powinny być pierwszym punktem agendy kolejnego przeglądu.
Kiedy działanie z postmortem jest zakończone?
Gdy uzgodniony wynik zostanie dostarczony i sprawdzony. Zamknięcie zadania lub aktualizacja dokumentu nie dowodzą same w sobie zmiany zachowania systemu.
Incydenty się powtarzają?
To problem procesu, a nie pecha. Audytujemy praktykę dostarczania i obsługi incydentów oraz naprawiamy mechanizm.
Warto doczytać
Jak obsłużyć awarię produkcji: playbook dla małych zespołów
Podczas awarii problem techniczny rzadko jest tym trudnym. Trudna jest koordynacja. Oto sekwencja, która powstrzymuje mały zespół przed pogorszeniem sprawy.
Audyt procesów inżynierskich: na co patrzymy i dlaczego
Gdy zespół dowozi wolno, przyczyną prawie nigdy nie są inżynierowie. Zwykle to cztery albo pięć konkretnych tarć, których nikt nie zmierzył.