Les runbooks gardés dans des documents statiques ne servent à rien quand l'incident vient. La vraie valeur, c'est quand ils sont vivants, scripts et déclenchables.
Ce que je fais
- Chaque runbook est un script (bash, Python ou Playwright) dans le repo, avec une description claire.
- Les étapes critiques peuvent être relayées via un CLI (ex:
npm run incident --runbook=slow-query). - Les runbooks s'accompagnent d'un template de post-mortem et d'alertes qui vérifient si un runbook a été exécuté récemment.
Ces runbooks ne sont pas des habits de cérémonie : ils s'exécutent dans la vraie base, ils nettoient des files d'attente, ils valident des transactions, puis ils poussent un résumé dans Slack/Teams/Telegram.
Les bénéfices
- Une crise devient une routine documentée, pas un stress. Les runbooks automatisés fournissent les commandes exactes et évitent les copies-collées dangereuses.
- Les équipes peuvent ajouter une nouvelle étape en codant simplement un script et en le liant à l'alerte.
- Chaque exécution génère un log, utile pour améliorer le runbook et prévenir la prochaine panne.