Une équipe reçoit trop de notifications quand les alertes ne distinguent pas urgence, information et bruit. La fatigue peut retarder une vraie intervention. Une revue basée sur les actions attendues aide une PME à retrouver une supervision praticable.
Mesurer le bruit
Comptez les alertes par service, leur fréquence, le temps de réponse et le nombre qui ont déclenché une action. Une règle répétée plusieurs fois pendant un même incident ne représente pas plusieurs problèmes. Regroupez les événements qui ont la même cause.
Identifiez les alertes sans propriétaire, celles qui ne donnent pas accès aux journaux et celles qui n’ont pas de procédure. Une alerte qui ne peut mener à aucune action doit devenir un rapport ou disparaître.
Relier l’alerte à un symptôme
Un seuil CPU peut être utile lorsqu’il précède une saturation, mais il ne suffit pas à représenter une panne. Associez les signaux techniques à un taux d’erreur, à une latence, à un âge de file ou à un échec de parcours utilisateur.
Définissez une durée et une fenêtre. Une valeur qui dépasse le seuil pendant quelques secondes ne mérite pas toujours une notification urgente. Une moyenne longue peut toutefois retarder une alerte sur un incident rapide, d’où l’intérêt de comparer les signaux.
Écrire une action claire
Le message doit nommer le service, l’environnement, la condition et le lien vers la procédure. Précisez si l’action attendue est de vérifier un déploiement, d’augmenter temporairement une capacité, de contacter un fournisseur ou de déclarer un incident.
Séparez l’astreinte des notifications de journée. Une alerte critique doit atteindre le canal surveillé à l’heure concernée. Un résumé quotidien peut contenir les tendances sans interrompre une personne pour chaque variation.
Revoir après chaque incident
Après le retour au service, examinez les alertes reçues. Ajoutez celles qui auraient réduit le délai de détection et retirez celles qui n’ont pas apporté d’information. Vérifiez aussi si une alerte a masqué une autre dans un canal trop chargé.
Conservez un historique de la règle et de sa raison. Une suppression sans trace peut rendre le même problème invisible plusieurs mois plus tard. Les changements de seuil doivent être comparés au niveau de service et à la charge observée.
Tester le dispositif
Simulez une erreur sur un environnement isolé et vérifiez la réception, le contenu et l’escalade. Testez une dépendance lente, une file bloquée et un certificat proche de l’expiration. Mesurez le temps entre le signal et la prise en charge.
Notre guide sur l’observabilité et les SLO aide à structurer les indicateurs. Un runbook de reprise doit ensuite transformer l’alerte en étapes sûres.
Sources : Google SRE, monitoring, Prometheus, alerting.