Szablon analizy zdarzeń

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 {zakres czasowy incydentu, np. od 15:45 do 16:35}, {DATA} {LICZBA} użytkowników doświadczyło następujących problemów: {OBJAWY ZDARZENIA}.

Zdarzenie było wywołane przez {ZMIANA} o godzinie {GODZINA WPROWADZENIA ZMIANY, KTÓRA DOPROWADZIŁA DO ZDARZENIA}.

{ZMIANA} obejmowała {OPIS ZMIANY LUB JEJ PRZYCZYNY, na przykład zmiana w kodzie w celu aktualizacji systemu}.

Błąd w tym kodzie spowodował {OPIS PROBLEMU}.

Zdarzenie zostało wykryte przez {SYSTEM MONITOROWANIA}. Zespół przystąpił do prac nad zdarzeniem poprzez {CZYNNOŚCI PODJĘTE W CELU ROZWIĄZANIA PROBLEMU}.

Ten incydent o poziomie istotności {POZIOM ISTOTNOŚCI} dotyczył {X%} użytkowników.

W związku z tym incydentem odnotowano dodatkowe skutki w postaci {np. LICZBA PRZESŁANYCH ZGŁOSZEŃ DO DZIAŁU WSPARCIA, WZMIANEK W MEDIACH SPOŁECZNOŚCIOWYCH, TELEFONÓW DO OPIEKUNÓW KLIENTÓW}.

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:

{DD.MM.RRRR} o {16:00}, ({CZAS, JAKI UPŁYNĄŁ, ZANIM KLIENCI SPOSTRZEGLI SKUTKI, np. 10 dni przed wystąpieniem wspomnianego incydentu}), wprowadzono zmianę w {PRODUKT LUB USŁUGA} w celu {ZMIANY, KTÓRE DOPROWADZIŁY DO INCYDENTU}.

Ta zmiana spowodowała {OPIS WPŁYWU ZMIANY}.

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: {LICZBA}. Problem utrzymywał się przez {OKRES}.

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:

{DD.MM.RRRR} przez {XX godz. i XX min} między {XX:XX czasu UTC i XX:XX czasu UTC} nasi użytkownicy borykali się ze skutkami incydentu {PODSUMOWANIE INCYDENTU}.

Incydent dotyczył {XX} poszkodowanych klientów (X% UŻYTKOWNIKÓW {SYSTEM LUB USŁUGA}), którzy doświadczyli następujących problemów: {OPIS OBJAWÓW}.

Przesłano {LICZBA ZGŁOSZEŃ DO DZIAŁU WSPARCIA I LICZBA WPISÓW W MEDIACH SPOŁECZNOŚCIOWYCH}.

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 {TYP ALERTU} i powiadomienia {ZESPÓŁ/OSOBA}.

Następnie powiadomiono {DODATKOWA OSOBA KONTAKTOWA}, ponieważ {PODSTAWOWA OSOBA KONTAKTOWA} nie miał(a) uprawnienia do zapisu usługi na dysku, co opóźniło reakcję o {XX MIN/GODZ.}.

{WŁAŚCICIEL ZESPOŁU ODPOWIEDZIALNEGO ZA ULEPSZENIE} wdroży ulepszenie polegające na {OPIS ULEPSZENIA}, aby {OCZEKIWANA POPRAWA}.

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 czasu UTC} {INŻYNIER PEŁNIĄCY DYŻUR DOMOWY} zalogował(a) się o {XX:XX czasu UTC} do systemu {SYSTEM, W KTÓRYM REJESTROWANE SĄ INFORMACJE O INCYDENTACH}.

Inżynier nie miał wystarczającej ilości informacji na temat {SYSTEM, W KTÓRYM DOSZŁO DO INCYDENTU}, dlatego o godzinie {XX:XX czasu UTC} wysłano drugie powiadomienie do {PEŁNIĄCEGO DYŻUR DOMOWY INŻYNIERA DS. ESKALACJI}, który(-a) zgłosił(a) się o {XX:XX czasu 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:

{OPISZ DZIAŁANIE, KTÓRE PODJĘTO W CELU ZMINIMALIZOWANIA SKUTKÓW PROBLEMU, PRZYCZYNĘ WYBORU TAKIEGO DZIAŁANIA ORAZ JEGO REZULTAT}

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 związany z obsługą puli połączeń doprowadził do wycieku połączeń w sytuacjach awaryjnych oraz braku widoczności stanu połączeń.

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