Modèle de rapport d’incident
Document autonome. Trame du rapport à rédiger après un incident (exercice d’incident de la S7, réalisation R1, compétence 16). Trame imposée par le cours : symptôme → cause → correction → mesure préventive ; elle est complétée ici par la qualification, la chronologie et le délai de reprise, que le contrat de service demande de mesurer (engagement : 4 heures). Méthode et fiches par alerte : Fiches-reflexes-incident.md. En fin de document, un exemple rempli à partir d’un incident réel provoqué sur le lab (test 7.11).
Dernière mise à jour : 02/11/2026
Le modèle (à copier)
# Rapport d'incident n° AAAA-MM-JJ-NN — <titre court : le service touché et le symptôme>
| | |
|---|---|
| Date | JJ/MM/AAAA |
| Rédigé par | <nom>, technicien du service Réseau et Système (niveau 1) |
| Gravité | critique / avertissement |
| Services touchés | <site web, DNS, base…> — coupé / dégradé |
| Utilisateurs touchés | <qui, combien> |
| Délai de reprise mesuré | <h min> (engagement : 4 h) — tenu / dépassé |
| Escalade | aucune / niveau 2 à HH:MM / niveau 3 à HH:MM |
## 1. Résumé
<3 lignes : ce qui s'est passé, la cause, comment c'est réparé.>
## 2. Chronologie
| Heure | Événement | Source (preuve) |
|---|---|---|
| HH:MM | premier signe (mail, sonde, plainte) | mail [FIRING], capture n° |
| HH:MM | début du diagnostic | |
| HH:MM | cause trouvée | commande, résultat |
| HH:MM | correction appliquée | |
| HH:MM | retour à la normale vérifié | mail [RESOLVED], sonde à 1 |
## 3. Symptôme
<Ce qu'on a observé, avec les messages EXACTS (copiés, pas résumés).>
## 4. Qualification
<Gravité et pourquoi ; coupé ou dégradé ; contournement possible ; niveau d'escalade.>
## 5. Diagnostic
| # | Hypothèse | Test (commande, endroit) | Résultat | Conclusion |
|---|---|---|---|---|
| 1 | | | | écartée / confirmée |
## 6. Cause
<La cause réelle (la cause racine), pas seulement le premier symptôme. Si elle reste inconnue : le dire.>
## 7. Correction
<Ce qui a été fait, commandes exactes, dans l'ordre.>
## 8. Vérification du retour à la normale
<Comment on a vérifié, vu comme un utilisateur : sonde, navigateur, état du service.>
## 9. Mesures préventives
| Mesure | Effet attendu | Qui | Quand |
|---|---|---|---|
| | | | |
## 10. Ce que la supervision a vu (ou pas)
<L'alerte est-elle arrivée ? À temps ? Avec le bon diagnostic ? Sinon, quelle règle améliorer.>
## 11. Preuves
<Captures, mails, extraits de journaux, numéros d'incident du Troubleshooting.>
Règles d’écriture : des heures précises ; des messages copiés tels quels ; une hypothèse par ligne, même celles qui étaient fausses (elles montrent la démarche) ; aucun mot de passe ; « je ne sais pas » vaut mieux qu’une cause inventée.
Exemple rempli : la perte de quorum du cluster (test 7.11, 02/11/2026)
Panne provoquée volontairement (la cause était donc connue d’avance) : l’exemple sert à montrer la forme du rapport et ce que la supervision a réellement vu. Détail : Documentation-pfSense.md, étape 58.
| Date | 02/11/2026 |
| Rédigé par | Axel, niveau 1 (avec Claude) |
| Gravité | critique |
| Services touchés | site web (www.sio.internal) — coupé ; supervision (Grafana) — coupée |
| Utilisateurs touchés | tous les utilisateurs du site |
| Délai de reprise mesuré | 3 min 12 s (13:24:56 → 13:28:08) — engagement de 4 h tenu |
| Escalade | aucune (résolu en niveau 1) |
1. Résumé — Deux des trois nœuds de base de données ont perdu le réseau. Le nœud restant, minoritaire, a refusé les écritures pour éviter deux bases divergentes : le site a répondu 503. Le réseau rétabli, le cluster s’est reformé seul.
2. Chronologie
| Heure | Événement | Source |
|---|---|---|
| 13:24:34 | état normal : 3 nœuds Primary | Prometheus |
| 13:24:56 | cartes réseau de srv-mysql-02 et srv-mysql-03 débranchées | Proxmox (link_down=1) |
| 13:25:16 | srv-mysql-01 : taille 1, non-Primary, wsrep_ready OFF | MariaDB |
| 13:25:27 | site : HTTP 503 | curl vers 10.0.10.5 |
| 13:27:12 | seul mail : [FIRING:1] Supervision aveugle | boîte de l’administrateur |
| 13:28:08 | cartes rebranchées | Proxmox |
| 13:28:17 | 3 nœuds Primary, Synced | MariaDB |
| 13:28:32 | site : HTTP 200 | curl |
3. Symptôme — site en 503 ; écriture refusée : ERROR 1047 (08S01): WSREP has not yet prepared node for application use ; API de Grafana en 401.
4. Qualification — critique : service coupé pour tous, aucun contournement (les trois nœuds sont nécessaires pour écrire tant que la majorité manque).
5. Diagnostic
| # | Hypothèse | Test | Résultat | Conclusion |
|---|---|---|---|---|
| 1 | Prometheus est tombé (titre du mail) | sondes dans Prometheus | Prometheus répond | écartée |
| 2 | le cluster a perdu la majorité | SHOW STATUS sur srv-mysql-01 | non-Primary, taille 1 | confirmée |
| 3 | les deux autres nœuds sont coupés | up dans Prometheus, carte réseau dans Proxmox | up = 0, link_down=1 | confirmée |
6. Cause — perte réseau de deux nœuds sur trois : le survivant, minoritaire, se met en non-Primary (quorum perdu).
7. Correction — réseau des deux nœuds rétabli (Disconnect décoché). Aucune autre action : pas de réamorçage.
8. Vérification — 3 / Primary / Synced / ON sur les trois nœuds ; site à 200 ; aucune donnée écrite
pendant la panne (test_quorum absente partout) ; règles d’alerte de nouveau en bonne santé.
9. Mesures préventives
| Mesure | Effet attendu | Qui | Quand |
|---|---|---|---|
| Règle « Supervision aveugle » renommée, avec les deux causes possibles | le mail donne le bon diagnostic | niveau 1 | fait le 02/11 |
| (piste) plus de votants dans le cluster (5 nœuds ou un arbitre) | tenir la perte de 2 nœuds | décision niveau 2 | si la panne se répète en production |
10. Ce que la supervision a vu — une seule alerte, à 13:27:12, dont le titre accusait Prometheus à tort : la base de Grafana est dans le cluster, Grafana ne pouvait plus rien calculer (H-66). Risque accepté (dette T-16) ; règle reformulée.
11. Preuves — capture 145-test-7-11-perte-quorum.png ; incident H-66.