SLIs, SLOs y Error Budgets en la Práctica de SRE: Gobernanza de Confiabilidad, OpenTelemetry y Alertas Multi-Burn-Rate

La fricción recurrente entre los equipos de Producto (que buscan acelerar lanzamientos) y los de Operaciones (que priorizan la estabilidad absoluta) se resuelve mediante un único principio matemático: el Error Budget (Presupuesto de Error). En el modelo moderno de Site Reliability Engineering (SRE), perseguir el 100% de disponibilidad es el objetivo equivocado: frena la innovación y multiplica los costes sin que el usuario perciba beneficio práctico.

1. La Tríada de SRE: SLIs, SLOs y SLAs Explicados

Diferencias clave entre estos conceptos fundamentales:

• SLI (Service Level Indicator): La métrica cuantitativa real observada. Ejemplo: 'El porcentaje de peticiones HTTP de pago que responden código 2xx en menos de 250ms'.
• SLO (Service Level Objective): El objetivo interno acordado entre negocio e ingeniería. Ejemplo: '99,95% de éxito sobre una ventana móvil de 30 días'.
• SLA (Service Level Agreement): El contrato jurídico formal con penalizaciones económicas ante incumplimientos graves.

Comparativa: Monitorización Clásica vs. Gobernanza SRE Better2Better

2. Operativa del Error Budget: Gobernando el Ciclo de Despliegues

Si su SLO fijado es de 99,9%, su Error Budget es de 0,1% (~43 minutos mensuales). Este presupuesto funciona como saldo compartido:

1. Con presupuesto disponible: Los desarrolladores despliegan nuevas funcionalidades con total agilidad.
2. Con presupuesto agotado: Se activa una Congelación de Releases (Release Freeze) automatizada, redirigiendo los equipos a resolver deuda técnica y robustecer defensas.

3. Alertas Avanzadas: Algoritmo Multi-Window Multi-Burn-Rate de Google SRE

Supervisamos la velocidad de consumo del Error Budget en dos ventanas simultáneas para suprimir falsas alarmas:

• Burn Rate 14.4x (2% del presupuesto consumido en 1 hora): Alerta crítica con guardia inmediata.
• Burn Rate 6x (5% consumido en 6 horas): Ticket de alta prioridad para resolución rápida.
• Burn Rate 1x (10% en 3 días): Notificación rutinaria para revisión en horario laboral.

4. Observabilidad Empresarial con OpenTelemetry

Implementamos el estándar OpenTelemetry (OTel) con propagación W3C Trace Context en microservicios Go, TypeScript, Java y Python, correlacionando frontend, APIs y consultas a bases de datos en una única traza visual.

5. Implementación en PromQL: Regla de Alerta Multi-Burn-Rate

Configuración en Prometheus para monitorizar el consumo de presupuesto:

groups:
  - name: slo_checkout_alerts
    rules:
      - alert: CheckoutErrorBudgetBurn14x
        expr: |
          (
            sum(rate(http_requests_total{job="checkout", status=~"5.."}[1h]))
            /
            sum(rate(http_requests_total{job="checkout"}[1h]))
          ) > (14.4 * (1 - 0.999))
          and
          (
            sum(rate(http_requests_total{job="checkout", status=~"5.."}[5m]))
            /
            sum(rate(http_requests_total{job="checkout"}[5m]))
          ) > (14.4 * (1 - 0.999))
        for: 2m
        labels:
          severity: page
        annotations:
          summary: "Checkout API consumiendo presupuesto a 14.4x"
          runbook_url: "https://wiki.better2better.com.br/sre/runbooks/checkout-burn-rate"

6. Cultura de Post-Mortem Sin Culpa (Blameless)

Buscar culpables oculta las debilidades reales del software. El error humano es inevitable; si un comando derribó la producción, la causa es una arquitectura deficiente y falta de protecciones. Las revisiones constructivas generan barreras de seguridad automáticas duraderas.

7. Checklist de Madurez SRE Empresarial

• [x] SLIs definidos y medidos desde la perspectiva del usuario final en rutas críticas.
• [x] SLOs ratificados por los líderes de Producto, Negocio e Ingeniería.
• [x] Alertas de CPU sustituidas por monitorización de tasa de consumo de Error Budget.
• [x] Trazado distribuido OpenTelemetry habilitado con contexto W3C Trace Context.
• [x] Política formalizada de congelación de releases ante agotamiento de presupuesto.

8. Preguntas Frecuentes sobre SRE y Observabilidad (FAQ)