Publicado: 13 ago 2025 · 7 min

SRE: Diseñar SLOs prácticos en 60 minutos

Paso 1 — Define usuarios y momentos de verdad

Identifica 2–3 journeys críticos. Ej.: “checkout web”, “API de órdenes”, “login móvil”. Para cada uno, documenta qué es “bueno” (tiempo de respuesta, tasa de éxito, frescura de datos).

Paso 2 — Elige SLI útiles

Prefiere métricas cercanas al usuario final: latencia p95, tasa de éxito, disponibilidad y frescura. Evita KPIs internos que no percibe el usuario.

Paso 3 — Marca SLO base

Arranca conservador: 99.0%–99.5% y sube al estabilizar. Usa ventanas rodantes (30 días) y excluye mantenimientos planificados.

Paso 4 — Alertas y error budget

Alertas de agotamiento de budget (rápido y lento) + sintéticos críticos. Escala por severidad y horario. Postmortems sin culpa.

Plantillas

Ejemplo de SLI/SLO en YAML (para documentar en tu repo reliability/):

service: checkout-web
journey: compra
slis:
  - name: success_rate
    query: sum(rate(http_requests_total{status=~"2.."}[5m])) / sum(rate(http_requests_total[5m]))
    slo: 99.5
  - name: latency_p95
    query: histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))
    threshold: 300ms
window: 30d
alerts:
  - type: error_budget_fast_burn
    burn_rate: 14.4 # ~2h
  - type: error_budget_slow_burn
    burn_rate: 2.0  # ~1d

Regla práctica: si la alerta no obliga a acción, no alertes. Mándala a un dashboard o reporte.