Alertas sin fatiga: SLO y presupuestos de error en la práctica

La fatiga de alertas tiene un patrón conocido. Cada incidente deja una alerta nueva, nadie retira las viejas, y al cabo de un tiempo el turno recibe cientos de avisos por noche. La mayoría no exige acción. El equipo aprende a ignorarlos, y el día que llega el aviso importante, se pierde entre el ruido.

Agregar más reglas no resuelve esto. Lo que funciona es cambiar el criterio: alertar cuando el servicio está fallando a sus usuarios de una forma que importa, y solo entonces. Los objetivos de nivel de servicio (SLO) y los presupuestos de error dan un método concreto para hacerlo.

SLI, SLO y presupuesto de error

Tres conceptos, en este orden:

• SLI (indicador de nivel de servicio): una medida de cómo vive el usuario el servicio. La forma más práctica es una proporción: eventos buenos sobre eventos válidos. Por ejemplo, solicitudes respondidas sin error y en menos de 500 ms, sobre el total de solicitudes.
• SLO (objetivo de nivel de servicio): el valor que ese indicador debe alcanzar en una ventana de tiempo. Por ejemplo, 99,9 % de solicitudes buenas en 30 días.
• Presupuesto de error: lo que el SLO permite fallar. Con un SLO de 99,9 %, el presupuesto es 0,1 % de los eventos de la ventana.

El presupuesto cambia la conversación. Ya no se discute si un error es aceptable en abstracto. Se pregunta cuánto presupuesto queda y a qué velocidad se está gastando. Mientras haya presupuesto, el equipo puede desplegar y experimentar. Si se agota, conviene priorizar la confiabilidad sobre las funciones nuevas hasta recuperarlo.

Cómo elegir buenos SLI

• Mide lo más cerca posible del usuario: en el balanceador, en la puerta de enlace de APIs o en el cliente, no en el disco del servidor.
• Empieza con pocos: disponibilidad (proporción de respuestas sin error) y latencia (proporción de respuestas por debajo de un umbral) cubren la mayoría de los servicios.
• Define qué cuenta como evento válido. Por ejemplo, un error 4xx causado por datos mal enviados por el cliente normalmente no debe consumir presupuesto.
• No fijes el SLO en 100 %. Ningún servicio lo cumple, y un objetivo imposible deja de orientar decisiones.

Alertar por síntomas, no por causas

Una causa es algo que puede producir un problema: CPU alta, una réplica caída, un disco al 85 %. Un síntoma es el problema tal como lo vive el usuario: errores, lentitud, operaciones que no se completan.

Alertar por causas tiene dos defectos. Genera avisos cuando no hay impacto (la CPU al 95 % puede ser normal en un proceso por lotes) y deja huecos cuando hay impacto sin causa prevista (un error de configuración no sube la CPU). Alertar por síntomas invierte la lógica: se avisa cuando los usuarios sufren, sea cual sea la causa.

Esto no significa eliminar las métricas de causa. Siguen siendo esenciales para diagnosticar. La diferencia está en el destino: las señales de causa alimentan los tableros y el análisis; las alertas que despiertan a alguien se reservan para los síntomas. El capítulo "Monitoring Distributed Systems" del libro de SRE de Google desarrolla este criterio.

Tasa de consumo: la medida que hace útil el SLO

Alertar directamente sobre el SLO tiene un problema. Si se avisa cuando la tasa de error supera 0,1 % en los últimos cinco minutos, cualquier pico breve dispara una alerta, aunque consuma una fracción mínima del presupuesto. Si se espera a que el SLO de 30 días se incumpla, ya es tarde.

La solución es la tasa de consumo (burn rate): la velocidad a la que se gasta el presupuesto, comparada con la velocidad que lo agotaría justo al final de la ventana.

• Una tasa de consumo de 1 gasta exactamente el presupuesto en los 30 días.
• Una tasa de 2 lo agota en 15 días.
• Una tasa de 14,4 lo agota en poco más de dos días (720 horas divididas por 14,4 dan 50 horas).

La tasa de consumo se calcula dividiendo la tasa de error observada entre la tasa de error que permite el SLO. Con un SLO de 99,9 %, una tasa de error de 1,44 % equivale a una tasa de consumo de 14,4.

Alertas por tasa de consumo en varias ventanas

El Site Reliability Workbook de Google, en el capítulo "Alerting on SLOs", recorre varias formas de alertar sobre SLO y recomienda una combinación: varias tasas de consumo, cada una evaluada en dos ventanas.

Por qué varias tasas de consumo

Un problema grave consume mucho presupuesto en poco tiempo y exige una respuesta inmediata. Un problema leve y sostenido lo consume despacio, pero también lo agota si nadie actúa. Por eso se definen varios niveles. Para un SLO de 30 días, el Workbook propone como punto de partida:

Presupuesto consumido	Ventana larga	Ventana corta	Tasa de consumo	Acción
2 %	1 hora	5 minutos	14,4	Aviso inmediato (page)
5 %	6 horas	30 minutos	6	Aviso inmediato (page)
10 %	3 días	6 horas	1	Ticket

Estos valores son un punto de partida razonable, no una regla fija. Cada organización debe ajustarlos según la criticidad del servicio y su capacidad de respuesta.

Por qué dos ventanas

La ventana larga asegura que se ha consumido una parte significativa del presupuesto, lo que evita alertas por picos breves. Pero tiene un efecto secundario: cuando el problema se resuelve, la ventana larga sigue mostrando una tasa alta durante un buen rato y la alerta tarda en apagarse.

La ventana corta corrige eso. La alerta solo se activa si la tasa de consumo supera el umbral en ambas ventanas a la vez. Así, cuando el problema termina, la ventana corta baja enseguida y la alerta se apaga. El Workbook sugiere que la ventana corta dure aproximadamente un doceavo de la larga, como en la tabla.

Ejemplo práctico

Este ejemplo es ilustrativo; los números no corresponden a ningún servicio real.

Supón una API de pagos con este SLO: el 99,9 % de las solicitudes válidas se responden sin error de servidor en una ventana de 30 días. Si la API recibe, por ejemplo, 10 millones de solicitudes al mes, el presupuesto es de 10.000 solicitudes fallidas.

Una alerta de tasa de consumo 14,4 en una hora significa que la tasa de error supera 1,44 % durante esa hora. Con ese volumen, en una hora llegan unas 13.900 solicitudes, y 1,44 % de ellas son unas 200: el 2 % del presupuesto mensual. Si nadie actuara, el presupuesto completo se agotaría en unas 50 horas.

Así se vería en reglas de alerta de Prometheus, con las dos condiciones de aviso inmediato. Las métricas y etiquetas son de ejemplo:

# Ejemplo: SLO de 99,9 % (presupuesto de error 0,001) para la API de pagos
groups:
  - name: slo-api-pagos
    rules:
      # 2 % del presupuesto en 1 hora: tasa de consumo 14,4
      - alert: PagosConsumoRapidoPresupuesto
        expr: |
          (
            sum(rate(http_requests_total{job="api-pagos",code=~"5.."}[1h]))
            /
            sum(rate(http_requests_total{job="api-pagos"}[1h]))
          ) > (14.4 * 0.001)
          and
          (
            sum(rate(http_requests_total{job="api-pagos",code=~"5.."}[5m]))
            /
            sum(rate(http_requests_total{job="api-pagos"}[5m]))
          ) > (14.4 * 0.001)
        labels:
          severity: page
        annotations:
          summary: "API de pagos: consumo rápido del presupuesto de error"

      # 5 % del presupuesto en 6 horas: tasa de consumo 6
      - alert: PagosConsumoSostenidoPresupuesto
        expr: |
          (
            sum(rate(http_requests_total{job="api-pagos",code=~"5.."}[6h]))
            /
            sum(rate(http_requests_total{job="api-pagos"}[6h]))
          ) > (6 * 0.001)
          and
          (
            sum(rate(http_requests_total{job="api-pagos",code=~"5.."}[30m]))
            /
            sum(rate(http_requests_total{job="api-pagos"}[30m]))
          ) > (6 * 0.001)
        labels:
          severity: page
        annotations:
          summary: "API de pagos: consumo sostenido del presupuesto de error"

En producción conviene precalcular las proporciones con reglas de grabación (recording rules) para no repetir consultas costosas. Plataformas como Dynatrace o Datadog ofrecen funciones nativas de SLO y alertas por tasa de consumo; el razonamiento es el mismo aunque cambie la configuración.

Cómo llevarlo a la operación

1. Inventaria las alertas actuales y clasifícalas: síntoma, causa o informativa. Revisa cuántas generaron una acción real en los últimos meses.
2. Define SLI y SLO para los servicios críticos, junto con el dueño de negocio. El SLO es un acuerdo, no solo un número técnico.
3. Implementa las alertas por tasa de consumo para esos servicios y conviértelas en las únicas que despiertan al turno por esos servicios.
4. Baja de nivel las alertas por causa: a tableros, tickets o contexto dentro del incidente.
5. Revisa el presupuesto con regularidad con producto y desarrollo, y acuerda qué pasa cuando se agota.
6. Ajusta después de cada incidente: ¿la alerta llegó a tiempo?, ¿sobró alguna?, ¿el SLI reflejó lo que sintió el cliente?

Un caso que requiere cuidado son los servicios con poco tráfico. Con pocas solicitudes por hora, un solo error puede disparar una tasa de consumo alta. Las opciones habituales son agrupar servicios relacionados, generar tráfico sintético o ajustar las ventanas. El Workbook trata este caso en el mismo capítulo.