Métriques d'incident

1) Pourquoi mesurer les incidents

Les métriques d'incidents transforment des événements chaotiques en un processus contrôlé : elles aident à réduire les temps de réaction et de récupération, à réduire la répétabilité des causes, à prouver l'exécution des SLO/traités et à trouver des points d'automatisation. Un bon ensemble des actes de naissance couvre tout le cycle : la détection → la classification → l'escalade → митигирующие les actions → la restitution → l'analyse → CAPA.

2) Définitions et formules de base

Intervalles d'événements

MTTD (Mean Time To Detect) = temps moyen entre T0 (début réel de l'influence) et le premier signal/détection.
MTTA (Mean Time To Acknowledge) = temps moyen entre le premier signal et ack on-call.
MTTM (Mean Time To Mitigate) = temps moyen avant de réduire l'influence en dessous du seuil SLO (souvent = temps avant la solution de contournement/dégradation UX).
MTTR (Mean Time To Recover) = temps moyen avant la restauration complète des SLI cibles.
MTBF (Mean Time Between Failures) = intervalle moyen entre les incidents pertinents.

Les temps de fonctionnement

Time to Declare - de T0 à la déclaration officielle de niveau SEV/incident.
Time to Comms - de l'annonce à la première mise à jour publique/interne sur SLA.
Time in State est la durée à chaque étape (triage/diag/fix/verify).

Fréquence et actions

Nombre d'incidents par période.
Taux d'incident - sur 1k/10k/100k de transactions ou de requêtes réussies (normalisation).
SEV Mix est la répartition par gravité (SEV-0... SEV-3).
SLA Breach Count/Rate est le nombre/la proportion de violations des SLA externes.
Taux d'échec du changement - % des incidents causés par les changements (versions/configurations/migrations).

Qualité des signaux et des processus

% Pages activables est la proportion de pages qui ont conduit à des actions significatives sur le playbook.
Faux Taux positif (Pages) : Proportion de faux positifs.
Detection Coverage est la proportion d'incidents détectés par l'automatisation (et non par les clients/support).
Reopen Rate est la proportion d'incidents répétés avec la même cause racine pendant ≤90 jours.
CAPA Completion - % des mesures correctives/d'avertissement fermées dans les délais.
Comms SLA Adherence est la proportion d'updates publiées à la fréquence requise.

3) Carte des métriques par stade d'incident

4) Normalisation et segmentation

Normalisez les compteurs par volume (trafic, opérations réussies, utilisateurs actifs).
Segmentez par : région/ténant, fournisseur (PSP/KYC/CDN), type de changement (code/config/infra), heure de la journée (day/night), source de détection (synthétique/RUM/infra/support).
Le SLI d'entreprise (succès des paiements, des inscriptions, des suppléments) est important pour les entreprises - les métriques d'incident sont liées à leur dégradation.

5) Objectifs de seuil (repères, adapter au domaine)

MTTD : ≤ 5 min pour le Tier-0, ≤ 10-15 min pour le Tier-1.
MTTA : ≤ 5 min (24/7), ≤ 10 min (follow-the-sun).
MTM : ≤ 15 min (Tier-0), ≤ 30-60 min (Tier-1).
MTTR : ≤ 60 min (Tier-0), ≤ 4 h (Tier-1).
Détection Coverage : ≥ 85 % d'automatisation.
% Actionable Pages: ≥ 80–90%; FP Pages: ≤ 5%.
Reopen Rate (90д): ≤ 5–10%.
CAPA Completion (à temps) : ≥ 85 %.

6) Attribution des causes et impact du changement

Attribuez une cause primaire à chaque incident (Code/Bou/Infra/Provider/Security/Data/Capacity) et trigger (release ID, config-change, migration, facteur externe).
Menez MTTR/Count - dans quelle mesure les versions et les configs contribuent (base pour les politiques de gate/canaries).
Tenez compte séparément des incidents sécurisés (PSP/KYC/CDN/Cloud) pour gérer les itinéraires et les contrats.

7) Communications et impact client

Time to First Public Update et Update Cadence (par exemple, toutes les 15/30 min).
Taux complet - tiquets/plaintes sur 1 incident, tendance.
Status Accuracy est une proportion d'updates publiques sans rétractations.
Le NPS Post-Incident (par client clé) est un bref élan après l' SEV-1/0.

8) Métriques de qualité d'alerte autour des incidents

Page Storm Index est le nombre de pages par heure et par appel pendant l'incident (médian/p95).
Dedup Efficiency est la proportion de doublons supprimés.
Quorum Confirmation Rate est la proportion d'incidents où le quorum des sondes a été déclenché (≥2 source indépendante).
Shadow→Canary→Prod la conversion des nouvelles règles (Alert-as-Code).

9) Dashboards (recrutement minimum)

1. Executive (28 jours) : nombre d'incidents, distribution SEV, MTTR/MTM, SLA breaches, Reopen, CAPA.
2. SRE Operations: MTTD/MTTA по часам/сменам, Page Storm, Actionable %, Detection Coverage, Time to Declare/Comms.
3. Change Impact : proportion d'incidents liés aux sorties/configues, MTTR pour les incidents de changement, fenêtres de service vs incidents.
4. Providers : incidents par fournisseurs, temps de dégradation, changement d'itinéraire, SLA contractuels.
5. Heatmap par service/région : incidents et MTTR sur 1k transactions.

Combinez les graphiques SLI/SLO avec les annotations de sortie et les marques SEV.

10) Schéma de données d'incident (recommandé)

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) Exemples de calculs (idée 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) Communication avec SLO et budgets d'erreurs

Enregistrer SLO burn minutes sur un incident est le principal « poids » de l'événement.
Hiérarchiser le CAPA en fonction du poids total burn et SEV plutôt qu'en fonction du nombre d'incidents.
Faites un burn avec l'impact financier (exemple : $/minute d'inactivité ou $/transaction perdue).

13) Mesures de la maturité du processus (programme-niveau)

Postmortem Lead Time : médiane depuis la fermeture de l'incident jusqu'à la publication du rapport.
Evidence Completeness : proportion de rapports avec temporisation, graphiques SLI, logs, liens PR/comms.
Alert Hygiene Score : indice composite par actif/FP/dédup/quorum.
Handover Defects : proportion de postes où le contexte des incidents actifs est perdu.
Coverage de formation :% sur appel, simulations par trimestre.

14) Chèque de mise en œuvre des métriques

• Des horodatages uniques (UTC) et un contrat pour les événements d'incident ont été définis.
• Le dictionnaire SEV, les causes (root cause taxonomy) et les sources de détection ont été adoptés.
• Les métriques sont normalisées par volume (trafic/opérations réussies).
• 3 dashboards sont prêts : Executive, Operations, Change Impact.
• Alert-as-Code : Chaque règlement de la page a un pleybuck et un propriétaire.
• Post-mortem SLA (par exemple, brouillon ≤72ch, finale ≤5 esclave. jours).
• Les CAPA sont tracés avec l'effet KPI et les dates D + 14/D + 30.
• Revue hebdomadaire de l'incident : tendances, causes principales, statut de l'ACPA.

15) Anti-modèles

Compter uniquement le MTTR sans MTD/MTTA/MTM → perte de maniabilité des phases précoces.
Ne pas normaliser le volume → les grands services « semblent » pire.
SEV sans système → la non-comparabilité des incidents.
L'absence d'Evidence → une controverse au lieu d'améliorations.
Focus sur le nombre d'incidents au lieu de l'influence burn/SLO.
Ignorer Reopen et CAPA → rechutes éternelles.
« Métriques dans Excel » sans déchargement automatique de la télémétrie/ITSM.

16) Mini-modèles

Carte d'incident (sokr.)

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

Rapport exécutif (28 jours à l'avance, lignes clés)

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) Feuille de route (4-6 semaines)

1. Ned. 1 : norme d'horodatage/champs, dictionnaire SEV/causes ; la vitrine de base des incidents.
2. Ned. 2 : calculs MTTD/MTTA/MTM/MTTR, normalisation et SEV-dashboard.
3. Ned. 3 : couplage avec releases/configues, Détection Coverage et Alert Hygiene.
4. Ned. 4 : Rapport exécutif, SLA post-mortem, CAPA tracker.
5. Ned. 5-6 : Rapports sur les fournisseurs, Finmodel burn→$, Objectifs trimestriels et Examen trimestriel des incidents.

18) Résultat

Les métriques d'incident ne sont pas seulement des chiffres, mais un storyboard de fiabilité opérationnelle. Lorsque vous mesurez l'ensemble du flux (de la détection au CAPA), normalisez les indicateurs, liez-les aux SLO et aux changements et effectuez régulièrement des examens, l'organisation réduit de manière prévisible le temps de réaction, le coût et la répétition des incidents - et les utilisateurs voient un service stable.