Odprawy powypadkowe

1) Dlaczego po incydencie potrzebny jest parsing

Odprawa pośmiertna (pośmiertna/AAR) jest ustrukturyzowanym procesem szkolenia organizacji po niepowodzeniu. Celem nie jest znalezienie winy, ale zidentyfikowanie głównych i przyczyniających się przyczyn i skonsolidowanie wymiernych działań (CAPA), które zmniejszają ryzyko nawrotu i koszty incydentów, poprawiając SLO, MTTR i zaufanie klientów/regulatorów.

2) Zasady (Just Culture)

Bez oskarżeń: analizujemy systemy, decyzje i kontekst, a nie osobowości.
Fakty są ważniejsze niż opinie: linia czasu, dzienniki, mierniki, szlaki, artefakty zmian.
widok E2E: od objawów na klienta do wewnętrznych zależności i zewnętrznych dostawców.
Weryfikowalność: każda hipoteza jest poparta eksperymentem/danymi.
Zamknięcie pętli: parsing CAPA → → punkty kontrolne → powtórzenia.

3) Kiedy uruchomić parsing i jakie formaty są

Wymagane: SEV-0/1; naruszenie SLA/wymogów regulacyjnych; wyciek danych; znaczące ryzyko PR.
Przyspieszone (światło): SEV-2 z zauważalnym wpływem lub powtarzającymi się objawami.
Komunikacja AAR: jeśli awaria wpływa na stronę stanu/wsparcie, sprawdzamy SLA aktualizacji i jakość wiadomości.

Warunki: projekt na 48-72 godziny, wersja końcowa - do 5 dni roboczych (chyba że uzgodniono inaczej).

4) Role i obowiązki

RCA Lead: organizuje proces, prowadzi spotkanie, odpowiada za jakość raportu i CAPA.
Incydent Commander (IC): Zapewnia incydent fakty i rozwiązania.
Tech Leads (według systemów): Analiza przyczyny, która potwierdza artefakty.
Komunikacja/Wsparcie/Prawo: Ocena wymogów w zakresie łączności i zgodności.
Skryba: protokół, zbieranie dowodów, zgodność ze strukturą.

Produkty/Interesariusze biznesowi - Wpływ klienta/Obrót, Priorytety CAPA

5) Przygotowanie: co zebrać przed spotkaniem

Linia czasu (UTC): wykrywanie T0 → Odzyskiwanie Tn; flagi/konfiguracje wydań/funkcji, status dostawców.
Dane dotyczące obserwacji: wykresy SLI/SLO, szybkość błędów, percentyle, dzienniki, ślady, zrzuty ekranu.
Kontekst zmian: linki do PR/deploy, migracje DB, flagi funkcji, plany prac.
Wpływ: dotknięte kohorty/regiony/dostawcy, minuty przestoju, kredyty SLA.
Komunikaty: projekty/posty na stronie statusu, odpowiedzi pomocnicze, ogłoszenia wewnętrzne.
Politycy/playbooks: co powinno się stać w procesie, w którym występowały odchylenia.

6) Procedury analityczne (wybrać kombinację)

5 Dlaczego: szybka autopsja łańcucha przyczynowego (ryzyko - nadmierne upraszczanie).
Wykres kości rybnej: Ludzie/Proces/Platforma/Polityka/Partner/Produkt.
Analiza drzewa błędów (FTA) - odliczenie od zdarzenia do wielu przyczyn (AND/OR).
Analiza zmian: Co zmieniło się podczas incydentu vs stabilny stan.
Wykres przyczynowy: Wykres przyczynowy dla złożonych mikroservices i zewnętrznych zależności.
Przegląd czynników ludzkich: zmęczenie, szum informacyjny, nieistotne książki startowe i.

7) Struktura raportu (szablon)

1. Podsumowanie - Co, kiedy, kto został dotknięty, ostateczny status.
2. Wpływ: SLI/SLO, użytkownicy, regiony/dostawcy, czas przestoju min, skutki finansowe/regulacyjne.
3. Linia czasu (UTC): najważniejsze wydarzenia, wydania, rozwiązania IC, komunikacja.
4. Obserwacje i dane: wykresy, dzienniki, ślady, dyfuzje konfiguracji/schematów.
5. Hipotezy i testy: przyjęte/odrzucone, odniesienia do eksperymentów/symulacji.
6. Przyczyny root: system/proces/techniczny (jasne brzmienie).
7. Czynniki przyczyniające się: dlaczego nie zauważono/zatrzymano wcześniej.
8. Co działało/co nie działało: procesy, narzędzia, ludzie.
9. CAPA: działania naprawcze i zapobiegawcze z udziałem właścicieli/terminy/wskaźniki sukcesu.
10. Plan weryfikacji: D + 14/D + 30 punktów kontroli, kryteria zamknięcia.
11. Wersje zewnętrzne: klient/regulator (brak danych wrażliwych).
12. Aplikacje: artefakty, linki do biletów/PR, zrzuty ekranu desek rozdzielczych.

8) Umowy CAPA: jak działać

Każda akcja ma właściciela, termin i efekt KPI (na przykład redukcja współczynnika awarii o X%, zerowy powtórzenie 90 dni, redukcja stopy spalania kolców).
Oddzielne środki naprawcze i zapobiegawcze.
Link to policy-as-code: alerts, SLO-gates, autoscale/limits, GitOps.
CAPA wpisuje zaległości publiczne z przeglądami na cotygodniowych spotkaniach operacyjnych.

9) Kontrola efektu i zamknięcie

Punkty kontrolne: D + 7 (pośredni), D + 14/D + 30 (główny), D + 90 (całkowity).
Weryfikacja: testy/symulacje (dzień gry), ruch cieni, obserwowalność (stabilne SLIs w zielonej strefie), brak nawrotów.
Zamknięcie jest możliwe tylko z zakończonymi jednostkami CAPA i zatwierdzonymi metrykami.

10) Komunikacja i zgodność

Wewnętrzne: jasny status produktu/wsparcie/zarządzanie, aktualizacje SLA są spełnione.
Zewnętrzna: strona stanu, maile do klientów/partnerów; język bez winy, jasny plan zapobiegania.
Przepisy: terminy zgłaszania, depersonalizacja przykładów, niezmienne przechowywanie raportów i artefaktów.

11) Metryka dojrzałości procesu

Czas publikacji raportu: rzeczywisty vs SLA (np. ≤ 5 dni roboczych).
Wskaźnik ukończenia CAPA:% działań zamkniętych w terminie wymagalności.
Szybkość ponownego otwarcia: odsetek powtarzających się incydentów w ciągu 90 dni.
Odsetek przyczyn ogólnoustrojowych vs „ludzki błąd”.
Higiena alarmu: spadek fałszywych stron, wzrost wpisów pokrytych książkami startowymi.
Zmiana mierników DORA: MTTR, wskaźnik awarii zmiany przed/po.

12) Listy kontrolne

Przed sparsowaniem

• Właściciel RCA i członkostwo określone.
• Zebrana linia czasu i artefakty (dzienniki/wykresy/wydania/flagi).
• Wpływ oceniany przez kohortę/region/dostawcę.
• Przygotowano projekty sekcji Impact and Timeline.
• Odpowiednie polityki/playbooks są mapowane do rzeczywistych działań.

Podczas

• Przyjęte/odrzucone hipotezy i uzasadnienie zostały zarejestrowane.
• Przyczyny źródłowe i przyczyny zidentyfikowane.
• Stworzono plan CAPA zawierający KPI i terminy.
• Uzgodniono wersje sprawozdań dla stron zewnętrznych (w razie potrzeby).

Po

• Sprawozdanie opublikowane na czas, dostęp według roli.
• Rejestry CAPA są rejestrowane, właściciele są potwierdzone.
• Punkty testowe i mini-symulacja są przypisane do weryfikacji.
• Aktualizacja książki startowej/SOP/wpisów/dokumentacji.

13) Anty-wzory

„Winny człowiek X” - powtórz → bez przyczyn systemowych.
Raport bez CAPA lub bez właścicieli/terminów - papier na papier.
Brak faktów/artefaktów - wnioski dotyczące doznań.
Zbyt powszechny język („przeciążenie bazy danych”) bez konkretnych zmian.
Ignorowanie komunikacji i zgodności to ryzyko reputacyjne.
Zamknięcie bez badania efektu - nawroty po tygodniach.

14) Mini szablony

Nagłówek raportu

Incident: INC-2025-10-31 (SEV-1)
Window: 2025-10-31 18: 05-18: 47 UTC
Owner of the analysis: @ rca-lead
Affected: EU region, payments (success -28% peak)
Status: corrected; 48 hours monitoring

Preparat źródłowy (przykład)

CAPA (fragment)

Włącz routing kanaryjski do PSP-A (1% → 5% → 25%), właściciel: @ payments-tl, do: 2025-11-07, KPI: zero incydentów P1, gdy dostawcy zwolnią 30 dni.
Rekonfiguracja terminów/przekładek z całkowitym czasem ≤ SLA 800 ms, właściciel: @ platform-sre, do: 2025-11-05, KPI: p99 <600 ms pod obciążeniem N.
Dodaj Business SLI przez BIN Cohort, Właściciel: @ data-lead, do: 2025-11-10, KPI: Detekcja degradacji <5 min.

15) Wbudowanie w codzienną praktykę

Tygodniowe opinie RCA: status CAPA, nowe lekcje, aktualizacje procesów.
Katalog zwłok w wiki z tagami (serwis, SEV, powody) i wyszukiwaniem.
Symulacje oparte na incydencie w ciągu 2-4 tygodni w celu zweryfikowania środków.
W tym lekcje dotyczące dyżurów na pokładzie i aktualizacji scenariuszy szkoleń.

16) Sedno sprawy

Po incydencie parsing jest mechanizmem poprawy systemowej. Kiedy zebrane są fakty, udowodniona jest przyczynowość, działania są mierzalne i weryfikowane, organizacja gromadzi kapitał operacyjny niezawodności: MTTR i powtarzające się incydenty spadają, uwalnia przewidywalność i zwiększa zaufanie klientów.