¿Cómo diseñás alerting que no provoque fatiga por alertas — cómo es en la práctica el alerting basado en SLO?
Alertar a alguien por cada pico de CPU lo entrena para ignorar las alertas; el alerting basado en SLO y burn-rate solo despierta a alguien cuando los usuarios realmente están siendo afectados, y rápido.
APRENDE HACIENDOPon a prueba tu intuición3 pasos
¿Cómo diseñás alerting que no provoque fatiga por alertas — cómo es en la práctica el alerting basado en SLO?
Usa los ejemplos y la explicación de la lección para comprobar tu idea.
Reflexión personal. No se envía a ningún servicio de IA.#La fatiga por alertas es una falla de diseño, no un problema de herramientas
La fatiga por alertas ocurre cuando el volumen y el ruido de las alertas entrena a las personas que las reciben a dejar de confiar en ellas como señal — terminan silenciándolas, posponiéndolas o confirmándolas en piloto automático, y para cuando llega una alerta genuinamente grave recibe la misma atención a medias que las noventa falsas alarmas anteriores. La causa raíz casi nunca es "necesitamos una mejor herramienta de paging." Es que las reglas de alerta se diseñaron alrededor de lo que es fácil de medir (una métrica cruzó un umbral) en lugar de alrededor de lo que realmente importa (¿los usuarios están siendo afectados, ahora mismo, lo suficientemente grave como para justificar despertar a alguien?).
#Alerting basado en causa: técnicamente correcto, prácticamente agotador
El enfoque ingenuo del alerting es instrumentar cada modo de falla plausible y alertar sobre cada uno individualmente: CPU por encima del 80%, disco por encima del 90%, un pod que reinició, una pausa de GC que superó los 200ms, una réplica de veinte que no está sana, profundidad de cola por encima de algún número arbitrario. Esto es alerting basado en causa — estás alertando sobre una causa raíz potencial de un problema, no sobre el problema en sí.
El problema es que las causas son numerosas, frecuentemente se autocorrigen, y solo a veces producen impacto real en el usuario. Que un pod reinicie es normal durante un rolling deploy. CPU al 85% durante dos minutos en un pico de tráfico que el autoscaling maneja sin drama no es un incidente. Si cada una de estas cosas le llega a una persona, la mayoría de las alertas son falsos positivos respecto de lo que realmente te importa —si los clientes pueden usar el producto— y ese es exactamente el patrón que entrena a la gente a ignorar las alertas.
#Alerting basado en síntoma / SLO: alertar sobre el dolor del usuario
La alternativa es alertar sobre síntomas — el comportamiento visible para el usuario contra el cual están definidos tus Service Level Objectives, típicamente disponibilidad (proporción de requests exitosos) y latencia (proporción de requests bajo cierto umbral). En lugar de "el disco está al 90%," la alerta es "la tasa de error de checkout-api estuvo por encima de lo sostenible para todavía cumplir nuestro SLO mensual." La causa —¿es el disco, es un mal deploy, es una dependencia downstream?— pasa a ser algo que el ingeniero de guardia investiga después de que lo llamen, usando dashboards y trazas, no algo que lo llama directamente.
Este único cambio colapsa docenas de posibles alertas basadas en causa en un puñado de alertas basadas en síntoma por servicio, porque casi todos los modos de falla sobre los que alertarías individualmente —un mal deploy, disco lleno, una caída downstream, thrashing de GC, un vecino ruidoso— se manifiestan como los mismos dos o tres síntomas visibles para el usuario: más errores, o respuestas más lentas. Igual querés dashboards y causas de menor urgencia visibles para la fase de investigación; simplemente no querés que suene el teléfono de una persona por cada una de ellas.
#Alerting por burn-rate: el mecanismo que hace que el alerting por SLO funcione de verdad
Acá está la parte fácil de arruinar: no podés alertar directamente "incumplimos nuestro SLO," porque un SLO se define sobre una ventana larga (comúnmente 28 o 30 días), y para cuando efectivamente incumpliste un SLO de 30 días, el daño ya está hecho y la alerta no sirve — querés saberlo horas antes de que el SLO se incumpla, y querés saber con qué urgencia.
El mecanismo es el burn rate: qué tan rápido estás consumiendo tu error budget en relación a la tasa que lo agotaría justo al final de la ventana del SLO. Un burn rate de 1x significa "estoy consumiendo el budget exactamente a la tasa que lo vacía justo en el límite de la ventana — todo normal." Un burn rate de 10x significa "a este ritmo, todo el budget de 30 días desaparece en tres días." La idea clave de la práctica de SRE de Google (alerting multi-ventana y multi-burn-rate) es que evaluás el burn rate sobre varias ventanas de tiempo a la vez, porque una ventana corta sola es demasiado ruidosa (un pico de dos minutos dispara una alerta por algo que se resuelve solo) y una ventana larga sola es demasiado lenta (un incidente que quema el budget rápido de verdad tarda horas en alertar si solo mirás un promedio de 6 horas).
El patrón estándar usa dos condiciones combinadas:
- Burn rápido — por ejemplo, burn rate ≥ 14.4x sostenido sobre una ventana de 1 hora (con una ventana corta de confirmación de 5 minutos para evitar disparar por una sola muestra ruidosa) — alerta de inmediato, con page. A ese ritmo, el 2% de todo el budget mensual desaparece en una hora; sin control, el budget completo se agota en unos dos días.
- Burn lento — por ejemplo, burn rate ≥ 6x sostenido sobre una ventana de 6 horas — crea un ticket o una notificación de baja urgencia, no un page. Es real, pero no es "despertar a alguien a las 3 de la mañana" urgente.
#Qué compone en la práctica una política de alerting basada en SLO
| Clase de alerta | Ventana(s) | Umbral de burn-rate | Urgencia | Disparador típico |
|---|---|---|---|---|
| Burn rápido | 1h + confirmación 5m | ≥ 14.4x | Page inmediato | Mal deploy, caída de una dependencia dura |
| Burn lento | 6h + confirmación 30m | ≥ 6x | Ticket, horario laboral | Degradación gradual de capacidad, fuga lenta |
| Budget agotado | Ventana móvil de 28–30 días | Budget restante ≈ 0 | Dispara una política, no un page | Feature freeze, trabajo obligatorio de confiabilidad |
Las cuatro señales doradas del libro de SRE de Google —latencia, tráfico, errores y saturación— siguen siendo las dimensiones correctas para instrumentar, pero el punto del alerting basado en SLO es que típicamente solo errores y latencia (las dos que el usuario experimenta directamente) llegan a alertar a una persona; tráfico y saturación quedan como señales de dashboard/diagnóstico que mirás después de una alerta basada en síntoma, para encontrar la causa.
🧠 Check your understanding
0/3 · 0/3 answered1. ¿Cuál es el principal problema del alerting puramente basado en causa (por ejemplo, alertar por cada instancia de CPU > 80%, disco > 90%, o un pod que reinicia)?
2. ¿Por qué las alertas de burn-rate típicamente evalúan dos ventanas a la vez (por ejemplo, una ventana de 1 hora con una confirmación de 5 minutos) en vez de una sola ventana?
3. En el alerting basado en SLO, ¿qué típicamente dispara un page directo a una persona, versus qué se investiga después del page?