Analyse post-incident

1) Pourquoi l'analyse post-incident est nécessaire

L'analyse post-incident (post-mortem/AAR) est un processus structuré d'apprentissage de l'organisation après une défaillance. L'objectif n'est pas de trouver les coupables, mais d'identifier les causes profondes et contributives et de consolider les actions mesurables (CAPA) qui réduisent le risque de répétition et le coût des incidents, en améliorant les SLO, MTTR et la confiance des clients/régulateurs.

2) Principes (Just Culture)

Pas d'accusations : nous analysons les systèmes, les décisions et le contexte, pas les personnalités.
Les faits sont plus importants que les opinions : temporisation, logs, métriques, tracés, artefacts de changement.
E2E : des symptômes sur le client aux dépendances internes et aux fournisseurs externes.
Vérifiable : chaque hypothèse est confirmée par l'expérience/les données.
Boucle de fermeture : analyse → CAPA → points de contrôle → retest.

3) Quand lancer l'analyse et quels sont les formats

Obligatoire : SEV-0/1 ; violation des exigences réglementaires/SLA ; Fuite de données ; risque de RP significatif.
Accéléré (léger) : SEV-2 avec une influence perceptible ou des symptômes récurrents.
Communication AAR : si l'échec a touché la page de statut/support, nous vérifions les updates SLA et la qualité des messages.

Délais : brouillon en 48-72 heures, version finale - jusqu'à 5 jours ouvrables (sauf accord contraire).

4) Rôles et responsabilités

Propriétaire de l'analyse (RCA Lead) : organise le processus, dirige la réunion, est responsable de la qualité du rapport et CAPA.
Commandant d'incident (IC) : fournit les faits de l'incident et la solution.
Tech Leaders (par systèmes) : analyse des causes justifiant les artefacts.
Comms/Support/Legal : évaluation des communications et des exigences de la conformité.
Scribe : protocole, collecte de preuves, respect de la structure.
Produits/entreprises Stackholders : impact sur les clients/chiffre d'affaires, priorité CAPA.

5) Préparation : Que rassembler avant la réunion

Temporisation (UTC) : Détection T0 → récupération Tn ; communiqués/fich drapeaux/configi, statut des fournisseurs.
Données d'observation : graphiques SLI/SLO, taux d'erreur, percentiles, logs, traces, captures d'écran.
Contexte du changement : liens vers la RP/deploi, migrations OBD, drapeaux fich, plans de travail.
Impact : cohortes/régions/fournisseurs touchés, minutes d'inactivité, crédits SLA.
Communications : brouillons/posts sur la page de statut, réponses de Sapport, annonces internes.
Politiciens/playbooks : ce qui devait se passer dans le processus où il y avait des écarts.

6) Méthodes d'analyse (choisir une combinaison)

5 Why : ouverture rapide de la chaîne causale (risque - simplification excessive).
Diagramme d'Ishikawa (Fishbone) : People/Process/Platform/Policy/Partner/Product.
Analyse des arbres de fond (FTA) : déduction d'un événement à une multitude de causes (AND/OR).
Analyse du changement : ce qui a changé au cours de la période d'incident vs état stable.
Case causale : graphique de causalité pour les microservices complexes et les dépendances externes.
Revue des facteurs humains : fatigue, bruit d'information, runbook non pertinent.

7) Structure du rapport (modèle)

1. Résumé (Résumé exécutif) : quand, qui a été influencé, le statut final.
2. Impact : SLI/SLO, utilisateurs, régions/fournisseurs, inactivité, effets financiers/réglementaires.
3. Timline (UTC) : événements clés, sorties, solutions IC, communications.
4. Observations et données : graphiques, logs, trajets, diffamations de fligs/schémas.
5. Hypothèses et vérifications : acceptées/rejetées, références à des expériences/simulations.
6. Causes racines : système/process/technique (formulation claire).
7. Facteurs contributifs : pourquoi n'a-t-on pas remarqué/arrêté plus tôt.
8. Ce qui a fonctionné/ce qui n'a pas fonctionné : les processus, les outils, les gens.
9. CAPA : mesures correctives et préventives avec les propriétaires/échéanciers/métriques de réussite.
10. Plan de vérification : points de contrôle D + 14/D + 30, critères de clôture.
11. Versions externes : client/réglementation (pas de données sensibles).
12. Applications : artefacts, liens vers tickets/PR, captures d'écran de dashboards.

8) CAPA : comment faire des actions des travailleurs

Chaque action a un propriétaire, une déduplication et un effet KPI (par exemple, réduire le taux de changement de X %, zéro répétition de 90 jours, réduire le taux de burn en pics).
Séparez la mesure corrective (corriger) et la mesure préventive (empêcher).
Liez aux policy-as-code : alertes, SLO-gates, auto-skale/limites, GitOps.
L'ACPA entre dans le backlog public avec des examens lors de réunions d'exploitation hebdomadaires.

9) Vérification de l'effet et fermeture

Points de contrôle : D + 7 (intermédiaire), D + 14/D + 30 (principal), D + 90 (total).
Vérification : tests/simulations (game day), trafic shadow, observabilité (SLI stables en zone verte), pas de rechutes.
La fermeture n'est possible qu'avec les CAPA et les métriques confirmées.

10) Communications et conformité

Interne : statut compréhensible pour les produits/support/gestion, les apdates SLA sont respectées.
Externe : page de statut, envois aux clients/partenaires ; un langage sans charges, un plan de prévention clair.
Réglementation : délais de notification, dépersonnalisation des exemples, stockage immuable des rapports et des artefacts.

11) Métriques de la maturité du processus

Heure de publication du rapport : fait vs SLA (par exemple, jours ouvrables ≤5).
Taux de CAPA completion :% des actions fermées à temps.
Taux de renouvellement : proportion d'incidents de répétition en 90 jours.
Proportion des causes du système vs « erreur humaine ».
Hygiène d'alerte : diminution des fausses pagaies, croissance des alertes couvertes de runbook.
Modification des métriques DORA : MTTR, change-failure-rate avant/après.

12) Chèques-feuilles

Avant l'analyse

• Le propriétaire de l'ACR et la composition des participants ont été déterminés.
• Temps et artefacts collectés (logs/graphiques/communiqués/drapeaux).
• L'impact est évalué par cohorte/région/fournisseur.
• Des brouillons des sections « Impact » et « Timline » ont été préparés.
• Les politiques/playbooks pertinents sont comparés aux actions réelles.

Pendant

• Les hypothèses et motifs acceptés/rejetés sont consignés.
• Les causes racines et contributives sont identifiées.
• Un plan CAPA a été mis en place avec des KPI et des échéances.
• Version harmonisée du rapport pour les parties externes (si nécessaire).

Après

• Rapport publié à temps, accès par rôle.
• Les CAPA sont inscrits sur le backlog, les propriétaires sont confirmés.
• Des points de contrôle et une mini-simulation ont été attribués pour la vérification.
• Mise à jour de runbook/SOP/alertes/documentation.

13) Anti-modèles

"Est coupable la personne X" - sans raisons systémiques → la répétition.
Un rapport sans CAPA ou sans propriétaires/délais - papier pour le papier.
Pas de faits/artefacts - conclusions sur les sensations.
Langage trop général ("surcharge OBD') sans changement spécifique.
Ignorer les communications et la conformité est un risque de réputation.
Fermeture sans vérification des effets - rechutes après des semaines.

14) Mini-modèles

Chapeau de rapport

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

Formulation de la cause racine (exemple)

CAPA (fragment)

Activer le routage canary à PSP-A (1%→5%→25 %), propriétaire : @ payments-tl, jusqu'à : 2025-11-07, KPI : Incidents de zéro P1 lors des sorties des fournisseurs 30 jours.
Reconfigurer les délais/retraits avec un temps total de ≤ SLA de 800 ms, propriétaire : @ platform-sre, à : 2025-11-05, KPI : p99 <600 ms sous charge N.
Ajouter un SLI d'entreprise par cohortes BIN, propriétaire : @ data-lead, jusqu'à : 2025-11-10, KPI : détection de dégradation <5 min.

15) Intégrer dans la pratique quotidienne

Revues RCA hebdomadaires : statut CAPA, nouvelles leçons, mises à jour des processus.
Annuaire de post-mortem dans le wiki avec tags (service, SEV, raisons) et recherche.
Simulations motivées par un incident dans 2 à 4 semaines pour vérifier les mesures.
Inclure des leçons dans onboard-call et mettre à jour les scénarios de formation.

16) Résultat

L'analyse post-incident est un mécanisme d'amélioration du système. Lorsque les faits sont recueillis, que la causalité est prouvée, que les actions sont mesurables et vérifiables, l'organisation accumule le capital d'exploitation de la fiabilité : les MTTR et les incidents répétés tombent, la prévisibilité des sorties et la confiance des clients augmentent.