🤦 Postmortem - nauka na błędach2023-05-24Cześć! Witaj w pierwszym odcinku cyklu praktyk inżynierskich najlepszych firm produktowych. Dzisiaj na tapet bierzemy: Postmortem - nauka na błędach A więc w dzisiaj mam dla Ciebie: Miłego czytania 😀 🤦 Postmortem - nauka na błędachGdy organizacja nie uczy się na błędachNa 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:
To długofalowo powoduje:
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 postmortemTermin 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:
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:
To tworzy środowisko, które promuje otwartość, odpowiedzialność i ciągłe doskonalenie. No dobra, a kto z tego korzysta? Przykład z branżyW 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.
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 postmortemJak 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.
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.
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:
Lub link do takiego szablonu od PagerDuty. O tych elementach opowiem szerzej w kolejnym punkcie. Określenie cech spotkaniaSpotkanie 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 spotkaniaKiedy 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 spotkaniaZwykle 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ć:
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:
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 incydentuGłó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ą:
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ówNastę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:
Analiza przyczynNastę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:
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 akcjiPo 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:
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 rezultatamiPraktyka 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 postmortemW 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.:
Na przykładzie powyższego postmortem mogłaby ona dodać komentarz:
Edukacja i komunikacjaNa 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:
To zwiększa tempo uczenia się organizacji i upraszcza radzenie sobie z przyszłymi incydentami. MateriałyTo wszystko powyżej jest tylko pigułką wiedzy. Zachęcam do sięgnięcia po szersze materiały od tytanów naszej branży:
PodsumowanieKultura 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? 💻 Prezentacja na DevoxxW ramach Devoxx Poland występuję z prezentacją: “How I Learned to Stop Worrying and Love the distributed transactions” Będę opowiadać o:
Jeśli będziesz na konferencji to przybij ze mną piątkę. 🤲 📧 Prześlij dalejDzięki, że doczytałeś(aś) do końca. 😊 Wszystkie poprzednie wydania newslettera są dostępne tutaj. Jeśli spodobał Ci się mój newsletter, prześlij go proszę osobom, którym też mógłby się spodobać. Z góry dziękuję. A jeśli nie jesteś jeszcze w newsletterze, to zachęcam do zapisania się. Polecam się na przyszłość!  "Inżynierskie podejście do produktów cyfrowych." P.S. Co myślisz o tym newsletterze? Odpisz :) |
