🤦 Postmortem - nauka na błędach
Praktyki Inżynierskie Najlepszych Firm Produktowych
Aby zebrać w jednym miejscu praktyczną i aktualną wiedzę dotyczącą praktyk inżynierskich, postanowiłem swoje doświadczenia zebrać w serii artykułów pod wspólną nazwą Praktyk Inżynierskich. Mam nadzieję że to kompendium będzie miejscem, do którego możesz wracać po wskazówki i rozwiązania.
W cyklu Praktyk Inżynierskich:
Postmortem - nauka na błędach [TEN ARTYKUŁ]
W ostatnim wydaniu przyglądaliśmy się bliżej obserwowalności i jej bezpośredniemu wpływowi na sukces produktu. Dziś porozmawiamy o postmortem, czyli czego z błedów może nauczyć się organizacja.
Gdy organizacja nie uczy się na błędach
Na pewno byłeś(aś) świadkiem sytuacji, że system przestał działać. Lub pewna kluczowa funkcjonalność zaczęła wariować. Przy pewnej skali awarie statystycznie muszą się wydarzyć.
Ale jest różnica jak reaguje na to organizacja.
Jeśli nie mamy kultury nauki na własnych błędach to najczęściej w organizacji wygląda to następująco:
Nie poszukujemy źródła awarii
Staramy się minimalizować wynikłe problemy
Zrzucamy na siebie winę za powstałą sytuację
Szyjemy rozwiązania na szybko
To długofalowo powoduje:
Tworzenie kultury unikania odpowiedzialności – zamiast rozwiązywać problemy staramy się aktywnie uniknąć bycia pociągniętym do odpowiedzialności.
Powielanie tych samych sytuacji w innych miejscach – możemy nie zauważyć powtarzających się wzorców awarii.
Nawarstwianie się problemów – w miarę proste incydenty napędzają jeszcze gorsze awarie.
Rosnącą frustrację pracowników – ludzie nie skupiają się na dostarczaniu wartości, tylko gaszeniu pożarów.
Organizacje wchodzą w błędne koło – rozwiązują problemy na szybko, ponieważ nie mają czasu ich naprawić, ponieważ mają bardzo dużo problemów, ponieważ rozwiązują je na szybko. 🤡
Firmy z wysoką kulturą inżynierską postępują inaczej.
Kultura postmortem
Termin postmortem odnosi się do analizy medycznej wykonywanej po śmierci pacjenta. Ten przykład wzięły do siebie firmy inżynierskie.
Postmortem jako praktyka to pisemny zapis zdarzenia incydentu, który opisuje:
Pierwotną przyczynę incydentu.
Wpływ incydentu na działanie systemu / firmy.
Działania podjęte w celu złagodzenia lub rozwiązania incydentu.
Działania następcze podjęte w celu zapobieżenia powtórzeniu się incydentu.
Postmortem wykonuje się po istotnym problemie, który zaistniał w firmie. Zespół spotyka się i analizuje określony incydent. To pozwala zrozumieć skąd pojawił sie dany problem i zapobiegać im w przyszłości.
Jednak często mówi się również o kulturze postmortem. Organizacja dba, by analiza po incydentach była integralną częścią podejścia do problemów i błędów. W takiej kulturze, zespoły i jednostki nie boją się przyznawać do błędów, a incydenty są postrzegane jako możliwości nauki i doskonalenia, a nie jako porażki do ukrycia.
Można tutaj nawiązać do świetnego artykułu Google – Postmortem Culture:
Writing a postmortem is not punishment—it is a learning opportunity for the entire company.
To tworzy środowisko, które promuje otwartość, odpowiedzialność i ciągłe doskonalenie.
No dobra, a kto z tego korzysta?
Przykład z branży
W tym cyklu artykułów pokazuję Tobie praktyki wykorzystywane przez rzeczywiste firmy. Dlatego do każdego artykułu będę się starał przytoczyć odpowiedzi polskich inżynierów, którzy wykorzystują daną praktykę.
Ciekawym sposobem wykorzystywania praktyki postmortem podzielił się ze mną Tomek Lis, Engineering Manager z firmy eSky.
Q: W jaki sposób działa u nas praktyka postmortem?
A: Po każdej większej awarii organizujemy postmortem, na który zapraszamy zainteresowane osoby, a w szczególności uczestniczące w wykryciu bądź naprawie awarii. W trakcie spotkania ustalamy przyczyny i możliwe sposoby wyeliminowania lub znaczącego ograniczenia wystąpienia podobnej awarii w przyszłości. Do każdej akcji przypisujemy osoby, które dopilnują ich realizacji.
Q: Jakie widzisz jej zalety w skali twojego zespołu i organizacji?
Przede wszystkim zdarza się zdecydowanie mniej awarii, a występujące mają zwykle mniejszy wpływ na naszych klientów. Kiedyś telefony od zespołów wsparcia po godzinach były normalne, a teraz to wyjątkowe sytuacje. W wyniku wniosków i akcji podejmowanych po postmortemach nasze zespoły mają bezpieczniejsze wdrożenia i brak dyżurów, a nasi klienci usługę o naprawdę wysokiej dostępności.
Ok, to skoro już wiesz czym jest postmortem i jakie ma zalety, to jak to podejście wdrożyć w życie firmy? 🤔
Widzę tutaj 3 aspekty:
Przygotowanie się do postmortem
Przeprowadzenie spotkania
Praca z rezultatami postmortem
Przygotowanie się do postmortem
Jak do większości tematów, nie warto siadać zbyt pochopnie, bo się można sparzyć i zaprzestać praktyki już po jednym razie.
Sprzedanie celów postmortem:
Praktyka postmortem + wdrożenie wymaganych akcji wymaga czasu pracowników. Jeśli nie masz „buy-inu" z góry, to takie postmortem staną się pustą strukturą, która nie wniesie nic do życia firmy.
Warto sprzedać cele postmortem, jako takie, które faktycznie wpłyną na życie firmy i cele biznesowe. Może to być np.
Poprawa jakości produktu
Redukcja kosztów przyszłych awarii i tempa naprawy.
Zwiększenie efektywności operacyjnej.
Poprawa morale zespołu.
Ustalenie kryteriów, kiedy rozpocząć
Dobrze jest sprecyzować jakie sytuacje są bodźcem, że trzeba przeprowadzić postmortem. Dzięki temu uprościsz dyskusję, czy to jest ten właściwy moment by uruchomić postmortem.
Dobrymi kryteriami są np.
Widoczne przez użytkownika przestoje lub degradacja pracy systemu powyżej określonego progu.
Utrata danych.
Interwencja inżyniera poza standardowym trybem pracy (wycofanie wersji, przekierowanie ruchu itp.)
Czas rozwiązania problemu powyżej pewnego progu.
Awaria monitorowania (co zwykle oznacza ręczne wykrywanie incydentów).
Jasne kryteria pomagają zespołom zrozumieć, kiedy analiza jest konieczna i zapewniają konsekwencję w całej organizacji.
Stworzenie struktury i szablonów dla analizy:
Aby ułatwić proces analizy, powinieneś(aś) opracować standardową strukturę dla postmortem. Wtedy nie bedziesz za każdym razem wymyślać koła na nowo.
Przykładowa struktura dokumentu:
Linia czasu incydentu
Skutki – biznesowe i techniczne
Przyczyny incydentu
Lekcje z incydentu
Rozwiązanie tymczasowe
Docelowe akcje
Lub link do takiego szablonu od PagerDuty.
O tych elementach opowiem szerzej w kolejnym punkcie.
Określenie cech spotkania
Spotkanie postmortem łatwo może skończyć się shitstormem. Aby temu przeciwdziałać musisz aktywnie zadbać o kulturę pracy.
Cechy spotkania świetnie przekazuje poniższa grafika z artykułu How to facilitate a Blameless Postmortem:
W kontekście analizy incydentów, ważne jest stworzenie atmosfery, w której członkowie zespołu czują się swobodnie dzieląc informacje o błędach i problemach, bez obawy o potępianie. To oznacza skupienie się na identyfikacji przyczyn problemu, a nie obwinianiu poszczególnych osób.
Przeprowadzenie spotkania
Kiedy już mamy ustalone podstawowe tematy, to możemy czekać na incydent 😅
Poniżej mam dla Ciebie opisany proces jak przeprowadzić takie spotkanie. Będę używać części z przykładowego dokumentu postmortem systemu Wypożyczania Rowerów.
Organizacja spotkania
Zwykle jeden z liderów (tech lead, engineering manager, senior), organizuje spotkanie. Warto spotkanie ustalić na dzień / godzinę, kiedy będzie można spokojnie dokonać analizy incydentu.
Na spotkanie powinniśmy zaprosić wszystkie osoby, które mogą przyczynić się do zrozumienia incydentu. To może obejmować:
członków zespołu, którzy byli bezpośrednio zaangażowani,
osoby, na których wpłynął incydent,
jak również innych pracowników organizacji, którzy są blisko obszarów związanych z incydentem.
Jeśli występujący problem ma duże konsekwencje można również zaprosić osobę z zewnątrz, aby poprowadziła spotkanie. Pozwoli to mieć bardziej obiektywnego moderatora spotkania.
Aby nie tracić czasu podczas spotkania można wcześniej stworzyć dokument postmortem. Wtedy wyślemy go od razu z zaproszeniem na spotkanie.
Tworzenie bezpiecznego środowiska:
Spotkanie dobrze jest rozpocząć od przedstawienia:
celów spotkania
przypomnienia cech spotkania
Wydaje się to zbyteczne, ale z punktu widzenia psychologii jest kluczowe by włożyć odpowiedni mindset w głowy uczestników. Dzięki temu nastawimy spotkanie na otwartość i uczciwość. Wszyscy uczestnicy powinni czuć się swobodnie dzieląc swoje myśli i obawy, bez obawy o potępianie lub krytykę.
Przegląd incydentu
Główna część postmortem powinno zawierać zbudowanie linii czasu incydentu. Określamy krok po kroku co stało się w ramach incydentu.
Zwykle ma to postać następującą:
16:35 – CPU na bazie danych osiąga 100%.
16:40 – 95% klientów nie jest w stanie zakończyć procesu.
17:00 – Uruchamia się co 30-minutowa sonda na bazie. Alert o wysyceniu bazy danych trafia na slacka działu SRE.
17:15 – Rafał odbiera wiadomość ze slacka i kontaktuje się z Piotrem z zespołu Wypożyczeń.
Opisujemy zarówno informacje związane z aktywnościami klienta, techniczne aspekty oraz interakcję z poszczególnymi osobami i działami.
Na tej podstawie zyskujemy szeroki obraz zaistniałej sytuacji – zarówno dlaczego powstał problem, jak i jak go rozwiązywaliśmy.
Określenie skutków
Następnie trzeba zastanowić się nad skutkami incydentu. Najlepiej jest skupić się na kwestiach klienckich i biznesowych. Warto posłużyć się dokładnymi liczbami, jeśli takie posiadamy.
Przykładowy opis skutków:
Przerwa w działaniu systemu na 1,5 godziny w godzinach szczytu.
Szacowana strata 10 000 wypożyczeń = 150 000 zł.
Negatywne komentarze na Social Media i oceny na Google.
Analiza przyczyn
Następnie, zespół powinien przeprowadzić szczegółową analizę przyczyn incydentu. To może obejmować techniczne aspekty, jak również procesy i decyzje, które mogły przyczynić się do incydentu.
Przykładowy opis przyczyn:
Główny problem
Przeciążenie bazy danych i wysycenie CPU.
Przyczyny
Błąd w oprogramowaniu, który doprowadził do generowania wielokrotnie powtarzanych, niepotrzebnych zapytań do bazy danych.
Wypuszczenie nowej wersji procesu wypożyczania bez testów wydajnościowych.
Brak wiedzy w zespole jak monitorować i pisać optymalne zapytania SQL.
Dobrą metaforą jest tutaj drzewo root cause:
Należy zbadać odpowiednio szeroko potencjalne powody, które skutkowały awarią. Nie powinniśmy się zatrzymać na samym „Baza danych osiągnęła 100% CPU".
Określenie dalszych akcji
Po zidentyfikowaniu przyczyn, zespół powinien omówić, czego nauczył się z incydentu i jakie mogą być dalsze kroki. To może obejmować zmiany w systemach lub procesach, szkolenia dla zespołu, lub inne działania, które mogą pomóc zapobiec podobnym incydentom w przyszłości.
Minimalnie ma to formę tabeli z:
Nazwą akcji
Osobą odpowiedzialną
Linkiem do zadania w systemie zadań + statusem
Przykład tabeli takich akcji:
Na pierwszy rzut oka widać co jest robione i jaki jest tego status.
Dobrze jest zadbać, aby każda przyczyna miała swoją akcję usprawniającą.
Praca z rezultatami
Praktyka postmortem nie kończy się spotkaniem. Należy jeszcze zadbać o to, aby zadania zostały faktycznie zrealizowane. Często firmy również promują dane postmortem jako naukę dla organizacji.
Ponowna analiza postmortem:
Analiza po incydentach nie jest celem samym w sobie, ale środkiem do poprawy. W związku z tym, po każdej analizie, organizacja powinna wprowadzić konkretną procedurę, aby wdrożyć zalecenia i śledzić ich skuteczność.
Zwykle organizacja daje sobie określony czas, po którym ponownie wraca do postmortem. Wtedy sprawdzamy na ile faktycznie udało nam się wdrożyć docelowe akcje. Lub w niektórych sytuacjach, dlaczego tego nie zrobiliśmy. 🥹
Review postmortem
W ramach danego postmortem definiuje się dodatkowego oceniającego. Jest to osoba z zewnątrz, która nie brała udziału w postmortem. Jej celem jest np.:
Sprawdzenie kompletności opisu wystąpienia incydentu.
Ocena analizy przyczyn i zdefiniowanych akcji.
Potwierdzenie, czy faktycznie akcje są realizowane.
Na przykładzie powyższego postmortem mogłaby ona dodać komentarz:
Brakuje akcji, który upewniłaby nas, że nowa funkcjonalność zadziała w godzinach szczytu. Np. testy wydajnościowe albo stopniowy rollout.
Edukacja i komunikacja
Na podstawie danego postmortem organizacja uczy się ponownie nie popełniać takich błędów.
Organizacje mają różne sposoby na powtórne wykorzystywanie materiałów z postmortem:
Ogłaszają wystąpienie postmortem na kanałach firmowych.
Odbywają się spotkania „fuck-up nights", aby opowiedzieć sobie o zaistniałych problemach.
Inne zespoły wykonują analizy, czy opisany incydent nie pojawi się u nich.
Firmy wykonują gry zespołowe (war games), w których przechodzą przez problemy związane z poprzednimi incydentami.
To zwiększa tempo uczenia się organizacji i upraszcza radzenie sobie z przyszłymi incydentami.
Materiały
To wszystko powyżej jest tylko pigułką wiedzy.
Zachęcam do sięgnięcia po szersze materiały od tytanów naszej branży:
https://sre.google/sre-book/example-postmortem/#id-mX2uoSWSotMfzG
https://knowledge.insead.edu/career/post-mortem-product-management
https://postmortems.pagerduty.com/resources/post_mortem_template/
https://medium.com/@sonnydewfall/the-facebook-outage-a-postmortem-ac60428a16cb
https://www.fearlessculture.design/blog-posts/how-to-facilitate-a-blameless-post-mortem
Podsumowanie
Kultura postmortem pozwala na adresowanie głównych problemów, zamiast na skupianiu się szukaniu winnych. Wg. mnie jest czynnikiem, który sprawia, że organizacje stają się coraz bardziej efektywne.
A u Ciebie, jak wygląda nauka na błędach? Bardziej shitstorm, czy bardziej postmortem?
W cyklu Inżynierskich Praktyk to już wszystko 😁 Mam nadzieję że seria dostarczyła Ci dużo praktycznych wskazówek. Jeśli masz jakieś pytania lub komentarze nie wahaj się podzielić się nimi poniżej lub skontaktować się ze mną bezpośrednio.