Interogări post-incident
1) De ce este necesară parsarea post-incident
Post-incident debriefing (post-mortem/AAR) este un proces structurat pentru formarea unei organizații după un eșec. Scopul nu este de a găsi vina, ci de a identifica cauzele profunde și contribuitoare și de a consolida acțiunile măsurabile (CAPA) care reduc riscul de recurență și costul incidentelor, îmbunătățind SLO, MTTR și încrederea clienților/reglementărilor.
2) Principii (Just Culture)
Fără acuzații: analizăm sistemele, deciziile și contextul, nu personalitățile.
Faptele sunt mai importante decât opiniile: cronologie, busteni, metrici, trasee, artefacte de modificări.
vizualizare E2E: de la simptome pe client la dependențe interne și furnizori externi.
Verificabilitate: fiecare ipoteză este susținută de experiment/date.
Închiderea buclei: analizarea → CAPA → punctele de control → retestări.
3) Când să rulați parsarea și ce formate sunt
Necesar: SEV-0/1; încălcarea cerințelor SLA/de reglementare; scurgeri de date; risc semnificativ de PR.
Accelerat (lumină): SEV-2 cu influență vizibilă sau simptome recurente.
Comunicare AAR: dacă eșecul afectează pagina de stare/suport, verificăm SLA-urile de actualizări și calitatea mesajelor.
Termeni: proiect pentru 48-72 ore, versiunea finală - până la 5 zile lucrătoare (dacă nu se convine altfel).
4) Roluri și responsabilități
RCA Lead: organizează procesul, conduce întâlnirea, este responsabil pentru calitatea raportului și CAPA.
Incident Commander (IC): Oferă fapte incidente și soluții.
Tech Leads (de sisteme): Analiza cauzei care confirmă artefacte.
Comms/Support/Legal: evaluarea cerințelor de comunicare și conformitate.
Scribe: protocol, colectarea probelor, respectarea structurii.
Product/Business Stakeholders - Impactul asupra clienților/Cifra de afaceri, Prioritizarea CAPA
5) Pregătirea: ce să colecteze înainte de întâlnire
Linia de timp (UTC): detectarea T0 → recuperarea Tn; releases/feature flags/configs, status of providers.
Date de observabilitate: grafice SLI/SLO, eroare-rate, percentile, busteni, urme, capturi de ecran.
Contextul modificărilor: link-uri către PR/implementare, migrații DB, steaguri de caracteristici, planuri de lucru.
Impact: cohorte/regiuni/furnizori afectați, minute de nefuncționare, credite SLA.
Comunicări: proiecte/postări pe pagina de stare, răspunsuri de sprijin, anunțuri interne.
Politicieni/playbook-uri: ce ar fi trebuit să se întâmple în procesul în care au existat abateri.
6) Proceduri analitice (selectați combinația)
5 De ce: autopsie rapidă a lanțului cauzal (risc - suprasimplificare).
Fishbone Chart: Oameni/Proces/Platformă/Politică/Partener/Produs.
Analiza arborelui de eroare (ALS) - deducerea de la eveniment la cauze multiple (AND/OR).
Analiza schimbării: Ce sa schimbat în timpul incidentului vs starea stabilă.
Grafic cauzal: Grafic cauzal pentru microservicii complexe și dependențe externe.
Factorii umani Review: Oboseală, zgomot de informații, runbooks' irelevante și.
7) Structura raportului (șablon)
1. Rezumat - Ce, atunci când, cine a fost afectat, statutul final.
2. Impact: SLI/SLO, utilizatori, regiuni/furnizori, timpi de nefuncționare minimă, efecte financiare/de reglementare.
3. Cronologie (UTC): evenimente cheie, versiuni, soluții IC, comunicații.
4. Observații și date: grafice, jurnale, urme, difuzoare de configurații/scheme.
5. Ipoteze și teste: acceptate/respinse, trimiteri la experimente/simulări.
6. Cauze rădăcină: sistem/proces/tehnic (formulare clară).
7. Factori care contribuie: de ce nu a observat/oprit mai devreme.
8. Ce nu a funcționat: procese, unelte, oameni.
9. CAPA: acțiuni corective și preventive cu proprietari/termene limită/valori de succes.
10. Plan de verificare: D + 14/D + 30 puncte de control, criterii de închidere.
11. Versiuni externe: client/reglementare (fără date sensibile).
12. Aplicații: artefacte, link-uri către bilete/PR, capturi de ecran de tablouri de bord.
8) CAPA-uri: cum să faci acțiunile să funcționeze
Fiecare acțiune are un proprietar, un termen limită și un efect KPI (de exemplu, o reducere a ratei de schimbare a ratei de eșec de X%, o repetare zero de 90 de zile, o reducere a ratei de ardere a vârfurilor).
Măsuri corective și preventive separate.
Link către policy-as-code: alerte, SLO-gates, autoscale/limite, GitOps.
CAPA intră în restanțele publice cu comentarii la reuniunile operaționale săptămânale.
9) Verificarea și închiderea efectelor
Puncte de control: D + 7 (intermediar), D + 14/D + 30 (principal), D + 90 (total).
Verificare: teste/simulări (ziua jocului), trafic de umbre, observabilitate (SLI-uri stabile în zona verde), fără recidive.
Închiderea este posibilă numai cu CAPA-uri completate și valori validate.
10) Comunicații și conformitate
Intern: starea clară pentru produs/suport/management, actualizările SLA sunt îndeplinite.
Extern: status page, mailings to clients/partners; limbaj fără vină, un plan clar de prevenire.
Reglementare: termene de notificare, depersonalizarea exemplelor, stocarea neschimbabilă a rapoartelor și artefactelor.
11) Măsurători ale maturității proceselor
Data publicării raportului: real vs SLA (de exemplu, ≤5 zile lucrătoare).
Rata de finalizare CAPA:% din activitățile închise la data scadentă.
Rata de redeschidere: proporția incidentelor repetate în 90 de zile.
Proporția cauzelor sistemice față de „eroarea umană”.
Igiena alertă: o scădere a paginilor false, creșterea alertelor acoperite cu cărți de alergare.
Modificarea măsurătorilor DORA: MTTR, modificarea ratei de eșec înainte/după.
12) Liste de verificare
Înainte de parsare
- Proprietarul RCA și calitatea de membru definite.
- Cronologie colectată și artefacte (jurnale/grafice/versiuni/steaguri).
- Impactul evaluat de cohortă/regiune/furnizor.
- Au fost pregătite proiecte ale secțiunilor Impact și Cronologie.
- Politicile relevante/cărțile de redare sunt mapate acțiunilor reale.
În timpul
- Au fost înregistrate ipoteze acceptate/respinse și motive.
- Rădăcină și cauze contribuitoare identificate.
- A fost creat un plan CAPA cu KPI-uri și termene limită.
- Versiunile de raport pentru părțile externe sunt convenite (dacă este necesar).
După
- Raport publicat la timp, acces după rol.
- CAPAs sunt înregistrate, proprietarii sunt confirmate.
- Punctele de testare și mini-simularea sunt atribuite pentru verificare.
- Runbook actualizat/SOP/alerte/documentație.
13) Anti-modele
„Omul vinovat X” - repetați → fără motive sistemice.
Raportați fără CAPA sau fără proprietari/termene limită - hârtie pentru hârtie.
Nu există fapte/artefacte - concluzii privind senzațiile.
Limbaj prea comun („supraîncărcare de baze de date”) fără modificări specifice.
Ignorarea comunicațiilor și conformitatea sunt riscuri reputaționale.
Închiderea fără testarea efectului - recidive după săptămâni.
14) Mini șabloane
Antetul raportului
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
Formularea cauzei rădăcinii (exemplu)
CAPA (fragment)
Activați rutarea canarului către PSP-A (1%→5%→25%), proprietarul: @ payments-tl, până la: 2025-11-07, KPI: zero incidente P1 atunci când furnizorii eliberează 30 de zile.
Reconfigurați timpii/retrout-urile cu un timp total ≤ SLA de 800 ms, proprietar: @ platform-sre, până la: 2025-11-05, KPI: p99 <600 ms sub sarcină N.
Add Business SLI by BIN Cohort, Owner: @ data-lead, to: 2025-11-10, KPI: Detectarea degradării <5 min.
15) Încorporarea în practica de zi cu zi
Recenzii săptămânale RCA: statutul CAPA, lecții noi, actualizări de proces.
Directory of post-mortems in wiki with tag-uri (service, SEV, motive) și căutare.
Simulări bazate pe incident în 2-4 săptămâni pentru a verifica măsurile.
Inclusiv lecții de onboarding de gardă și actualizarea scenariilor de formare.
16) Linia de jos
Parsarea post-incidentă este un mecanism de îmbunătățire sistemică. Când faptele sunt colectate, cauzalitatea este dovedită, acțiunile sunt măsurabile și verificate, organizația acumulează capital de operare de fiabilitate: MTTR și incidentele repetate cad, predictibilitatea eliberării și creșterea încrederii clienților.