Analiza głównej przyczyny — 5 Whys
Streszczenie
Analiza głównej przyczyny metodą 5 Whys to uporządkowana technika rozwiązywania problemów, w której zaczynasz od określenia problemu i zadajesz pytanie "Dlaczego?" pięć razy z rzędu. Każda odpowiedź staje się podstawą następnego pytania. Celem jest wyjście poza objawy i ujawnienie leżącej u podstaw awarii procesu lub systemu, którą można faktycznie naprawić.
Kto może z niej korzystać
Zespoły produktowe i inżynieryjne
Zespoły operacyjne i DevOps
Zespoły obsługi klienta i serwisu
Kierownicy projektów
Zespoły zapewniania jakości
Każdy, kto bada powtarzające się problemy lub incydenty
Jak tego używać
Napisz jasny opis problemu — co się wydarzyło, kiedy i jaki był tego wpływ.
Zadaj pytanie „Dlaczego to się stało?” i zapisz odpowiedź (Odpowiedź 1).
Zadaj pytanie „Dlaczego wydarzyła się Odpowiedź 1?” i zapisz odpowiedź (Odpowiedź 2).
Powtórz dla Odpowiedzi 3, 4 i 5.
Przerwij, gdy dojdziesz do przyczyny, którą możesz usunąć zmianą procesu lub systemu — to jest Twoja przyczyna podstawowa.
Zdefiniuj działania naprawcze: przypisz każdemu działaniu osobę odpowiedzialną i termin wykonania.
Wskazówka: dobra przyczyna podstawowa wskazuje na proces lub system, a nie na osobę. Jeśli Twoja odpowiedź to czyjeś imię, zapytaj „dlaczego” jeszcze raz.
Przykład
Opis problemu: Strona realizacji zamówień była niedostępna przez 3 godziny 12 sierpnia — około 18 000 USD utraconych zamówień i ponad 40 zgłoszeń do wsparcia. (Zbadano 13 sierpnia przez zespół platformy.)
Dlaczego 1: Serwer płatności wyczerpał dostępną pamięć i uległ awarii.
Dlaczego 2: W usłudze płatności występuje wyciek pamięci.
Dlaczego 3: Wydanie z 8 sierpnia nie zamyka starych połączeń z bazą danych.
Dlaczego 4: Wydanie nie było wcześniej testowane pod obciążeniem przed wdrożeniem.
Dlaczego 5: Lista kontrolna wydania nie zawiera kroku testów wydajności.
Przyczyna źródłowa: Proces wydania nie zawiera obowiązkowego kroku testów obciążeniowych/wydajnościowych.
Działania korygujące:
Dodaj zautomatyzowany test obciążeniowy do CI pipeline (lider DevOps, 30 sierpnia)
Ustaw alerty pamięci przy 80% wykorzystania (zespół SRE, 22 sierpnia)
Zaktualizuj listę kontrolną wydania i przeszkol zespół (kierownik zespołu inżynierskiego, 20 sierpnia)
Pozdrawiam!
Khawaja Rizwan
