Diseñar alertas que nadie ignora

Cada alerta que salta sin necesitar a una persona está, en silencio, enseñando a tu equipo a ignorar la siguiente. Hazlo unas semanas y la alerta que de verdad importa acaba en un canal que nadie lee, o se descarta a las 3 de la mañana junto a las otras diecisiete que no importaban. Lo caro no es la caída que se te escapó: es el ingeniero de on-call que ha aprendido, con toda la razón, que las alertas son ruido de fondo.

Así que el objetivo aquí no es 'más monitorización'. Es lo contrario: un puñado de alertas en las que cada una significa que alguien tiene que actuar ya, conectadas al ritmo al que estás consumiendo tu presupuesto de error, con todo lo demás enviado a donde no despierta a nadie. Voy a deducir las cuentas, darte reglas de Prometheus listas para pegar y hablar del proceso que lo mantiene honesto.

Si una persona no tiene que tomar una decisión inteligente, no debería recibir un page. Aplica esa única regla sin piedad y desaparece casi todo el ruido.

El ruido es, en sí mismo, un problema de fiabilidad

Trata el on-call como cualquier otro sistema con un SLO. Un objetivo sensato es no más de uno o dos pages accionables por turno, y prácticamente cero pages falsos. En cuanto lo superas, el tiempo hasta que alguien reacciona se dispara, la gente silencia los canales y la confianza en todo el sistema de alertas se viene abajo, algo mucho más peligroso que cualquier panel en rojo.

Cada page falso gasta algo difícil de recuperar: la suposición de que un page es real. Protege esa suposición como protegerías los datos de producción.

La mayor parte del dolor del on-call es un problema de ruido y de enrutamiento: decenas de alertas de causa se reducen a un puñado de pages que de verdad necesitan a una persona.

Tres destinos, solo uno despierta a alguien

Antes de ajustar un solo umbral, decide a dónde van las señales. La mayoría de los líos de alertas son, en el fondo, líos de enrutamiento: estaba todo apuntando al pager.

Page — alguien debe actuar en minutos. Reservado para daño visible al usuario, sostenido y quemando presupuesto deprisa.
Ticket — alguien debe actuar, pero puede esperar al horario laboral: fugas lentas de presupuesto, tendencias de capacidad, un certificado que caduca la semana que viene.
Dashboard / registro — solo conciencia. No se despierta a nadie; alimenta la vista de on-call y la revisión semanal.

Tu pico de error de un segundo, que se recuperó solo, pertenece al tercer cubo: visible en un dashboard, registrado contra el presupuesto, revisado más tarde. Es real, te costó algo, y desde luego no merece una llamada.

Decide a dónde va cada señal antes de tocar un umbral. Solo el page despierta a alguien; el pico de un segundo que se recuperó pertenece a un dashboard.

Alerta sobre síntomas, no sobre causas

Las alertas basadas en causas — 'CPU > 80%', 'disco al 90%', 'pod reiniciado' — saltan a todas horas y rara vez coinciden con un usuario sufriendo. Los sistemas modernos van calientes y reinician cosas a propósito; eso es sano, no es un incidente. Las alertas basadas en síntomas avisan de lo que el usuario siente de verdad:

¿Fallan las peticiones? (ratio de errores)
¿Van lentas hasta el punto de que el usuario lo nota? (SLI de latencia)
¿El trabajo está saliendo? (rendimiento, antigüedad de la cola, frescura de los datos)

Alerta sobre el síntoma y podrás borrar la mayoría de las alertas de causa: te enterarás de que el disco se llenó porque las peticiones empezaron a fallar, y te enterarás con un page en vez de nueve. Las causas pertenecen a los dashboards y a los runbooks, donde ayudan a diagnosticar, no al pager, donde solo compiten por tu atención.

Alerta sobre lo que el usuario siente; deja las causas en los dashboards y los runbooks, donde ayudan a diagnosticar en vez de competir por la atención.

Por qué un solo umbral nunca puede ganar

La alerta de SLO ingenua es 'avísame cuando estemos quemando presupuesto'. Elige una sola ventana y te ves abocado a un mal compromiso. Corta, se vuelve nerviosa: un hipo de 30 segundos despierta a alguien por un problema que ya se arregló solo. Larga, se vuelve lenta: puedes estar 20 minutos en plena caída antes de que salte nada.

Es exactamente el problema del pico de un segundo. Un pico breve consume una porción del presupuesto (cierto, y conviene registrarlo) pero nunca debería dar page, y un solo umbral no distingue 'breve y recuperado' de 'sostenido y a peor'. Necesitas dos escalas de tiempo a la vez.

Burn rate, desde el principio

Empieza por el presupuesto. Un SLO de disponibilidad del 99,9% durante 30 días permite que falle el 0,1% de las peticiones: ese es tu presupuesto de error, unos 43 minutos de caída total equivalente al mes. Gástalo despacio y vas bien; gástalo en una tarde y tienes un incidente.

Burn rate es la rapidez con que gastas frente a 'justo dentro del presupuesto'. Un burn rate de 1 gasta exactamente el 100% del presupuesto a lo largo de la ventana del SLO: sostenible. Un burn rate de 14,4 gasta 14,4× demasiado rápido: a ese ritmo arrasarías el presupuesto entero de 30 días en unos dos días, y ya has quemado el 2% en la última hora.

burn_rate = (errores / total) / (1 - SLO)

# SLO del 99.9%  ->  1 - SLO = 0.001
# si ahora mismo falla el 1.44% de las peticiones:
#   burn_rate = 0.0144 / 0.001 = 14.4
#
# presupuesto gastado en una ventana = burn_rate * (ventana / periodo_SLO)
#   14.4 * (1h  / 720h) =  2%   del presupuesto de 30 dias, en una hora
#    6   * (6h  / 720h) =  5%   en seis horas
#    1   * (72h / 720h) = 10%   en tres dias

Esas tres filas no son arbitrarias: son los niveles de alerta. Decide cuánto presupuesto estás dispuesto a perder antes de molestar a una persona, y el burn rate y la ventana salen directos de las cuentas.

Cada nivel de burn rate no es más que una pendiente. 14.4× vacía un presupuesto de 30 días en unos dos días, 6× en cinco, 1× llega justo al día 30 — y de ahí salen los umbrales de alerta.

Multi-ventana, multi-burn-rate

La solución a la trampa del umbral único es vigilar una ventana larga y una corta a la vez, con más de un burn rate. La ventana larga confirma que el problema es real y sostenido; la corta — más o menos una doceava parte de la larga — hace que la alerta salte rápido y, sobre todo, se apague rápido cuando te recuperas. La alerta solo salta cuando ambas ventanas superan el umbral.

Un pico de un segundo dispara la ventana corta pero nunca la larga, así que nunca da page; una quema sostenida dispara ambas y sí. La ventana corta también hace que la alerta se apague a los pocos minutos de recuperarte, y eso es lo que acaba con el flapping.

La severidad viene del burn rate, no de apilar ventanas del mismo tamaño. Quema rápida y pronunciada = despierta a alguien ya. Quema lenta y suave = un ticket para mañana:

SEVERIDAD   BURN    VENTANA-L  VENTANA-C   PRESUP. GASTADO   DESTINO
------------------------------------------------------------------
critico     14.4x   1h         5m          2%  en 1 hora     page
alto         6x     6h         30m         5%  en 6 horas    page
aviso        1x     3d         6h          10% en 3 dias     ticket

Léelo como lo describirías en voz alta: una quema pronunciada en un horizonte corto es un page crítico; una quema suave que solo aparece al cabo de días es un ticket de aviso para la fuga lenta que el nivel rápido dejaría pasar. Corre los tres a la vez: no chocan, cubren formas de fallo distintas.

La ventana corta es la parte que mata el ruido. Como la alerta también necesita la ventana corta encendida, deja de saltar a los pocos minutos de recuperarte, en vez de arrastrarse durante toda la ventana larga. Eso es lo que acaba con el flapping, y con el page de las 3 de la mañana por algo que se arregló hace 90 segundos.

Las queries

Calcula el SLI una sola vez

Define el síntoma una sola vez como un ratio de errores. En Prometheus lo precalculas por ventana con recording rules — barato, legible y reutilizado por todos los dashboards. En Datadog defines el SLI una vez en un SLO basado en métricas y él calcula las ventanas por ti.

groups:
- name: payments-slo
  rules:
  # SLI del síntoma: fracción de peticiones malas (5xx o demasiado lentas)
  - record: job:sli_err:ratio5m
    expr: |
      sum(rate(http_requests_total{job="payments",code=~"5.."}[5m]))
      / sum(rate(http_requests_total{job="payments"}[5m]))
  - record: job:sli_err:ratio1h
    expr: |
      sum(rate(http_requests_total{job="payments",code=~"5.."}[1h]))
      / sum(rate(http_requests_total{job="payments"}[1h]))
  # ...repite para las ventanas de 30m, 6h y 3d sobre las que alertas

# Datadog calcula las ventanas por ti: define el SLI una vez como un
# SLO basado en métricas (eventos buenos / eventos totales). El ratio de error crudo:
100 * (
  sum:trace.http.request.errors{service:payments}.as_count()
  / sum:trace.http.request.hits{service:payments}.as_count()
)

Alert rules — multi-ventana, multi-burn-rate

El SLO es 99,9%, así que el denominador del presupuesto es 0,001. Cada nivel necesita que tanto su ventana larga como la corta superen el burn rate antes de dispararse — escrito de forma explícita en Prometheus, y un parámetro nativo del monitor de burn rate de Datadog.

- alert: PaymentsBudgetFastBurn
  expr: |
    job:sli_err:ratio1h / 0.001 > 14.4
    and
    job:sli_err:ratio5m / 0.001 > 14.4
  labels: { severity: page }
  annotations:
    summary: "Payments quemando presupuesto a 14,4x (2%/h)"
    runbook: "https://runbooks/payments/error-budget"

- alert: PaymentsBudgetSlowBurn
  expr: |
    job:sli_err:ratio3d / 0.001 > 1
    and
    job:sli_err:ratio6h / 0.001 > 1
  labels: { severity: ticket }
  annotations:
    summary: "Payments con fuga lenta de presupuesto (10%/3d)"
    runbook: "https://runbooks/payments/error-budget"

# Datadog hace multi-ventana de forma nativa — un monitor de burn rate sobre el SLO,
# con las ventanas larga y corta como parámetros:

# quema rápida -> page  (2% del presupuesto de 30 días en 1h)
burn_rate("payments-availability").over("30d").long_window("1h").short_window("5m") > 14.4

# quema lenta -> ticket  (10% en 3 días)
burn_rate("payments-availability").over("30d").long_window("3d").short_window("6h") > 1

Mete el nivel de 6× / 6h / 30m en medio y has cubierto caídas rápidas, degradaciones medias y fugas lentas con tres alertas por servicio — no treinta.

Cada page tiene que ganarse su sitio

Las cuentas te dan una señal limpia; el proceso la mantiene limpia. Somete cada page a cuatro pruebas:

Accionable — si el on-call no puede hacer nada ahora mismo, es un ticket o se borra.
Tiene runbook — el page enlaza a 'qué pasa y por dónde empezar', no a una búsqueda en la wiki a las 3 de la mañana.
Tiene dueño — llega a exactamente un equipo, y ese equipo puede cambiarlo.
Aporta algo nuevo — dice algo que el page anterior no decía; agrupa los duplicados.

Luego haz baratos y regulares dos hábitos. Una revisión semanal del presupuesto de error: cuánto gastamos, en qué, vamos a tiempo. Y una revisión de alertas: repasa cada page que saltó y, para cada uno, mantenlo, arréglalo o bórralo. Borrar alertas es el trabajo de fiabilidad más infravalorado que existe.

Anti-patrones para borrar esta semana

Umbrales fijos sobre métricas irregulares ('CPU > 80%'): saltan con carga sana.
Pages de disco o memoria por máquina: alerta sobre el síntoma visible al usuario; el resto se planifica como tickets.
Pages 'informativos': una contradicción; mándalos a un dashboard.
Alertar sobre una causa cuyo síntoma ya alertas: recibirás dos pages por un mismo incidente.
Cualquier alerta sin runbook y sin dueño: nadie puede actuar, así que es puro ruido.

Cómo llegar sin volar a ciegas

Define un SLI y un SLO por recorrido de usuario (checkout, login, pagos): síntomas, no máquinas.
Añade las recording rules para las ventanas en las que vayas a alertar.
Despliega los tres niveles de burn rate solo en modo ticket primero: aún sin pages.
Observa dos o tres semanas; compara lo que habría dado page con lo que fue de verdad un incidente.
Asciende el nivel rápido a page; mantén el lento como tickets.
Borra los pages de causa que esto vuelve redundantes, de uno en uno y mirando el presupuesto.
Monta la revisión semanal del presupuesto y la revisión de alertas, y sigue podando.

El objetivo nunca fue 'menos alertas' como métrica de vanidad. Es que, cuando suena el teléfono, sea real, sea accionable y haya un runbook esperando, para que la gente confíe, conteste, y el sistema siga siendo fiable porque las personas que lo defienden no están agotadas.