Alertes & Bruit : Réduire les Fausses Pages

Pourquoi votre seuil unique vous réveille à 3h du matin pour rien, et comment le multi-burn-rate résout le problème.

Une alerte qui se déclenche trop souvent perd toute crédibilité. Les équipes l'ignorent, puis passent à côté d'un vrai incident. Le problème n'est pas la sensibilité de l'alerte — c'est son architecture.

Le piège du seuil unique

Un seuil sur le taux d'erreur brut ("alert si error_rate > 1 %") se déclenche sur tout : un pic de 2 minutes, un redémarrage de pod, un test de charge. Ces événements consomment moins de 0,1 % de votre budget mensuel — ils ne méritent pas une page. Un bon système d'alerte ne mesure pas si quelque chose va mal maintenant, il mesure si la vitesse actuelle de dégradation menace votre SLO sur la fenêtre restante.

Le taux de burn comme filtre

Le taux de burn mesure à quelle vitesse vous consommez votre budget d'erreur par rapport à la vitesse "normale". Un taux de 1× signifie que vous consommez exactement votre budget en une fenêtre. Un taux de 14,4× signifie que vous épuiserez votre budget mensuel en 50 heures — une urgence réelle. Alerter uniquement quand le burn rate dépasse un seuil significatif filtre naturellement les microperturbations.

taux_de_burn = taux_erreur_observé / (1 − SLO)

Fenêtre unique vs double fenêtre

Une fenêtre longue (ex : 1h) lisse les pics courts et détecte les burns soutenus. Mais un burn qui a cessé depuis 45 minutes peut encore faire sonner l'alerte — c'est un faux positif retardé. La solution : exiger que DEUX fenêtres soient élevées simultanément. La fenêtre longue confirme que le burn rate est élevé en moyenne ; la fenêtre courte (ex : 5 min) confirme qu'il l'est encore en ce moment. Si l'incident s'est résolu, la fenêtre courte redescend — pas d'alerte.

Le modèle Google SRE

Google SRE a publié quatre politiques d'alerte par défaut. Chaque paire définit un multiplicateur de burn, une fenêtre longue et une fenêtre courte. Les deux premières déclenchent une page (intervention immédiate) ; les deux dernières créent un ticket (action planifiée). Ce modèle couvre à la fois les incidents catastrophiques (budget épuisé en 1h) et les dégradations lentes (budget épuisé en 30 jours).

Pièges courants

! Fenêtre trop courte : vous revenez à l'alerte sur taux brut, avec tous ses faux positifs.
! Fenêtre trop longue : vous détectez les burns tardifs mais manquez les incidents qui se résolvent vite et laissent un cratère dans votre budget.
! Oublier la condition ET : si une seule fenêtre suffit à alerter, vous perdez l'avantage de la double fenêtre.