Alerter sans noyer l'équipe
Le piège de la fatigue d'alerte
Une équipe qui reçoit des dizaines d'alertes par jour, dont la plupart sont non actionnables ou redondantes, finit par les ignorer toutes, y compris les vraies urgences. C'est l'alert fatigue, l'un des pires anti-patterns en supervision.
Une bonne alerte doit être actionnable
Chaque alerte doit répondre à trois questions : Quel est le problème ? Quel est son impact ? Que dois-je faire maintenant ? Une alerte "CPU à 85%" sans contexte ne dit pas si c'est grave ni quoi faire.
Seuils statiques vs dynamiques
- Seuil statique : "alerter si CPU > 90%". Simple mais génère du bruit si le seuil n'est pas adapté au comportement normal du système.
- Seuil dynamique : basé sur une comparaison avec le comportement historique (ex. "alerter si le trafic est 50% en dessous de la moyenne des 4 dernières semaines à la même heure"). Plus pertinent mais plus complexe à mettre en place.
Niveaux de sévérité
| Niveau | Signification | Action attendue |
|---|---|---|
| Critique | Service indisponible ou impact utilisateur direct | Intervention immédiate, réveil de nuit si besoin |
| Warning | Dégradation qui n'impacte pas encore l'utilisateur | Investigation dans les heures/jours suivants |
| Info | Événement à tracer, aucune action requise | Consultation lors d'une revue périodique |
Cas concret
Une équipe reçoit une alerte "espace disque > 80%" identique sur 15 serveurs chaque nuit, car ce seuil est normal pour leur usage. Après plusieurs semaines, un ingénieur d'astreinte ignore par réflexe une nouvelle alerte similaire, qui s'avère cette fois être un vrai incident (disque plein imminent). Ajuster le seuil à 90% avec une vraie marge de sécurité aurait éliminé le bruit sans rien manquer d'important.
Erreurs fréquentes
- Fixer des seuils sans les revoir jamais, générant du bruit permanent que l'équipe finit par ignorer systématiquement.
- Envoyer toutes les alertes au même niveau de priorité, rendant impossible de distinguer l'urgent du secondaire d'un simple coup d'œil.
- Créer une alerte sans documenter l'action attendue : l'ingénieur d'astreinte perd un temps précieux à comprendre quoi faire au lieu d'agir.
À retenir
- L'alert fatigue (trop d'alertes non pertinentes) fait ignorer les vraies urgences.
- Chaque alerte doit indiquer le problème, l'impact, et l'action attendue.
- Distinguer clairement critique / warning / info évite de traiter tout au même niveau d'urgence.
Mini-exercice
Une alerte "CPU élevé" se déclenche 20 fois par jour sur un serveur dont c'est le comportement normal en heures de pointe. Quelle est la meilleure correction : ignorer l'alerte au cas par cas, ou ajuster sa configuration ?
Réponse : ajuster la configuration de l'alerte (seuil plus réaliste, ou seuil dynamique basé sur l'historique), jamais l'ignorer manuellement : une alerte ignorée par habitude finit par masquer une vraie urgence future.