Metriche di incidenti

1) Perché misurare gli incidenti

Le metriche degli incidenti trasformano gli eventi caotici in un processo gestito, riducendo i tempi di risposta e di ripristino, riducendo la ripetibilità delle cause, dimostrando l'applicazione di SLO/contratti e individuando punti di automazione. Una buona serie di metriche copre l'intero ciclo: rilevamento, classificazione, escalation, attività mitiganti, ripristino e del sistema di controllo.

2) Definizioni di base e formule

Intervalli di eventi

MTTD (Mean Time To Detect) = Tempo medio da T0 (inizio effettivo dell'influenza) al primo segnale/rilevamento.
MTTA (Mean Time To Acknowledge) = tempo medio dal primo segnale all'ack on-call.
MTTM (Mean Time To Mitigate) = Tempo medio fino a ridurre l'impatto al di sotto della soglia SLO (spesso = tempo prima della soluzione di bypass/degrado UX).
MTTR (Mean Time To Recover) = Tempo medio fino al ripristino completo degli SLI di destinazione.
MTBF (Mean Time Between Failures) = intervallo medio tra gli incidenti rilevanti.

Tempi operativi

Time to Declare - da T0 fino all'annuncio ufficiale del livello SEC/incidente.
Time to Comms - dall'annuncio al primo apdate pubblico/interno SLA.
Time in State - Durata in ogni fase (triage/diag/fix/verify).

Frequenza e quota

Insert Count - Numero di incidenti nel periodo.
Incident Rate - in 1k/10k/100k transazioni o richieste di successo (normalizzazione).
SEC Mix - Distribuzione per gravità (SEC-0... SEC-3).
SLA Breach Count/Rate è il numero/percentuale di violazioni SLA esterne.
Change Failure Rate è il% degli incidenti causati da modifiche (rilasci/configi/migrazioni).

Qualità dei segnali e dei processi

% Actionable Pages è la percentuale di pagelle che hanno portato a azioni di playbook sensibili.
False Positive Rate è una percentuale di falsi risultati.
Detection Coverage è la percentuale di incidenti rilevati automaticamente (non da client/supporto).
Reopen Rate è la percentuale di incidenti ripetuti con la stessa causa radice di giorni ≤90.
CAPE Complection è il% di azioni di correzione/avvertimento chiuse entro il termine.
Comms SLA Adherence è la percentuale di update pubblicati sulla frequenza richiesta.

3) Mappa delle metriche secondo le fasi dell'incidente

4) Normalizzazione e segmentazione

Normalizzare i contatori di volume (traffico, operazioni completate, utenti attivi).
Segmentare per: regione/tenente, provider (PSP/KYC/CDN), tipo di modifica (codice/config/infra), ora del giorno (day/night), origine di rilevamento (synthetic/RUM/infra/support).
Per le aziende è importante il business SLI (successo dei pagamenti, delle iscrizioni, dei rimpatri) - le metriche degli incidenti sono collegati al loro degrado.

5) Obiettivi soglia (punti di riferimento, adattarsi al dominio)

MTTD: 5 min per Tier-0, 10-15 min per Tier-1.
MTTA: 5 min (24/7), 10 min (follow-the-sun).
MTTM: 15 min (Tier-0), 30-60 min (Tier-1).
MTTR: 60 min (Tier-0), 4 ore (Tier-1).
Detection Coverage: ≥ 85% automatico.
% Actionable Pages: ≥ 80–90%; FP Pages: ≤ 5%.
Reopen Rate (90д): ≤ 5–10%.
CAPE (data di scadenza): 85%.

6) Attribuzione delle cause e impatto delle modifiche

A ciascun incidente, assegnare un primo motivo (Code/Config/Infra/Provider/Security/Data/Capacity) e un trigger (release ID, config, migrazione, fattore esterno).
Mantieni Change-linked MTTR/Count - quanto i rilasci e i confighi contribuiscono (base per i criteri gate/canarini).
Prendere in considerazione separatamente gli incidenti Provider-caused (PSP/KYC/CDN/Cloud) per gestire percorsi e contratti.

7) Comunicazioni e impatto dei clienti

Time to First Public Update e Update Cadence (ad esempio ogni 15/30 minuti).
Complaint Rate - ticket/lamentele per 1 incidente, tendenza.
Status Accuracy è una quota di update pubblici senza ritracciamenti.
Post-Incident NPS (per client chiave) è un breve impulso dopo la SEC-1/0.

8) Metriche di qualità alerting intorno agli incidenti

Page Storage Index - Numero di pagelle/ora per on-call durante l'incidente (mediana/p95).
Dedup Efficiency è la percentuale di duplicati soppressi.
Quorum Confirmation Rate è la percentuale di incidenti in cui ha funzionato il quorum delle sonde (sorgenti indipendenti).
Conversione Shadow→Canary→Prod delle nuove regole (Alert-as-Code).

9) Dashboard (set minimo)

1. Executive (28 giorni): numero di incidenti, distribuzione SEC, MTTR/MTTM, SLA breaches, Reopen, CAPA.
2. SRE Operations: MTTD/MTTA по часам/сменам, Page Storm, Actionable %, Detection Coverage, Time to Declare/Comms.
3. Change Impact - Percentuale di incidenti relativi a release/configure, MTTR per gli incidenti di change, finestre di servizio vs incidenti.
4. Providers: incidenti sui provider, tempi di degrado, interruzioni di rotte, SLA contrattuali.
5. Heatmap per servizi/regioni: incidenti e MTTR per transazioni 1k.

Combinare i grafici SLI/SLO con le annotazioni di release e i marchi SEC.

10) Schema dei dati dell'incidente (raccomandato)

incident_id, sev, state, service, region, tenant, provider?,
t0_actual, t_detected, t_ack, t_declared, t_mitigated, t_recovered,
source_detect (synthetic    rum    infra    support),
root_cause (code    config    infra    provider    security    data    capacity    other),
trigger_id (release_id    change_id    external_id),
slo_impact (availability    latency    success), burn_minutes,
sla_breach (bool), public_updates[], owners (IC/TL/Comms/Scribe),
postmortem_id, capa_ids[], reopened_within_90d (bool)

11) Esempi di calcolo (idea SQL)

sql
SELECT PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY EXTRACT(EPOCH FROM (t_recovered - t0_actual))/60) AS mttr_min
FROM incidents
WHERE t0_actual >= '2025-10-01' AND t_recovered IS NOT NULL AND sev IN ('SEV-0','SEV-1','SEV-2');

sql
SELECT 100.0 SUM(CASE WHEN source_detect <> 'support' THEN 1 ELSE 0 END) / COUNT() AS detection_coverage_pct
FROM incidents
WHERE t0_actual >= current_date - INTERVAL '28 days';

sql
SELECT 100.0 COUNT() FILTER (WHERE trigger_id IS NOT NULL) / NULLIF(COUNT(),0) AS change_failure_rate_pct
FROM incidents
WHERE t0_actual >= current_date - INTERVAL '28 days';

12) Relazione con SLO e budget degli errori

Fissare la SLO burn minute sull'incidente è il peso principale dell'evento.
Priorità CAPA per il peso totale burn e SEC anziché per il numero di incidenti.
Unisci il burn con l'impaccio finanziario (esempio: $/minuto di inattività o $/transazione persa).

13) Metriche di maturità del processo (program-level)

Postmortem Lead Time: mediana dalla chiusura dell'incidente alla pubblicazione del report.
Evidence Completeness - Percentuale di report con timeline, grafici SLI, logi, riferimenti a PR/comms.
Alert Hygiene Score: indice composito per actionable/FP/Dedup/quorum.
Handover Defects è la quota di turni in cui il contesto di incidenti attivi è stato perso.
Training Coverage:% on-call di simulazioni a trimestre.

14) Foglio di assegno per l'implementazione delle metriche

• Sono state definite etichette temporali uniche (UTC) e il contratto degli eventi dell'incidente.
• Adottato il dizionario SEC, le cause (root cause taxi) e le fonti di rilevamento.
• Le metriche sono normalizzate in volume (traffico/operazioni completate).
• 3 dashbord: Executive, Operations, Change Impact.
• Alert-as-Code: ogni regola di pagina ha un playbook e un proprietario.
• Post mortem SLA (ad esempio bozza), finale, schiavo. giorni).
• Le CAPE si muovono con effetto KPI e date D + 14/D + 30.
• Invident Review settimanale: trend, top cause, stato CAPA.

15) Anti-pattern

Conta solo MTTR senza MTTD/MTTA/MTTM per perdere la maneggevolezza delle fasi iniziali.
Non normalizzare i grandi servizi sembra peggio.
La SEV senza sistema ha → la comparabilità degli incidenti.
L'assenza di Evidence è una discussione invece di migliorare.
Focus sul numero di incidenti invece di burn/SLO-influenza.
Ignorare Reopen e CAPE è una ricaduta eterna.
Metriche in Excel senza caricamento automatico dalla telemetria/ITSM.

16) Mini modelli

Scheda incidente (socc.)

INC: 2025-11-01-042 (SEV-1)
T0=12:04Z, Detected=12:07, Ack=12:09, Declared=12:11,
Mitigated=12:24, Recovered=12:48
Service: payments-api (EU)
SLI: success_ratio (-3.6% к SLO, burn=18 мин)
Root cause: provider (PSP-A), Trigger: status red
Comms: first 12:12Z, cadence 15m, SLA met
Links: dashboards, logs, traces, release notes

Report Executive (28 giorni, righe chiave)

Incidents: 12 (SEV-0:1, SEV-1:3, SEV-2:6, SEV-3:2)
Median MTTR: 52 мин; Median MTTD: 4 мин; MTTA: 3 мин; MTTM: 17 мин
Detection Coverage: 88%; Actionable Pages: 86%; FP Pages: 3.2%
Change Failure Rate: 33% (4/12) — 3 связаны с конфигом
Reopen(90d): 1/12 (8.3%); CAPA Completion: 82% (2 просрочены)
Top Root Causes: provider(4), config(3), capacity(2)

17) Road map (4-6 settimane)

1. Ned. 1: standard di etichette tempo/campo, dizionario SEC/cause; la vetrina di base degli incidenti.
2. Ned. 2: calcoli MTTD/MTTA/MTTM/MTTR, normalizzazione e SEV-dashboard.
3. Ned. 3: collegamento con release/configure, Detection Coverage e Alert Hygiene.
4. Ned. 4: Report Executive, SLA post mortem, CAPE-tracker.
5. Ned. 5-6 - Rapporti di provider, Finmodel , obiettivi trimestrali e Review trimestrale.

18) Totale

Le metriche degli incidenti non sono solo numeri, ma storyboard dell'affidabilità operativa. Quando si misura l'intero flusso (dal rilevamento al CAPA), si normalizzano gli indicatori, si collegano a SLO e modifiche e si fanno recensioni regolari, l'organizzazione riduce prevedibilmente i tempi di risposta, i costi e la ricorrenza degli incidenti, mentre gli utenti vedono un servizio stabile.