Documentez un incident avec une chronologie vérifiable, les impacts observés et des corrections attribuées, puis contrôlez leur effet après mise en œuvre.
Le service fonctionne de nouveau et l’équipe passe au dossier suivant. Quelques semaines plus tard, une panne proche revient, mais personne ne retrouve pourquoi la première intervention avait réussi. Un compte rendu utile conserve les faits nécessaires pour comprendre la situation et suivre les corrections décidées.
Commencez pendant l’incident par noter les événements et les décisions. L’analyse détaillée peut attendre la stabilisation du service. Un journal simple avec des heures explicites sera plus facile à exploiter que plusieurs conversations dont les informations se contredisent.
Décrire l’impact avec ses limites
Indiquez le parcours touché, la période observée et les utilisateurs concernés lorsque ces éléments sont connus. Distinguez l’heure à laquelle le problème a été signalé de l’heure de début établie par les traces. Si cette dernière reste inconnue, conservez cette incertitude.
Précisez les conséquences vérifiées : action impossible, résultat retardé ou données à reprendre. Évitez d’étendre une observation à tous les clients sans preuve. Une indisponibilité constatée sur un compte peut encore nécessiter une recherche sur le reste du périmètre.
Ajoutez les limites de la mesure. Des journaux manquants ou une supervision partielle peuvent empêcher de calculer précisément la durée ou le nombre d’opérations concernées. Le compte rendu doit permettre au lecteur de distinguer les faits établis des estimations utilisées pour décider.
Construire une chronologie commune
Utilisez un même fuseau horaire ou affichez-le à chaque événement. Reliez les faits importants aux sources disponibles : déploiement, alerte, ticket utilisateur ou résultat d’une commande autorisée. Évitez de recopier des données confidentielles dans le document ; une référence vers un espace protégé peut suffire.
| Moment | Type d’information à conserver |
|---|---|
| Première observation | Signal reçu et personne qui l’a examiné |
| Qualification | Périmètre connu et hypothèses de travail |
| Intervention | Action, auteur et résultat constaté |
| Reprise | Contrôle technique et validation métier |
| Suivi | Opérations restantes et prochain point prévu |
Une action infructueuse mérite aussi d’être consignée. Elle peut expliquer le délai de reprise et éviter qu’une équipe répète la même tentative. Décrivez ce qui a été fait et observé, sans transformer une hypothèse de départ en cause démontrée.
Examiner les conditions qui ont permis l’incident
La démarche de postmortem sans recherche de culpabilité présentée par Google SRE cherche à comprendre les conditions de l’incident et à produire des actions d’amélioration. Elle repose sur l’analyse des informations et des contraintes auxquelles les intervenants étaient confrontés.
Dans votre revue, demandez ce que la personne savait au moment de décider. Une commande incorrecte peut avoir été facilitée par deux environnements mal identifiés, une procédure ambiguë ou l’absence de contrôle. Ces éléments orientent des corrections plus précises qu’une recommandation générale de vigilance.
Séparez le déclencheur des facteurs contributifs. Un déploiement peut avoir déclenché la panne, tandis qu’un défaut de supervision a retardé sa détection. Un problème d’accès peut ensuite avoir prolongé la reprise. Chacun mérite son propre examen et n’appelle pas nécessairement la même correction.
Distinguer stabilisation et correction durable
Le redémarrage d’un composant peut rétablir temporairement le service. Notez cette mesure avec ce qu’elle a permis de vérifier et les questions qui restent ouvertes. Une reprise réussie ne démontre pas automatiquement la cause supposée.
Pour chaque hypothèse importante, indiquez l’élément qui la soutient et la vérification encore nécessaire. Si l’analyse demande un environnement de reproduction, préparez des données autorisées et un périmètre qui évite de reproduire les effets sur les utilisateurs.
Le guide de journalisation applicative aide à identifier les événements manquants lors d’une enquête. Ajoutez un champ ou une trace seulement si vous savez quelle question il permettra de résoudre. Vérifiez aussi les données qui risqueraient d’être exposées par cette instrumentation.
Rendre les actions contrôlables
Une action doit avoir un responsable, une échéance et un résultat observable. « Améliorer la supervision » laisse trop de place à l’interprétation. Préférez une tâche comme détecter l’absence du résultat quotidien avant l’heure nécessaire au métier, avec un test démontrant la réception de l’alerte.
Limitez la liste aux changements que l’équipe s’engage à suivre. Classez les autres propositions dans le travail à arbitrer, avec leur motif. Un compte rendu chargé de promesses sans propriétaire devient difficile à maintenir après le retour à l’activité normale.
Prévoyez des corrections qui réduisent la probabilité de l’incident et d’autres qui facilitent sa détection ou sa reprise. Lorsqu’un accès manquant a bloqué l’intervention, faites tester le nouvel accès par la personne qui devra réellement l’utiliser, dans les conditions prévues.
Clôturer après vérification
Le service peut être rétabli alors que le compte rendu reste ouvert pour suivre les corrections. Distinguez ces statuts afin que les utilisateurs sachent si leur travail peut reprendre sans attendre la fin de l’analyse.
À l’échéance convenue, reprenez chaque action avec sa preuve de réalisation. Le plan de reprise d’activité doit intégrer les changements qui concernent les contacts, les accès ou les étapes de récupération. Vérifiez également les opérations métier laissées en attente pendant la panne.
Conservez la version finale du compte rendu et les liens vers les changements livrés. Lors du prochain exercice ou incident comparable, utilisez ces éléments pour examiner ce qui a fonctionné et ce qui nécessite encore une correction.