Analiza przyczyny głównej

1) Co to jest RCA i dlaczego jest potrzebne

Analiza przyczyny głównej jest ustrukturyzowanym procesem identyfikacji głównych przyczyn zdarzenia w celu zapobiegania nawrotom. W centrum - fakty, relacje przyczynowe i ulepszenia systemowe (procesy, architektura, testy), a nie wyszukiwanie winy.
Cele: zapobieganie nawrotom, zmniejszenie wskaźnika MTTR/incydentów, poprawa SLO, budowanie zaufania z organami regulacyjnymi i partnerami.

2) Zasady (Just Culture)

Żadnych zarzutów. Karamy nie ludzi, ale ryzykowne praktyki.
Faktyczność. Tylko sprawdzalne dane i artefakty.
E2E widok. Od klienta po dostawców.
Testowalność hipotez. Każde oświadczenie - z testem/eksperymentem.
Zamknięcie CAPA. Środki naprawcze i zapobiegawcze wraz z właścicielami i terminami.

3) Wejścia artefakty i przygotowanie

Linia czasu UTC: wykrywanie T0 → działania T + → Odzyskiwanie T +.
Dane dotyczące obserwacji: dzienniki, mierniki (w tym według kohorty), ślady, syntetyka, strona statusu.
Zmiany: wydania, flagi funkcji, konfiguracje, zdarzenia dostawcy.
Środowisko: wersje, hash artefakt, SBOM, tagi infrastrukturalne.
Podstawa incydentu: opis wpływu (SLO/SLA, klienci, obrót), podjęte decyzje, praca.
Łańcuch opieki: kto i kiedy zebrane/zmodyfikowane dowody (ważne dla zgodności).

4) Metody RCA: kiedy

1. 5 Dlaczego - szybko rozgryźć łańcuch przyczynowy dla wąskich problemów. Ryzyko: „zwiń” złożony system do linii.
2. Kość rybna - Kategoryzacja czynników jako Ludzie/Proces/Platforma/Polityka/Partner/Produkt. Przydatne na początku.
3. Analiza drzewa błędu (FTA) - odliczenie od zdarzenia do zestawów wywołujących (AND/OR). W przypadku awarii infrastruktury i drzew.
4. Wykres przyczynowy/łańcuch zdarzeń - wykres zależności z prawdopodobieństwem i wagą składki. Dobre dla mikroservices i zewnętrznych dostawców.
5. FMEA (Analiza trybów awarii i skutków) - Zapobieganie: tryby awarii, nasilenie (S), częstotliwość (O), wykrywalność (D), RPN = S × O × D.
6. Zmiana analizy - porównanie „jak było/jak się stało” (config diff, schemat, wersje).
7. Przegląd czynników ludzkich - kontekst decyzji ludzi (zmęczenie alarmowe, złe playbooki, przeciążenie).

Zalecane połączenie: Fishbone → Zmiana analizy → Wykres przyczynowy/FTA → 5 Dlaczego według kluczowych gałęzi.

5) Krok po kroku proces RCA

1. Zainicjować: wyznaczyć właściciela RCA, określić termin wydania raportu (na przykład 5 dni roboczych), zebrać zespół (IC, TL, Scribe, przedstawiciele dostawcy).
2. Zbierz fakty: linia czasu, wykresy, wydania, dzienniki, artefakty; Naprawić wersje i kontrolę kwoty.
3. Wpływ na mapę: które SLI/SLO zostały dotknięte, które kohorty (kraje, dostawcy, VIP).
4. Buduj hipotezy: podstawowe, alternatywne; Sprawdź, które są teraz możliwe do zweryfikowania.
5. Hipotezy testowe: odtwarzanie na scenie/symulacji/kanarka, analiza śladu, wstrzyknięcie usterki.
6. Określić korzeń i przyczyny: technologiczne, procesowe, organizacyjne.
7. Formularz CAPA: korekcyjny (prawidłowy) i zapobiegawczy (zapobiegawczy); metryki sukcesu i harmonogramy.
8. Uzgodnić i opublikować raport: wewnętrzna baza wiedzy +, w razie potrzeby, wersja zewnętrzna dla klientów/regulatora.
9. Sprawdź efekt: punkty kontrolne po 14/30 dni; zamykanie akcji.

6) Co liczy się jako „przyczyna korzeniowa”

• słabe flagi testów/funkcji, brakujące limity/wpisy, niejednoznaczna dokumentacja, nieprawidłowe domyślne, krucha architektura.
• Często jest to połączenie czynników (konfiguracja × brak bramy × ładunek × dostawca).

7) CAPA: środki naprawcze i zapobiegawcze

• kod/config fix, wzór rollback, zmiana limitów/timeouts, dodawanie indeksów, repliki/shading, redystrybucja ruchu, aktualizacja certyfikatu.

• testy (kontrakt, przypadki chaosu), wpisy (wskaźnik oparzeń, kworum syntetyki), polityka uwalniania (kanaryjska/niebiesko-zielona), GitOps dla konfiguracji, listy treningowe/kontrolne, duplikacja dostawcy, ćwiczenia DR.

Każda akcja: właściciel, termin, oczekiwany efekt, miernik weryfikacji (na przykład spadek wskaźnika awarii o X%, brak powtórzeń o 90 dni).

8) Weryfikacja hipotez i skutków

Eksperymenty: wtrysk usterki/chaos, ruch cieni, konfiguracje A/B, obciążenie prawdziwymi profilami.
Wskaźniki sukcesu: odzyskiwanie SLO, stabilizacja p95/p99, brak kolców błędów, redukcja MTTR, szybkość spalania i trend zero wznowienia przez 30 dni.
Punkty kontroli: D + 7, D + 30, D + 90 - przegląd wdrażania i wpływu CAPA.

9) Szablon raportu RCA (wewnętrzny)

1. Krótkie podsumowanie: co się stało, kiedy, kto dotknął.
2. Wpływ: SLI/SLO, użytkownicy, regiony, obroty/kary (jeśli istnieją).
3. Linia czasu (UTC): główne wydarzenia (wpisy, decyzje, wydania, poprawki).
4. Obserwacje i dane: wykresy, dzienniki, ślady, konfiguracje (diffs), statusy dostawcy.
5. Hipotezy i testy: przyjęte/odrzucone, odniesienia do eksperymentów.
6. Przyczyny: technologiczne, procesowe, organizacyjne.
7. Czynniki przyczyniające się: „dlaczego nie zauważył/nie zatrzymał”.
8. Plan CAPA: tabela działań z właścicielami/terminy/mierniki.
9. Zagrożenia i zagrożenia rezydualne: co jeszcze należy monitorować/testować.
10. Aplikacje: artefakty, linki, wykresy (lista).

10) Przykład (krótki, uogólniony)

Wydarzenie: sukces płatniczy na 35% o 19: 05-19: 26 (SEV-1).
Wpływ: 21 min e2e-SLO naruszone, 3 kraje dotknięte, zwroty/odszkodowania.
Powód 1 (te): Nowa wersja walidatora karty zwiększyła opóźnienie do 1. 2 s → timeouts do dostawcy.
Powód 2 (procent): nie było kanarka dla dostawcy „A”, wydanie było natychmiast 100%.
Powód 3 (org): próg alarmowy dotyczący SLI dla przedsiębiorstw nie obejmował określonego zakresu BIN (kohorty VIP).
CAPA: zwróć starą wersję walidatora; wprowadź kanaryjski 1/5/25%; dodać SLIs biznesowe przez kohorty BIN; uzgodnić awarię ponad 30% dla dostawcy „B”; Sprawa chaosu „powoli w górę rzeki”.

11) Metryki dojrzałości procesu RCA

Zakończenie CAPA na czas (% zamknięte w 30 dni).
Szybkość ponownego otwarcia (incydenty ponownie otwarte w ciągu 90 dni).
Wskaźnik awarii zmiany przed/po.
Odsetek incydentów, w których występują przyczyny ogólnoustrojowe (nie tylko „ludzki błąd”).
Badanie pokrycia nowych scenariuszy z RCA.
Czas wydania raportu (publikacja SLA).

12) Cechy regulowanych domen (fintech/iGaming, itp.)

Raportowanie na zewnątrz: klient/wersja regulacyjna raportu bez podania szczegółów, ale z planem zapobiegania powtórzeniom.
Dziennik audytu i niezmienność: przechowywanie artefaktów, podpisywane raporty, powiązanie z biletami, CMDB, dzienniki wydawania.
Dane użytkownika: depersonalizacja/maskowanie w dziennikach próbki.
Okresy wypowiedzenia: związane z umowami i przepisami (np. N godziny na początkowe zawiadomienie).

13) Anty-wzory

„Vasya jest winny” - zatrzymanie czynnika ludzkiego bez przyczyn systemowych.
Brak testów hipotezy - wnioski przez intuicję.
Zbyt ogólne RCA („usługa była przeciążona”) - brak konkretnych zmian.
Brak CAPA lub brak właścicieli/terminów - raport dla dobra raportu.
Ukrywanie informacji - utrata zaufania, niezdolność do szkolenia organizacji.
Przeciążenie metrykami non-SLO/business SLI.

14) Narzędzia i praktyki

Repozytorium RCA (wiki/baza wiedzy) z metadanymi: usługa, SEV, powody, CAPA, status.
Szablony i boty: generowanie ramki raportu z incydentu (linia czasu, wykresy, wydania).
Wykres przyczynowości: budowa mapy przyczynowo-zdarzeniowej (na przykład na podstawie kłód/śladów).
Katalog chaosu: skrypty do odtwarzania wcześniejszych incydentów na scenie.
Deski rozdzielcze „po RCA”: poszczególne widżety, co potwierdza efekt CAPA.

15) Lista kontrolna „gotowa do publikacji”

• Ramy czasowe i artefakty są kompletne i zweryfikowane.
• Przyczyny korzenia zidentyfikowane i udowodnione przez testy/eksperymenty.
• Przyczyny i przyczyny są oddzielone.
• CAPA zawiera właścicieli, terminy, mierzalne wskaźniki efektów.
• Istnieje plan weryfikacji w 14/30 dni.
• Wersja dla zewnętrznych zainteresowanych stron jest przygotowana (w razie potrzeby).
• Raport przeszedł przegląd techniczny/procentowy.

16) Sedno sprawy

RCA nie jest retrospektywny ze względu na formalność, ale mechanizm uczenia się dla systemu. Po zebraniu faktów, udowodnieniu związku przyczynowego, a CAPA są zablokowane w metrykach i testowane przez eksperymenty, organizacja staje się bardziej stabilna za każdym razem: SLO są bardziej stabilne, ryzyko nawrotu jest mniejsze, a użytkownik i zaufanie regulacyjne jest wyższe.