Plansza do analizy bezbłędnej post mortem

Ten „bezwinny” szablon Post-Mortem pomaga zebrać informacje o incydentach, które miały miejsce w produkcji. Przestrzeganie tego procesu oznacza, że inżynierowie, których działania przyczyniły się do wypadku, mogą dostarczyć szczegółowy opis:

• jakie działania podjęli i o której godzinie,

• jakie skutki zaobserwowali,

• oczekiwania, które mieli,

• założenia, które przyjęli,

• ich zrozumienie osi czasu wydarzeń w miarę ich występowania.

• i że mogą podać taki szczegółowy opis bez obawy przed karą lub represjami.

Blameless postmortem obejmuje następujące sekcje

Krok 1. Podsumowanie (wypełnij przed spotkaniem)

Ogólny zarys zgłoszenia, koncentrujący się na tym, co jest obecnie znane i jaki wpływ miało to na klienta. Pozostań przy jednym lub dwóch zdaniach.

Krok 2. Wstępna oś czasu (przed wypełnieniem przed spotkaniem)

Orientacyjna oś czasu zgłoszenia. W zależności od tego, jak szybko rozwijało się zgłoszenie, oś czasu może obejmować od kilku minut do kilku godzin do kilku dni. Jeśli Twoim głównym celem jest poprawa czasu reakcji zespołu w sytuacjach awaryjnych, powinieneś zadbać o to, aby było to mierzone do sekundy.

Podczas rejestrowania osi czasu, upewnij się, aby uwzględnić:

• Kiedy zgłoszenie zostało zarejestrowane i przez kogo/jakiego procesu

• Jakie działania zostały podjęte

• Kiedy komunikacja była realizowana do i z zespołu

Pomysły na usunięcie skutków

• Kiedy spotykasz się, aby omówić zgłoszenie, zaproś wszystkich, którzy pracowali nad zgłoszeniem. Obejmuje to zespół pomocy technicznej oraz członków zespołu obsługi klienta, którzy mogli być zaangażowani.

• Przejrzyj podsumowanie, przeanalizuj harmonogram i dodaj brakujące części, a następnie przejdź do pomysłów na remediację.

• Te pytania są sformułowane, aby pomóc zespołowi wziąć odpowiedzialność za problem. Istnieją pewne problemy, które wydają się być poza kontrolą zespołu (centrum danych traci zasilanie, itp.). Ale nawet w takich wydarzeniach zespół może wciąż poprawić swoją reakcję na katastrofę.

Krok 3. Wykrywanie – Jak możemy wykryć ten problem lub podobny szybciej?

Przyjmij, że ten problem lub bardzo podobny wystąpi ponownie. Jak zespół pomocy może szybciej wykryć ten problem i znaleźć go zanim zrobi to klient?

Krok 4. React – Jak możemy poprawić naszą reakcję na takie zgłoszenia?

Przyjmijmy, że zgłoszenie zostało zgłoszone. Jak szybka była reakcja? Czy stracono minuty, gdy ludzie wysyłali e-maile, próbując nakłonić kogoś do zajęcia się problemem?

Kiedy następnym razem pojawi się ten problem, jak zespół może zareagować szybciej lub w bardziej zorganizowany sposób?

Krok 5. Szybkie rozwiązanie – Jak szybciej zatamować krwawienie?

Czy gdy to się powtórzy, mamy gotowe rozwiązanie dla klienta, które pozwoli zmniejszyć wpływ problemu?

Jeśli to coś, co pogarsza się z czasem (jak atak DDOS), czy mamy szybki sposób na zamknięcie dopływu danych, podczas gdy ustalamy przyczynę źródłową?

Krok 6. Zapobieganie – Jak możemy zapobiec lub zmniejszyć wpływ problemów w przyszłości?

To często jedyne pytanie, które zespoły zadają na spotkaniach postmortem. To ważne pytanie i powinieneś spędzić tutaj dużo czasu. Jednak jeśli ograniczasz się do pytania tylko o to, jak zapobiec zgłoszeniu, unikasz wzięcia odpowiedzialności za rzeczy, które są pod twoją kontrolą (jak sposób, w jaki wykrywasz, reagujesz czy szybko naprawiasz zgłoszenie).

Podczas przeprowadzania burzy mózgów nie ograniczaj się do rozwiązań technicznych. Lepsze monitorowanie, lepsze ścieżki komunikacji, lepsze szkolenia, upewnianie się, że osoby w dziale obsługi klienta znają osoby w dziale pomocy produkcyjnej po imieniu itp.

Krok 7. Inne obszary ryzyka – Jakie inne obszary mają tę samą podatność?

Każde zgłoszenie jest wskazówką, gdzie system jest słaby. Prawdopodobnie na każde zgłoszenie, które znajdziesz, przypadają dziesiątki ukrytych w cieniu, czekających na odkrycie.

Tak jak, gdybyś zobaczył mysz w swojej kuchni. Nie masz problemu z „myszą”, tylko z „myszami”.

Istnieją prawdopodobnie inne części systemu, które dzielą te same założenia projektowe lub w niektórych przypadkach ten sam kod (nie żeby ktoś kiedykolwiek kopiował/wklejał kod).

Poświęć kilka minut na przeprowadzenie burzy mózgów nad innymi miejscami, które są podatne w podobny sposób.

Kiedy zespoły są zestresowane i przemęczone, pomijają ten krok. Uważam, że jest to najważniejsze pytanie, które należy zadać, aby wprowadzić zespół w proaktywny sposób myślenia i zmniejszyć występowanie problemów w przyszłości.

Krok 8. Kolejne Kroki (Działania)

Po zidentyfikowaniu wszystkich możliwych działań, które możesz podjąć, aby poprawić wykrywanie, reakcję, szybkie naprawy i zapobieganie zgłoszeniom… oraz po znalezieniu innych obszarów aplikacji wymagających uwagi… przejdź do podejmowania decyzji, jakie działania wybrać.

To, jak ustalisz priorytety, zależy od Ciebie. Mam jednak kilka rad.

Uzyskaj nazwę i datę dla każdego działania, które planujesz podjąć przed opuszczeniem spotkania.

Jeśli ktoś na spotkaniu jest chętny do podjęcia się jednego z działań, zachęć go do tego, nawet jeśli uważasz, że może to nie być najważniejsza kwestia do rozwiązania.

Nazwy i daty

Ogólnie stwierdziłem, że zespoły cieszą się z tego ćwiczenia (pod warunkiem, że możesz stworzyć środowisko bez obwiniania dla spotkania). Lubią analizować problem i przeprowadzać burzę mózgów nad rozwiązaniami. Jednak wszyscy czują się zajęci i przepracowani. Jeśli to spotkanie nie zakończy się przypisaniem właścicieli i terminów do rzeczy, które trzeba wykonać, istnieje duże prawdopodobieństwo, że żadne z usprawnień się nie wydarzy.

Co się stanie, to że za 3 tygodnie, kiedy ten sam problem pojawi się na produkcji (ale tym razem na większą skalę), ktoś powie: „O tak, rozmawialiśmy o naprawieniu tego.” Nie najlepsze miejsce do przebywania.

Aby temu przeciwdziałać, po prostu upewnij się, że przy każdej akcji, którą grupa chce podjąć, znajduje się imię i data.

Oparte na planszy do moratorium postmortem Davida Frinka.