sinraQu’est-ce qu’un Post-mortem ?
Un post-mortem dans Sinra est un enregistrement structuré d’analyse d’incident. Il capture ce qui s’est passé, pourquoi, et ce qui empêchera que cela se reproduise. Il est explicitement blameless : l’objectif est d’identifier les défaillances systémiques, pas les erreurs individuelles.
Créer un Post-mortem
- Accédez à
/postmortems - Créez un enregistrement avec un titre et la date d’occurrence
- Définissez la sévérité selon l’impact
- Renseignez les dates clés : detected_at, resolved_at
- Rédigez les sections facteurs contributifs et impact
- Ajoutez les événements de la chronologie, chacun avec sa date et son heure
- Ajoutez des actions de remédiation avec des responsables et des échéances
Niveaux de Sévérité
| Sévérité | Usage |
|---|---|
| low | Perturbation mineure, impact utilisateur limité |
| medium | Dégradation notable, contournement possible |
| high | Panne significative ou problème de données, aucun contournement |
| critical | Panne totale du service ou perte de données |
Structure d’un Post-mortem
Chronologie : une liste d’événements datés, toujours affichée dans l’ordre chronologique quel que soit l’ordre de saisie. L’heure saisie est lue dans votre fuseau horaire ; chaque lecteur la voit dans le sien. Survolez une heure pour lire la date complète et le fuseau. Les bonnes chronologies décrivent ce que chaque intervenant a fait et pourquoi — avec empathie pour les informations dont il disposait à ce moment-là. Les post-mortems écrits avant ce changement gardent leur ancienne chronologie en texte libre en base, mais elle n’est plus affichée ni modifiable.
Facteurs Contributifs (texte riche) : conditions systémiques qui ont rendu l’erreur possible ou amplifié son impact. Pas qui a fait quoi, mais ce qui a rendu le système fragile.
Impact (texte riche) : périmètre de l’incident — utilisateurs affectés, revenus perdus, SLA non respecté, données à risque.
Actions : tâches de remédiation spécifiques avec un responsable, une échéance et un statut, les mêmes actions suivies que dans les rétrospectives (voir Rétrospectives). Chaque action doit traiter un facteur contributif, pas un symptôme. Convertir en issue ouvre le formulaire d’issue pré-rempli comme un bug ; l’action suit ensuite le statut de l’issue.
Cycle de Vie des Statuts
| Statut | Signification |
|---|---|
| draft | En cours de rédaction, pas encore partagé |
| in_review | Partagé pour relecture avec l’équipe |
| published | Finalisé, partagé avec l’organisation |
MTTR (Mean Time To Recovery)
Sinra calcule automatiquement le MTTR de occurred_at à resolved_at. Cette métrique apparaît sur chaque post-mortem et peut être comparée entre incidents pour suivre la capacité de récupération de votre organisation dans le temps.
Si resolved_at n’est pas défini, le post-mortem est marqué comme ongoing (en cours).
Lien avec le Contexte
Liez un post-mortem à une release, un cycle ou un projet pour le connecter au contexte de travail où l’incident s’est produit. Cela le rend consultable depuis la vue release et crée une traçabilité entre livraison et incident.
Issues liées
Liez les issues concernées par l’incident. Le post-mortem affiche chaque issue avec son statut courant, lu à l’affichage de la page, et la page de l’issue liste les post-mortems où elle apparaît.
Participants
Ajoutez les intervenants et relecteurs comme participants. Cela documente l’équipe qui a répondu et crée une liste de personnes à notifier lors de la publication du post-mortem.
Blameless vs Revues d’Incidents Traditionnelles
Les revues d’incidents traditionnelles demandent : qui a fait l’erreur ? Les post-mortems blameless demandent : qu’est-ce qui a permis à cette erreur d’avoir cet impact ?
La distinction n’est pas cosmétique. Quand les individus craignent d’être blâmés, ils cachent les near-misses, sous-déclarent les incidents et contournent silencieusement les systèmes fragiles. Quand les organisations traitent les incidents comme des opportunités d’apprentissage systémique, les ingénieurs signalent les problèmes tôt, les post-mortems sont lus par d’autres équipes et les améliorations systémiques sont prioritisées.
La structure de post-mortem de Sinra est conçue pour faire émerger les causes systémiques : la section facteurs contributifs se concentre explicitement sur les conditions, pas sur les acteurs.
La liste des postmortems n’a qu’un seul bouton « Nouveau ».