¿Por qué SLOs y no solo monitorización?
Si llevas tiempo en el mundo de operaciones, seguramente has vivido la situación: tienes cientos de alertas, dashboards por todos lados, y sin embargo cuando algo falla… nadie sabe realmente si el usuario está afectado.
Los SLOs (Service Level Objectives) cambian el enfoque por completo. En lugar de monitorizar todo, nos preguntamos: ¿qué experiencia estamos prometiendo a nuestros usuarios?
“Hope is not a strategy.” — Google SRE Book
Los tres pilares
SLIs (Service Level Indicators)
Un SLI es una medida cuantitativa de algún aspecto del nivel de servicio. Los más comunes:
- Disponibilidad: Proporción de requests exitosos
- Latencia: Proporción de requests por debajo de un umbral
- Throughput: Cantidad de requests por segundo
- Error rate: Tasa de errores
# Ejemplo: SLI de disponibilidad en Prometheus
- record: sli:availability:ratio_rate5m
expr: |
sum(rate(http_requests_total{code!~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))
SLOs (Service Level Objectives)
El SLO es el objetivo que fijamos para un SLI. Por ejemplo:
| Servicio | SLI | SLO |
|---|---|---|
| API Gateway | Disponibilidad | 99.9% (mensual) |
| API Gateway | Latencia p99 | < 200ms |
| Payment Service | Disponibilidad | 99.99% (mensual) |
Error Budget
El Error Budget es la diferencia entre el 100% y tu SLO. Si tu SLO es 99.9%, tu error budget es 0.1%.
# Error budget en minutos (mes de 30 días)
slo = 99.9
total_minutes = 30 * 24 * 60 # 43,200 minutos
error_budget_minutes = total_minutes * (1 - slo / 100)
print(f"Error budget: {error_budget_minutes:.1f} minutos")
# Output: Error budget: 43.2 minutos
Implementación con Prometheus
Aquí es donde la teoría se convierte en práctica. Veamos cómo implementar un sistema de SLOs con Prometheus y Grafana:
# prometheus-rules.yml
groups:
- name: slo-rules
rules:
# SLI: Disponibilidad (multi-window)
- record: sli:http_availability:ratio_rate5m
expr: |
1 - (
sum(rate(http_requests_total{code=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))
)
# SLO burn rate alert (fast burn)
- alert: SLOBurnRateHigh
expr: |
(
sli:http_availability:ratio_rate1h < (1 - 14.4 * 0.001)
and
sli:http_availability:ratio_rate5m < (1 - 14.4 * 0.001)
)
for: 2m
labels:
severity: critical
annotations:
summary: "High SLO burn rate detected"
Conclusión
Los SLOs no son solo métricas — son un contrato con tu equipo sobre cuánto riesgo es aceptable. Implementarlos correctamente cambia la dinámica entre desarrollo y operaciones, convirtiendo las discusiones de “quiero más features” vs “quiero más estabilidad” en una conversación basada en datos.
En el próximo post veremos cómo crear dashboards de Error Budget en Grafana que realmente sean útiles para la toma de decisiones.
¿Tienes preguntas o quieres compartir cómo implementaste SLOs en tu organización? Encuéntrame en Twitter.