La règle fondamentale : alerter sur les symptômes, pas sur les causes, et ne notifier que ce qui est actionnable et urgent. Une alerte bruyante qui se déclenche chaque nuit est mise en sourdine ou ignorée — donc le vrai risque n'est pas une alerte manquée, c'est un on-call désensibilisé qui dort pendant la vraie.
Alerter sur les SLO visibles par l'utilisateur (taux d'erreur, latence, disponibilité), pas sur les causes internes comme « CPU > 80 % ». Un CPU élevé peut être inoffensif ; ce qui compte est si les utilisateurs sont affectés.
BAD (cause) CPU > 80% for 5m → fires constantly, often no impact
GOOD (symptom) error-rate SLO burn is fast → fires only when users hurt
Un seul seuil statique est soit trop réactif, soit trop lent. À la place, alerter sur la rapidité avec laquelle vous consommez le budget d'erreur, en utilisant deux fenêtres pour qu'une consommation rapide déclenche une notification immédiate et une consommation lente ne déclenche une notification que si elle persiste.
# Page: 2% of monthly budget burned in 1h AND still burning over 5m
- alert: HighErrorBudgetBurn
expr: |
(slo:error_ratio_1h > 14.4 * 0.001) # fast window: catch big outages
and
(slo:error_ratio_5m > 14.4 * 0.001) # short window: confirm it's still happening
for: 2m
labels: { severity: page }
La fenêtre courte empêche de notifier sur un problème qui s'est déjà auto-résolu ; la fenêtre longue empêche de notifier sur une fausse alerte brève.
PAGE actionable + urgent → wake a human now (SLO at risk, checkout down)
TICKET actionable, not urgent → fix in business hours (disk 70%, cert in 20 days)
DASHBOARD informational → no alert, just visible (per-endpoint traffic)
Si une alerte n'est pas actionnable, elle ne devrait pas déclencher une notification — transformez-la en ticket ou en panneau de tableau de bord. Ensuite, affinez au fil du temps : examinez chaque notification, supprimez celles sur lesquelles personne n'a agit.
La fatigue des alertes est un risque de fiabilité, pas juste une nuisance : les humains filtrent mentalement les canaux bruyants, donc plus vous envoyez de faux positifs, plus il est probable qu'une vraie panne soit manquée. Alerter sur les symptômes avec des fenêtres de consommation du budget, et réserver la notification pour l'urgence actionnable, fait de chaque notification quelque chose de significatif — c'est ce qui maintient l'on-call réactif.