Transición de los SLOs teóricos a alertas prácticas de burn rate que solo despiertan al ingeniero de guardia cuando la experiencia del usuario se deteriora activamente.
En la búsqueda de eliminar la fatiga de alertas, muchos equipos se dan cuenta de que las alertas basadas en umbrales son fundamentalmente defectuosas. Si alerta cuando las tasas de error alcanzan el 2%, pero el tráfico es tan bajo que el 2% equivale a una sola sonda sintética fallida, ha activado un ingeniero por una anomalía estadística.
El estándar de la industria como reemplazo de los umbrales heredados es el alerting basado en Objetivos de Nivel de Servicio (SLO). Al definir SLIs estrictos, negociar Presupuestos de Error y alertar únicamente sobre Tasas de Consumo, los SREs garantizan que solo son llamados cuando los usuarios sufren un dolor significativo y sostenido.
Una de las barreras psicológicas más difíciles de superar en ingeniería es aceptar que una aplicación no necesita un 100% de tiempo de actividad. Buscar el 100% de confiabilidad congela la velocidad de despliegue de funcionalidades y desencadena interminables tormentas de alertas por problemas microscópicos.
Normalmente, un objetivo entre 99,9% (Tres Nueves, aproximadamente 43 minutos de inactividad al mes) y 99,99% es ideal. El 0,1% restante es su Presupuesto de Error. Es una asignación de inestabilidad aceptable. Si está dentro de su presupuesto, los despliegues continúan y el pager permanece en silencio. Si lo consume demasiado rápido, el pager suena para detener el sangrado.
Un Indicador de Nivel de Servicio (SLI) es una métrica estrictamente definida y medible que representa la experiencia del usuario. El libro de Google SRE define una fórmula genérica que simplifica casi todos los cálculos de SLI:
Good Events / Total Events * 100
Apliquemos esto a una API Web:
Si recibimos 10.000 solicitudes y 9.900 son rápidas y exitosas, nuestro SLI es del 99%.
Imagine que establece una alerta de umbral estático: Avísame si el SLI cae por debajo del 99% en una ventana de 5 minutos.
Encontrará dos modos de fallo:
Si la base de datos falla completamente y su SLI cae a 0%, la ventana de 5 minutos es demasiado lenta. Necesitaba ser alertado 30 segundos después del inicio de la interrupción, no 5 minutos después.
Si una fuga de memoria lenta hace consistentemente que el 1,5% de las solicitudes fallen, su SLI es del 98,5%. Como nunca cae drásticamente, la alerta nunca se activa. Sin embargo, durante 30 días, los usuarios experimentan constantemente frustración y silenciosamente destruye su presupuesto de error mensual.
La solución a estos modos de fallo son las Alertas de Burn Rate. En lugar de verificar umbrales absolutos, calcula a qué velocidad se está agotando su Presupuesto de Error mensual.
Una tasa de consumo de 1 implica que el presupuesto se agotará exactamente en 30 días.
Una tasa de consumo de 14,4 implica que el presupuesto se agotará completamente en exactamente 2 días.
Configuramos Alertas de Burn Rate de Múltiples Ventanas para detectar tanto consumos rápidos como lentos:
Aquí hay un ejemplo de fragmento PromQL para una alerta de consumo rápido (tasa 14,4) durante una ventana de 1 hora para un SLO del 99,9%. Generarlos manualmente puede ser complejo, por lo que se recomiendan herramientas como Sloth o Prometheus Operator.
sum(rate(http_requests_total{status=~"5.."}[1h]))
/
sum(rate(http_requests_total[1h]))
> (1 - 0.999) * 14.4Esto consulta exactamente lo que le importa: ¿Estamos consumiendo nuestra tolerancia de fallos permitida demasiado rápido para sobrevivir el mes?
Migrar de umbrales estáticos a alertas de burn rate de SLO requiere un salto de madurez en las culturas de monitoreo. Acepta la realidad de que pequeños problemas son aceptables, mientras garantiza una respuesta inmediata directamente proporcional al dolor real del usuario.
Para construir SLIs con confianza, debe medir los verdaderos límites de su infraestructura. Las comprobaciones HTTP sintéticas globales y las sondas de anomalías DNS de Heimdall generan métricas SLI perfectas, garantizando que cuando Heimdall reporta un objetivo fallido, puede estar absolutamente seguro de que el usuario está siendo impactado.
Heimdall Observer fue construido para proteger su infraestructura digital. Comience hoy con alertas en tiempo real, análisis detallados y monitoreo confiable.
Comienza Gratis
Ingeniero sénior de confiabilidad de sistemas (SRE) enfocado en la disponibilidad, respuesta a incidentes y construcción de sistemas de monitoreo que revelen problemas antes de que los usuarios lo noten.
