SLO, SLI y Error Budget: implementación práctica para equipos SRE
Cómo definir objetivos de fiabilidad accionables y conectar observabilidad con decisiones de producto, plataforma y negocio.
Sin SLOs claros, cada incidente se gestiona por percepción. Con SLI, SLO y error budget bien definidos, el equipo decide con datos cuándo acelerar entrega y cuándo proteger estabilidad.
Diferencia operativa entre SLI, SLO y Error Budget
- SLI: métrica observable (latencia, disponibilidad, tasa de errores).
- SLO: objetivo cuantificado sobre ese indicador en una ventana temporal.
- Error Budget: margen de fallo permitido para no sacrificar innovación.
Plantilla inicial por tipo de servicio
| Servicio | SLI sugerido | SLO inicial | Ventana |
|---|---|---|---|
| API crítica | Disponibilidad | 99.9% | 30 días |
| Backoffice interno | Latencia p95 | < 800 ms | 7 días |
| Pipeline CI/CD | Éxito de despliegues | 98% | 14 días |
Traducción técnica de disponibilidad a tiempo de caída
| SLO | Error budget mensual aprox. | Uso recomendado |
|---|---|---|
| 99.0% | 7h 12m | Servicios no críticos |
| 99.5% | 3h 36m | Backoffice y procesos internos |
| 99.9% | 43m 12s | APIs de negocio crítico |
| 99.95% | 21m 36s | Servicios con alto impacto financiero |
Gráfico técnico: consumo de error budget (ejemplo mensual)
Referencia para gobernar releases y deuda de fiabilidad
Entrando en zona amarilla, limitar cambios no críticos
Margen operativo suficiente para iterar
Revisar fallos de despliegue repetitivos
Cómo usar el Error Budget para tomar decisiones
- Define umbrales: verde (normal), amarillo (cautela), rojo (foco en fiabilidad).
- Asocia cada estado a acciones de release y priorización.
- Revisa semanalmente con producto y plataforma en un mismo foro.
Errores frecuentes al empezar
- Elegir métricas que no reflejan experiencia real del usuario.
- Establecer objetivos irreales sin baseline histórico.
- No vincular objetivos de fiabilidad a roadmap de producto.
- Definir SLO sin ownership claro por servicio.
Si se implementa bien, SRE no reduce velocidad: la hace sostenible. El objetivo no es cero errores, sino controlar el riesgo operativo con disciplina técnica.
Validación técnica y evidencia recomendada
Para que este enfoque sea defendible ante dirección y equipos técnicos, conviene acompañar la implementación con pruebas repetibles, métricas comparables y un registro claro de decisiones.
Pruebas técnicas mínimas
- Definir SLI/SLO por servicio crítico y validar ventanas de error budget.
- Prueba de alertas con escenarios controlados (ruido vs señal).
- Simulación de incidente para validar detección y escalado.
- Revisión de postmortem con acciones preventivas verificables.
Protocolo de validación reproducible
| Fase | Objetivo | Método | Criterio de aceptación |
|---|---|---|---|
| Baseline | Identificar servicios críticos y experiencia objetivo | Definir user journeys y SLI asociados | SLO acordados por servicio crítico |
| Hipótesis | Reducir ruido y acelerar respuesta | Clasificar alertas por severidad y accionabilidad | Plan para reducir alertas irrelevantes |
| Validación | Comprobar detección y recuperación | Game day con escenarios de fallo controlado | MTTD/MTTR dentro de objetivo |
| Escalado | Sostener fiabilidad en crecimiento | Revisión semanal de error budget y postmortems | Incidentes repetitivos en descenso |
Datos que debes conservar como evidencia
| Métrica | Herramienta | Cadencia | Objetivo |
|---|---|---|---|
| Disponibilidad real | Synthetics + SLO | Diario | >= objetivo SLO |
| MTTD | Alerting | Semanal | Tendencia descendente |
| MTTR | Incidentes | Semanal | Tendencia descendente |
| Incidentes repetitivos | Postmortem tracker | Mensual | < 20% |
Dashboard mínimo recomendado
| Panel | Fuente | Actualización | Umbral operativo |
|---|---|---|---|
| Error budget | SLO platform | Diario | Consumo < 75% de ventana |
| Ruido de alertas | Pager / alert manager | Diario | Alertas accionables > 60% |
| Diagnóstico | Logs + traces + metrics | Tiempo real | Tiempo a causa raíz en descenso |
| Postmortem | Tracker de acciones | Semanal | Acciones cerradas >= 80% en plazo |
Curva de madurez esperada (referencial)
Esta visualización sirve como referencia operativa para 90 días. Debe ajustarse con tus datos reales, complejidad técnica y contexto de negocio.
SLI/SLO y señal de alertas definidos.
Reducción de ruido y mejor detección temprana.
MTTD/MTTR en descenso con playbooks activos.
Ciclo continuo de mejora con error budget.
Riesgos que invalidan resultados
- Definir SLO sin vincularlos a una experiencia de usuario concreta.
- Tener dashboards bonitos pero sin alertas accionables.
- Acumular postmortems sin cerrar acciones preventivas.
- Medir disponibilidad solo por infraestructura y no por transacción.
Recomendaciones de implementación real
- No crear alertas sin playbook asociado.
- Reducir ruido de alertado antes de ampliar cobertura.
- Unificar trazas, logs y métricas por servicio para acelerar diagnóstico.
- Cerrar postmortems solo con acciones implementadas y validadas.
Preguntas frecuentes que suele hacer un equipo técnico
¿Qué diferencia hay entre monitorización y observabilidad?
Monitorización detecta síntomas; observabilidad permite explicar causas. Para SRE necesitas ambas y trazabilidad end-to-end.
¿Cuántos SLO debería definir al inicio?
Empieza con 2-4 SLO por servicio crítico (latencia, disponibilidad, errores) y amplía cuando el proceso madure.
¿Cómo reducir la fatiga del equipo on-call?
Eliminando alertas no accionables, mejorando runbooks y midiendo de forma estricta el ratio señal/ruido.
Preguntas frecuentes
¿Qué diferencia hay entre SLI y KPI?
SLI mide directamente la salud técnica del servicio; KPI mide resultado de negocio. Ambos deben conectarse, pero no son equivalentes.
¿Qué SLO debería usar una API en producción?
Como punto de partida, muchas APIs críticas usan 99.9% de disponibilidad mensual y complementan con latencia p95/p99 según tipo de operación.
¿Cómo calcular el error budget de un 99.9%?
En una ventana de 30 días, 99.9% permite alrededor de 43 minutos de indisponibilidad total. Ese presupuesto guía decisiones de release y hardening.
¿Quién define los SLO en una empresa?
Lo ideal es una definición conjunta entre producto, plataforma y negocio: producto define criticidad, plataforma traduce a objetivos medibles y negocio valida impacto.
¿Cada cuánto revisar SLO y error budget?
Al menos semanalmente para operaciones y mensualmente a nivel dirección técnica para ajustar objetivos y roadmap.
¿Quieres aplicarlo en tu plataforma?
Si quieres priorizar quick wins y un plan ejecutable para tu equipo, podemos ayudarte con una sesión técnica de 30 minutos.