SLIs y SLOs mal definidos: por qué generan falsas alertas

El costo oculto del monitoreo sin contexto#

En muchos equipos el problema no es que falten métricas, dashboards o herramientas de observabilidad. El problema es más profundo: nadie ha definido con precisión qué significa que el servicio esté “bien”.

Cuando eso pasa, el resultado es predecible: alertas que no importan, ruido constante, un equipo on-call saturado y, lo más grave, incidentes reales que pasan desapercibidos entre tanto ruido.

La raíz casi siempre es la misma: SLIs y SLOs mal definidos. Se confunde telemetría interna con experiencia de usuario y se termina construyendo un sistema de alertas que reacciona a síntomas irrelevantes mientras ignora los que sí afectan al negocio.

La fatiga de alertas no es un problema cultural ni de disciplina del equipo. Es un problema de diseño de indicadores. Si cada página que llega a las 3 a. m. termina en “no había nada que hacer”, el equipo aprende a ignorarlas, y un día ignora la que sí importaba. Esta guía explica cómo romper ese ciclo desde la definición de los indicadores hasta la regla de alerta.

Documentación: Google SRE Book · Monitoring Distributed Systems ↗ · Google SRE Book · Service Level Objectives ↗

SLI, SLO y error budget en dos minutos#

Un SLI (Service Level Indicator) es una medida cuantitativa de algún aspecto del nivel de servicio que recibe el usuario. La forma más útil de expresarlo es como proporción: eventos buenos divididos entre eventos válidos. Por ejemplo, el porcentaje de peticiones de checkout que responden sin error.

Un SLO (Service Level Objective) es el objetivo sobre ese indicador en una ventana de tiempo. Por ejemplo: 99,9 % de peticiones de checkout exitosas en una ventana rodante de 30 días.

El error budget es el complemento del SLO: 1 − SLO. Con un SLO de 99,9 %, el presupuesto de error es 0,1 %. En 30 días eso equivale a unos 43 minutos de indisponibilidad total, o a su equivalente repartido en errores parciales. Ese margen no es un fracaso: es el espacio que el equipo puede “gastar” en despliegues, experimentos y fallos inevitables.

Este cambio de enfoque es lo que hace útiles a los SLOs. Ya no persigues el 100 % de disponibilidad, que es caro e innecesario para casi cualquier producto; buscas un equilibrio explícito entre confiabilidad y velocidad de entrega. Y, sobre todo, el error budget define cuándo un problema realmente importa.

Documentación: Google SRE Book · Service Level Objectives ↗ · Google SRE Workbook · Implementing SLOs ↗

El error de base: medir lo que es fácil, no lo que importa#

Hasta aquí todo suena razonable. El problema empieza cuando se elige mal el SLI. Muchos equipos monitorean CPU alta, uso de memoria, número de pods o errores internos que el usuario nunca ve. Eso no es confiabilidad desde el punto de vista del usuario: es telemetría interna, útil para diagnosticar, pero no para decidir si alguien tiene que despertarse.

Un buen SLI responde una sola pregunta: ¿el usuario pudo hacer lo que necesitaba, correctamente y a tiempo? Si el indicador no responde eso, estás midiendo lo incorrecto. Al usuario no le importa tu CPU; le importa si pudo pagar.

Los SLIs centrados en el usuario suelen caer en cuatro familias: disponibilidad (¿funciona?), latencia (¿es rápido?), calidad o corrección (¿la respuesta es correcta?) y completitud o frescura (¿el flujo terminó, los datos están al día?). Para latencia, usa percentiles como p95 o p99 en lugar de promedios: el promedio esconde la cola lenta, que es justo donde están los usuarios que peor lo pasan. Para calcular percentiles con Prometheus necesitas histogramas bien definidos, con buckets cerca de tu umbral de SLO.

Documentación: Google SRE Book · Service Level Objectives ↗ · Prometheus · Histograms and summaries ↗

Por qué aparecen las falsas alertas#

Las falsas alertas no son un problema de umbral: son un problema de significado. Aparecen cuando la métrica no representa impacto real, cuando el SLO no refleja la experiencia del usuario o cuando el sistema alerta sobre causas en lugar de consecuencias.

El ejemplo clásico: la CPU sube y se dispara una alerta, pero el sistema sigue respondiendo perfectamente. Nadie debería despertarse por eso. El libro de SRE de Google lo formula como la diferencia entre síntomas (qué está roto para el usuario) y causas (por qué). Alerta por síntomas; investiga las causas con dashboards.

Por eso conviene separar dos funciones que muchos equipos mezclan: monitorear y alertar. No todo lo que se mide debe generar una alerta.

Monitoreo, para entender e investigar el sistema:

• CPU, memoria y uso de recursos.
• Logs y trazas.
• Reintentos, timeouts y comportamiento interno.
• Colas, throughput y saturación.

Alertas, para provocar una acción humana:

• Caída real de disponibilidad en un journey crítico.
• Degradación sostenida de latencia que afecta a usuarios.
• Consumo acelerado del error budget.

Cuando esta separación no existe, todo se mezcla. Y cuando todo dispara una alerta, nada es realmente importante.

Documentación: Google SRE Book · Monitoring Distributed Systems ↗

La solución: alertar por burn rate, no por umbrales estáticos#

Las alertas tradicionales del tipo “latencia > X”, “errores > Y” o “CPU > Z” no consideran contexto ni impacto acumulado. Se disparan por picos de un minuto, por eventos irrelevantes y por situaciones que no requieren acción.

El burn rate mide la velocidad a la que consumes el error budget en relación con el SLO. Un burn rate de 1 significa que, a ese ritmo, gastarías exactamente todo el presupuesto al final de la ventana. Un burn rate de 14,4 sostenido durante una hora consume el 2 % del presupuesto mensual y, si continúa, lo agota en poco más de dos días. Eso sí merece una página.

El Google SRE Workbook recomienda combinar varias ventanas y varios burn rates: una ventana larga para confirmar que el problema es significativo y una corta para que la alerta deje de dispararse rápido cuando el problema termina. Los valores de partida que propone para un SLO de 30 días son 14,4 en 1 hora (con ventana corta de 5 minutos) y 6 en 6 horas (con 30 minutos) como páginas, y 1 en 3 días (con 6 horas) como ticket. Así detectas tanto caídas severas como degradaciones lentas pero peligrosas.

groups:
  - name: slo-checkout-recording
    rules:
      # SLI de disponibilidad expresado como ratio de errores: 5xx / total.
      - record: job:slo_errors_per_request:ratio_rate5m
        expr: |
          sum by (job) (rate(http_requests_total{job="checkout-api",code=~"5.."}[5m]))
          /
          sum by (job) (rate(http_requests_total{job="checkout-api"}[5m]))
      # Repite la misma regla cambiando la ventana: 30m, 1h, 6h y 3d.
      - record: job:slo_errors_per_request:ratio_rate1h
        expr: |
          sum by (job) (rate(http_requests_total{job="checkout-api",code=~"5.."}[1h]))
          /
          sum by (job) (rate(http_requests_total{job="checkout-api"}[1h]))

  - name: slo-checkout-alerts
    rules:
      # SLO 99,9 %: presupuesto de error = 0,001.
      - alert: CheckoutErrorBudgetBurnFast
        expr: |
          (
            job:slo_errors_per_request:ratio_rate1h{job="checkout-api"} > (14.4 * 0.001)
            and
            job:slo_errors_per_request:ratio_rate5m{job="checkout-api"} > (14.4 * 0.001)
          )
          or
          (
            job:slo_errors_per_request:ratio_rate6h{job="checkout-api"} > (6 * 0.001)
            and
            job:slo_errors_per_request:ratio_rate30m{job="checkout-api"} > (6 * 0.001)
          )
        labels:
          severity: page
        annotations:
          summary: "Checkout está consumiendo el error budget demasiado rápido"
      - alert: CheckoutErrorBudgetBurnSlow
        expr: |
          job:slo_errors_per_request:ratio_rate3d{job="checkout-api"} > 0.001
          and
          job:slo_errors_per_request:ratio_rate6h{job="checkout-api"} > 0.001
        labels:
          severity: ticket

Fíjate en dos detalles que suelen fallar en implementaciones copiadas: cada ventana usada en una alerta necesita su propia recording rule (si falta una, la expresión simplemente nunca coincide) y el umbral se expresa como burn rate multiplicado por el presupuesto, no como un porcentaje fijo de errores.

Documentación: Google SRE Workbook · Alerting on SLOs ↗ · Prometheus · Recording rules ↗ · Prometheus · Alerting rules ↗

Cómo redefinir tus SLIs y SLOs paso a paso#

• Identifica los journeys críticos del usuario. Lista los flujos que generan valor directo: login, checkout, búsqueda, carga de reportes. No los procesos internos del sistema, sino los que ejecuta el usuario final.
• Define qué significa éxito en cada flujo. No basta con que responda: debe responder correctamente y dentro de un tiempo aceptable. Por ejemplo, login exitoso en menos de 500 ms.
• Expresa cada SLI como proporción. Eventos buenos entre eventos válidos: peticiones no 5xx sobre el total, o porcentaje de respuestas bajo el umbral de latencia. Las proporciones encajan directamente en la matemática del error budget y son estables aunque el tráfico cambie.
• Fija SLOs realistas a partir de datos históricos. No elijas 99,99 % porque suena bien. Revisa el comportamiento real de los últimos meses y define un objetivo exigente pero alcanzable. Una ventana rodante de 30 días suaviza los picos puntuales.
• Alerta por burn rate, con varias ventanas. Sustituye los umbrales estáticos por alertas de consumo del presupuesto, como en el ejemplo anterior.
• Acuerda una política de error budget. Define qué ocurre cuando se agota: congelar despliegues no urgentes, priorizar trabajo de confiabilidad sobre features, revisar el postmortem. Sin esa política, el SLO es solo un número en un dashboard.
• Revisa y ajusta periódicamente. Los SLIs evolucionan con el producto. Lo que era crítico hace seis meses puede no serlo hoy; revisa indicadores y objetivos con el equipo de producto, por ejemplo cada trimestre.

Documentación: Google SRE Workbook · Implementing SLOs ↗ · Google SRE Workbook · Error budget policy ↗

Señales de que tus SLOs están mal definidos#

Algunas señales son obvias; otras requieren honestidad técnica:

• Alertas constantes, pero pocos incidentes reales.
• Alertas fuera de horario que, al revisarlas, no tienen impacto perceptible en usuarios.
• El equipo on-call dejó de leer las páginas.
• Los dashboards están en verde mientras suben los tickets de soporte.
• Los postmortems revelan que ningún monitor automático detectó el incidente: lo reportaron los usuarios.
• Hay demasiados SLIs y ninguno tiene prioridad.

La prueba más fiable es la del dashboard verde: si todo aparece en verde pero los usuarios reportan problemas en soporte o en redes, tus SLIs están desconectados de la experiencia real.

También vale la pena medir tu propio sistema de alertas. Tres indicadores sencillos: qué proporción de páginas terminan sin ninguna acción, cuánto tarda la persona on-call en decidir si una alerta es real y cuántos incidentes detecta primero el monitoreo frente a los que reportan los usuarios. Si las páginas sin acción son frecuentes, si decidir lleva demasiado tiempo o si los usuarios se adelantan a tus alertas, el problema está en los indicadores, no en las personas.

Documentación: Google SRE Book · Monitoring Distributed Systems ↗

Checklist antes de activar tu próximo SLO#

Si tu equipo está discutiendo si subir el umbral de CPU o ampliar la ventana de evaluación, probablemente está optimizando el indicador equivocado. Aplica esta verificación a cada servicio crítico antes de activar nuevas alertas:

• El SLI mide un resultado, no un esfuerzo: refleja una acción completada por el usuario, por ejemplo el porcentaje de checkouts con respuesta exitosa en menos de 500 ms.
• El SLO está validado con datos reales: revisaste el cumplimiento histórico del SLI y el objetivo es alcanzable pero exigente.
• Las alertas usan burn rate con ventana larga y corta, para anticipar el agotamiento del presupuesto sin reaccionar a picos aislados.
• Cada alerta que puede despertar a alguien está atada a un SLO. Las que no, pasan a dashboard o a notificación informativa, o se eliminan.
• Existe una política de error budget acordada con producto.

Regla práctica para validar cualquier SLI: pregúntate “si este indicador se cumple, ¿el usuario tuvo una buena experiencia?”. Si la respuesta no es un sí claro y directo, reemplázalo por uno que mida el resultado de una acción crítica: checkout completado, login exitoso, búsqueda con resultados.

Documentación: Google SRE Workbook · Implementing SLOs ↗

Cierre: el problema no es la cantidad de alertas#

El problema no es tener muchas o pocas alertas; es tener alertas que no significan nada. Un buen sistema de confiabilidad no mide infraestructura, mide experiencia. Y un buen sistema de alertas no detecta cualquier anomalía: detecta riesgo real.

Cuando los SLIs y SLOs están mal definidos, las consecuencias van más allá del ruido: burnout del equipo on-call, decisiones basadas en señales incorrectas, pérdida de confianza en el monitoreo, incidentes más largos y menos tiempo para mejorar el producto. Lo más peligroso es que el sistema puede parecer “bien” en sus métricas internas mientras los usuarios ya están teniendo una mala experiencia.

Ni el autoscaling ni una herramienta nueva arreglan esto. Todo empieza por definir con claridad qué significa que tu servicio funcione.