Contexte du problème : les canaux d’alerte critique et d’avertissement (Warning) ont été séparés, et la réception d’appels téléphoniques a été introduite pour les alertes critiques. Cependant, l’explosion des alertes d’avertissement — plus de 10 000 par mois — a entraîné une banalisation des notifications ainsi qu’une hausse de la fatigue d’astreinte (on-call).
Insight clé : un excès d’alertes finit par réduire la messagerie à un simple health checker, ce qui nuit à la visibilité du système. Il a été proposé de mesurer le « taux de réaction aux alertes » à l’aide des émojis Slack (👀, ✅) comme indicateur clé pour réduire les alertes.
Processus de résolution :
Ajustement et suppression des alertes dont l’intention de configuration initiale ne correspondait plus à l’environnement actuel (par ex. incohérence du seuil d’augmentation de volume EBS).
Suppression sans hésitation des alertes dénuées de sens dont l’intention des anciens intervenants était impossible à déterminer.
Résultat supplémentaire : après avoir éliminé le bruit d’alerte, il a été découvert que l’iowait élevé sur un serveur spécifique était dû à un recordsize ZFS excessif par rapport à la charge réelle, puis ce paramètre a été normalisé.
Résultat : baisse de 95,7 % des alertes d’avertissement (10 553 par mois → 453). Réduction de plus de 70 % des appels critiques reçus la nuit et les jours fériés. Résolution du manque de sommeil lié à l’astreinte et amélioration concrète de la disponibilité et de la visibilité du système.
Aucun commentaire pour le moment.