Przyczyny źródłowe

Jak opisałbyś przebieg wydarzeń w czasie?

Wdrożenie poszło o 14:20, a pierwsze alerty o błędach pojawiły się jakieś osiem minut później.
Klienci zaczęli zgłaszać problemy z logowaniem, zanim wychwycił to nasz monitoring.
Rollback zrobiliśmy o 15:05, ale pełne wyczyszczenie cache zajęło jeszcze 20 minut.
Co poszło dobrze?

Co zadziałało i pomogło nam skutecznie zareagować?

Alerty wyłapały skok liczby błędów niemal natychmiast.
Zespół w ciągu kilku minut dołączył do calla incydentowego i zachował spokój.
Jasna procedura rollbacku zaoszczędziła nam mnóstwo czasu.
Co poszło źle?

Gdzie coś się posypało lub zawiodło?

Nie mieliśmy żadnego testu automatycznego dla tej ścieżki konfiguracji.
Monitoring nie obejmował zależności, która faktycznie padła.
Ścieżka eskalacji była niejasna, więc właściwe osoby zostały wezwane za późno.
Działania do podjęcia

Co zrobimy, żeby zapobiec temu w przyszłości?

Dodać testy automatyczne obejmujące zmianę konfiguracji, która spowodowała awarię.
Zaktualizować runbook i w przyszłym tygodniu sprawdzić kroki rollbacku.
Wprowadzić zakaz piątkowych wdrożeń dla zmian wysokiego ryzyka.

Czym jest retrospektywa post-mortem?

Retrospektywa post-mortem to przegląd incydentu, projektu lub wydania po jego zakończeniu, prowadzony bez szukania winnych. Zespół ustala, co się stało, dlaczego tak się stało i co trzeba zmienić, żeby ten sam problem nie wrócił. Sprawdza się przy incydentach produkcyjnych i awariach, ale równie dobrze przy niedotrzymanym terminie czy zamknięciu dużej inicjatywy. Tablica ma cztery kolumny. „Przyczyny źródłowe” zaczynają się od osi czasu: zespół opisuje, co się wydarzyło i kiedy, zanim ktokolwiek zacznie to analizować, dzięki czemu wszyscy pracują na tych samych faktach. „Co poszło dobrze?” zbiera to, co pomogło, na przykład alerty, które szybko zadziałały, albo skuteczny rollback. „Co poszło źle?” obejmuje luki i tarcia, które pogorszyły sytuację. „Działania do podjęcia” zamieniają dyskusję w konkretne poprawki z przypisaną osobą i terminem. W TeamRetro wszyscy dodają obserwacje jednocześnie, grupują powiązane ze sobą, głosują na problemy o największym wpływie i przypisują działania następcze, zanim spotkanie się skończy. Post-mortemy bez szukania winnych to standardowa praktyka w inżynierii niezawodności (SRE) i zarządzaniu incydentami. Gdy zespół traktuje awarię jako informację o systemie, a nie jako czyjąś winę, ludzie opowiadają, co naprawdę się wydarzyło, i właśnie w ten sposób odkrywa się słabe punkty procesu. Zachowaj podsumowanie, a następnym razem, gdy zepsuje się coś podobnego, będziesz mieć zapis, do którego można wrócić.

Format retrospektywy post-mortem

Przyczyny źródłowe

Jak opisałbyś przebieg wydarzeń w czasie?

Zanim zaczniecie analizę, zbudujcie wspólny, oparty na faktach opis incydentu lub projektu. Poproś zespół o ułożenie wydarzeń po kolei, z naciskiem na to, co się stało i kiedy, a nie na to, kto co zrobił. Uzgodnienie osi czasu na początku zapobiega nieporozumieniom i daje wszystkim ten sam punkt wyjścia do szukania przyczyn.

Co poszło dobrze?

Co zadziałało i pomogło nam skutecznie zareagować?

Nawet przy złym incydencie zwykle jest coś, co warto zachować. Wykorzystaj tę kolumnę, żeby nazwać działania, narzędzia i decyzje, które pomogły, tak aby zespół wiedział, co robić dalej. Zaczynanie od tego, co zadziałało, rozładowuje też część napięcia przed dalszą rozmową.

Co poszło źle?

Gdzie coś się posypało lub zawiodło?

Ta kolumna obejmuje problemy, luki i tarcia, które pogorszyły incydent lub jego skutki. Skupiaj dyskusję na procesach i systemach, a nie na osobach, i przypominaj zespołowi, że celem jest nauka. Szukaj luk, przez które kilka rzeczy mogło pójść źle naraz, takich jak brak monitoringu czy niejasna ścieżka eskalacji.

Działania do podjęcia

Co zrobimy, żeby zapobiec temu w przyszłości?

Zamień dyskusję w konkretne usprawnienia, każde z przypisaną osobą i terminem. Dbaj o to, żeby były na tyle realistyczne, by dało się je faktycznie zrealizować. Na początek listy wstaw zmiany, które najskuteczniej zapobiegną powtórce.

Kiedy należy skorzystać z niniejszego przeglądu retrospektywnego

  • Po incydencie produkcyjnym lub awarii, aby zrozumieć przyczynę i zapobiec jej powtórzeniu
  • Po zakończeniu dużego projektu lub wydania, aby zebrać wnioski, póki szczegóły są świeże
  • Gdy termin nie został dotrzymany lub inicjatywa nie spełniła oczekiwań, a zespół potrzebuje szczerego przeglądu
  • Gdy ten sam problem wciąż powraca i chcesz znaleźć jego prawdziwą przyczynę
  • Gdy chcesz, żeby Twoje zespoły traktowały porażki jako okazję do nauki, a nie powód do szukania winnych

Proponowane pytania lodołamacze

  • Jaka była Twoja najbardziej pamiętna wpadka, z której wyniosłeś świetną lekcję?
  • Gdyby ten incydent był filmem, jaki miałby tytuł?

Czy chciałby Pan/Pani, aby Państwa zespół wykonał ćwiczenie rozgrzewkowe, a nie tylko odpowiadał na pytania na głos? Przejrzyj bezpłatne lodołamacze →

Pomysły i wskazówki dotyczące spotkania retrospektywnego

  • Zaznacz na samym początku, że sesja odbywa się bez szukania winnych, żeby ludzie czuli się bezpiecznie, opowiadając, co naprawdę się stało
  • Zbudujcie wspólną, opartą na faktach oś czasu, zanim ktokolwiek zacznie analizować
  • Użyj metody 5 Why, żeby przejść od objawów do faktycznej przyczyny
  • Każde działanie musi mieć przypisaną osobę i termin, inaczej nie zostanie zrealizowane
  • Zaproś osoby, które brały udział w zdarzeniu, ale utrzymaj grupę na tyle małą, żeby rozmowa była skupiona
  • Spisz wnioski i na kolejnych sesjach sprawdzaj wcześniejsze działania, żeby upewnić się, że poprawki się utrzymały

Najczęściej zadawane pytania

Czym jest post-mortem bez szukania winnych?
To przegląd, który zamiast obwiniać konkretne osoby, analizuje systemy, procesy i okoliczności stojące za incydentem. Ludzie są bardziej szczerzy, gdy nie muszą się bronić, więc zespół dociera do prawdziwych przyczyn i może je usunąć.
Kiedy przeprowadzić retrospektywę post-mortem?
Po poważnym incydencie, awarii, niedotrzymanym terminie lub zakończeniu dużego projektu. Zorganizuj ją wkrótce po zdarzeniu, póki szczegóły są jeszcze świeże.
Ile trwa retrospektywa post-mortem?
Zwykle 60–90 minut, w zależności od złożoności incydentu. Zarezerwuj dodatkowy czas na analizę przyczyn źródłowych i uzgodnienie jasnych działań.
Czym post-mortem różni się od retrospektywy sprintu?
Retrospektywa sprintu dotyczy określonego okresu pracy i tego, jak zespół ze sobą współpracował. Post-mortem skupia się na jednym incydencie lub zdarzeniu, zaczynając od osi czasu i cofając się do przyczyn.
Kto powinien uczestniczyć w retrospektywie post-mortem?
Osoby bezpośrednio zaangażowane w incydent lub projekt oraz każdy, kto może wnieść kontekst albo będzie odpowiadać za któreś z działań. Utrzymaj grupę na tyle małą, żeby każdy mógł zabrać głos.
Jak sprawić, żeby post-mortem nie zamienił się w szukanie winnych?
Zaznacz na początku, że sesja odbywa się bez szukania winnych, skupiaj rozmowę na procesach i systemach zamiast na ludziach i traktuj błędy jako informację. Neutralny facylitator pomaga utrzymać konstruktywny ton.
Czy są Państwo gotowi do przeprowadzenia tej retrospektywy?Zapraszamy do obejrzenia tej retrospektywy na żywo