RCA incydentu technicznego — od objawu do trwałej poprawki

Oddziel przywrócenie usługi od wyjaśnienia przyczyny#

Podczas incydentu priorytetem jest ograniczenie wpływu: przełączenie ruchu, restart procesu, wyłączenie wadliwej funkcji albo rollback. Te działania nie muszą być ostatecznym rozwiązaniem. Ich celem jest stabilizacja.

RCA zaczyna się po zabezpieczeniu usługi, gdy można analizować bez presji natychmiastowego przywrócenia. W dokumencie wyraźnie rozróżnij:

• mitygację — co przywróciło działanie,
• przyczynę — jaki mechanizm doprowadził do awarii,
• poprawkę trwałą — co usuwa lub kontroluje mechanizm,
• prewencję — co zmniejsza prawdopodobieństwo albo czas wykrycia.

Restart, który „pomógł”, jest faktem. Nie jest jeszcze wyjaśnieniem.

Zbuduj oś czasu z zegarów, którym można ufać#

Oś czasu powinna być oparta na logach, metrykach, trace, ticketach i działaniach operatorów. Zanim połączysz zdarzenia, sprawdź strefy czasowe oraz synchronizację NTP. Log aplikacji w UTC i zgłoszenie klienta w IST mogą wyglądać jak dwie różne awarie.

Dla każdego wpisu zapisz:

• czas i strefę,
• źródło dowodu,
• zdarzenie,
• wpływ lub zmianę stanu,
• poziom pewności.

Przykład:

Chronologia pomaga znaleźć korelację, ale sama korelacja nie dowodzi przyczynowości.

Fakty, hipotezy i założenia powinny być oznaczone#

W trakcie incydentu pojawia się wiele interpretacji. Zapis „baza była przeciążona” może być faktem, jeśli istnieje metryka CPU i wait events, albo hipotezą wynikającą z timeoutów aplikacji.

Używaj trzech kategorii:

• potwierdzony fakt — wsparty konkretnym dowodem,
• hipoteza — możliwy mechanizm wymagający testu,
• założenie — informacja przyjęta tymczasowo z powodu braku danych.

Następnie dla każdej hipotezy określ test falsyfikujący. Jeśli sądzisz, że firewall blokował RTP, capture na obu interfejsach powinien pokazać, czy pakiet dochodził i gdzie znikał. Jeśli hipoteza nie może zostać obalona żadnym testem, jest zbyt ogólna.

Opisz mechanizm awarii jako łańcuch#

„Błędna konfiguracja” jest słabą root cause. Lepszy opis pokazuje, jak konkretna wartość wywołała efekt:

nowa reguła routingu
→ nie obejmowała połączeń przekierowanych
→ PAI zawierał numer wewnętrzny
→ operator odrzucał INVITE kodem 403
→ połączenia forwardowane nie dochodziły do celu

Łańcuch powinien łączyć zmianę lub warunek z obserwowanym wpływem. Każda strzałka wymaga dowodu albo jasno opisanej inferencji.

Często nie ma jednej przyczyny. Techniczny defekt mógł istnieć od dawna, ale incydent pojawił się dopiero po zmianie ruchu. Wtedy warto rozdzielić:

• trigger,
• latent defect,
• contributing factors,
• brakujące guardraile.

Pytanie „dlaczego?” ma prowadzić do kontroli, nie do osoby#

Metoda „5 Why” jest użyteczna, jeśli nie kończy się na „administrator popełnił błąd”. Człowiek działa w systemie procesów, narzędzi i informacji. Bardziej użyteczne pytania:

• Dlaczego konfiguracja mogła zostać wdrożona bez testu tej ścieżki?
• Dlaczego monitoring nie wykrył różnicy przed klientem?
• Dlaczego środowisko testowe nie odzwierciedlało produkcji?
• Dlaczego rollback wymagał ręcznej rekonstrukcji?
• Dlaczego dokumentacja nie zawierała zależności?

Celem jest poprawa systemu, nie znalezienie ostatniej osoby dotykającej konfiguracji.

Oceń wpływ liczbowo i jakościowo#

Wpływ powinien odpowiadać na pytania biznesowe:

• ilu użytkowników lub klientów dotyczył problem,
• jakie funkcje były niedostępne,
• od kiedy do kiedy,
• czy doszło do utraty lub opóźnienia danych,
• czy wystąpiło ryzyko bezpieczeństwa lub zgodności,
• jak działały kanały awaryjne.

Jeżeli nie ma dokładnej liczby, podaj przedział i sposób estymacji. Unikaj fałszywej precyzji. „Około 18–25% prób połączeń na gatewayu B” jest uczciwsze niż liczba wyliczona z niepełnych CDR bez wyjaśnienia.

Poprawka wymaga testu regresyjnego#

Działanie „zaktualizować konfigurację” jest niekompletne. Powinno zawierać:

• dokładny zakres zmiany,
• właściciela,
• termin,
• kryterium sukcesu,
• test przed wdrożeniem,
• test po wdrożeniu,
• sposób rollbacku.

Dla błędu SIP test może sprawdzać konkretne nagłówki na obu legach. Dla aplikacji test automatyczny powinien odtworzyć dane wejściowe, które wcześniej wywoływały błąd. Dla infrastruktury można dodać policy check w CI.

Działania podziel na:

• natychmiastowe,
• krótkoterminowe,
• strategiczne.

Nie każde strategiczne działanie musi być wykonane od razu, ale powinno mieć świadomą decyzję i właściciela.

Monitoring ma wykrywać wpływ i mechanizm#

Alert na CPU 90% może być przydatny, lecz użytkownik odczuwa błąd funkcji. Po incydencie oceń dwie warstwy:

• symptom monitoring — dostępność, błędy, opóźnienie, skuteczność połączeń,
• cause monitoring — kolejki, pool saturation, utrata RTP, liczba auth failures, stan repliki.

Symptom alert mówi, że klient ma problem. Cause alert pomaga zareagować wcześniej. Oba są potrzebne.

Alert powinien mieć runbook: co sprawdzić, jakie wykresy otworzyć, jak rozpoznać fałszywy alarm i kiedy eskalować. Bez tego monitoring tylko szybciej informuje o chaosie.

Struktura dokumentu RCA#

Praktyczny szablon:

1. Podsumowanie dla osób nietechnicznych.
2. Zakres i wpływ.
3. Oś czasu.
4. Detekcja i reakcja.
5. Fakty techniczne.
6. Mechanizm przyczynowy.
7. Contributing factors.
8. Mitygacja.
9. Poprawka trwała i dowód weryfikacji.
10. Działania prewencyjne z właścicielami.
11. Czego nie wiemy i jakie dane trzeba dodać.
12. Załączniki: logi, trace, wykresy i commity.

Dokument powinien być wystarczająco precyzyjny, aby inna osoba mogła zrozumieć tok dowodowy, ale nie powinien kopiować tysięcy linii logów. Załącz dowody i wskaż istotne fragmenty.

Czerwone flagi słabego RCA#

• przyczyna jest opisana jako „błąd ludzki” bez analizy systemu,
• dokument nie odróżnia mitygacji od poprawki,
• brak dowodu łączącego przyczynę z objawem,
• działania to wyłącznie „monitorować uważniej” lub „zachować ostrożność”,
• nie ma właścicieli i terminów,
• poprawka nie ma testu regresyjnego,
• oś czasu miesza strefy czasowe,
• dokument ukrywa niepewność zamiast ją oznaczyć,
• po kilku tygodniach te same działania nadal są otwarte bez decyzji.

RCA jest wartościowe, gdy zmienia sposób działania systemu. Najlepszym dowodem jakości nie jest długość dokumentu, lecz to, że podobny mechanizm zostaje wykryty wcześniej, zablokowany przez test albo ograniczony przez architekturę.