Transition des SLOs théoriques aux alertes pratiques de burn rate qui ne réveillent l'ingénieur d'astreinte que lorsque l'expérience utilisateur se dégrade activement.
Dans la quête d'éliminer la fatigue des alertes, de nombreuses équipes réalisent que les alertes basées sur des seuils sont fondamentalement défaillantes. Si vous déclenchez une alerte quand les taux d'erreur atteignent 2%, mais que le trafic est si faible que 2% équivaut à une seule sonde synthétique échouée, vous avez paginé un ingénieur pour une anomalie statistique.
Le standard industriel en remplacement des seuils hérités est l'alerting basé sur les Objectifs de Niveau de Service (SLO). En définissant des SLIs stricts, en négociant des Budgets d'Erreur et en alertant uniquement sur les Taux de Consommation, les SREs s'assurent d'être paginés seulement lorsque les utilisateurs souffrent d'une douleur significative et soutenue.
L'une des barrières psychologiques les plus difficiles à surmonter en ingénierie est d'accepter qu'une application n'a pas besoin de 100% de disponibilité. Viser 100% de fiabilité bloque la vélocité de déploiement des fonctionnalités et déclenche d'interminables tempêtes de pages pour des problèmes microscopiques.
Habituellement, un objectif entre 99,9% (Trois Neuf, environ 43 minutes d'indisponibilité par mois) et 99,99% est idéal. Les 0,1% restants constituent votre Budget d'Erreur. C'est une allocation d'instabilité acceptable. Si vous êtes dans votre budget, les déploiements continuent et le pager reste silencieux. Si vous le consommez trop vite, le pager sonne pour arrêter le saignement.
Un Indicateur de Niveau de Service (SLI) est une métrique strictement définie et mesurable représentant l'expérience utilisateur. Le livre Google SRE définit une formule générique qui simplifie presque tous les calculs de SLI :
Good Events / Total Events * 100
Appliquons cela Ă une API Web :
Si nous recevons 10 000 requêtes et que 9 900 sont rapides et réussies, notre SLI est de 99%.
Imaginez que vous définissez une alerte à seuil statique : Paginez-moi si le SLI descend en dessous de 99% sur une fenêtre de 5 minutes.
Vous rencontrerez deux modes d'Ă©chec :
Si la base de données plante complètement et que votre SLI s'effondre à 0%, la fenêtre de 5 minutes est bien trop lente ! Vous deviez être paginé 30 secondes après le début de la panne, pas 5 minutes après.
Si une fuite mémoire lente provoque constamment l'échec de 1,5% des requêtes, votre SLI est de 98,5%. Comme il ne chute jamais drastiquement, l'alerte ne se déclenche jamais. Pourtant, sur 30 jours, les utilisateurs vivent constamment de la frustration, et vous détruisez silencieusement votre budget d'erreur mensuel.
La solution à ces modes d'échec est le Burn Rate Alerting. Au lieu de vérifier des seuils absolus, vous calculez à quelle vitesse votre Budget d'Erreur mensuel est épuisé.
Un burn rate de 1 implique que le budget sera exactement épuisé en 30 jours.
Un burn rate de 14,4 implique que le budget sera complètement épuisé en exactement 2 jours.
Nous configurons des Alertes de Burn Rate Multi-Fenêtres pour détecter les consumptions rapides et lentes :
Voici un exemple de snippet PromQL pour une alerte de combustion rapide (taux 14,4) sur une fenêtre de 1 heure pour un SLO de 99,9%. Générer ceux-ci manuellement peut être complexe, c'est pourquoi des outils comme Sloth ou Prometheus Operator sont recommandés.
sum(rate(http_requests_total{status=~"5.."}[1h]))
/
sum(rate(http_requests_total[1h]))
> (1 - 0.999) * 14.4Cela interroge exactement ce qui vous importe : consommons-nous notre tolérance aux pannes autorisée trop vite pour survivre au mois ?
Migrer des seuils bruts vers les alertes de burn rate SLO nécessite un saut de maturité pour les cultures de surveillance. Cela accepte la réalité que de petits accrocs sont acceptables, tout en garantissant une réponse immédiate directement proportionnelle à la douleur réelle de l'utilisateur.
Pour construire des SLIs en toute confiance, vous devez mesurer les véritables limites de votre infrastructure. Les vérifications HTTP synthétiques mondiales et les sondes d'anomalies DNS de Heimdall génèrent des métriques SLI parfaites, garantissant que lorsque Heimdall signale un objectif en échec, vous pouvez être absolument certain que l'utilisateur est réellement impacté.
Rejoignez des milliers d'équipes qui comptent sur Heimdall pour maintenir leurs sites web et API en ligne 24h/24 et 7j/7. Commencez avec notre plan gratuit dès aujourd'hui.
Commencer la surveillance gratuitement
Ingénieur senior en fiabilité des systèmes (SRE) axé sur la disponibilité, la réponse aux incidents et la construction de systèmes de surveillance qui révèlent les problèmes avant que les utilisateurs ne s'en aperçoivent.
