Monitoring : transformer une alerte en runbook d’exploitation actionnable

Une alerte n’a de valeur que si quelqu’un peut l’utiliser au bon moment. Beaucoup de plateformes disposent déjà de métriques, de logs, de dashboards et de notifications. Le problème n’est donc pas toujours de collecter plus de signaux, mais de transformer un signal en décision exploitable : comprendre ce qui se passe, qualifier le périmètre, décider si l’on agit, puis documenter le retour à l’état normal.

Le scénario ici est volontairement générique : une équipe exploite des services cloud, des composants réseau, des automatisations et quelques workloads applicatifs. Les alertes existent, mais elles sont inégales. Certaines déclenchent trop souvent, d’autres arrivent sans contexte, et quelques-unes demandent encore de retrouver à la main le bon dashboard ou la bonne commande. L’objectif est de passer d’une alerte “bruit” à une alerte avec runbook.

Partir de la décision attendue

Une alerte doit répondre à une question simple : quelle décision doit-elle provoquer ? Si la réponse est seulement “quelqu’un doit regarder”, l’alerte n’est pas encore assez mûre. Il faut identifier l’action probable ou au moins le diagnostic immédiat attendu.

Pour chaque alerte
Signal détecté
Impact possible
Périmètre concerné
Première vérification
Décision attendue
Action autorisée
Retour arrière ou escalade

Cette grille évite les alertes décoratives. Une métrique intéressante n’est pas forcément une bonne alerte. Une bonne alerte indique un état qui demande une décision dans une fenêtre de temps utile.

Nommer le symptôme, pas seulement la métrique

Le nom d’une alerte doit parler comme un symptôme opérationnel. “CPU > 90%” donne une mesure, mais pas un contexte. “Runner CI saturé pendant les fenêtres de déploiement” oriente déjà l’analyse : on sait quel composant regarder, quand le problème compte et quel risque est associé.

Moins utile
High CPU
Error rate too high
Disk full

Plus exploitable
Runner CI saturé pendant exécution Terraform
Backend API retourne plus d’erreurs 5xx que son niveau habituel
Volume de logs proche de la limite empêchant l’écriture applicative

Le niveau de précision doit rester lisible. Un titre d’alerte trop long devient difficile à scanner, mais un titre trop générique impose une enquête avant même de commencer le diagnostic.

Ajouter le contexte minimum dans la notification

La notification doit contenir assez d’information pour éviter l’aller-retour immédiat vers trois outils. Elle n’a pas besoin de remplacer le dashboard, mais elle doit donner le point d’entrée.

Contexte minimal
Service ou composant concerné
Environnement
Région ou réseau si pertinent
Valeur observée
Seuil ou baseline
Heure de début
Lien vers dashboard ou requête
Lien vers runbook

Le lien vers le runbook est important. Sans lui, la connaissance reste implicite : une personne sait quoi faire, les autres doivent deviner. Avec lui, l’alerte devient un début de procédure.

Séparer diagnostic et remédiation

Un runbook d’alerte ne doit pas mélanger trop vite observation et action. Les premières étapes doivent confirmer le symptôme, réduire le périmètre et éliminer les causes évidentes. La remédiation vient ensuite, avec des conditions d’exécution claires.

Runbook d’alerte
1. Confirmer que l’alerte est encore active
2. Identifier le périmètre touché
3. Comparer avec les changements récents
4. Vérifier les dépendances proches
5. Choisir une action autorisée
6. Valider le retour à la normale
7. Noter ce qui doit être corrigé durablement

Cette séparation limite les corrections dangereuses. Par exemple, redémarrer un service peut masquer un problème de dépendance, vider une preuve utile ou déclencher un effet de bord plus large.

Définir ce qui peut être automatisé

Certaines alertes justifient une automatisation directe, d’autres non. Le critère n’est pas seulement technique : il faut savoir si l’action est réversible, bornée, observable et acceptable sans validation humaine.

Action automatisable
Périmètre limité
Effet connu
Retour arrière simple
Logs suffisants
Risque faible si déclenchée deux fois

Action à garder manuelle
Impact large
Diagnostic ambigu
Risque de perte de données
Dépendance métier non visible
Action difficile à annuler

Un bon compromis consiste à automatiser la collecte de diagnostic plutôt que la correction. L’alerte peut lancer ou proposer une requête, rassembler les dernières erreurs, vérifier le DNS, ou préparer un résumé, tout en laissant la décision finale à l’équipe.

Tester les alertes comme des interfaces

Une alerte est une interface d’exploitation. Elle doit être testée. Le test ne consiste pas seulement à vérifier que la notification arrive, mais à vérifier que la personne de garde peut comprendre et agir sans reconstruire le contexte.

Test d’alerte
La notification arrive au bon canal
Le titre décrit le symptôme
Le contexte permet de trouver le composant
Le dashboard lié s’ouvre sur la bonne période
Le runbook contient une première vérification
L’action proposée est claire
Le retour à la normale est mesurable

Ce test peut être fait lors d’une revue mensuelle ou après un incident. L’important est de corriger les alertes qui ont créé de la confusion, pas seulement les incidents qui ont eu un impact.

Garder une boucle d’amélioration courte

Une alerte qui réveille souvent sans décision utile doit être modifiée, regroupée ou supprimée. Une alerte qui manque de contexte doit être enrichie. Une alerte qui arrive trop tard doit être rapprochée d’un signal plus précoce. Le runbook doit évoluer avec ces apprentissages.

Questions de revue
Cette alerte a-t-elle déclenché une action utile ?
Le seuil est-il encore adapté ?
Le contexte était-il suffisant ?
Le runbook a-t-il été suivi ?
Une étape de diagnostic peut-elle être automatisée ?
Faut-il changer le canal, la sévérité ou la fenêtre ?

Cette boucle évite l’empilement. Le monitoring reste un système vivant, pas une collection historique de seuils ajoutés au fil des incidents.

Conclusion

Rendre une alerte actionnable, ce n’est pas seulement choisir un bon seuil. C’est relier un signal à un symptôme, un périmètre, une première vérification, une décision et un retour à la normale mesurable. Le runbook donne à l’alerte sa valeur opérationnelle.

Une bonne base consiste à revoir les alertes les plus bruyantes ou les plus critiques, puis à leur ajouter un contexte minimum, un lien de diagnostic et une procédure courte. À partir de là, l’équipe peut automatiser progressivement ce qui est sûr : collecte de preuves, vérifications répétables, enrichissement de notification. Le reste doit rester explicite, traçable et validé.