SLIs y SLOs mal definidos 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: no sabemos qué significa realmente que el servicio esté “bien”.

Y cuando eso pasa, ocurre lo inevitable: alertas que no importan, ruido constante, equipos saturados e incidentes reales que pasan desapercibidos.

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.

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

Un SLI (Service Level Indicator) es una métrica que mide el comportamiento del servicio desde la perspectiva del usuario. Un SLO (Service Level Objective) es el objetivo sobre ese indicador en un periodo de tiempo definido.

Ejemplo: SLI = porcentaje de peticiones exitosas. SLO = 99.9% de éxito en 30 días rodantes.

Hasta ahí todo bien. El problema empieza cuando eliges mal el SLI. Muchos equipos monitorean CPU alta, uso de memoria, número de pods o errores internos no visibles. Eso no es confiabilidad desde el punto de vista del usuario: eso es telemetría interna.

Un buen SLI debe responder esta pregunta: ¿el usuario pudo hacer lo que necesitaba? Si no responde eso, estás midiendo lo incorrecto.

Cómo redefinir tus SLIs y SLOs correctamente

1. 1Identifica los journeys críticos del usuarioLista los flujos que generan valor directo: login, checkout, búsqueda, carga de reportes. No los internos del sistema, los que el usuario final ejecuta.
2. 2Define SLIs que midan resultado, no esfuerzoReemplaza 'CPU alta' por 'peticiones exitosas en el camino crítico'. Reemplaza 'memoria disponible' por 'latencia P95 del endpoint de pago'. Cada SLI debe estar atado a una acción del usuario.
3. 3Establece SLOs realistas basados en datos históricosNo elijas 99.99% porque suena bien. Analiza los últimos 90 días y define un objetivo que sea ambicioso pero alcanzable. Usa ventanas rodantes de 30 días para evitar el efecto de los picos puntuales.
4. 4Diseña burn rate alerts en vez de alertas de umbral estáticoUn burn rate mide la velocidad a la que estás consumiendo tu presupuesto de error. Si tu SLO es 99.9% mensual, una alerta de burn rate detecta que estás gastando tu presupuesto demasiado rápido, sin reaccionar a picos aislados de un minuto.
5. 5Crea un Error Budget PolicyDefine qué sucede cuando se agota el presupuesto de errores: congelar deploys, priorizar fiabilidad sobre features, escalar automáticamente. Sin esta política, el SLO es solo un número en un dashboard.
6. 6Revisa y ajusta cada trimestreLos SLIs evolucionan con el producto. Lo que era crítico hace 6 meses puede no serlo hoy. Revisa periódicamente con el equipo de producto y ajusta indicadores y objetivos.

Métricas que revelan si tus SLOs están mal definidos

Configuración práctica: SLO basado en burn rate

A continuación, un ejemplo real de configuración de SLO con burn rate usando Prometheus y recording rules. Este enfoque reduce falsas alertas al detectar tendencias de degradación, no picos instantáneos.

groups:
  - name: slo-availability-rules
    interval: 60s
    rules:
      - record: slo:availability:ratio_rate5m
        expr: |
          sum(rate(http_requests_total{code=~"2..",job="checkout-api"}[5m]))
          /
          sum(rate(http_requests_total{job="checkout-api"}[5m]))

      - record: slo:availability:error_budget:rate5m
        expr: |
          (1 - slo:availability:ratio_rate5m) / (1 - 0.999)

  - name: slo-availability-alerts
    rules:
      - alert: HighErrorBudgetBurnRate
        expr: |
          slo:availability:error_budget:rate5m > 14.4
          and
          slo:availability:error_budget:rate1h > 14.4
        for: 2m
        labels:
          severity: critical
          team: platform
        annotations:
          summary: "Checkout API consumiendo error budget demasiado rápido"
          description: "El burn rate actual agotará el presupuesto de error mensual en menos de 2 días."
          runbook_url: "https://docs.codifly.com/runbooks/checkout-burn-rate"

Señales de que tus SLIs necesitan una redefinición urgente

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

Las alertas se disparan fuera de horario laboral y al revisarlas no hay impacto perceptible en los usuarios. Los dashboards están siempre verdes pero los tickets de soporte aumentan. El equipo on-call ha dejado de leer los mensajes de PagerDuty. Las revisiones post-mortem revelan que el incidente no fue detectado por ninguna alerta automática.

Si reconoces dos o más de estas señales, es momento de detener la adición de nuevas métricas y redefinir los indicadores desde la perspectiva del usuario.

Cómo C4C7OPS ayuda a eliminar las falsas alertas

C4C7OPS permite definir SLIs alineados con los journeys de usuario reales, calcula burn rates automáticamente y genera alertas solo cuando el impacto en el usuario es medible. No necesitas construir recording rules manualmente ni mantener configuraciones complejas de Prometheus.

Con C4C7OPS puedes visualizar el error budget restante en tiempo real, correlacionar métricas de infraestructura con experiencia de usuario, y ajustar SLOs con datos históricos sin esfuerzo manual.

Lista de verificación antes de definir tu próximo SLO

Si tu equipo está discutiendo si subir el umbral de CPU o ajustar la ventana de evaluación, probablemente estás optimizando el indicador equivocado. El siguiente checklist ayuda a validar que cada SLO que definas esté alineado con la experiencia real del usuario y no solo con la salud interna del sistema.

Aplica esta verificación a cada servicio crítico antes de activar nuevas alertas en tu herramienta de observabilidad. Un SLO bien construido reduce el ruido operativo y enfoca al equipo en lo que realmente impacta al negocio.

1. 1Verifica que el SLI mida resultado, no esfuerzoConfirma que el indicador refleje una acción completada por el usuario, no un estado interno del sistema. Ejemplo correcto: porcentaje de peticiones de checkout con respuesta exitosa en menos de 500ms.
2. 2Valida el SLO con datos reales de los últimos 90 díasNo elijas un objetivo porque suene ambicioso. Extrae el percentil real de cumplimiento de tu SLI en los últimos tres meses y define el SLO como un valor alcanzable pero exigente.
3. 3Usa burn rate para anticipar, no solo para reaccionarConfigura alertas basadas en la velocidad de consumo del error budget. Un burn rate alto en una ventana corta indica que el presupuesto se agotará antes de fin de mes, incluso si el promedio general parece aceptable.
4. 4Revisa las alertas existentes y elimina las que no están atadas a un SLOSi una alerta no está conectada a un SLO con impacto en el usuario, candidata a eliminación o degradación a notificación informativa. Cada alerta que no requiere acción humana erosiona la confianza del equipo.