Root Cause Analysis

1) Cosa è RCA e perché è necessario

Root Cause Analysis è un processo strutturato per identificare le cause radici dell'incidente per escludere la ripetizione. Al centro ci sono fatti, causali e miglioramenti sistemici (processi, architettura, test), non la ricerca di colpevoli.
Gli obiettivi sono prevenire la ricaduta, ridurre la frequenza di incidenti MTTR, migliorare la SLO, rafforzare la fiducia di regolatori e partner.

2) Principi (Just Culture)

Senza accuse. Non puniamo le persone, puniamo le pratiche di rischio.
Fattibilità. Solo dati e manufatti verificabili.
Uno sguardo E2E. Dal cliente al backend e ai provider.
La validità delle ipotesi. Qualsiasi affermazione è con un test/esperimento.
Un cortocircuito CAPA. Misure correttive e di prevenzione con proprietari e scadenze.

3) Manufatti di ingresso e preparazione

Timeline UTC: T0 rilevamento → T + azione → T + ripristino.
I dati di osservazione sono: fogli, metriche, trailer, sintetici, status page.
Modifiche: comunicati, flag fich, confighi, eventi di provider.
Ambiente: versioni, hash manufatti, SBOM, etichette di infrastruttura.
Base dell'incidente: descrizione dell'impatto (SLO/SLA, clienti, traffico), decisioni prese, workaround's.
Chain of custody: chi e quando ha raccolto/modificato le prove (importante per la compilazione).

4) Tecniche RCA: quando quale

1. 5 Why - scoprire rapidamente la catena causale per problemi stretti. Rischio: «ridurre» il sistema complesso al righello.
2. Diagramma Ishikawa (Fishbone) - Espande i fattori in categorie People/Process/Platform/Policy/Partner/Product. È utile all'inizio.
3. Fault Tree Analysis (FTA) - Deduzione da evento a set di cause (AND/OR). Per l'infrastruttura e i guasti all'albero.
4. Causal Graph/Event Chain è un grafico delle dipendenze con probabilità e peso del contributo. Ottimo per microservizi e provider esterni.
5. Failure Mode & Efficients Analysis - Prevenzione: modalità di errore, gravità (S), frequenza (O), rilevabilità (D), RPN = S x O x D.
6. Change Analysis - Confronto «com'è stato/come è stato» (diff configurs, schema, versioni).
7. Human Factors Review è il contesto delle decisioni delle persone (affaticamento alert, cattive playbook, surriscaldamento).

Collegamento consigliato: Fishbone Change Analysis Causal Graph/FTA 5 Why su rami chiave.

5) Processo RCA passo passo

1. Avvia: assegna il proprietario di RCA, imposta la data di rilascio del report (ad esempio 5 giorni lavorativi), assembla il comando (IC, TL, Scribe, provider).
2. Raccogliere i fatti: timeline, grafici, release, fogli, manufatti; Fissare le versioni e il controllo delle somme.
3. Mappare l'impatto: quali SLI/SLO sono stati colpiti, quali coorti (paesi, provider, VIP).
4. Fare ipotesi: primarie, alternative; Segnare quali verifiche sono in corso.
5. Controlla le ipotesi: riproduzione su stage/simulazione/canarino, analisi delle roulotte, fault injection.
6. Identificare le cause radici e favorevoli: tecnologia, processo, organizzazione.
7. Formare CAPE: regolatori (correggere) e avvertenti (impedire); metriche di successo e tempi.
8. Allineare e pubblicare il report: knowledge base interna +, se necessario, versione esterna per client/regolatori.
9. Convalida gli effetti: punti di controllo dopo 14/30 giorni; Chiusura delle attività.

6) Cosa è considerata «causa radice»

• test/flag deboli, limiti/alert mancanti, documentazione ambigua, default improprio, architettura fragile.
• Spesso è una combinazione di fattori (configurazione x mancanza di gate x carico x provider).

7) CAPE: misure correttive e di prevenzione

• Fix codice/configurazioni, restituzione del pattern, modifica dei limiti/timeout, aggiunta di indici, replica/charding, reimpostazione del traffico, aggiornamento dei certificati.

• test (contratti, valigette di caos), alert (burn rate, quorum sintetico), politiche di rilascio (canary/blue-green), GitOps di configi, apprendimento/assegno-fogli, duplicazione del provider, esercitazioni DR.

Ogni azione: proprietario, deadline, effetto previsto, metrica di convalida (ad esempio, riduzione del cambio-failure-rate di X%, assenza di ripetizioni di 90 giorni).

8) Verifica delle ipotesi e degli effetti

Esperimenti: fault inquection/chaos, traffico shadow, configure A/B, carichi con profili reali.
Metriche di successo: ripristino SLO, stabilizzazione p95/p99, assenza di picchi errato-rate, riduzione MTTR, trend burn-rate e zero-reopen per 30 giorni.
Punti di controllo: D + 7, D + 30, D + 90 - Rivedere l'esecuzione del CAPA e l'impatto.

9) Modello di report RCA (interno)

1. Un breve riassunto di cosa è successo quando, chi è stato colpito.
2. Impatto: SLI/SLO, utenti, regioni, traffico/multe (se disponibili).
3. Timeline (UTC) - Eventi principali (alert, decisioni, comunicati, registri).
4. Osservazioni e dati: grafici, fogli, tracciati, configi (diffidi), stati di provider.
5. Ipotesi e test - accettati/rifiutati, riferimenti agli esperimenti.
6. Cause radici: tecnologia, processo, organizzazione.
7. I fattori favorevoli sono «perché non sono stati notati o fermati».
8. Il piano CAPA è una tabella di azioni con proprietari/scadenze/metriche.
9. I rischi e le vulnerabilità residue che devono ancora essere monitorati/testati.
10. Allegati: manufatti, link, grafici (elenco).

10) Esempio (breve, riassunto)

Evento: riduzione del 35% del successo dei pagamenti alle 19: 05-19: 26 (SEC-1).
Impatto: e2e-SLO violato 21 mine, 3 paesi colpiti, rimborsi/risarcimenti.
Motivo 1 (t): la nuova versione del validatore della carta ha aumentato la latitanza a 1. Due timeout per il provider.
Motivo 2: mancava il canary per il provider «A», il rilascio è andato al 100%.
Motivo 3 (org): la soglia alert del business SLI non copriva una specifica gamma BIN (VIP).
CAPA - Restituire la vecchia versione del validatore; immettere canary 1/5/25%; Aggiungere un SLI aziendale per coorti BIN; negoziare una failover del 30% per il provider «B»; la valigetta del caos slow upstream.

11) Metriche di maturità del processo RCA

Esecuzione di CAPA entro 30 giorni (% chiuso).
Reopen rate (incidenti riaperti in 90 giorni).
Change-failure-rate prima/dopo.
Percentuale di incidenti in cui si trovano cause sistemiche (non solo «errore umano»).
Coprire i nuovi script RCA con i test.
Ora di pubblicazione del report (SLA pubblicazione).

12) Caratteristiche dei domini regolabili (fintech/iGaming, ecc.)

Report all'esterno: versioni client/regolatori del report senza dettagli sensibili, ma con un piano di prevenzione delle ripetizioni.
Controllo-login e invariabilità: memorizzazione degli artefatti, report firmati, mappatura a ticket, CMDB, CAD.
Dati utente: depersonalizzazione/occultamento in esempi di logi.
I tempi di notifica sono associati a contratti e norme (ad esempio, N ore per notifica primaria).

13) Anti-pattern

«La colpa è di Vasia».
La mancata verifica delle ipotesi è una conclusione intuitiva.
RCA troppo generico («il servizio era sovraccarico») - senza modifiche specifiche.
Niente CAPA o nessun proprietario/data di scadenza - rapporto per il rapporto.
Nascondere le informazioni è una perdita di fiducia, non è possibile formare un'organizzazione.
Sovraccarico di metriche senza collegamento con SLO/Business SLI.

14) Strumenti e pratiche

Archivio RCA (wiki/knowledge base) con metadati: servizio, SEC, motivi, CAPE, stato.
Modelli e bot - Genera l'ossatura del report da un incidente (timeline, grafica, release).
Grafico causale: creazione di una mappa evento-causale (ad esempio, basata su logi/trailer).
Catalogo Chaos - Script per la riproduzione di precedenti incidenti di stage.
Dashboards «dopo RCA»: widget separati che confermano l'effetto CAPA.

15) Foglio di assegno «pronto per la pubblicazione»

• Timeline e manufatti completi e verificati.
• Cause radici definite e dimostrate da test/esperimenti.
• Divise le radici e le cause favorevoli.
• CAPE contiene proprietari, tempistiche, metriche di effetto misurabili.
• C'è un piano di verifica tra 14/30 giorni.
• La versione per gli steakholder esterni è stata preparata (se necessario).
• Il rapporto è stato superato da quelle/le/le/le/le/le/le/le

16) Totale

RCA non è una retrospettiva per la formalità, ma un meccanismo di apprendimento del sistema. Quando i fatti sono raccolti, la causalità è dimostrata e le CAPE sono bloccate in metriche e testate in esperimenti, l'organizzazione diventa sempre più resistente: il SLO è più stabile, il rischio di ricadute è più basso e la fiducia degli utenti e dei regolatori è maggiore.