Alertes de supervision : réduire le bruit sans perdre les pannes

La boîte de supervision reçoit des messages que plus personne ne lit vraiment. Chacun connaît les alertes habituelles et les écarte presque sans regarder. Puis un utilisateur appelle pour une application indisponible. Le signal était peut-être là, au milieu des autres.

Face à cette situation, je commence par examiner ce que les notifications demandent à l’équipe. Ajouter un tableau de bord ne répond pas à cette question. Monter tous les seuils non plus. Le travail consiste à retrouver, pour chaque interruption, une raison d’agir et quelqu’un qui peut le faire.

Partir des notifications effectivement reçues

Je propose de commencer par un service dont l’exploitation agace déjà l’équipe. Il faut un périmètre assez précis pour suivre les décisions : une application métier et ses dépendances connues, par exemple. Un nettoyage global de la supervision risque de rester un chantier ouvert que personne ne termine.

Exportez les notifications d’une période représentative de son activité. Incluez un traitement périodique s’il génère des alertes particulières. Rapprochez cet export des tickets d’incident et des opérations de maintenance. La liste des règles configurées ne suffit pas : elle ne montre ni les répétitions ni ce que les destinataires ont réellement reçu.

Pour chaque famille de messages, faites préciser l’action effectuée. Une vérification suivie d’une décision compte comme une action. Un acquittement mécanique ne prouve rien. Si personne ne sait expliquer le message, gardez cette incertitude visible et désignez quelqu’un pour l’instruire avant de désactiver la notification.

Je conserve aussi les règles silencieuses dans cette revue. Une alerte qui ne s’est jamais déclenchée peut couvrir une panne rare et sérieuse. Le volume permet de choisir où commencer, pas de décider seul ce qui mérite de rester.

Séparer urgence, travail planifiable et diagnostic

Le chapitre de Google SRE consacré à la supervision recommande des alertes qui appellent une action et distingue les symptômes visibles des causes techniques. Je retiens surtout ce critère pour les notifications urgentes : faut-il interrompre quelqu’un maintenant, et pour faire quoi ?

Voici une grille de décision que je propose comme point de départ. Les situations sont des exemples à adapter au service, pas des seuils universels.

Le classement dépend du contexte métier. Un traitement interrompu peut attendre si sa reprise reste possible avant l’utilisation du résultat. Le même échec devient urgent lorsqu’il menace cette échéance. Je demande donc au responsable d’exploitation de faire confirmer le délai utile par le métier.

Une notification urgente doit expliquer pourquoi agir maintenant, pas seulement pourquoi une mesure a changé.

Réécrire le message autour de la première action

Une alerte intitulée avec un nom de serveur et un état critique oblige le destinataire à reconstruire le contexte. Je veux pouvoir identifier le service, l’environnement, le symptôme et la première vérification depuis le message. Le détail technique reste accessible par un lien vers la bonne vue de supervision.

Prenons un exemple fictif : un contrôle de consultation des commandes échoue. Le message doit préciser quel site ou quel parcours est concerné, depuis quand le contrôle échoue et où vérifier son résultat. La consigne peut demander de confirmer l’échec depuis un autre point de contrôle, puis de contacter le support applicatif selon le résultat.

Cette consigne ne doit pas devenir un ordre de redémarrage aveugle. Si la première action peut aggraver la situation, elle demande des conditions explicites et un niveau d’autorisation adapté. Je préfère un diagnostic court et fiable à une procédure spectaculaire que personne n’ose exécuter.

Chaque règle a aussi besoin d’un propriétaire chargé de son entretien. C’est lui qui revoit le message lorsque l’application change. Pour une tâche planifiable, le ticket contient un résultat attendu et une échéance ; empiler les notifications dans une file ne crée pas ce suivi.

Corriger les répétitions avec des règles compréhensibles

La documentation d’Alertmanager distingue le regroupement des alertes, l’inhibition de notifications lorsqu’une autre alerte est active et les silences temporaires. Ces mécanismes répondent à des problèmes différents. Je commence par nommer le problème avant de choisir le réglage.

Regrouper sert à présenter ensemble les signaux d’un même événement. L’inhibition peut éviter des notifications secondaires lorsqu’une panne amont est déjà signalée. Un silence couvre une période délimitée, comme une intervention prévue. Il ne doit pas devenir la manière permanente de supporter une règle mal conçue.

Pour les variations transitoires, la clause for décrite dans les règles d’alerte Prometheus permet d’attendre que la condition reste active pendant une durée définie avant de déclencher l’alerte. Cette attente retarde aussi la détection : sa durée doit rester compatible avec le temps disponible pour intervenir.

Je refuse les dépendances trop difficiles à expliquer. Si une inhibition masque un défaut indépendant, le calme obtenu est trompeur. Il faut pouvoir dire précisément quelles notifications disparaissent, dans quelle condition, et où leurs états restent visibles. Ces questions valent aussi avec un autre outil de supervision.

Vérifier la détection après chaque modification

Avant de toucher aux règles, conservez leur configuration et prévoyez comment la rétablir. Je fais ensuite comparer les règles proposées aux incidents connus du service. Pour chacun, demandez si le signal aurait encore été détecté, à quel moment et vers quel destinataire il aurait été envoyé.

Cette comparaison a une limite : l’historique ne contient que ce qui a déjà été observé. Il faut donc compléter par des essais maîtrisés. Selon l’outil, utilisez des données rejouées, un environnement de test ou une simulation sans effet sur la production. Vérifiez séparément l’évaluation de la règle et l’acheminement du message.

Le test doit aller jusqu’au canal réellement utilisé. Une règle correctement déclenchée avec une destination erronée ne protège personne. Contrôlez également le retour à la normale, l’expiration d’un silence et le comportement si les données de supervision cessent d’arriver. L’absence de mesure ne doit pas être interprétée implicitement comme un service sain.

Je limite les changements simultanés pour pouvoir expliquer un résultat inattendu. Pour un service récemment livré, les parcours décrits dans la recette métier fournissent des candidats utiles aux contrôles. Ils ne remplacent toutefois pas la surveillance des dépendances et des traitements invisibles à l’utilisateur.

Organiser la première revue avec l’équipe

La semaine prochaine, réunissez la personne qui connaît l’application et celle qui reçoit ses notifications. Apportez l’export, les incidents associés et les règles en vigueur. Pour chaque famille retenue, consignez la décision, son motif, le propriétaire et la vérification attendue. Le livrable est une liste de modifications exécutables.

Je commence par les cas dont l’explication fait consensus : destinataire obsolète, doublon établi, message incompréhensible, maintenance sans expiration. Les règles discutées restent à instruire. Il serait contre-productif d’exiger une baisse immédiate du volume et de pousser l’équipe à masquer ce qu’elle comprend mal.

Après application, regardez ensemble les interruptions reçues, les actions engagées et les incidents découverts par les utilisateurs sans signal préalable. Interprétez ces observations selon l’activité : une semaine calme ne démontre pas une meilleure supervision. Aucun objectif arbitraire de réduction ne remplace cette lecture.

Enfin, si une alerte correspond toujours à une vraie dégradation, conservez-la et traitez le défaut. Lorsque la correction exige un arbitrage durable, elle rejoint le travail sur la dette technique. Le nettoyage de la supervision est terminé sur un périmètre quand l’équipe comprend ce qui l’interrompt et sait quoi en faire. Le silence, à lui seul, ne constitue pas une preuve.