Wszystko posiada jakiś punkt graniczny. W przypadku ludzkiego życia jest to śmierć. Jakkolwiek patetycznie to nie brzmi - to jest czymś pewnym, oznaczającym po prostu koniec jakiegoś etapu. Koniec to też często czas refleksji, który ma posłużyć do określenia tego co moglibyśmy zrobić w przyszłości, aby uniknąć takiego zakończenia (o ile było nie do końca akceptowalne).

Refleksja jest bardzo ważnym aspektem naszej egzystencji. W literaturze często można spotkać się z terminem post mortem (łac. po śmierci), który poddaje analizie przyczyny zgonu w sensie zarówno symbolicznym, jak i bardziej przyziemnym. I co nie jest również nowością - termin ten został zaadoptowany przez IT. Na szczęście nie chodzi w nim o sytuację, gdy ktoś rzeczywiście umiera. Post-mortem dotyczy procesu analizy sytuacji, która doprowadziła do poważnej awarii w systemie. Analiza taka ma nam pomóc zrozumieć co się właściwie wydarzyło, dlaczego oraz jak możemy uniknąć podobnych sytuacji w przyszłości.

Dlaczego analiza post-mortem jest ważna?

W systemach IT często dochodzi do różnego rodzaju awarii - czasami związanych z bezpieczeństwem, czasami z błędem w kodzie lub błędnymi danymi, które zostały przekazane do aplikacji. Innymi słowy awarie to wszelkie niepożądane sytuacje, które dzieją się w związku z naszą aplikacją. Identyfikacja przyczyn takich zdarzeń może mieć kluczowe znaczenie w zrozumieniu ich pochodzenia, ale też zabieganiu im w przyszłości. Analiza post-mortem jest narzędziem, które właśnie do tego służy. Technicznie rzecz ujmując jest to mechanizm kontrolny, którego głównym zadaniem jest dbanie o stabilność i niezawodność systemów.

Aplikacje biznesowe, które są rozwijane w trybie ciągłym są o wiele bardziej podatne na nieoczekiwane błędy, które wynikają często z wdrażania nowych funkcjonalności do systemu. W szczególności w sytuacji, gdy nowa funkcja ma zastępować poprzednie rozwiązanie lub gdy stoi w sprzeczności z dotychczasowymi rozwiązaniami. W takich sytuacjach skuteczne zarządzanie procesem wdrażania oprogramowania jest kluczowe. Post-mortem pozwala na stosunkowo wczesne wykrycie problemów w przyszłości i zmniejszenie ryzyka ich ponownego wystąpienia w przyszłości.

Co istotne - dobrze przeprowadzona analiza post-mortem nie szuka winnych ani nie oskarża nikogo. Ma służyć przede wszystkim tworzeniu środowiska, w którym każdy członek zespołu może czuć się bezpiecznie, gdzie można mówić o swoich spostrzeżeniach i obawach związanych z aplikacją czy procesami.

Podsumowując post-mortem to retrospektywna analiza incydentu (np. awarii systemu), która ma pomóc zrozumieć co się wydarzyło i dlaczego, a także wyciągnąć wnioski na przyszłość.

Struktura

Ważnym aspektem przeprowadzenia poprawnej analizy zebranie wszystkich zespołów lub osób, które mogłyby zaangażowane w wystąpienie incydentu. Kluczowe jest ustalanie co się stało, dlaczego doszło do zdarzenia, jaka była reakcja zespołu i jak należałoby postępować w przyszłości, gdyby doszło do podobnej sytuacji. Wskazywanie winnych i karanie nie działa korzystnie w takich sytuacjach i jest wręcz niewskazane - może prowadzić do ukrywania pewnych istotnych faktów, wzajemnego przerzucania odpowiedzialności - a w ostateczności do wyciągnięcia błędnych wniosków.

Według takich organizacji jak Google wyeliminowanie efektu "polowania na czarownice" - rozwija kulturę uczenia się, poprawia wydajność i pozwala skupić się na unikaniu podobnych błędów w przyszłości. Przeciwnicy takich narzędzi twierdzą, że ich przeprowadzenie bez wskazania winnych jest niewykonalne przede wszystkim dlatego, że ludzie mają naturalną tendencję do osądzania. Natomiast zakaz osądzania powoduje niezdrową i niekomfortową sytuację, gdzie blokuje się swobodę wypowiedzi i sztucznie poprawia się samopoczucie osób rzeczywiście winnych.

Analiza post-mortem zakłada natomiast, że pozbycie się oskarżeń ma pomóc wskazać faktyczne obszary, które należałoby poprawić - zamiast szukać tymczasowych rozwiązań. Przykładowo pracownik A popełnił błąd, który doprowadził do sytuacji, że aplikacja była niedostępna przez kilka godzin. Zwolnienie takiego pracownika nie naprawi sytuacji - wręcz przeciwnie, bez poprawnej analizy tego co i dlaczego się wydarzyło - nie możemy zakładać, że pracownik B również nie popełni takiego lub podobnego błędu w przyszłości. W moim odczuciu zwolnienie lub ukaranie jest tylko chwilowym, nie do końca skutecznym, rozwiązaniem.

Porażka jest wpisana w proces wytwarzania oprogramowania. Trudno oczekiwać, że programiści czy (współcześnie AI) nie będą popełniać błędów. Błędy są wynikiem tego, że pewnych aspektów nie jesteśmy w stanie przewidzieć na wczesnych etapach wytwarzania.

Złote zasady pisania post-mortem

Każde narzędzie - również post-mortem - można użyć poprawnie, jak i źle. Jest kilka podstawowych zasad, którymi powinniśmy się kierować tworząc taką analizę. Przede wszystkim powinniśmy opierać się na faktach, a nie na opiniach. Opinie nie pomogą nam w zrozumieniu incydentu, wręcz przeciwnie - wprowadzą dużo dodatkowych zmiennych i szumu informacyjnego. Pamiętajmy, że opinie mogą być istotne przy wybieraniu rozwiązania, ale już niekoniecznie przy analizie powstałych błędów.

Dla pełnego zrozumienia sytuacji nie ma znaczenia, kto spowodował błąd / awarię - ale dlaczego do niej doszło. Dziś mógł to być nowo zatrudniony junior, a jutro ten sam błąd może popełnić senior z wieloletnim doświadczeniem. Skoro już doszło do incydentu - skupmy się na tym dlaczego - to może pomóc znaleźć odpowiednio rozwiązania.

Przeanalizujmy całą sytuację - krok po kroku - co wydarzyło się pierwsze, a co ostatnie. Tak powstała linia czasu pozwoli nam przejść przez cały incydent i znaleźć najsłabsze punkty.

Dokumentujmy wszystko. Mówiąc wszystko - mam na myśli wszystko, tj. wszystkie decyzje i działania, które podjęliśmy w związku z daną awarią. Poprawnie opisane kroki pozwoli nam lepiej zrozumieć jak zabezpieczyć się przed podobnymi sytuacjami w przyszłości.

Żeby nie było tylko gorzko - pamiętajmy również o dodaniu sekcji - co poszło dobrze.

Gdzie zapisywać post-mortem?

Są dwie szkoły zapisywania post-mortem. Pierwsza, której ja jestem zwolennikiem, mówi o tym, aby post-mortem trzymać blisko kodu, a zatem najpewniej w repozytorium kodu. Moim zdaniem dobrze napisane post-mortem są również częścią dokumentacji - natomiast aby zapewnić do niej swobodny dostęp dobrze jest ją trzymać tam, gdzie kod źródłowy.

Druga szkoła sugeruje raczej korzystanie z narzędzi do tworzenia dokumentacji / notatek - takich jak Confluence, Google Docs, Notion. Istnieją też dedykowane narzędzia jak: Jellyfish, Blameless czy Incident.io

Nie ma to jednak większego znaczenia, które podejście wybierzemy. Ważne, żebyśmy zaczęli monitorować i spisywać incydenty. Podczas tworzenia takich dokumentów warto stosować dobre praktyki. Analizy warto dzielić wg tematyki, której dotyczyły awarie. Same post-mortem powinny być też wersjonowane. Dobrze jest też dodać link do incydentu w narzędziach do monitoringu i analizy infrastruktury takich jak Grafana czy Datadog.

Do post-mortem dostęp powinni mieć przede wszystkim ludzie, którzy pracują nad rozwojem aplikacji - developerzy, QA, zespoły odpowiedzialne za bezpieczeństwo i product managerowie.

Przykładowy szablon analizy post-mortem mógłby wyglądać następująco:

Kiedy tworzyć post-mortem?

Każda poważna awaria powinna zostać opisana za pomocą post-mortem. Może to być wyciek danych, brak dostępności usługi czy regresja. Ponadto zawsze, gdy klient zgłasza poważny błąd lub gdy SLA zostało przekroczone. SLA to umowa o gwarantowanej jakości świadczonej usługi, która może dotyczyć zarówno czasu reakcji na zgłoszenie, czasu naprawy, maksymalnego czasu niedostępności usługi.

Istnieje również positive post-mortem, które tworzy się po udanych akcjach, będących szczególnie ryzykownych z punktu widzenia rozwoju aplikacji.

Podsumowanie

Post-mortem to świetne narzędzie do świadomego zapobiegania incydentom w przyszłości. Dzięki niemu jakość tworzonego rozwiązania będzie wyższa, a zespół z większą uwagą podejdzie do problemów w przyszłości. Należy jednak pamiętać, że samo dodanie narzędzia to dopiero połowa sukcesu - powinniśmy go regularnie tworzyć i po incydentach wyciągać wnioski, aby zabezpieczyć się przed nieprzewidzianymi sytuacjami w przyszłości. Dokumentujmy, nie oskarżajmy i rozwijajmy - siebie i naszą aplikację.