Suivre les actions issues des post-mortems jusqu'à leur clôture : tickets de suivi, responsable unique et revue par ancienneté

Objectif

S'assurer que les changements promis par un post-mortem se produisent réellement, et rendre visible le cas contraire, afin qu'un même incident ne puisse pas se reproduire alors qu'un document le prédisait déjà.

Prérequis

Une pratique du post-mortem qui produit des actions, un outil de suivi de tickets utilisé par tous, et une réunion récurrente sur les opérations ou la fiabilité.

Étapes

1. Lors de la revue du post-mortem, reformuler chaque action jusqu'à ce qu'elle nomme un changement système avec un critère d'achèvement. L'exemple de mauvais post-mortem du workbook utilise des formulations comme « améliorer » et « rendre meilleur » et liste des actions sans responsable ; chacune d'elles est renvoyée.
2. Donner à chaque action exactement un responsable, une priorité, un type (le tableau d'exemple du workbook utilise investiguer, prévenir, atténuer, réparer et détecter) et un ticket de suivi. Le SRE book indique qu'une fois que les personnes impliquées sont satisfaites du document et de ses actions, le post-mortem est ajouté à un dépôt des incidents passés ; lier le ticket depuis le document et le document depuis le ticket avant que cela n'arrive.
3. Marquer au moins une action comme le correctif préventif du déclencheur ; si aucune n'est réalisable, le document le dit et explique pourquoi. Le workbook note que changer le comportement humain est moins fiable que changer des systèmes automatisés, si bien que les actions du type « être plus prudent » ne comptent pas.
4. Fixer les échéances selon la priorité. Le workbook cite la règle selon laquelle tout post-mortem faisant suite à une interruption affectant les utilisateurs doit être associé à au moins un ticket P0 ou P1 ; adopter un équivalent local.
5. Revoir les actions ouvertes toutes les deux à quatre semaines lors de la réunion permanente, triées par ancienneté. Pour chaque action en retard, choisir l'une des options suivantes : la faire maintenant, la re-cadrer, ou la clore comme « ne sera pas faite » avec la raison consignée à la fois dans le ticket et dans le post-mortem. La laisser inchangée sur la liste n'est pas une option.
6. Lorsqu'une action est close, consigner dans le post-mortem ce qui a changé et comment cela a été vérifié : la nouvelle alerte s'est déclenchée lors d'un test, le runbook a été utilisé lors d'un exercice, la limite est appliquée par configuration.
7. Chaque trimestre, compter les actions ouvertes, closes et abandonnées, et relire ensemble celles qui ont été abandonnées ; un schéma récurrent d'actions préventives abandonnées est lui-même une observation à retenir.

Résultat attendu

Une archive de post-mortems où chaque action est faite, explicitement refusée, ou visiblement en retard, et une équipe capable de dire ce qu'un incident a changé.

Limites et base de vérification

Les actions de grande ampleur (réécritures, migrations) appartiennent à la feuille de route, le post-mortem se contentant d'y renvoyer ; les suivre comme des actions produit des lignes en retard permanentes. La procédure suit les chapitres cités ; aucun taux d'achèvement n'est revendiqué.