Les incidents sont des tests de charge pour votre système sociotechnique. Si les post-mortems se terminent par « erreur humaine » ou un bouc émissaire unique, les échecs se répètent—car les incitations masquent les trous systémiques au lieu de les corriger.
Clarifiez les rôles avant que le pager sonne : commandant d’incident pour coordonner, responsable communication pour les clients, scribe pour les faits chronologiques. Faire tourner ces rôles muscle l’organisation sans dépendre des héros.
Les playbooks vivent à côté des services : basculement, drainage du trafic, emplacement des logs, tableaux utiles. Pendant l’incident, préférez de courts statuts sur un canal unique ; après, conservez une chronologie en UTC avec la justification des décisions.
Sans reproches ne veut pas dire sans conséquences—cela veut dire analyser les conditions qui ont permis l’erreur. Demandez pourquoi les garde-fous manquaient : absence de canary, feature flag flou, rollback peu clair, trou dans les tests.
Les actions correctives ont besoin d’owners et d’échéances suivis comme du travail produit. Reliez la remédiation au risque SLO : si une lacune menace le budget d’erreur, priorisez-la explicitement au sprint suivant.
Entraînez-vous avec des game days sur des chemins non critiques. Les incidents synthétiques révèlent si les runbooks sont exacts et si les permissions sont réellement accordées à l’astreinte.
À lire aussi : conseil DevOps et plus de ressources.