Fatigue des alertes

Qu'est-ce que la fatigue des alertes ?

La fatigue des alertes (alert fatigue) survient quand des personnes reçoivent tant d'alertes, ou tant d'alertes de faible valeur, qu'elles cessent de réagir vite, voire de réagir du tout. Elle touche autant les ingénieurs d'astreinte que les équipes de support et les analystes sécurité. Le livre SRE de Google décrit l'effet sans détour : quand les pages sont trop fréquentes, on doute, on survole ou on ignore les alertes entrantes, et un vrai incident se perd dans le bruit.

Pourquoi elle apparaît

• Des alertes sur lesquelles personne ne peut agir, comme une métrique élevée sans impact pour les utilisateurs.
• Des alertes sur des causes (CPU au-dessus de 80 %) plutôt que sur des symptômes ressentis par les utilisateurs (requêtes lentes ou en échec).
• Le flapping : un contrôle en échec depuis un seul emplacement, ou une brève coupure, déclenche une alerte et se résorbe une minute plus tard.
• Les doublons : le même problème se déclenche dans trois outils et cinq canaux.
• Des alertes jamais ajustées ni retirées après l'évolution du système.
• Dans les équipes sécurité, des outils de détection qui produisent beaucoup de faux positifs, si bien que les analystes apprennent à écarter les alertes.

Ce que cela coûte

Une réponse plus lente, car on consulte les alertes plus tard. Des incidents manqués, parce que celui qui compte ressemble aux autres. Une perte de confiance dans la supervision, et les alertes finissent coupées. Le livre SRE note aussi que les pannes peuvent durer plus longtemps parce que le bruit gêne un diagnostic rapide. La solution est rarement d'ajouter des alertes, mais d'en avoir de meilleures.

Comment la réduire

1. Rendre chaque page exploitable. Selon le livre SRE, une page qui ne mérite qu'une réponse robotique ne devrait pas être une page. Automatisez-la ou transformez-la en ticket.
2. Alerter sur les symptômes. Déclenchez sur ce que vivent les utilisateurs, comme des requêtes en échec ou lentes. Gardez les alertes sur les causes pour les tableaux de bord, sauf si elles signalent un problème précis et imminent.
3. Confirmer avant d'alerter. Exigez plusieurs échecs consécutifs, ou des échecs depuis plus d'un emplacement, avant d'envoyer une alerte.
4. Router selon la gravité. Les pannes urgentes vers le bipeur, la dégradation vers un canal de discussion, les tendances lentes vers un ticket.
5. Regrouper et dédoublonner. Un incident doit produire une notification, pas une par hôte ou par contrôle.
6. Revoir régulièrement. Pour chaque alerte déclenchée, demandez qui a agi. Si personne, ajustez-la ou supprimez-la.
7. Réduire au silence les travaux planifiés. Utilisez des fenêtres de maintenance pendant les déploiements et les migrations.

Exemple

Un contrôle d'API échoue une fois à 03 h 00 depuis une seule région à cause d'un incident réseau passager, puis se rétablit à l'exécution suivante. Avec une configuration naïve, l'ingénieur d'astreinte est réveillé. Après réglage, le contrôle n'alerte que s'il échoue deux fois de suite depuis au moins deux emplacements. Les réponses lentes mais correctes vont dans un canal de discussion. L'astreinte est sollicitée moins souvent, et chaque alerte a un sens.

La fatigue des alertes dans la surveillance d'API LoadFocus

La surveillance d'API LoadFocus propose plusieurs réglages contre les fausses alertes : nouvelles tentatives, seuil d'échecs consécutifs, nombre minimal d'emplacements en échec et seuil de dégradation sur le temps de réponse. Les alertes peuvent partir vers l'e-mail, Slack, Microsoft Teams, Discord, PagerDuty, Opsgenie et les webhooks, avec un routage par canal pour l'échec, le rétablissement, la dégradation et l'expiration SSL. Les contrôles gratuits s'exécutent toutes les 5 minutes. Lancer chaque contrôle depuis au moins deux emplacements est le conseil de la page elle-même pour éviter les faux positifs. Voyez surveillance d'API et surveillance synthétique pour leur fonctionnement, et bonnes pratiques de supervision pour concevoir vos alertes.

Erreurs courantes

• Alerter sur un seuil de ressources sans impact pour les utilisateurs.
• Envoyer chaque alerte à tout le monde.
• Couper un canal bruyant au lieu de corriger la règle qui le remplit.
• Garder des seuils par défaut que personne n'a remis en question.
• Omettre les notifications de rétablissement, si bien que personne ne sait si l'incident est terminé.

Fatigue des alertes et réponse aux incidents

De bonnes alertes sont la première étape de la réponse aux incidents : elles déterminent la rapidité avec laquelle la bonne personne démarre. Quand l'incident est réel, la communication d'incident et une page de statut tiennent tout le monde informé, pour que les ingénieurs n'aient pas à répondre sans cesse à la même question.

Questions fréquentes

Qu'est-ce qui cause la fatigue des alertes ?

Trop d'alertes sur lesquelles on ne peut pas agir : seuils bruyants, alertes sur les causes plutôt que sur les symptômes, doublons entre outils, et alertes jamais revues après l'évolution du système.

Comment réduire la fatigue des alertes ?

Alerter uniquement sur des symptômes exploitables, confirmer les échecs avant d'alerter, router selon la gravité, dédoublonner les notifications et examiner chaque alerte déclenchée. Ajustez ou supprimez celles que personne ne traite.

La fatigue des alertes est-elle seulement un problème de sécurité ?

Non. Les analystes sécurité la connaissent avec des outils de détection à gros volume, mais les équipes d'astreinte, le support et toute personne qui reçoit des alertes de supervision peuvent en souffrir.

En quoi la surveillance d'API aide-t-elle ?

Des contrôles qui exigent plusieurs échecs consécutifs ou plusieurs emplacements en échec avant d'alerter, avec un routage par canal, réduisent les fausses alertes isolées. La surveillance d'API LoadFocus propose ces réglages.