Module 4 · Reprendre après l'erreurEnviron 1 min
Les trente premières minutes
Quand une alerte critique tombe, l’improvisation coûte cher. Une procédure d’incident (runbook), écrite à froid, décide à votre place des premiers gestes. Celle de Nadia tient en une page :
Texte
PROCÉDURE D'INCIDENT · flux critique
0 à 5 min Annoncer dans #incidents : « je prends ».
Ouvrir l'exécution en échec depuis le lien de l'alerte.
5 à 10 min Qualifier : un flux ou tous ? Panne passagère ou définitive ?
Le service appelé a-t-il publié un incident sur sa page d'état ?
10 à 20 min Contenir, du plus doux au plus fort :
1. laisser travailler la file et les réessais si la panne est passagère ;
2. ouvrir le disjoncteur pour mettre les éléments de côté ;
3. dépublier le workflow, en dernier recours.
20 à 30 min Informer : service client si des clients sont touchés,
direction si l'incident dure. Noter l'heure de chaque décision.
Ensuite Rejouer les éléments mis de côté, vérifier l'absence de doublons,
programmer le post-mortem dans les cinq jours ouvrés.L’ordre compte : contenir avant de comprendre. On cherche la cause racine une fois les clients protégés, pas pendant.
Rangez cette procédure à côté des workflows, dans le dépôt Git ou le wiki de l’équipe. Relisez-la après chaque post-mortem, et faites-la dérouler une fois par trimestre par quelqu’un qui ne l’a pas écrite : c’est le seul moyen de savoir qu’elle tient.
Dépublier n’est pas neutreUn workflow dépublié ne reçoit plus ses webhooks de production : selon l’appelant, ces événements seront renvoyés plus tard ou perdus. Pour chaque flux critique, sachez ce que fait l’appelant quand il reçoit une erreur.