Analizy zdarzeń

Czym jest analiza post-mortem?

Analiza to pisemny opis zdarzenia zawierający:

• Skutki zdarzenia.
• Działania podjęte w celu złagodzenia skutków zdarzenia lub ich usunięcia.
• Główną przyczynę zdarzenia.
• Dalsze działania podejmowane w celu zapobiegania powtórnemu wystąpieniu zdarzenia.

W przedsiębiorstwie Atlassian śledzimy wszystkie analizy za pomocą zgłoszeń w systemie Jira, aby mieć pewność, że zostały zrealizowane i zatwierdzone. Można korzystać z prostszego rozwiązania takiego jak strona Confluence w przypadku każdej analizy, jeśli wymagania użytkownika są mniejsze.

Dlaczego opracowujemy analizy?

Celem analizy jest zrozumienie wszystkich przyczyn głównych, udokumentowanie zdarzenia i wyłapanie powtarzających się sytuacji, aby móc wdrożyć skuteczne działania prewencyjne mające ograniczyć prawdopodobieństwo ich ponownego wystąpienia oraz skutki.

Aby analiza post-mortem pozwalała na skuteczne ograniczenie powtarzających się incydentów, proces przeglądu musi motywować zespoły do identyfikowania przyczyn głównych i ich usuwania. Konkretna metoda zależy od kultury zespołu. W Atlassian zdecydowaliśmy się na kombinację różnych sposobów, które sprawdzają się w przypadku naszych zespołów ds. reagowania na incydenty:

• Spotkania bezpośrednie mające pomagać w przeprowadzaniu odpowiedniej analizy i ustalaniu z zespołem, co wymaga naprawy.
• Zatwierdzanie analiz przez kierowników zespołów ds. dostaw i operacji motywujące zespoły do starannego działania.
• Zaprojektowane działania priorytetowe, którym przypisuje się ustalony poziom usług (ang. Service Level Objective, SLO) wynoszący 4 lub 8 tygodni w zależności od rodzaju usługi wraz z przypomnieniami i raportami gwarantującymi ich realizację.

Realizacja tego procesu i zapewnienie jego efektywności wymaga zaangażowania na wszystkich poziomach przedsiębiorstwa. Nasi inżynierzy techniczni i kierownicy wyznaczyli osoby zatwierdzające i poziom usług w związku z działaniami mającymi na celu rozwiązywanie zdarzeń w swoich obszarach. Ten system jedynie koduje ich decyzje i ma zapewnić możliwość ich egzekwowania.

Kiedy analiza jest potrzebna?

Przeprowadzamy analizy, którym przypisano znaczenie na poziomach 1 i 2. W innych przypadkach jest to dobrowolne.

Podczas rozwiązywania problemu lub bezpośrednio po tym osoba odpowiedzialna za analizę tworzy nowe zgłoszenie analizy.

Kto przeprowadza analizę?

Zespół ds. dostarczania usługi, która nie działa (zespół odpowiedzialny za „Nieprawidłowo działającą usługę” w zgłoszeniu zdarzenia), odpowiada za dokonanie analizy. Wybiera on osobę odpowiedzialną za analizę i przypisuje do niej zgłoszenie analizy.

• Właściciel analizy post-mortem prowadzi ją od utworzenia wersji roboczej i zatwierdzenia aż do momentu publikacji. Odpowiada on za jej ukończenie.
• Jedna lub kilka osób do tego wyznaczonych ocenia i zatwierdza analizę. Powinna również określić priorytety dotyczące działań kontrolnych na liście zadań.

Dysponujemy stroną Confluence, na której znajduje się lista osób zatwierdzających analizy (obowiązkowe i nieobowiązkowe) według grupy usług, która zasadniczo odpowiada produktom Atlassian (np. Bitbucket Cloud).

Jak śledzi się działania w ramach analizy?

W odniesieniu do każdego działania po analizie:

• Tworzymy zgłoszenie w systemie Jira na liście zadań zespołu, który za nie odpowiada. Wszystkie działania z zakresu analizy należy śledzić w systemie Jira.
• Tworzymy powiązanie z poziomu zgłoszenia analizy pod tytułem „Działanie priorytetowe” (dla przyczyn źródłowych) lub „Działanie ulepszające” (dla ulepszeń niezwiązanych z główną przyczyną).

Opracowujemy niestandardowe raporty, używając interfejsów programowania aplikacji Jira REST, w celu śledzenia liczby zdarzeń na każdym poziomie ważności, których przyczyn źródłowych nie usunięto w ramach działań naprawczych określonych w analizie. Kierownicy ds. technicznych w każdym dziale regularnie sprawdzają tę listę.

Proces analizy

Proces analizy obejmuje utworzenie zgłoszenia analizy, odbycie zebrania w tej sprawie, wychwycenie działań, uzyskanie zgody i (opcjonalnie) przekazanie informacji o uzyskanych wynikach.

Osoba odpowiedzialna za przeprowadzenie analizy musi wykonać poniższe działania:

1. Utworzyć analizę i powiązać ją ze zdarzeniem.
2. Edytować zgłoszenie analizy, zapoznać się z opisami w polach i je wypełnić.
3. Korzystając z techniki „5 × dlaczego”, przeanalizować łańcuch zdarzeń i ustalić rzeczywistą główną przyczynę incydentu.
4. Zaplanować zebranie dotyczące analizy. Zaprosić zespół ds. świadczenia usług, zespoły, których sprawa dotyczy, i osoby zainteresowane, korzystając z szablonu zaproszenia na zebranie.
5. Odbyć zebranie z zespołem i postępować zgodnie z poniższym harmonogramem zebrania.
6. Skontaktować się z odpowiedzialnymi kierownikami ds. opracowywania produktów, aby zostały podjęte działania zmierzające do wyeliminowania zdarzeń tej klasy.
7. Utworzyć zgłoszenie w systemie Jira na liście zadań zespołu, który za nie odpowiada. Utworzyć powiązanie z poziomu zgłoszenia analizy pod tytułem „Działanie priorytetowe” (dla przyczyn źródłowych) lub „Działanie ulepszające” (dla ulepszeń niezwiązanych z główną przyczyną).
8. Wyszukać odpowiednie osoby zatwierdzające w Confluence i dodać je w polu „Osoby zatwierdzające” analizy post-mortem.
9. Wybrać przejście „Wniosek o zatwierdzenie”, aby poprosić o zatwierdzenie ze strony wskazanych osób zatwierdzających. Do zgłoszenia zostanie automatycznie dodany komentarz zawierający instrukcje dla osób zatwierdzających.
10. Podejmij dalsze wymagane działania w celu zatwierdzenia analizy.
11. Po zatwierdzeniu analizy zostanie automatycznie utworzony szkic wpisu dotyczącego analizy na blogu w aplikacji Confluence, który można edytować i publikować. Poprzez publikowanie na blogu analiz można podzielić się swoimi doświadczeniami, co zwiększa przydatność analiz.

Po zakończeniu analizy działania są porządkowane przez zespół programistów w zależności od ich wagi, w ramach opracowywania standardowej listy zadań zgodnie ze SLO zespołu.

Zebrania dotyczące analizy

Sądzimy, że odbycie zebrania zespołu w celu omówienia wniosków pozwala dogłębniej przeanalizować główne przyczyny. Często zebranie odbywa się w formie wideokonferencji ze względu na rozproszenie członków zespołu, a czasem w grupach — jeśli zdarzenia dotyczą dużych grup ludzi.

Sugerowany porządek działań

1. Przypomnieć zespołowi, że analizy nie powinny dociekać winnych ani powodów.
2. Potwierdzić oś czasu zawierającą zdarzenia.
3. Potwierdzić główne przyczyny.
4. Ustalić działania, korzystając z metody „otwartego myślenia”: „Co możemy zrobić, aby zapobiec zdarzeniom tej klasy w przyszłości?”.
5. Zapytać zespół o to, co poszło dobrze, co mogło pójść lepiej i gdzie mieliśmy szczęście.

Szablon sugerowanej rezerwacji w kalendarzu:

Proszę, dołącz do mnie, żeby przeprowadzić analizę bez dociekania winy dotyczącą , gdzie .

Celem analizy jest zrozumienie wszystkich przyczyn głównych, udokumentowanie zdarzenia i wyłapanie powtarzających się sytuacji, aby móc wdrożyć skuteczne działania prewencyjne mające ograniczyć prawdopodobieństwo ich ponownego wystąpienia oraz skutki.

Podczas spotkania postaramy się ustalić główne przyczyny i zdecydować, jakie działania mogą je zminimalizować.

Jeśli na zebraniu nie jest obecny odpowiedzialny kierownik ds. programowania, należy unikać podejmowania konkretnych działań podczas zebrania, ponieważ nie jest to odpowiedni moment na podejmowanie decyzji dotyczących priorytetów. Pracownicy będą odczuwać presję do podjęcia działań bez potrzebnych informacji. Zamiast tego należy skontaktować się z odpowiedzialnymi kierownikami po zebraniu, aby uzyskać ich zapewnienie o planowanej realizacji priorytetowych działań.

Pola zgłoszenia analizy

Nasze zgłoszenie analizy zawiera dużą liczbę pól, aby zachęcić do gromadzenia wszystkich ważnych informacji na temat zdarzenia przed odbyciem zebrania dotyczącego analizy. Poniżej znajduje się kilka przykładów, jak wypełnić te pola.

Przyczyny główne i bezpośrednie

Gdy piszesz lub czytasz analizę, ważne, aby rozróżniać przyczyny bezpośrednie i główne.

• Przyczyny bezpośrednie doprowadziły do zdarzenia w bezpośredni sposób.
• Przyczyny główne to przyczyny w optymalnym punkcie łańcucha zdarzeń, w którym zmiana pozwoli zapobiec całej klasie zdarzeń tego typu.

Celem analizy post-mortem jest odkrycie głównych przyczyn i ustalenie, jak optymalnie zminimalizować ich skutki. Znalezienie tego optymalnego miejsca w łańcuchu zdarzeń to prawdziwa sztuka. Zastosowanie techniki, takiej jak 5 × dlaczego, pozwoli przeanalizować cały łańcuch i znaleźć główne przyczyny.

Oto kilka wybranych przykładów przyczyn bezpośrednich i głównych:

Kategorie przyczyn głównych i powiązane działania

Używamy tych kategorii, aby grupować główne przyczyny i omawiać odpowiednie działania wymagane dla każdej z nich.

Przyczyny główne z zależnościami

Gdy wystąpi zdarzenie dotyczące usługi ze względu na usterkę zależności, lokalizacja usterki i główna przyczyna zależą od tego, czy zależność pochodzi od firmy Atlassian czy innej, a także jakie są rozsądne oczekiwania odnośnie do działania zależności.

Jeśli jest to zależność pochodząca od firmy Atlassian, należy zadać sobie pytanie: „Jaki jest cel poziomu usług (SLO) usterki?”:

• Czy zależność spowodowała naruszenie SLO?
  • Usterka dotyczy zależności i konieczne jest podwyższenie poziomu jej niezawodności.
• Czy zależność była w ramach SLO, a mimo to wystąpiła awaria usługi?
  • Należy podnieść poziom niezawodności usługi.
• Czy dla zależności nie określono SLO?
  • Należy to zrobić!

W przypadku zależności innej firmy, należy zadać sobie pytanie „Jakie są nasze rozsądne oczekiwania* odnośnie do dostępności/utajenia itp. zależności innych firm?”.

• Czy zależność innej firmy przekroczyła nasze oczekiwania (w złym znaczeniu tego słowa)?
  • Nasze oczekiwania były nieprawidłowe.
    • Czy mamy pewność, że nie zdarzy się to ponownie? Np. Zapoznajemy się z analizą głównej przyczyny firmy i akceptujemy ją. W takim przypadku działanie dotyczy analizy głównej przyczyny.
    • A może musimy zmienić nasze oczekiwania? W takim wypadku działanie obejmuje zwiększenie niezawodności naszych produktów i dostosowanie oczekiwań.
    • Czy nasze dostosowane oczekiwania są nie do przyjęcia? W takim wypadku musimy jakoś usunąć rozdźwięk pomiędzy wymaganiami i rozwiązaniem, np. znaleźć innego dostawcę.
• Czy zależność innej firmy była zgodna z naszymi oczekiwaniami, a mimo to wystąpiła awaria usługi?
  • W takim wypadku Twoja usługa wymaga zwiększenia niezawodności.
• Czy naprawdę nie mamy oczekiwań?
  • Właściciel zależności strony trzeciej musi to ustalić i poinformować o tym zespoły, żeby wiedziały, w jaki poziom niezawodności muszą celować, aby wpasować się w ich usługi zależne.

* Dlaczego „oczekiwania”? Czy nie mamy zawartych umów SLA z innymi firmami? W rzeczywistości umowy SLA zawierane z innymi firmami nie są przydatne podczas ustalania usterki i działań minimalizujących skutki. Np. AWS nie publikuje prawie żadnej umowy SLA dla usługi EC2. Jeśli więc jesteśmy zależni od usług innych firm, musimy podjąć decyzję na temat poziomu niezawodności, dostępności, wydajności lub innych kluczowych wskaźników, którego możemy racjonalnie oczekiwać od nich.

Działania w ramach analizy

Sue Lueder i Betsy Beyer z firmy Google mają doskonałą prezentację i artykuł na temat działań z zakresu analizy, które wykorzystujemy w firmie Atlassian jako podpowiedź dla zespołu.

Przeczytaj dokładnie poniższe pytania, aby upewnić się, że analiza po zdarzeniu będzie zawierać rozwiązania długo- i krótkoterminowe:

„Zminimalizuj skutki przyszłych zdarzeń” i „Zapobiegaj przyszłym zdarzeniom” to najbardziej prawdopodobne źródła działań odnoszące się do głównej przyczyny. Upewnij się, żeby odnieść się do co najmniej jednego z nich.

Zatwierdzanie analiz

Firma Atlassian wykorzystuje przepływ zadań w narzędziu Jira obejmujący operację zatwierdzania w celu zapewnienia akceptacji analiz. Osoby zatwierdzające zazwyczaj są jednocześnie odpowiedzialne za usługi albo są to kierownicy odpowiedzialni za działanie usługi. Na zatwierdzenie analizy składają się poniższe elementy:

• Zatwierdzenie wyników analizy po zdarzeniu, w tym głównej przyczyny oraz
• Uznanie, że powiązane działania pod nazwą „Działanie priorytetowe” są dopuszczalnym rozwiązaniem głównej przyczyny.

Osoby zatwierdzające często wymagają dodatkowych działań lub zidentyfikowania łańcucha zdarzeń, do którego nie odnoszą się proponowane działania. Tym sposobem, w naszej ocenie, zatwierdzanie powoduje znaczne ulepszenie procesu analiz w firmie Atlassian.

W zespołach, w których ma miejsce mniej zdarzeń lub które zarządzają mniej złożoną infrastrukturą, zatwierdzanie analiz może nie być konieczne.

Analizy bez dociekania winy

Gdy coś pójdzie nie tak, naturalną tendencją jest poszukiwanie winnych. W interesie firmy Atlassian jest jej uniknięcie, dlatego, opracowując analizę, należy dążyć do celowego powstrzymania się od takich działań. Zakładamy, że nasz personel ma dobre intencje, i nigdy nie winimy ludzi za usterki. W ramach analizy należy uczciwie i obiektywnie prześledzić okoliczności, które doprowadziły do usterki, aby możliwe było znalezienie głównej przyczyny i zminimalizowanie jej skutków. Szukanie winnych naraża to zadanie na szwank, ponieważ:

• Gdy ludzie obawiają się o swoją pozycję w oczach współpracowników oraz o swoją przyszłą karierę, zazwyczaj w ich hierarchii najlepszy interes pracodawcy schodzi na dalszy plan, w związku z czym naturalnym zachowaniem jest przemilczenie lub ukrywanie prawdy, aby chronić swoje podstawowe potrzeby.
• Nawet jeśli osoba podjęła działania, które doprowadziły bezpośrednio do zdarzenia, nie należy pytać, dlaczego to zrobiła, ale dlaczego system umożliwił zrobienie tego lub spowodował, że osoba uznała działanie za prawidłowe.
• Obwinianie innych jest niegrzeczne, a powtarzane często, wzbudza w pracownikach strach i brak zaufania.

W naszych analizach wykorzystujemy te techniki, aby budować atmosferę wzajemnego zaufania:

• Spotkanie dotyczące analizy post-mortem należy rozpocząć od zakomunikowania, że nie ma ona na celu wskazywania winnych, i przedstawienia powodów takiego postępowania.
• Zamiast wymieniać nazwiska osób, należy odnosić się do pełnionych ról (np. dyżurujący specjalista ds. widżetów). (Jednocześnie przedstawiając fakty jasno i jednoznacznie).
• Zadbać o to, aby oś czasu analizy, łańcuch zdarzeń i działania w celu zminimalizowania skutków odnosiły się do systemów, procesu i ról, a nie osób.

Naszą inspiracją w zakresie analiz bez dociekania winy i użytecznej koncepcji „drugich poziomów” był nowatorski artykuł, którego autorem jest John Allspaw.