Close

Zarządzanie incydentami dla dynamicznych zespołów

Analizy zdarzeń

W przedsiębiorstwie Atlassian praktykujemy analizy bez dociekania winy, aby poznać i usunąć główną przyczynę każdego zdarzenia o znaczeniu plasującym się na poziomie 2. lub wyższym. Oto skrócona wersja naszej wewnętrznej dokumentacji opisującej, jak w przedsiębiorstwie Atlassian przeprowadzamy analizy.

Podręcznik zarządzania incydentami

Uzyskaj podręcznik w formie drukowanej lub jako plik PDF

Oferujemy limitowaną pulę drukowanych wersji naszego Podręcznika zarządzania incydentami, który wysyłamy za darmo. Możesz również pobrać wersję PDF.


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.

Pole

Instrukcje

Przykład

Streszczenie zdarzenia

Streść zdarzenie w kilku zdaniach. Opisz poziom ważności, powody wystąpienia zdarzenia i czas trwania jego skutków.

W godzinach , klientów doświadczyło następujących problemów: . Zdarzenie było wywołane przez wdrożenie o godzinie . Wdrożenie obejmowało zmianę kodu w celu . Błąd we wdrożeniu spowodował .

Zdarzenie zostało wykryte przez . Zminimalizowaliśmy skutki zdarzenia poprzez .

Zdarzenie dotknęło X% klientów.

W związku z tym incydentem zgłoszono/zamieszczono .

Przygotowanie

Opisz okoliczności, które doprowadziły do zdarzenia, na przykład przed zmianami, które spowodowały wystąpienie ukrytych błędów.

O w dniu () wprowadzono zmianę w , aby… . Zmiana spowodowała… .

Błąd

Opisz, co nie zadziałało zgodnie z oczekiwaniami. Dołącz zrzuty ekranowe ważnych wykresów lub danych przedstawiających usterkę.

Wysłano nieprawidłowo odpowiedzi w liczbie na X% żądań w okresie .

Wpływ

Opisz, co wewnętrzni i zewnętrzni klienci zobaczyli podczas zdarzenia. Dołącz informację o liczbie zgłoszeń do pomocy technicznej.

Przez pomiędzy w dniu miało miejsce zdarzenia .

Jego skutki dotknęły klientów w liczbie (X% ze wszystkich klientów ), którzy napotkali .

Przesłano zgłoszenia do pomocy technicznej i opublikowano posty w serwisach społecznościowych w liczbie .

Wykrycie

Jak i kiedy firma Atlassian wykryła zdarzenie?

Jak można było skrócić czas potrzebny na wykrycie? W ramach ćwiczenia na myślenie: co byś zrobiła/a, aby skrócić ten czas o połowę?

Zdarzenie zostało wykryte, gdy został uruchomiony i wezwano . Następnie konieczne było wezwanie , ponieważ poprzednia osoba lub zespół nie posiadały usługi dokonującej zapisu na dysku, co opóźniło reagowanie o .

zostanie wdrożone przez w celu .

Odpowiedź

Kto zareagował, kiedy i jak? Czy wystąpiły opóźnienia lub utrudnienia podczas reagowania?

Po wezwaniu o godzinie 14:34 czasu UTC specjalista z firmy KITT zgłosił się online o godzinie 14:38 w pokoju poświęconym omawianiu zdarzeń. Jednak wezwany specjalista nie miał wystarczających informacji w autoskalerze Escalator, dlatego wysłano dodatkowe powiadomienie o godzinie 14:50 i wezwano do pokoju starszego specjalistę z firmy KITT o godzinie 14:58.

Odzyskiwanie

Opisz, jak i kiedy usługa została przywrócona. Jak dotarłeś/dotarłaś do punktu, w którym wiadomo było, w jaki sposób zminimalizować skutki zdarzenia?

Dodatkowe pytania, które należy zadać w zależności od scenariusza: Jak można było skrócić czas potrzebny na zminimalizowanie skutków? W ramach ćwiczenia na myślenie: co byś zrobiła/a, aby skrócić ten czas o połowę?

Odzyskiwanie odbyło się w ramach trójstopniowej odpowiedzi:

  • Zwiększenie rozmiaru kompilacji instancji EC2 ASG w celu zwiększenia liczby dostępnych węzłów, aby zaspokoić obciążenie i ograniczyć prawdopodobieństwo zaplanowania zbyt dużej liczby zasubskrybowanych węzłów.

  • Zablokowanie aktoskalera Escalator, aby zapobiec agresywnemu ograniczeniu klastra.

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

Oś czasu

Przygotuj szczegółową oś czasu incydentu, zawierającą zdarzenia uporządkowane w kolejności chronologicznej ze znacznikami czasu i strefami czasowymi.

Rozmieścić wprowadzenie, moment rozpoczęcia skutków, czas wykrycia, eskalowanie zdarzenia, decyzje i zmiany oraz moment zakończenia.

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

11:48 - Ukończono uaktualnienie K8S 1.9 płaszczyzny kontrolnej
12:46 - Ukończono uaktualnienie Goliath do wersji 1.9, obejmujące autoskaler klastrów i instancję programu planującego BuildEng
14:20 - Dział projektowania kompilacji 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 konkretny węzeł jako nieuwzględniany w planowaniu
14:49 - Program planujący BuildEng 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 do standardowego programu planującego
15:34 - Program BuildEng zgłasza awarię 300 strąków (ang. pods)
16:00 - Program BuildEng niszczy wszystkie kompilacje, które uległy awarii z raportem OutOfCpu
16:13 - Program BuildEng zgłasza, że usterki powracają w przypadku nowych kompilacji, co oznacza, że nie były przejściowe .
16:30 - Zespół KITT uznaje usterki za zdarzenie i postępuje z nimi jako ze zdarzeniem.
16:36 - Zespół KITT blokuje autoskaler Escalator, aby zapobiec usunięciu wyliczeń przez autoskaler w celu zminimalizowania problemu.
16:40 - Zespół KITT potwierdza, że grupa ASG jest stabilna, obciążenie klastra jest normalne, a skutki dla klientów usunięte.

5W (pięć pytań dlaczego)

Użyć techniki identyfikowania głównej przyczyny.

Rozpocząć od skutków i spytać, dlaczego zdarzenie miało miejsce oraz dlaczego spowodowało takie skutki. Kontynuować zadawanie pytań o przyczyny, aby odnaleźć główną przyczynę.

Udokumentować pytania „dlaczego” w postaci listy tutaj lub w diagramie dołączonym do zgłoszenia.

  1. Usługa przestała działać, ponieważ baza danych była zablokowana.

  2. Ponieważ wystąpiło zbyt dużo wpisów w bazie danych.

  3. Ponieważ dokonano zmiany usługi i nie spodziewano się wzrostu.

  4. Ponieważ nie mamy skonfigurowanego procesu projektowania na potrzeby sytuacji, gdy powinniśmy załadować zmiany testowe.

  5. Nigdy nie przeprowadziliśmy testów obciążenia i osiągamy nowe poziomy skali.

Główna przyczyna

Jaka była główna przyczyna? Jest to kwestia wymagająca zmiany, aby uniemożliwić ponowne występowanie zdarzeń tej klasy.

Błąd przetwarzania puli połączeń doprowadził do wycieku połączeń w sytuacjach awaryjnych w połączeniu z brakiem wglądu w stan połączeń.

Kontrola listy zadań

Czy Twoja lista zadań zawiera elementy, które mogłyby zapobiec zdarzeniu lub znacznie ograniczyć jego skutki? Jeśli tak, dlaczego ich nie zrealizowano?

Dokonanie uczciwej oceny w tym punkcie pomaga wyjaśnić wcześniejsze decyzje dotyczące priorytetów i ryzyka.

Nieszczególnie. Udoskonalenia w zakresie typowania przepływu były znanymi, ciągłymi zadaniami, w odniesieniu do których obowiązywały rytuały (np. dodanie typów przepływów podczas zmiany/tworzenia pliku). Dokonano zgłoszeń dotyczących naprawy testów integracji, jednak były one nieskuteczne.

Powtarzanie się zdarzeń

Czy to zdarzenie (mające tę samą główna przyczynę) miało już miejsce wcześniej? Jeśli tak, dlaczego zdarzyło się ponownie?

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

Wyciągnięte wnioski

Czego się nauczyliśmy?

Omów, co poszło dobrze, co mogło pójść lepiej i gdzie udało nam się znaleźć możliwości wprowadzenia ulepszeń.

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

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

  3. 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

Co zamierzamy zrobić, aby nie dopuścić do ponownego wystąpienia incydentu tej klasy? Kto podejmie działania i kiedy je zakończy?

Utwórz łącza do zgłoszeń pod tytułem „Działanie priorytetowe”, aby monitorować każde działanie.

  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

  4. Duże migracje wymagają koordynacji, ponieważ usługi AWS ES nie są skalowane automatycznie.

  5. Sprawdzić, czy wyszukiwanie w rozwiązaniu Stride jest nadal klasyfikowane jako warstwa 2.

  6. Wysłać zgłoszenie do wiersza against pf-directory-service, aby wymusić częściową usterkę zamiast pełnej, gdy zawiedzie wiersz xpsearch-chat-searcher.

  7. Alert w usłudze Cloudwatch w celu zidentyfikowania problemu związanego z dużą liczbą operacji we/wy w klastrze ElasticSearch.


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:

Scenariusz Przyczyna bezpośrednia i działanie Główna przyczyna Minimalizowanie skutków przyczyny głównej

Usługi ekipy „Red Dawn” narzędzia Stride nie mają skonfigurowanych monitorów Datadog ani alertów dotyczących tych usług dla osób pełniących dyżury domowe bądź nie zostały poprawnie skonfigurowane.

Członkowie zespołu nie skonfigurowali opcji monitorowania i powiadamiania dla nowych usług.

Skonfiguruj te usługi.

Nie istnieje proces uruchamiania nowych usług, który obejmuje monitorowanie i wysyłanie powiadomień.

Utworzyć proces ###zabezpieczania nowych usług i pokazać zespołowi, jak go przeprowadzać.

Krok nieprzydatny w przeglądarce IE11 ze względu na uaktualnienie edytora tkanin, który nie działa w tej wersji przeglądarki.

Uaktualnienie zależności.

Przywróć uaktualnienie.

Brak testów zgodności przeglądarek.

Zautomatyzuj ciągłe testowanie zgodności przeglądarek.

Dzienniki z systemu Micros EU nie docierały do usługi logowania.

Rola przypisana do mikr, aby wysyłać je wraz z dziennikami była nieprawidłowa.

Poprawić rolę.

Nie wiemy, kiedy logowanie z poziomu środowiska nie działa.

Dodać monitorowanie i powiadamianie o brakujących dziennikach dla każdego środowiska.

Problem spowodowany wcześniejszym zdarzeniem w usłudze AWS; węzły Confluence Vertigo wyczerpały pulę połączeń do mediów, co doprowadziło do sporadycznych błędów załączników i multimediów.

Awaria usługi AWS.

Uzyskaj analizę dotyczącą usługi AWS.

Błąd przetwarzania puli połączeń aplikacji Confluence doprowadził do wycieku połączeń w stanach awaryjnych, w połączeniu z brakiem wglądu w stan połączeń.

Usunąć błąd i dodać monitorowanie, które umożliwi wykrywanie podobnych sytuacji w przyszłości zanim ich skutki będą odczuwalne.


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.

KATEGORIA

Definicja

Co należy z tym zrobić?

Błąd

Zmiana kodu wprowadzona przez firmę Atlassian (jest to konkretny rodzaj zmiany)

Przetestować. Przeprowadzić „test kanarka”. Przeprowadzić stopniowe wdrożenia i obserwować je. Użyć flag funkcji. Porozmawiać ze specjalistą ds. jakości.

Zmiana

Zmiana wprowadzona przez firmę Atlassian (inna niż kod)

Poprawić system wprowadzania zmian, np. analizy zmian lub procesy zarządzania zmianami. Wszystko, co znajduje się obok kategorii Problem ma również zastosowanie tutaj.

Skaluj

Niepowodzenie podczas skalowania (np. ograniczenia wysyłania ślepego sygnału do zasobów lub brak planowania przepustowości)

Jakie są ograniczenia w zakresie zasobów na potrzeby świadczenia usług? Czy są one monitorowane i czy są wysyłane powiadomienia? W przypadku braku planu przepustowości, należy takowy sporządzić. Jeśli istnieje taki plan, jakie nowe ograniczenie trzeba brać pod uwagę?

Architektura

Niezgodność architektury z warunkami operacyjnymi

Przeanalizować strukturę. Czy konieczna jest zmiana platform?

Zależność

Usterka usługi innej firmy (innej niż Atlassian)

Czy zarządzasz ryzykiem wystąpienia usterki usługi innej firmy? Czy podjęliśmy decyzje biznesowe w celu zaakceptowania ryzyka czy musimy zaplanować konieczność minimalizowania skutków? Zobacz „Główne przyczyny wraz z zależnościami” poniżej.

Nieznany

Trudne do określenia (podjęte działania przyczynią się do zwiększenia możliwości diagnozowania)

Zwiększyć możliwość obserwowania działania systemu poprzez dodanie logowania, monitorowania, debugowania itp.


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.

KATEGORIA Pytanie, które należy zadać Przykłady

Badanie zdarzenia

„Co spowodowało to zdarzenie i dlaczego?” Ostatecznym celem jest ustalenie głównych przyczyn.

analiza dzienników, tworzenie diagramu ścieżki żądania, analiza heap dumpów

Minimalizowanie skutków zdarzenia

„Jakie natychmiastowe działania podjęliśmy, aby rozwiązać to zdarzenie i nim zarządzać?”

wstrzymanie, przypadkowe wybieranie, wymuszanie konfiguracji, komunikacja z użytkownikami, których dotyczy zdarzenie

Naprawianie szkód wywołanych zdarzeniem

„Jak usunęliśmy bezpośrednie lub uboczne szkody wynikające z tego zdarzenia?”

przywracanie danych, naprawa urządzeń, usunięcie przekierowania ruchu sieciowego

Wykrywanie przyszłych zdarzeń

„Jak możemy skrócić czas potrzebny na skuteczne wykrycie posobnej usterki?”

monitorowanie, powiadamianie, kontrole wiarygodności na wejściu/wyjściu

Minimalizowanie skutków przyszłych zdarzeń

„Jak możemy zmniejszyć wagę lub czas trwania podobnych zdarzeń w przyszłości?”

„Jak możemy ograniczyć procent użytkowników dotkniętych usterką tej klasy, gdy wydarzy się następnym razem?”

łaskawa degradacja, pomijanie wyników, których znaczenie nie jest krytyczne, zaniechanie otwarcia, rozbudowanie bieżących praktyk z użyciem pulpitów lub podręczników strategii, zmiany w zakresie przetwarzania zdarzeń

Zapobieganie przyszłym zdarzeniom

„Jak możemy zapobiec ponownemu wystąpieniu tego typu usterki?”

ulepszenia w zakresie stabilności kodu podstawowego, bardziej dokładne testy modułów, weryfikacja poprawności danych wejściowych i niezawodności w warunkach występowania błędów, zmiany dotyczące udostępniania usług

Korzystamy także z porad pań Lueder i Beyer na temat formułowania działań w ramach analizy.

Formułowanie działań w ramach analizy:

Prawidłowe sformułowanie działań w ramach analizy może ułatwić ich realizację, zapobiegając opóźnieniom wynikającym z niewykonalności lub prokrastynacji. Dopracowane działanie w ramach analizy powinno posiadać następujące cechy:

Wykonalność: Każde działanie należy zdefiniować zdaniem rozpoczynającym się od czasownika. Rezultatem działania powinien być użyteczny wynik, a nie proces. Na przykład: „Stwórz listę krytycznych zależności” to odpowiednie działanie w odróżnieniu od zdania „Zbadaj zależności”.

Szczegółowość: Określ zakres każdego działania jak najdokładniej, jasno definiując, co należy wykonać, a czego nie.

Ustalone granice: Sformułuj każde działanie w taki sposób, aby wiadomo było, kiedy jest zakończone, a kiedy jest otwarte lub trwa.

Od... Do...

Zbadać proces monitorowania dla tego scenariusza.

(Wykonalność) Dodać opcje powiadamiania dla wszystkich przypadków, gdy w usłudze wystąpi >1% błędów.

Naprawić zdarzenie, które spowodowało przestój.

(Szczegółowość) Zająć się nieprawidłowym kodem pocztowym wprowadzanym w formularzu adresu użytkownika.

Zadbać, aby inżynier sprawdził, czy da się przetworzyć schemat bazy danych przed uaktualnieniem.

(Ustalone granice) Dodać automatyczną kontrolę przed wysłaniem dla zmian schematów.


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.