Proces analizy post-mortem incydentów: śledzenie, dokumentowanie i usprawnianie

Kluczowe wnioski

• Analizy post-mortem incydentów pomagają zespołom zrozumieć, co się wydarzyło, dlaczego do tego doszło i co należy zmienić, aby zapobiec powtórzeniu się problemów.

• Korzystanie z aplikacji Jira Service Management, Confluence i Jira razem pozwala utworzyć połączony przepływ pracy obejmujący reagowanie, dokumentowanie i działania następcze.

• Spójny szablon analizy post-mortem ułatwia dokumentowanie przeglądów po incydentach, ich porównywanie oraz wyciąganie z nich wniosków na przestrzeni czasu.

• Przekształcanie działań naprawczych w zgłoszenia Jiry z wyznaczonymi właścicielami i terminami pomaga zespołom przełożyć zdobytą wiedzę na rzeczywiste usprawnienia. 

Gdy w środowisku produkcyjnym pojawi się problem, usunięcie usterki to dopiero początek. Równie ważne jest zrozumienie, dlaczego tak się stało, i zadbanie o to, aby sytuacja się nie powtórzyła. 

Analiza post-mortem incydentu to uporządkowany przegląd incydentu od początku do końca, obejmujący opis tego, co poszło nie tak, sposób reakcji zespołu oraz wnioski dotyczące zmian na przyszłość.

Dzięki szablonowi planu reagowania na incydenty, który wytycza kierunek działań, zespół może spójnie dokumentować każdy incydent, dzięki czemu żadna ważna informacja nie zostanie pominięta, a każdy przegląd przyczyni się do rzeczywistych usprawnień.

Jak to działa: obsługa incydentów i rejestrowanie analizy post-mortem

Dobre zarządzanie incydentami to nie tylko rozwiązywanie bieżących problemów. Chodzi o opracowanie systemu, w którym każdy incydent przyczynia się do doskonalenia procesów i narzędzi oraz lepszego przygotowania na przyszłość. Korzystanie z aplikacji Jira Service Management, Confluence i Jira razem zapewnia zespołowi połączony przepływ pracy, który obejmuje cały cykl reagowania na incydenty — od momentu wygenerowania alertu, przez analizę post-mortem, aż po działania następcze. 

Takie podejście zapewnia spójne dokumentowanie wszystkich incydentów i ustanawia klarowny łańcuch odpowiedzialności. Zamiast szczegółów incydentów rozproszonych w wiadomościach na Slacku, e-mailach i w czyjejś pamięci wszystkie dane znajdują się w jednym, spójnym ekosystemie, gdzie można je przeglądać, odwoływać się do nich i podejmować w związku z nimi odpowiednie działania. Ta spójność oznacza również, że szablon planu reagowania na incydenty pozostaje centralnym elementem procesu, a nie tylko dokumentem, który zespół wypełnia, gdy znajdzie na to czas. 

Poniżej opisano przebieg procesu na poszczególnych etapach:

Obsługa incydentu w Jira Service Management

Jira Service Management to miejsce, w którym rozpoczyna się reagowanie na incydent. Gdy tylko pojawi się problem, należy go zarejestrować w JSM, określić poziom istotności i przypisać odpowiednie osoby reagujące. 

W trakcie incydentu zespoły mogą korzystać z JSM, aby:

• śledzić czynności, decyzje i eskalacje w czasie rzeczywistym;

• prowadzić przejrzystą dokumentację dotyczącą osób zaangażowanych oraz wprowadzonych zmian;

• rejestrować szczegóły, które później posłużą do przeprowadzenia analizy post-mortem;

• informować kierownictwo, nie zakłócając przy tym prac osób reagujących.

JSM integruje się z aplikacjami Confluence i Jira, dlatego dane zebrane podczas incydentu mogą być bezpośrednio wykorzystywane w dokumentacji analizy post-mortem oraz działaniach następczych. W przypadku zespołów korzystających z JSM w ramach bardziej rozbudowanej platformy oprogramowania ITSM dane dotyczące incydentów są również uwzględniane w szerszym kontekście zarządzania usługami.

JSM wspiera również skuteczną komunikację dotyczącą incydentów na wszystkich etapach reagowania, pomagając zespołom:

• informować klientów, zespoły wsparcia i interesariuszy na bieżąco;

• ograniczać niejasności podczas trwających incydentów;

• zapewnić widoczność statusu i wpływu;

• komunikować się w sposób bardziej przejrzysty podczas zdarzeń o wysokiej istotności lub w scenariuszach zarządzania kryzysowego.

W momencie rozwiązania incydentu zespół ma już szczegółowy zapis jego przebiegu, co ułatwia sporządzenie analizy post-mortem i sprawia, że jest ona bardziej przydatna w kontekście przyszłych usprawnień.

Rejestrowanie analizy post-mortem w Confluence

Po rozwiązaniu incydentu należy go udokumentować, póki szczegóły są jeszcze świeże — najlepiej w ciągu 24–48 godzin. Im dłużej zwlekasz, tym więcej kontekstu umyka, a analiza post-mortem staje się mniej przydatna. 

Utwórz dedykowaną stronę w Confluence, korzystając z szablonu analizy post-mortem incydentu, a następnie przejdź przez kolejne sekcje: oś czasu, analiza głównej przyczyny, ocena wpływu oraz wyciągnięte wnioski. Szablon reagowania na incydenty zamieszczony na tej stronie stanowi kompletny schemat, który zespół może skopiować i wypełnić przy każdym nowym incydencie, dzięki czemu nie trzeba za każdym razem zastanawiać się, co należy udokumentować.

Przechowywanie analiz post-mortem w Confluence ma kilka praktycznych zalet:

• Widoczność dla całego zespołu: każdy — od inżynierów po kadrę kierowniczą — może sprawdzić, co się wydarzyło, bez konieczności kontaktowania się z osobą pełniącą dyżur domowy w celu uzyskania ustnego podsumowania.

• Rozpoznawanie wzorców: gdy wszystkie incydenty są dokumentowane w tym samym formacie, znacznie łatwiej zauważyć powtarzające się awarie i systemowe słabości w poszczególnych kwartałach.

• Dokumentacja bez wskazywania winnych: ustrukturyzowany szablon reagowania na incydenty pozwala skupić dyskusję na systemach i procesach, a nie na wzajemnym obwinianiu się, co prowadzi do bardziej rzetelnych i przydatnych raportów.

• Szybsze wdrażanie nowych pracowników: nowi członkowie zespołu mogą zapoznać się z dotychczasowymi analizami post-mortem, aby zrozumieć, jak systemy działają w sytuacjach kryzysowych i jakie wnioski zespół wyciągnął z poprzednich incydentów.

Aby uzyskać bardziej szczegółowe wskazówki dotyczące prowadzenia konstruktywnych analiz post-mortem, zapoznaj się z naszym podręcznikiem analizy post-mortem incydentów.

Śledzenie działań następczych jako zgłoszeń Jiry

Analiza post-mortem jest wartościowa tylko wtedy, gdy prowadzi do podjęcia konkretnych działań. Każde działanie naprawcze i każdy powtarzający się problem zidentyfikowany podczas przeglądu należy przekształcić w zgłoszenie Jiry z jasno określonym właścicielem i terminem. 

To właśnie ten krok odróżnia zespoły, które faktycznie wprowadzają ulepszenia, od tych, które wciąż borykają się z tymi samymi problemami. Gdy działania naprawcze są zapisane w Jirze jako zgłoszenia, które można śledzić, menedżerowie mogą monitorować postępy, a zespoły mogą wzajemnie rozliczać się z wprowadzenia uzgodnionych usprawnień. Pomaga to również w ustalaniu priorytetów. Gdy zgłoszenia związane z incydentami znajdują się obok pozostałych pozycji w backlogu, łatwiej jest je porównać z innymi priorytetami, zamiast pozwolić im niezauważenie spaść na koniec listy.

Odpowiednie narzędzia do zarządzania incydentami pozwalają na kompleksowe połączenie całego tego przepływu pracy. Gdy systemy reagowania, dokumentowania i prowadzenia działań następczych są ze sobą zintegrowane, czas między wykryciem problemu a podjęciem działań zapobiegających jego ponownemu wystąpieniu ulega znacznemu skróceniu.

Szablon reagowania na incydenty

Poniżej znajduje się szablon planu reagowania na incydenty, który zespół może skopiować i dostosować do każdego nowego incydentu. Obejmuje wszystkie etapy analizy post-mortem — od wstępnego podsumowania i osi czasu, przez analizę głównej przyczyny i wyciągnięte wnioski, aż po działania naprawcze. Stosowanie spójnej struktury w przypadku każdego incydentu gwarantuje, że nic nie zostanie pominięte, a porównywanie analiz post-mortem z upływem czasu jest łatwiejsze.

Przykłady zawarte w szablonie stanowią punkt wyjścia, a nie sztywny scenariusz. Dostosuj język i poziom szczegółowości do sposobu działania Twojej organizacji. Celem jest udokumentowanie wystarczającej ilości kontekstu, aby każdy, kto przeczyta tę analizę post-mortem kilka miesięcy później, mógł dokładnie zrozumieć, co się wydarzyło i jakie działania podjął zespół.

Streszczenie zdarzenia

W kilku zdaniach podsumuj incydent. Uwzględnij informacje o jego przebiegu, przyczynach, istotności oraz czasie trwania skutków.

PRZYKŁAD:

W godzinach {time range of incident, e.g. 15:45 and 16:35} dnia {DATE} {NUMBER} użytkowników doświadczyło następujących problemów: {EVENT SYMPTOMS}. 

Zdarzenie było wywołane przez {CHANGE} o godzinie {TIME OF CHANGE THAT CAUSED THE EVENT}. 

Zmiana {CHANGE} obejmowała {DESCRIPTION OF OR REASON FOR THE CHANGE, such as a change in code to update a system}. 

Błąd w tym kodzie spowodował {DESCRIPTION OF THE PROBLEM}. 

Zdarzenie zostało wykryte przez {MONITORING SYSTEM}. Zespół przystąpił do prac nad zdarzeniem poprzez {RESOLUTION ACTIONS TAKEN}.

Ten incydent o poziomie istotności {SEVERITY LEVEL} dotyczył {X%} użytkowników.

W związku z tym incydentem odnotowano dodatkowe skutki w postaci {e.g. NUMBER OF SUPPORT TICKETS SUBMITTED, SOCIAL MEDIA MENTIONS, CALLS TO ACCOUNT MANAGERS}. 

Przygotowanie

Opisz sekwencję zdarzeń, które doprowadziły do incydentu, na przykład poprzednie zmiany, które spowodowały wystąpienie niewykrytych jeszcze błędów.

PRZYKŁAD:

O {16:00} w dniu {MM/DD/YY} ({AMOUNT OF TIME BEFORE CUSTOMER IMPACT, e.g. 10 days before the incident in question}) wprowadzono zmianę w {PRODUCT OR SERVICE}, aby {THE CHANGES THAT LED TO THE INCIDENT}. 

Ta zmiana spowodowała {DESCRIPTION OF THE IMPACT OF THE CHANGE}.

Błąd

Opisz, co we wdrożonej zmianie nie zadziałało w oczekiwany sposób. Dołącz zrzuty ekranu z wizualizacjami istotnych danych (o ile są dostępne), aby zilustrować usterkę.

PRZYKŁAD:

W przypadku {XX%} żądań wysłano następującą liczbę błędnych odpowiedzi: {NUMBER}. Problem utrzymywał się przez {TIME PERIOD}.

Wpływ

Opisz, w jaki sposób incydent wpłynął na użytkowników wewnętrznych i zewnętrznych w trakcie jego trwania. Dodaj informację o liczbie zgłoszeń do działu wsparcia, jakie napłynęły.

PRZYKŁAD:

{MM/DD/YY} przez {XXhrs XX minutes} między {XX:XX UTC and XX:XX UTC} nasi użytkownicy borykali się ze skutkami incydentu {SUMMARY OF INCIDENT}.

Incydent dotyczył {XX} poszkodowanych klientów (X% UŻYTKOWNIKÓW {SYSTEM OR SERVICE}), którzy doświadczyli następujących problemów: {DESCRIPTION OF SYMPTOMS}.

Przesłano {XX NUMBER OF SUPPORT TICKETS AND XX NUMBER OF SOCIAL MEDIA POSTS}.

Wykrycie

Kiedy zespół wykrył incydent? Skąd dowiedział się, że w ogóle doszło do incydentu? Jak można skrócić czas do wykrycia? Zastanów się: co można było zrobić, aby skrócić ten czas o połowę?

PRZYKŁAD:

Incydent został wykryty w wyniku wyzwolenia alertu {ALERT TYPE} i powiadomienia {TEAM/PERSON}. 

Następnie powiadomiono {SECONDARY PERSON}, ponieważ {FIRST PERSON} nie miał(a) uprawnienia do zapisu usługi na dysku, co opóźniło reakcję o {XX MINUTES/HOURS}.

{TEAM OWNER OF THE IMPROVEMENT} wdroży ulepszenie polegające na {DESCRIBE THE IMPROVEMENT}, aby {EXPECTED IMPROVEMENT}.

Odpowiedź

Kto zareagował na incydent? Kiedy zareagowano na incydent i jakie działania podjęto? Odnotuj wszelkie opóźnienia lub przeszkody, które utrudniły reakcję.

PRZYKŁAD:

Po odebraniu powiadomienia o {XX:XX UTC} {ON-CALL ENGINEER} zalogował(a) się o {XX:XX UTC} do systemu {SYSTEM WHERE INCIDENT INFO IS CAPTURED}. 

Inżynier nie miał wystarczającej ilości informacji na temat {AFFECTED SYSTEM}, dlatego o godzinie {XX:XX UTC} wysłano drugie powiadomienie do {ESCALATIONS ON-CALL ENGINEER}, który(-a) zgłosił(a) się o {XX:XX UTC}.

Odzyskiwanie

Opisz, w jaki sposób usługa została przywrócona, a incydent został uznany za zakończony. Przedstaw szczegółowy opis pomyślnego przywrócenia usługi, uwzględniając, skąd było wiadomo, jakie kroki należy podjąć w celu odzyskania. 

W zależności od scenariusza, rozważ następujące pytania: Jak można skrócić czas potrzebny na zminimalizowanie skutków? Jak można go skrócić o połowę?

PRZYKŁAD:

W procesie odzyskiwania systemu zastosowano podejście oparte na trzech elementach: 

{DESCRIBE THE ACTION THAT MITIGATED THE ISSUE, WHY IT WAS TAKEN, AND THE OUTCOME} 

Przykład: zwiększenie rozmiaru w BuildEng EC3 ASG w celu zwiększenia liczby węzłów dostępnych do obsługi obciążenia i ograniczenia prawdopodobieństwa uwzględnienia w harmonogramie nadsubskrypcji węzłów.

• Zablokowanie aktoskalera Escalator, aby zapobiec agresywnemu ograniczeniu klastra.

• Przywrócenie programu planującego projektowanie kompilacji do poprzedniej wersji.

Oś czasu

Zaprezentuj szczegółową oś czasu incydentu. Zalecamy podawanie czasu UTC w celu ustandaryzowania stref czasowych.

Uwzględnij istotne zdarzenia poprzedzające, rozpoczęcia czynności, pierwszy odnotowany wpływ oraz eskalacje. Odnotuj wszelkie decyzje lub wprowadzone zmiany, uwzględnij czas zakończenia incydentu oraz istotne zdarzenia następcze. 

PRZYKŁAD:

Wszystkie godziny są podane w formacie UTC (uniwersalny czas koordynowany).

11:48 — Ukończono uaktualnienie K8S 1.9 płaszczyzny sterowania. 

12:46 — Ukończono uaktualnienie do wersji 1.9, obejmujące autoskaler klastrów i instancję harmonogramu BuildEng. 

14:20 — Zespół Build Engineering zgłasza problem do zespołu KITT Disturbed.

14:27 — Zespół KITT Disturbed rozpoczyna badanie usterek konkretnej instancji EC2 (ip-203-153-8-204). 

14:42 — Zespół KITT Disturbed oznacza węzeł jako nieuwzględniany w planowaniu. 

14:49 — Zespół Build Engineering zgłasza problem jako dotyczący więcej niż jednego węzła. 86 instancji problemu pokazuje, że usterki dotyczą większej części systemu. 

15:00 — Zespół KITT Disturbed sugeruje przełączenie na standardowy harmonogram. 

15:34 — Zespół Build Engineering zgłasza awarię 200 zasobników. 

16:00 — Zespół Build Engineering zatrzymuje wszystkie kompilacje, które uległy awarii z raportem OutOfCpu. 

16:13 — Zespół Build Engineering zgłasza, że usterki pojawiają się ponownie w przypadku nowych kompilacji, co oznacza, że nie były przejściowe. 

16:30 — Zespół KITT uznaje usterki za incydent i obsługuje je jako incydent. 

16:36 — Zespół KITT blokuje autoskaler Escalator, aby zapobiec usunięciu zaosbów obliczeniowych przez autoskaler i zminimalizować problem.

16:40 - Zespół KITT potwierdza, że grupa ASG jest stabilna, obciążenie klastra jest normalne, a skutki dla klientów usunięte.

SZABLON:

XX:XX UTC — AKTYWNOŚĆ ZWIĄZANA Z INCYDENTEM; PODJĘTE DZIAŁANIE

XX:XX UTC — AKTYWNOŚĆ ZWIĄZANA Z INCYDENTEM; PODJĘTE DZIAŁANIE

XX:XX UTC — AKTYWNOŚĆ ZWIĄZANA Z INCYDENTEM; PODJĘTE DZIAŁANIE

Identyfikacja głównej przyczyny: technika „5 × dlaczego”

„5 × dlaczego” to technika identyfikowania głównej przyczyny. Stosuje się ją w następujący sposób:

• Zacznij od opisania incydentu i zadaj pytanie, dlaczego wystąpił. 

• Odnotuj wpływ, jaki wywarł incydent.  

• Zapytaj, dlaczego do tego doszło oraz dlaczego wpływ był taki, a nie inny. 

• Następnie stawiaj kolejne pytania „dlaczego”, aż dotrzesz do głównej przyczyny.

Zamieść listę odpowiedzi na pytania „dlaczego” w swojej dokumentacji z analizy post-mortem.

PRZYKŁAD:

1. Wystąpiła awaria aplikacji, ponieważ baza danych została zablokowana.

2. Baza danych została zablokowana, ponieważ wystąpiło zbyt wiele operacji zapisu do bazy danych.

3. Ponieważ wypchnęliśmy zmianę do usługi i nie spodziewaliśmy się zwiększonej liczby operacji zapisu.

4. Ponieważ, nie mamy opracowanego procesu programistycznego testowania zmian pod kątem obciążenia.

5. Ponieważ do momentu osiągnięcia tego poziomu skali nie mieliśmy poczucia, że testy pod kątem obciążenia są w ogóle konieczne.

Główna przyczyna

Zapisz główną przyczynę incydentu, czyli rozpoznany element, który trzeba zmodyfikować, aby zapobiec ponownemu występowaniu incydentów tej klasy.

PRZYKŁAD:

Błąd w

Kontrola listy zadań

Przeanalizuj backlog prac inżynierskich, aby ustalić, czy były jakieś nieplanowane prace, które mogły zapobiec danemu incydentowi lub przynajmniej ograniczyć jego wpływ? 

Świeże spojrzenie na backlog może rzucić nieco światła na podjęte decyzje w kontekście priorytetów i ryzyka.

PRZYKŁAD:

W backlogu nie ma żadnych konkretnych elementów, które mogłyby poprawić działanie tej usługi. Jest notatka o udoskonaleniach typowania z uwzględnieniem przepływu. Były to zadania w toku, dla których opracowano przepływy pracy.  

Przesłano zgłoszenia dotyczące poprawy testów integracji, jednak dotychczas sugestie nie zostały wdrożone.

Powtarzanie się zdarzeń

Teraz, gdy znasz już główną przyczynę, możesz spojrzeć wstecz, aby sprawdzić, czy ta sama główna przyczyna nie doprowadziła również do innych incydentów. Jeśli tak, odnotuj działania zaradcze podjęte w przypadku takich incydentów i zadaj pytanie o to, dlaczego ponownie doszło do incydentu.

PRZYKŁAD:

Ta sama główna przyczyna wywołała zdarzenia HOT-13432, HOT-14932 i HOT-19452.

Wyciągnięte wnioski

Omów, co w przebiegu reakcji na incydent poszło dobrze, co można poprawić oraz zdefiniuj potencjalne obszary poprawy.

PRZYKŁAD:

• Wymagany jest test modułu, aby sprawdzić, czy ogranicznik zadań był odpowiednio utrzymywany.

• Należy przeanalizować obciążenia występujące w przypadku operacji przeprowadzanych masowo, które nie są typowe dla zwykłych operacji.

• Operacje przeprowadzane masowo powinny rozpoczynać się powoli i być monitorowane, a ich tempo powinno rosnąć, gdy uzyskiwane wskaźniki usług są nominalne.

Działania naprawcze

Opisz działania naprawcze zalecone w celu uniknięcia tego rodzaju incydentów w przyszłości. Wskaż osobę odpowiedzialną oraz termin wykonania prac i miejsce, w którym można śledzić ich postęp.

PRZYKŁAD:

1. Tymczasowe wdrożenie ręcznego limitu współczynnika automatycznego skalowania w celu ograniczenia liczby usterek

2. Test modułu i ponowne wprowadzenie ograniczeń współczynnika zadań

3. Wprowadzenie dodatkowego mechanizmu w celu gromadzenia rozproszonych informacji o wskaźnikach w klastrze jako wskazówek pomocnych podczas skalowania