Comment décidez-vous sur quoi alerter pour un service backend ?

Alertez sur les symptômes que les utilisateurs ressentent, définis comme des objectifs de niveau de service : disponibilité et latence mesurées en périphérie, plus des signaux de justesse comme des paiements échoués ou une file qui cesse de se vider. N'appelez quelqu'un que lorsqu'un objectif risque d'être manqué, en utilisant le taux de consommation du budget d'erreur, pour qu'une dérive lente crée un ticket et qu'une consommation rapide réveille quelqu'un. Gardez les alertes de cause comme un CPU élevé sur des tableaux de bord, pas en astreinte.

Je pars de ce qu'un utilisateur remarquerait : des requêtes qui échouent, des requêtes lentes, et les choses propres au domaine qui sont pires que les deux, comme des commandes non confirmées ou un retard de consommation qui ne cesse de monter. Ça devient des objectifs avec une cible, disons 99,9 pour cent de requêtes réussies et un 95e centile de latence sous trois cents millisecondes, mesurés au répartiteur de charge plutôt que dans l'application pour compter les échecs que mon code ne voit jamais. Ensuite la sévérité des alertes vient du taux de consommation : brûler le budget d'erreur mensuel en une heure appelle immédiatement, tandis qu'une consommation lente sur plusieurs jours est un ticket. Les métriques de cause comme le CPU, la mémoire ou le disque restent sur des tableaux de bord et dans des alertes de capacité, parce qu'un CPU chargé que personne ne ressent n'est pas un incident. Chaque appel doit être actionnable, donc il pointe vers un runbook, et tout ce qui s'est déclenché sans action est revu. Dans une équipe, on a réduit le volume d'astreinte d'environ deux tiers comme ça, et le vrai gain, c'est que les alertes restantes étaient prises au sérieux.