Post-mortem¶

Analyser les incidents sans blame pour identifier les causes racines et éviter la recidive.

Principes du post-mortem blameless¶

Le post-mortem blameless repose sur le postulat que les personnes impliquees dans un incident ont agi de bonne foi avec les informations et les outils dont elles disposaient. L'objectif n'est pas d'identifier un coupable mais de comprendre comment le système a permis l'incident.

Principes clés :

Les individus ne sont pas la cause racine — les systèmes, les processus et les contraintes le sont
Tout le monde peut participer sans crainte de sanctions
Les conclusions doivent produire des actions concrètes, pas des injonctions morales
Le post-mortem est partage avec toute l'équipe comme vecteur d'apprentissage

Fréquence obligatoire P1/P2

Tout incident P1 doit faire l'objet d'un post-mortem dans les 5 jours ouvrables. Les incidents P2 recurrents (même symptome plus de 2 fois en 30 jours) doivent egalement en faire l'objet. Un post-mortem bacle ou jamais réalisé est un signal d'alerte culturel.

Template de post-mortem¶

Résumé executif¶

Date et durée de l'incident
Sévérité finale et périmètre réel
Impact mesure (utilisateurs, SLO, revenu si applicable)

Timeline¶

Reconstruction chronologique des événements, décisions et actions. Utilisez la timeline war room comme base.

Analyse d'impact¶

Nombre d'utilisateurs touches
Services impactes
SLO/SLA affectes et valeur consommee

Causes racines¶

Identifiées via les méthodes 5 Whys ou Ishikawa (voir ci-dessous).

Actions correctives¶

Action	Type	Responsable	Echeance
Ajouter alerte sur connexions DB	Prévenir	@sre-alice	J+7
Automatiser le rollback deploy	Détecter	@dev-bob	J+14
Runbook pour saturation pool	Mitiger	@sre-team	J+5

Privilegiez les actions dans cet ordre : prévenir > détecter > mitiger.

Leçons apprises¶

Ce qui a bien fonctionne (pour renforcer)
Ce qui a mal fonctionne (pour corriger)
Ce qui nous a surpris (pour étendre la surveillance)

Méthode des 5 Whys¶

La méthode des 5 Whys consiste à remonter à la cause racine en questionnant successivement chaque cause.

Exemple : incident de saturation base de données

Iteration	Question	Réponse
Why 1	Pourquoi l'API est-elle en erreur 500 ?	Le pool de connexions DB est épuisé
Why 2	Pourquoi le pool est-il épuisé ?	Chaque requête ouvre une connexion sans la fermer
Why 3	Pourquoi les connexions ne sont-elles pas fermees ?	Le nouveau service ne géré pas les connexions dans un bloc finally
Why 4	Pourquoi ce bug n'a-t-il pas été détecté ?	Pas de test de charge ni de revue de code sur la gestion des connexions
Why 5	Pourquoi n'y a-t-il pas de test de charge ?	Le pipeline CI ne comporte pas d'étape de test de performance

Cause racine : absence de test de performance en CI sur les nouveaux services.

Diagramme d'Ishikawa (aretes de poisson)¶

L'Ishikawa permet de cartographier les causes selon plusieurs catégories.

flowchart LR
    subgraph Causes
        direction TB
        P[Processus\nPas de test de charge\nen CI]
        T[Technologie\nPool de connexions\nnon surveille]
        H[Humain\nRevue de code\nincomplete]
        E[Environnement\nCharge de prod\nnon reproduite en test]
    end
    P --> I([Saturation\nbase de donnees])
    T --> I
    H --> I
    E --> I

Suivi des actions correctives¶

Les actions du post-mortem doivent être trackees comme des tickets normaux avec :

Un responsable nomme (pas une équipe — une personne)
Une echeance realiste
Un critère de completude objectif

Les actions non completees dans les 30 jours doivent être revalidees lors d'une rétrospective. Un post-mortem sans actions completees n'est qu'un exercice de documentation.