3 h 12, PagerDuty : « Disque 75 % staging-db ». L'astreinte snooze. 3 h 28 : « Mémoire haute prometheus-dev ». Snooze. 4 h 05 : « Taux erreur paiement 15 % prod » — noyé dans le bruit, lu à 9 h. Perte estimée : quatre heures de ventes.
La fatigue d'alertes n'est pas un problème d'outil. C'est un problème de contrat : trop de signaux sans gravité, sans runbook, sans responsable — jusqu'à ce que le canal devienne spam et que l'urgence réelle passe inaperçue. Prometheus, Datadog ou Grafana ne créent pas le bruit : une gouvernance absente le laisse s'accumuler.
Gravité, routage et règle de page
| Niveau | Canal | Exemple |
|---|---|---|
| P1 critical | Pager téléphone | Paiement down, perte données |
| P2 | Slack @oncall | p95 x2 30 min |
| P3 | Ticket | Tendance disque 7 j |
| Info | Tableau de bord | Planification capacité |
Une alerte sans lien runbook et sans responsable service devrait être interdite en production. Si l'astreinte ne sait pas quoi faire en soixante secondes, ce n'est pas une alerte — c'est une notification.
Chaque page nocturne doit changer une action concrète — sinon elle n'aurait jamais dû partir.
Symptômes utilisateur vs métriques vanity
Bon : taux d'erreurs 5xx sur checkout ; burn rate SLO multi-fenêtre. Mauvais : processeur supérieur à soixante pour cent sans corrélation ; certificat expire dans trente jours (un ticket suffit).
Prometheus Alertmanager permet le group_by et l'inhibition : si le datacenter est down, inhiber les alertes enfants évite une avalanche inutile. Mais l'outil ne remplace pas le choix des signaux — voir Métriques Prometheus pour instrumenter ce qui compte.
Fenêtres, hysteresis et flapping
for: 10m évite un pic unique. Seuils avec marge : repager seulement si la situation est pire qu'hier et au-dessus du SLO. Le flapping signale un mauvais seuil ou une mauvaise métrique — corrigez la racine, ne répétez pas le silence.
Une alerte qui oscille entre déclenchée et résolue toutes les dix minutes use l'équipe plus qu'une panne réelle. Mesurez le taux de faux positifs trimestriellement.
Propriété et revue trimestrielle
Auditez : déclenchée les quatre-vingt-dix derniers jours ? Action prise ? Taux de faux positifs ? Supprimez impitoyablement le bruit. La préproduction ne doit pas pager la même rotation prod — label env=staging → ticket uniquement.
Chaque alerte doit avoir un propriétaire nommé — pas « l'équipe infra ». Sans ownership, personne ne défend la suppression du bruit ni l'amélioration du runbook.
Astreinte humaine : sommeil et rotation
Rotation d'au moins trois personnes, passation documentée, compensation temps. Post-incident : alerte manquante ? trop bruyante ? ajustez — sans blâme. Une astreinte épuisée rate les vraies urgences autant qu'une alerte mal calibrée. Documentez aussi qui peut silencer une alerte et pendant combien de temps — un silence permanent sur staging est sain ; un silence permanent sur paiement est une panne non traitée.
Le sommet : monitoring qui pleure loup
Décider et avancer sans angle mort
Reclassez d'abord les alertes existantes par gravité réelle et impact utilisateur. Remplacez ensuite les seuils processeur par des alertes basées sur les SLO utilisateur quand la corrélation le permet. Ajoutez un runbook à chaque alerte qui réveille quelqu'un la nuit. Planifiez une revue trimestrielle avec suppression explicite du bruit. Isolez la préproduction de la rotation nocturne production. Comparez le monitoring managé via l'annuaire et le comparateur. Visez plus de quatre-vingts pour cent de pages nocturnes actionnables.
Questions fréquentes
Combien d'alertes pager en prod ?
Peu — chaque page exige une action immédiate. Le reste va en ticket ou tableau de bord. Moins de cinq pages éveillées par semaine si bien calibré ; au-delà, l'équipe normalise le bruit.
Quelle différence warning vs critical ?
Critical page avec runbook et responsable ; warning en heures ouvrées seulement. Ne jamais mélanger les deux chaînes nocturnes — cela détruit la crédibilité de l'astreinte.
Comment tester une alerte ?
Exercice simulé, injection d'erreur, vérification du déclenchement et du runbook. Une alerte jamais testée est probablement fausse ou ignorée. Planifiez un game day trimestriel.
Alertes infra vs SLO utilisateur ?
Symptômes utilisateur d'abord ; processeur seulement si corrélation prouvée. Un processeur élevé sans impact utilisateur ne devrait pas réveiller personne.
Une alerte qui ne change pas une action nocturne ne devrait pas réveiller personne.