Analisi post-incidenti

1) Perché le analisi post-incidenti

L'analisi post-incidente (post-mortem/AAR) è un processo strutturato di apprendimento dell'organizzazione dopo un guasto. L'obiettivo non è individuare i colpevoli, ma individuare le cause radici e favorevoli e consolidare le azioni misurabili (CAPA) che riducono il rischio di ripetizione e i costi degli incidenti, migliorando lo SLO, l'MTTR e la fiducia dei clienti/regolatori.

2) Principi (Just Culture)

Senza accuse, analizziamo i sistemi, le decisioni e il contesto, non le personalità.
I fatti sono più importanti delle opinioni: timeline, fogli, metriche, roulotte, artefatti del cambiamento.
Visione E2E - dai sintomi sul cliente alle dipendenze interne e ai provider esterni.
Ogni ipotesi è confermata da un esperimento/dati.
Circuito a circuito: analizzare la CAPA i punti di controllo del retest.

3) Quando eseguire l'analisi e quali sono i formati

Obbligatorio: SEC-0/1; Violazione della SLA/regolamentazione; Fuga di dati Rischio PR rilevante.
Accelerato (light): SEV-2 con evidenti effetti o sintomi ripetitivi.
AAR di comunicazione: se il guasto ha colpito lo stato/supporto, controlliamo gli update di SLAs e la qualità dei messaggi.

Tempo: bozza 48-72 ore, versione finale fino a 5 giorni lavorativi (se non specificata diversamente).

4) Ruoli e responsabilità

Proprietario analisi (RCA Lead) - Organizza il processo, organizza l'incontro, gestisce la qualità del report e la CAPE.
Incident Comment (IC) - Fornisce la fattispecie dell'incidente e della soluzione.
Tech Leader (sistemi) - Analisi delle cause che confermano i manufatti.
Comms/Support/Legale: valutazione delle comunicazioni e dei requisiti della compilazione.
Scribe: protocollo, raccolta delle prove, conformità alla struttura.
Stakeholder prodotto/business: impatto su client/fatturato, priorità di CAPA.

5) Preparazione: cosa raccogliere prima dell'incontro

Timeline (UTC) - T0 rilevamento → Tn ripristino; comunicati/flag/configi, stato dei provider.
I dati di osservazione includono grafici SLI/SLO, error-rate, percense, percezioni, screenshot.
Contesto delle modifiche: collegamenti a PR/deposito, migrazioni database, flag Fiech, piani di lavoro.
Impatto: coorti/regioni/provider, minuti di inattività, prestiti SLA.
Comunicazioni: bozze/post sulla pagina di stato, risposte allo zapport, annunci interni.
Regole/playbook: cosa sarebbe dovuto accadere in un processo in cui ci sono state deviazioni.

6) Tecniche di analisi (selezionare una combinazione)

5 Why: rapida autopsia della catena causale (rischio - eccessiva semplificazione).
Grafico Ishikawa (Fishbone): People/Process/Platform/Policy/Partner/Product.
Fault Tree Analysis (FTA) - Deduzione da un evento a più cause (AND/OR).
Change Analysis: ciò che è cambiato durante l'incidente vs è stabile.
Causal Graph: il grafico causa-effetto per microservizi complessi e dipendenze esterne.
La Human Factors Review è stanchezza, rumore informativo, runbook fuori luogo.

7) Struttura report (modello)

1. Riepilogo (Executive Summary): cosa, quando, chi è stato influenzato, lo stato finale.
2. Impatto: SLI/SLO, utenti, regioni/provider, minuti di inattività, effetti finanziari/regolatori.
3. Timeline (UTC): eventi chiave, comunicati, soluzioni IC, comunicazioni.
4. Osservazioni e dati: grafici, logi, roulotte, diagrammi e diagrammi.
5. Ipotesi e test: accettati/rifiutati, riferimenti a esperimenti/simulazioni.
6. Cause radici: sistema, processo/tecnica (termini chiari).
7. I fattori favorevoli sono perché non sono stati notati o fermati prima.
8. Ciò che ha funzionato non ha funzionato, processi, strumenti, persone.
9. CAPA: misure correttive e di prevenzione con proprietari/scadenze/metriche di successo.
10. Piano di verifica: punti di controllo D + 14/D + 30, criteri di chiusura.
11. Le versioni per gli esterni sono client/regolatori (senza dati sensibili).
12. Applicazioni: manufatti, link a tickets/PR, screenshot di dashboard.

8) CAPE: come rendere operative le azioni

Ogni azione ha un proprietario, un effetto deadline e un effetto KPI (ad esempio, riduzione del cambio-failure-rate di X%, ripetizione zero di 90 giorni, riduzione del burn-rate nei picchi).
Separare Corrective (correggere) e Preventive (evitare).
Collegare a policy-as-code: alert, gate SLO, scale automatico/limiti, GitOps.
La CAPA entra in un backlog pubblico con recensioni negli incontri operativi settimanali.

9) Controllo degli effetti e chiusura

Punti di controllo: D + 7 (intermedio), D + 14/D + 30 (base), D + 90 (totale).
Controllo: test/simulazioni (game day), traffico shadow, osservabilità (SLI stabili nella zona verde), nessuna ricaduta.
La chiusura può essere eseguita solo con CAPA completate e metriche confermate.

10) Comunicazioni e compliance

Interno: stato comprensibile per prodotti/supporto/gestione, SLA update rispettati.
Pagina esterna: stato, distribuzione ai clienti/partner; linguaggio senza accuse, piano di prevenzione chiaro.
Regolazione: tempi di notifica, depersonalizzazione degli esempi, conservazione invariata dei rapporti e degli artefatti.

11) Metriche di maturità del processo

Data di pubblicazione del report: fatto vs SLA (ad esempio, ≤5 giorni lavorativi).
CAPA competition rate:% di azioni chiuse entro il termine.
Reopen rate: percentuale di incidenti ripetuti in 90 giorni.
Parte delle cause di sistema vs «errore umano».
Alert-igiene: riduzione delle pagelle false, crescita degli alert rivestiti.
Modifica delle metriche DORA: MTTR, change-failure-rate prima/dopo.

12) Assegno fogli

Prima di esaminare

• Il proprietario di RCA e la composizione dei partecipanti sono stati definiti.
• Assemblare timeline e artefatti (login/grafici/comunicati/bandiere).
• È stato valutato l'impatto per coorti/regione/provider.
• Sono state preparate le bozze di Impatto e Timeline.
• I criteri/playbook pertinenti sono mappati alle azioni effettive.

Durante

• Sono state registrate ipotesi e basi accettate/rifiutate.
• Definite le cause radici e favorevoli.
• È stato creato un piano CAPA con KPI e scadenze.
• Versioni del report concordate per gli esterni (se necessario).

Dopo

• Report pubblicato entro la data di scadenza, accesso ai ruoli.
• CAPE inseriti nel backlog, proprietari confermati.
• Sono stati assegnati punti di controllo e mini-simulazione per la convalida.
• Runbook/SOP/alert/documentazione aggiornati.

13) Anti-pattern

«È colpa dell'uomo X», senza alcun motivo di sistema.
Un rapporto senza CAPA o senza proprietari/scadenze è carta per carta.
Niente fatti/manufatti - conclusioni sulle sensazioni.
Lingua troppo comune («sovraccarico del database») senza modifiche specifiche.
Ignorare le comunicazioni e la compliance sono rischi di reputazione.
Chiudere senza controllare gli effetti - ricadute dopo settimane.

14) Mini modelli

Cappello report

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

Formulazione causa radice (esempio)

CAPO (porzione)

Abilita l'instradamento canary a PSP-A (1%→5%→25%), proprietario @ payments-tl, fino a 2025-11-07, KPI: zero P1 incidenti durante i rilasci dei provider da 30 giorni.
Riconfigurare timeout/retrai con tempo totale SLA 800 ms, proprietario @ platform-sre, a 2025-11-05, KPI: p99 <600 ms sotto carico N.

Aggiungi SLI Business per i coorti BIN, proprietario @ data-lead, a 2025-11-10, KPI: rilevamento degrado <5 min

15) Incorporazione nella pratica giornaliera

RCA-RCA settimanali: stato CAPA, nuove lezioni, aggiornamenti dei processi.
Catalogo post mortem in wiki con tag (servizio, SEC, motivi) e ricerca.
Le simulazioni per l'incidente sono tra 2-4 settimane per controllare le misure.
Includere le lezioni nell'onboording on-call e aggiornare gli script didattici.

16) Totale

Le analisi post-incidenti sono un meccanismo di miglioramento sistemico. Quando i fatti sono stati raccolti, la causalità è provata, le azioni sono misurabili e verificate, l'organizzazione accumula capitale operativo di affidabilità: cadono MTTR e incidenti ripetuti, aumentano la prevedibilità dei rilasci e la fiducia dei clienti.