Quand un service tombe, on a deux réflexes. Le premier : réparer vite. Le second : oublier aussi vite. Dès que tout remarche, on passe à autre chose en se disant « bon, voilà, c’est réglé ».
Et trois mois plus tard, la même panne revient. Et on repart de zéro, en se demandant comment on avait fait la dernière fois.
Le postmortem (littéralement « après la mort ») est l’habitude qui casse ce cycle : écrire quelques lignes sur ce qui s’est passé, tant que c’est frais. Dans les grandes entreprises, c’est un document long, relu par plusieurs personnes. Chez soi, dix minutes et une page suffisent.
« Blameless » : pourquoi pas de coupable ?
Les gens du SRE parlent de postmortem blameless, c’est-à-dire sans recherche de coupable. L’idée : si on cherche qui a fait l’erreur, les gens se cachent. Si on cherche ce qui a permis l’erreur, on peut corriger le système.
Dans un homelab, tu es à la fois l’auteur de l’erreur et le seul lecteur. Ça pourrait sembler inutile. Mais la règle te protège toi-même : elle t’évite de finir ton analyse par « quel idiot je suis », ce qui n’améliore rien. À la place, on pose la question utile : qu’est-ce qui aurait empêché cette erreur, ou l’aurait rendue visible plus tôt ?
Exemple :
- ❌ « J’ai oublié de surveiller le disque. »
- ✅ « Rien ne me prévenait quand un disque approchait de la saturation. »
La seconde formulation débouche directement sur une action : ajouter une alerte.
Le modèle en cinq questions
Voici la structure que je te propose. Crée un fichier pannes/AAAA-MM-JJ-nom.md (dans le dépôt git où tu ranges tes scripts) et réponds à ces cinq questions.
# Panne : <titre court>
Date : AAAA-MM-JJ — Durée : X h / X min — Services touchés : ...
## 1. Que s'est-il passé ?
Chronologie en quelques lignes (heure : événement).
## 2. Pourquoi ?
La cause racine. Si possible, creuser avec « pourquoi ? » plusieurs fois.
## 3. Comment je l'ai su ?
Alerte, message de quelqu'un, découverte par hasard ? Combien de temps après le début ?
## 4. Comment j'ai réparé ?
Les commandes et les étapes qui ont marché.
## 5. Qu'est-ce que je change ?
2 ou 3 actions concrètes, avec une case à cocher.Les questions 3 et 5 sont les plus précieuses. La 3 mesure ton délai de détection : si tu l’as appris trois jours plus tard, ta surveillance a un trou. La 5 transforme la panne en amélioration.
Les « cinq pourquoi », version simple
Pour trouver la vraie cause, on demande « pourquoi ? » jusqu’à tomber sur quelque chose qu’on peut changer. Un exemple inspiré de la panne classique du disque plein :
- Pourquoi l’application ne synchronisait plus ? → Parce que les écritures échouaient.
- Pourquoi les écritures échouaient ? → Parce que le disque était plein.
- Pourquoi le disque était plein ? → Parce que les données avaient grossi plus vite que prévu.
- Pourquoi je ne l’ai pas vu ? → Parce que rien ne m’alertait à 90 % d’occupation.
- Pourquoi il n’y avait pas d’alerte ? → Parce que je n’avais pas défini ce que je voulais surveiller.
La vraie cause n’est pas « le disque plein », c’est la réponse numéro 5. Et celle-là, on peut la corriger en vingt minutes.
Un exemple complet, en petit
# Panne : synchronisation Nextcloud interrompue
Date : exemple — Durée : environ 48 h — Services touchés : Nextcloud
## 1. Que s'est-il passé ?
- Les envois de fichiers ont échoué en silence pendant deux jours.
- Découvert quand quelqu'un a cherché des photos récentes.
## 2. Pourquoi ?
Le volume de données était plein (0 octet libre).
## 3. Comment je l'ai su ?
Par hasard, avec 48 h de retard. Aucune alerte.
## 4. Comment j'ai réparé ?
Libéré de la place, agrandi le volume, relancé la synchronisation.
## 5. Qu'est-ce que je change ?
- [x] Alerte à 85 % d'occupation, prévue avec predict_linear.
- [x] Notification sur mon téléphone.
- [ ] Revoir la taille du volume tous les six mois.Ce document tient en une page, se rédige en dix minutes, et on y gagne trois actions concrètes.
Quand en écrire un ?
Pas besoin d’en écrire un à chaque redémarrage. Une règle simple suffit :
- Panne de plus de 30 minutes sur un service qui compte.
- Perte de données, même minime.
- Panne qui revient : la deuxième fois, c’est que la première cause n’a pas été traitée.
- Moment de frayeur : si tu as pensé « ouf, c’était limite », écris-le.
Les « presque pannes » sont souvent plus instructives que les vraies : on a le temps de réfléchir, et personne n’est fâché.
Où ranger tout ça ?
N’importe quel endroit où tu retrouveras le texte dans six mois :
- Un dossier
pannes/dans ton dépôt git, en Markdown. - Un wiki auto-hébergé.
- À la limite, un simple fichier texte daté.
Le critère n’est pas l’outil, c’est de pouvoir le retrouver quand la même panne revient.
À retenir
- Écris dix minutes après la panne, pas trois semaines plus tard.
- Cherche ce qui a permis la panne, pas qui l’a causée.
- Termine toujours par deux ou trois actions concrètes.
- Relis tes anciens postmortems de temps en temps : tu y verras vite les schémas qui reviennent.
Et si ça te semble trop sérieux pour un homelab, retiens au moins la question 5. Elle seule vaut le coup.
