Plantilla de Documento SLO (Service Level Objective)

Usa esta plantilla para definir targets de confiabilidad que equilibran felicidad de usuarios con velocidad de ingeniería. Consulta la Guía de Monitoreo y Alertas para recolección de métricas y la Guía de Respuesta a Incidentes On-Call para procedimientos de escalamiento.

Cómo implementar SLOs paso a paso

No intentes rollout SLOs a todos los servicios a la vez. Elige un servicio, trabaja estos ocho pasos, aprende qué funciona para tu equipo, luego expande. La mayoría de los equipos fracasan con SLOs porque intentan hacer demasiado muy rápido — empieza pequeño, demuestra el valor, luego escala.

1. Elige un servicio — empieza con el servicio que más duele cuando está caído. No rollout SLOs a 20 servicios a la vez. Elige uno, aprende, luego expande.
2. Identifica el viaje del usuario — ¿qué hace un usuario con este servicio? “Usuario hace un pago”, “usuario inicia sesión”, “usuario sube un archivo”. Escríbelo.
3. Define qué significa “exitoso” — para cada paso del viaje, ¿qué cuenta como éxito? “Transacción completada en < 500ms”, “login retorna 200 en < 200ms”. Estos son tus SLIs.
4. Define el target SLO — mira la performance actual. Si estás en 99.5% hoy, no prometas 99.99%. Pon el target ligeramente arriba de la performance actual para dejar espacio a mejorar.
5. Calcula el error budget — 100% - target SLO. Para 99.9% disponibilidad en 30 días, el budget es 0.1% = 43.2 minutos de downtime permitido.
6. Define alertas de burn rate — alerta cuando el burn rate sea suficientemente rápido para agotar el budget antes de que se resetee la ventana. Fast burn (2% en 1h) pagea; slow burn (5% en 6h) crea un ticket.
7. Escribe la política de error budget — ¿qué pasa cuando el budget está bajo? ¿Freeze de deploys? ¿Todos manos a confiabilidad? Escríbelo antes de que lo necesites.
8. Revisa trimestralmente — pon la revisión en el calendario. Verifica si el SLO sigue siendo alcanzable, si los SLIs siguen matcheando la experiencia del usuario, y si la política sigue funcionando.

Flujo SLO: SLI a Alerta

Plantilla

# SLO: [Nombre del Servicio]

## Overview
| Campo | Valor |
|-------|-------|
| **Servicio** | [nombre] |
| **Dueño** | [equipo o individuo] |
| **Fecha de revisión** | [trimestral] |

## SLIs (Service Level Indicators)

| SLI | Descripción | Medición |
|-----|-------------|----------|
| **Disponibilidad** | Ratio de requests exitosos | (total - errores) / total |
| **Latencia** | Distribución de tiempo de respuesta | p95, p99 por endpoint |
| **Throughput** | Requests por segundo | RPS en pico |

## SLOs (Targets)

| Objetivo | Target | Ventana de Medición |
|----------|--------|---------------------|
| Disponibilidad | 99.9% | 30 días rolling |
| Latencia p95 | < 200ms | 7 días rolling |
| Tasa de error | < 0.1% | 24 horas rolling |

## Presupuesto de Error

- **Presupuesto:** 100% - target SLO (ej. 0.1% para 99.9% disponibilidad)
- **Período:** 30 días
- **Política:** Cuando el presupuesto de error está > 50% consumido en < 50% del período, congelar deploys no críticos

## Umbrales de Alertas

| Severidad | Umbral | Respuesta |
|-----------|--------|-----------|
| Page | 10% del presupuesto consumido en 1 hora | On-call responde inmediatamente |
| Ticket | 50% del presupuesto consumido en 7 días | Equipo revisa en siguiente sprint |

## Dependencias

| Dependencia | Su SLO | Impacto Si Fallan |
|-------------|--------|-------------------|
| Payment API | 99.95% | Nuestro SLO de checkout baja |
| Identity Provider | 99.9% | Fallas de login afectan disponibilidad |

Elegiendo el SLO Correcto

Impacto de Usuario	SLO Típico	Razonamiento
Path crítico (pagos, login)	99.99% (4 nines)	El downtime bloquea revenue directamente
Importante pero no crítico	99.9% (3 nines)	~43 min downtime/mes aceptable
Herramientas internas	99% (2 nines)	~7 horas downtime/mes aceptable

Política de Presupuesto de Error

Presupuesto restante | Política
---------------------|--------
> 50%               | Operaciones normales
25-50%              | Freeze de deploy para cambios riesgosos
< 25%               | Freeze de deploy excepto fixes críticos
< 10%               | Todos en confiabilidad; detener feature work

Guía de Selección de SLIs

Tipo de Servicio	Buen SLI	Mal SLI	Por qué
HTTP API	Tasa de éxito de requests (2xx+3xx / total)	Uso de CPU	Usuarios cuidan respuestas, no CPU
Servicio gRPC	grpc_io_server_completed_rpcs (OK / total)	Uso de memoria	Usuarios cuidan RPCs exitosos
Job batch	Frescura (tiempo desde último run exitoso)	I/O de disco	Usuarios cuidan datos actuales
Consumer de cola	Lag (mensajes detrás del head)	Throughput de red	Usuarios cuidan procesamiento al día
Base de datos	Tasa de éxito de queries + latencia p99	Conteo de conexiones	Usuarios cuidan queries rápidos

Modelo RED vs USE

• RED (para servicios): Rate, Errors, Duration. Usa para HTTP APIs, servicios gRPC, consumers de mensajes.
• USE (para infraestructura): Utilization, Saturation, Errors. Usa para bases de datos, caches, load balancers.
• No los mezcles: un SLI RED en una base de datos pierde saturación; un SLI USE en una API pierde experiencia de usuario.

Anti-patrones de SLI

• Uso de CPU como SLI — a los usuarios no les importa el CPU. CPU alto puede estar bien (ocupado pero rápido); CPU bajo puede ser malo (deadlock).
• Uptime como SLI — un servicio puede retornar errores y seguir “up”. Mide tasa de éxito, no reachabilidad.
• Latencia promedio como SLI — promedios esconden tail latency. Usa percentiles p95 o p99.
• Conteo de errores (no tasa) como SLI — 100 errores de 1M requests está bien; 100 errores de 200 no. Usa tasas, no conteos.

Lo que funciona

• Empieza con métricas visibles para usuarios — “uso de CPU” no es un SLI; “tasa de requests exitosos” sí. Consulta la Guía de Monitoreo y Alertas para selección de métricas.
• Define SLOs basados en performance actual — si estás en 99.5% hoy, no prometas 99.99%
• Revisa trimestralmente — ajusta targets basado en feedback de usuarios y capacidad de ingeniería
• Distingue SLI, SLO y SLA — SLI es la métrica, SLO es el target, SLA es la promesa contractual a clientes

Errores Comunes

• SLOs demasiado laxos — 99% para una API de pagos significa 7 horas de downtime “aceptable”
• SLOs demasiado estrictos — 99.999% requiere infraestructura cara por beneficio marginal de usuario
• Trackear SLIs que nadie mira — cada SLI necesita un dueño y un ciclo de revisión
• Ignorar quema de presupuesto de error — el presupuesto existe para proteger velocidad de ingeniería, no para ignorarse. Consulta la Plantilla de Postmortem de Incidente para cuando los SLOs se incumplen.

Solución de Problemas de SLO

• Error budget se quema muy rápido: revisa si un deploy reciente introdujo una regresión. Mira la tasa de errores antes y después del deploy. Si el deploy lo causó, rollback. No ajustes el SLO — fix el deploy.
• SLO se cumple pero los usuarios se quejan: tu SLI no captura lo que los usuarios experimentan. Añade un SLI basado en el viaje del usuario (ej., “checkout completa en < 2s”) en lugar de una métrica de infraestructura.
• Fatiga de alertas por burn rate: ajusta las ventanas de alerta. Fast burn (2% en 1h) captura outages; slow burn (5% en 6h) captura issues crónicos. Si solo tienes una, prefiere slow burn — es más actionable.
• La revisión de SLO nunca pasa: asigna un dueño con nombre y pon la revisión en el calendario del equipo. Un SLO sin cadencia de revisión es un documento, no una práctica.
• Error budget siempre en 0: tu SLO es demasiado agresivo. Trackea 2-3 meses de datos, luego ajusta a un target realista. No lo bajes después de un solo mal mes.

Lectura Adicional

• Google SRE Workbook — SLO Engineering: la referencia canónica para diseño de SLO y políticas de error budget.
• Google SRE Book — Service Level Objectives: conceptos fundamentales, distinciones SLI/SLO/SLA.
• Sloth — SLO Generator for Prometheus: herramienta open-source para generar reglas SLO de Prometheus desde specs declarativas.
• Nobl9 — SLO Platform: plataforma managed de SLO con tracking de error budget y alertas de burn rate.
• OpenTelemetry — SLI Metrics: convenciones semánticas para métricas de service-level.

Notas de Producción

• Empieza con un SLO — elige el servicio que más duele cuando está caído. No rollout SLOs a 20 servicios a la vez.
• Trackea el error budget en un dashboard — Grafana con un panel “budget restante” hace el SLO visible para todo el equipo.
• Alerta en burn rate, no en breach de SLO — un SLO de 99.9% no significa “pagea cuando disponibilidad baja de 99.9%”. Significa “pagea cuando el burn rate sea suficientemente rápido para agotar el budget antes de que se resetee la ventana”.
• Revisa SLOs trimestralmente — las expectativas de usuarios cambian, la infraestructura mejora, y los SLOs que eran correctos hace 6 meses pueden ser demasiado laxos o estrictos ahora.

Puntos Clave

• Los SLOs son un contrato entre el equipo y los usuarios — definen qué significa “suficientemente confiable” y te dan un budget para tomar riesgos.
• El error budget es el punto — sin él, los SLOs son solo números. El budget te dice cuándo frenar y cuándo podés mover rápido.
• La selección de SLI importa más que los targets de SLO — un SLI equivocado (uso de CPU) hace el SLO inútil; un SLI correcto (tasa de éxito de requests) lo hace actionable.
• Revisa o retira — un SLO que nadie mira es peor que no tener SLO. Revisa trimestralmente o elíminalo.

Variantes

Contexto	Enfoque	Notas
Startup	SLOs básicos: disponibilidad y latencia	Objetivo Nivel 2 primero
Enterprise	SLOs multi-ventana + error budget policies	Nivel 3-4 con revisiones trimestrales
Microservicios	SLOs por servicio + SLOs de dependencia	Incluir SLOs de servicios upstream
Batch processing	SLOs de frescura y throughput	La latencia no aplica igual

Modelo de Madurez de SLO

Nivel	Qué tienes	En qué estás trabajando
1 — Ad hoc	Sin SLOs; “¿está up?” es la única métrica	Definiendo qué les importa a los usuarios
2 — Básico	1-2 SLOs (disponibilidad, latencia); tracking manual	Automatizando recolección de SLIs y dashboards
3 — Gestionado	2-4 SLOs por servicio; error budget trackeado; alertas de burn rate	Enforcement de política de error budget
4 — Optimizado	SLOs multi-ventana; enforcement automatizado; revisiones trimestrales	Tracking predictivo, release gating basado en SLO

La mayoría de los equipos está en Nivel 2. Llegar a Nivel 3 requiere: (1) dashboards de error budget, (2) alertas de burn rate conectadas a PagerDuty, (3) una política escrita que el equipo acuerde seguir. Nivel 4 es avanzado — solo invertí cuando tengas 10+ servicios con SLOs y el tooling para soportar enforcement automatizado.

Ejemplos de SLO por Industria

E-commerce checkout

SLI	Target	Ventana	Alerta
Tasa de éxito de checkout	99.95%	30 días	Page a 10x burn
Latencia p95 de checkout	< 800ms	7 días	Ticket a 5x burn
Disponibilidad de payment gateway	99.9%	30 días	Page a 10x burn

Checkout está en el path crítico. Un target de 99.95% te da ~22 minutos de downtime permitido por mes. Trackea el viaje completo: “agregar al carrito” → “ingresar pago” → “confirmación”.

Plataforma de API SaaS

SLI	Target	Ventana	Alerta
Tasa de éxito de API (por endpoint)	99.9%	30 días	Page a 10x burn
Latencia p99 de API	< 300ms	30 días	Ticket a 5x burn
Emisión de tokens de auth	99.95%	30 días	Page a 10x burn

Para plataformas de API, trackea SLOs por endpoint, no solo por servicio. Un endpoint /health lento está bien; un endpoint /checkout lento no.

Pipeline batch interno

SLI	Target	Ventana	Alerta
Frescura del job (tiempo desde último éxito)	< 4 horas	Rolling	Page si > 6 horas
Tasa de éxito del job	99%	30 días	Ticket a 5x burn
Completitud de datos	100%	Por run	Page si < 100%

Los jobs batch no necesitan SLOs de latencia. Frescura y completitud importan más que velocidad.

Ejemplo de SLO Completo

Aquí hay un SLO completado para un servicio de pagos. Muestra dos SLIs (tasa de éxito y latencia), los targets de SLO, matemática de error budget, y umbrales de alerta de burn rate. Copia esta estructura y adaptá los números a tu servicio.

=== SLO: payment-service ===

SLI: Tasa de éxito de transacciones
  Definición: requests HTTP 2xx+3xx / total requests HTTP
  Fuente: Prometheus (http_requests_total)
  Query: sum(rate(http_requests_total{service="payment",status!~"5.."}[5m])) / sum(rate(http_requests_total{service="payment"}[5m]))

SLO: 99.9% de éxito en ventana de 30 días
  Error budget: 0.1% = 43.2 minutos de errores en 30 días
  Alerta fast burn: 2% del budget en 1 hora
  Alerta slow burn: 5% del budget en 6 horas

SLI: Latencia p95
  Definición: percentil 95 del tiempo de respuesta
  Fuente: Prometheus (http_request_duration_seconds)
  Query: histogram_quantile(0.95, rate(http_request_duration_seconds_bucket{service="payment"}[5m]))

SLO: p95 < 500ms en ventana de 30 días
  Error budget: 0.1% de requests pueden exceder 500ms

Revisión: Trimestral
Owner: Team Payments

Política de Error Budget

=== Política de Error Budget ===

Budget restante | Acción
----------------|--------
75-100%         | Desarrollo normal; feature work priorizado
50-75%          | Desarrollo normal; monitorear tendencias
25-50%          | Freeze de deploys para cambios riesgosos
< 25%           | Freeze excepto fixes críticos
< 10%           | Todos manos a fiabilidad; detener feature work

Excepciones:
- Hotfixes de seguridad: siempre permitidos
- Fixes que restauran budget: siempre permitidos
- Feature flags deshabilitadas: permitidas (no afectan budget)

Como definimos SLIs que importan a los usuarios?

Un buen SLI mide lo que los usuarios experimentan, no lo que la infraestructura hace. “Uso de CPU” no es un SLI — a los usuarios no les importa el CPU. “Tasa de éxito de requests” sí es un SLI — los usuarios notan cuando sus requests fallan. Para definir SLIs: identifica el viaje del usuario (ej., “usuario hace un pago”). Para cada paso del viaje, define qué significa “exitoso” (ej., “transacción completada en < 500ms”). Mide eso. Evita SLIs de infraestructura (CPU, memoria, disco) a menos que estén directamente correlacionados con la experiencia del usuario. Usa el modelo RED (Rate, Errors, Duration) para servicios y USE (Utilization, Saturation, Errors) para infraestructura.

Como ajustamos SLOs que son demasiado agresivos?

Si un SLO es demasiado agresivo (el equipo consistentemente quema el error budget): no bajes el SLO inmediatamente. Primero, investiga por qué el SLO no se cumple: ¿hay bugs recurrentes? ¿dependencias inestables? ¿deuda técnica? Si la causa es sistémica: crea un plan de mejora de fiabilidad antes de ajustar el SLO. Si después de 1-2 trimestres de mejora el SLO sigue sin cumplirse: ajusta el SLO a un nivel alcanzable. Documenta el cambio y la razón. Comunica a stakeholders que el SLO se ajusta para ser realista. Nunca ajustes un SLO después de un solo mal mes — puede ser una anomalía. Usa datos de 2-3 meses para decisiones de ajuste de SLO.

Como comunicamos SLOs a stakeholders no tecnicos?

Traduce SLOs a lenguaje de negocio: “99.9% de disponibilidad significa que el servicio puede estar caido 43 minutos por mes.” En lugar de “p95 < 500ms”, usa “el 95% de las requests se completan en menos de medio segundo.” Conecta SLOs a impacto de negocio: “cada minuto de caida del servicio de pagos cuesta $10,000 en transacciones perdidas.” Usa dashboards visuales con semaforos (verde/amarillo/rojo) en lugar de numeros. Reporta SLOs mensualmente a liderazgo. Incluye el error budget restante y las acciones tomadas cuando se agota. No uses jerga (SLI, SLO, burn rate) con stakeholders no tecnicos — traduce a impacto.

Que herramientas necesitamos para implementar SLOs?

Para implementar SLOs necesitas: un sistema de monitoreo (Prometheus, Datadog) para recolectar metricas. Un sistema de dashboards (Grafana) para visualizar SLOs y error budgets. Un sistema de alertas (Alertmanager, PagerDuty) para alertas basadas en burn rate. Opcionalmente: una herramienta de SLO (Sloth, Prometheus Operator, Nobl9) para automatizar el calculo de error budget y las alertas. Para servicios sin metricas tradicionales (batch, event-driven): usa herramientas como OpenTelemetry para generar metricas personalizadas. Empieza simple — Prometheus + Grafana es suficiente para Nivel 2. Agrega herramientas especializadas cuando alcances Nivel 3-4.

Errores Comunes en Producción

• Dejar campos requeridos vacíos o usar respuestas vagas de una palabra.
• Llenar el documento una vez y nunca actualizarlo cuando cambia el alcance o las decisiones.
• Guardar el documento donde el equipo no lo busque durante incidentes o revisiones.
• No asignar un responsable, fecha límite o cadencia de revisión.
• Copiar texto base sin eliminar secciones que no aplican.
• Saltar el control de versiones, lo que impide rollback y responsabilidad.
• No vincular el documento con decisiones relacionadas o acciones de seguimiento.
• Evitar revisiones trimestrales que retirarían secciones obsoletas o sin uso.