Plantilla de Objetivo de Nivel de Servicio (SLO)

Descripcion General

Un Objetivo de Nivel de Servicio (SLO) define un objetivo de confiabilidad para un servicio. Traduce las expectativas de los usuarios en metas medibles que orientan las prioridades de ingenieria, las compensaciones y la inversion. Esta plantilla ayuda a los equipos a definir Indicadores de Nivel de Servicio (SLIs), establecer objetivos, gestionar presupuestos de error y revisar el rendimiento en el tiempo.

Cuando Usar

• For alternatives, see Complete Guide to Observability with the Grafana Stack.

• Lanzar un nuevo servicio o producto.

• Establecer expectativas de confiabilidad con stakeholders o clientes.

• Introducir presupuestos de error para equilibrar velocidad y estabilidad.

• Negociar un Acuerdo de Nivel de Servicio (SLA) interno o externo.

• Revisar la salud del servicio trimestralmente o despues de incidentes mayores.

Prerequisitos

• Comprension clara de la funcionalidad orientada al usuario y los viajes criticos del usuario.
• Instrumentacion que produce las metricas necesarias para los SLIs.
• Plataforma de monitoreo u observabilidad que pueda calcular la confiabilidad en el tiempo.
• Acuerdo de prioridades entre producto, ingenieria y operaciones.
• Datos historicos o estimaciones para establecer objetivos realistas.

Solucion

Plantilla

1. Definicion del SLO

Campo	Descripcion	Ejemplo
Nombre del servicio	El servicio o sistema cubierto	Checkout API
Nombre del SLO	Nombre corto para el objetivo	Disponibilidad de checkout
SLI	Medida cuantitativa del nivel de servicio	Ratio de solicitudes HTTP exitosas
Objetivo	Nivel de confiabilidad deseado	99.9%
Ventana de medicion	Periodo de tiempo para evaluacion	30 dias
Dueno	Equipo responsable	Equipo checkout
Stakeholders	Usuarios del SLO	Producto, soporte, plataforma

2. Tipos Comunes de SLIs

Tipo de SLI	Que Mide	Formula Tipica de SLI
Disponibilidad	Esta respondiendo el servicio?	solicitudes exitosas / solicitudes totales
Latencia	Que tan rapido es el servicio?	porcentaje de solicitudes bajo umbral
Calidad	Es correcta la salida?	respuestas validas / respuestas totales
Tasa de error	Con que frecuencia falla?	1 - (solicitudes exitosas / solicitudes totales)
Throughput	Puede manejar la carga?	solicitudes por segundo
Frescura	Los datos estan actualizados?	porcentaje de datos actualizados dentro del umbral
Durabilidad	Se preservan los datos?	porcentaje de objetos almacenados exitosamente en el tiempo

3. Ejemplos de SLOs

Servicio	SLI	Objetivo	Ventana	Justificacion
Checkout API	Disponibilidad	99.95%	30 dias	Endpoint critico para ingresos
Checkout API	Latencia p99	< 500ms	30 dias	Umbral de experiencia de usuario
Servicio de busqueda	Disponibilidad	99.9%	30 dias	Importante pero no critico para ingresos
Servicio de busqueda	Latencia p95	< 200ms	30 dias	Retroalimentacion rapida al usuario
Pipeline de datos	Frescura	99.5%	24 horas	Analitica necesita datos recientes
Almacenamiento de objetos	Durabilidad	99.999999999%	1 ano	Proteccion contra perdida de datos

4. Politica de Presupuesto de Error

Objetivo	Presupuesto de Error	Tasa de Quemado (Diaria)	Accion al Agotar el Presupuesto
99.9%	0.1%	~0.003%	Revisar politica de releases y congelar cambios no criticos
99.95%	0.05%	~0.0017%	Endurecer rollout y requerir revision de incidentes
99.99%	0.01%	~0.0003%	Detener releases de funcionalidades y priorizar trabajo de confiabilidad

Lineamientos:

• Un presupuesto de error mide cuanta falta de confiabilidad es aceptable en una ventana.
• La tasa de quemado indica que tan rapido se consume el presupuesto.
• Cuando el presupuesto se agota o se proyecta agotarse, reducir cambios riesgosos.
• Un presupuesto excesivo restante puede indicar objetivos demasiado conservadores.

5. Medicion y Alertas

Metrica	Fuente	Agregacion	Umbral de Alerta
Disponibilidad	Load balancer o logs de aplicacion	Ventana 5 min	Objetivo SLO - 1% durante 10 min
Latencia p99	Metricas de aplicacion	Ventana 1 hora	Latencia objetivo + 20% durante 15 min
Tasa de error	Logs de aplicacion	Ventana 5 min	> 0.5% durante 5 min
Presupuesto de error	Calculo de SLO	30 dias movil	80% consumido en 50% de la ventana
Tasa de quemado	Calculo de SLO	Ventana 1 hora	Alta tasa de quemado por 2 horas consecutivas

6. Ciclo de Revision y Mejora

Actividad	Frecuencia	Dueno	Salida
Revision de dashboard de SLOs	Semanal	Equipo SRE	Estado actual y tendencias
Revision de presupuesto de error	Mensual	Dueno del servicio	Decisiones de releases y acciones de seguimiento
Revision de objetivos SLO	Trimestral	Producto + ingenieria	Objetivos ajustados con justificacion
Revision post-incidente	Despues de cada incidente	Comandante de incidente	Impacto en SLO y acciones de mejora
Comunicacion de SLOs	Trimestral	Liderazgo de ingenieria	Reporte de stakeholders sobre confiabilidad

Explicacion

Los SLOs dan a los equipos un lenguaje compartido para la confiabilidad. Al definir SLIs, objetivos y presupuestos de error, una organizacion puede decidir cuando priorizar nuevas funciones versus trabajo de estabilidad. Los SLOs tambien reducen la fatiga de alertas al enfocar el monitoreo en la confiabilidad que impacta al usuario en lugar de cada metrica interna.

Definicion de SLO en Prometheus (Sloth)

version: "prometheus/v1"
service: "api-gateway"
slos:
  - name: "availability"
    objective: 99.9
    description: "Respuestas HTTP exitosas para el API gateway"
    sli:
      events:
        error_query: sum(rate(http_requests_total{job="api-gateway",status=~"5.."}[{{.window}}]))
        total_query: sum(rate(http_requests_total{job="api-gateway"}[{{.window}}]))
    alerting:
      name: ApiGatewayAvailability
      page_alert:
        disable: false
        labels:
          severity: page
          team: platform
      ticket_alert:
        disable: false
        labels:
          severity: ticket
          team: platform

  - name: "latency-p99"
    objective: 99
    description: "Latencia P99 por debajo de 500ms para el API gateway"
    sli:
      events:
        error_query: |
          sum(rate(http_request_duration_seconds_bucket{job="api-gateway",le="0.5"}[{{.window}}]))
          /
          sum(rate(http_request_duration_seconds_count{job="api-gateway"}[{{.window}}]))
        total_query: "1"
    alerting:
      name: ApiGatewayLatency
      page_alert:
        disable: false
      ticket_alert:
        disable: false

Hoja de Calculo de Presupuesto de Error

=== Calculo de Presupuesto de Error ===

Objetivo SLO: 99.9% disponibilidad
Periodo: 30 dias (43,200 minutos)

Tiempo de inactividad permitido (presupuesto de error):
  43,200 * (1 - 0.999) = 43.2 minutos por mes

Presupuesto consumido este periodo:
  - Incidente 1 (2026-06-05): 12 min inactividad -> 12 min consumidos
  - Incidente 2 (2026-06-12): 8 min inactividad -> 8 min consumidos
  - Incidente 3 (2026-06-20): 5 min inactividad -> 5 min consumidos
  Total consumido: 25 minutos

Presupuesto restante: 43.2 - 25 = 18.2 minutos (42% del presupuesto restante)

Tasa de quemado:
  - Quemado rapido (ventana 1h): 2x normal -> alertar si > 6x
  - Quemado lento (ventana 6h): 1x normal -> alertar si > 3x

Decision: 42% del presupuesto restante al dia 20 de 30.
  - Verde (>50%): Continuar releases normales
  - Amarillo (20-50%): Reducir frecuencia de releases, priorizar estabilidad
  - Rojo (<20%): Congelar releases no criticos, enfocar en confiabilidad

Agenda de Reunion de Revision de SLO

=== Revision Mensual de SLO ===

1. Reporte de Cumplimiento de SLO (10 min)
   - Cumplimos cada objetivo SLO?
   - Estado del presupuesto de error: consumido vs restante
   - Tendencia: mejorando, estable o degradando?

2. Revision de Incidentes (15 min)
   - Incidentes que consumieron presupuesto
   - Patrones de causa raiz
   - Acciones de revisiones post-incidente

3. Discusion de Objetivos SLO (10 min)
   - Debemos ajustar algun objetivo?
   - Los SLIs siguen midiendo lo correcto?
   - Nuevos servicios que necesitan SLOs?

4. Planificacion de Releases (10 min)
   - Guia de presupuesto de error para el proximo mes
   - Cambios riesgosos planificados
   - Prioridades de trabajo de estabilidad

5. Acciones (5 min)
   - Responsable y fecha limite para cada accion
   - Proxima fecha de revision

Variantes

• SLO orientado al cliente: Se usa para respaldar SLAs externos y comunicaciones con clientes.
• SLO de plataforma interna: Rastrea la confiabilidad de servicios internos consumidos por otros equipos.
• SLO de carga batch: Se enfoca en throughput, frescura y ventanas de finalizacion en lugar de disponibilidad.
• SLO de movil o cliente: Incluye tasas de crash, tiempo de inicio de app y latencia de respuesta API.
• SLO de plataforma de datos: Enfatiza frescura, completitud y rendimiento de consultas.

Lo que funciona

• Comienza con unos pocos viajes criticos del usuario en lugar de medir todo.
• Establece objetivos basados en expectativas de usuario y necesidades de negocio, no en infraestructura ideal.
• Usa presupuestos de error para guiar decisiones de release en lugar de como castigo.
• Manten los SLOs simples y comprensibles para stakeholders no tecnicos.
• Revisa los objetivos trimestralmente y ajustalos a medida que evolucionan los servicios.
• Alerta sobre quemado rapido de presupuesto, no solo sobre faltas de objetivo.
• Documenta los SLIs de forma reproducible entre herramientas.
• Alinea los SLOs con las prioridades de respuesta a incidentes.

Errores Comunes

• Establecer SLOs al 100% sin considerar costo y complejidad.
• Elegir SLIs que no reflejan la experiencia real del usuario.
• Definir demasiados SLOs y perder el foco.
• No usar presupuestos de error para influir en decisiones de release.
• Ignorar los SLOs despues de definirlos.
• Establecer objetivos basados solo en el rendimiento actual sin metas de mejora.
• Confundir SLOs internos con SLAs externos.

Troubleshooting

• No logs for a failing request: verify log shipping, retention, and that the request reached the service.
• Alert fires but the service is healthy: tune thresholds and use multi-signal alerts.
• Dashboard shows stale data: check refresh intervals, query range, and data source lag. Verify that the metric still exists.
• High cardinality metrics explode costs: drop high-cardinality labels, aggregate before ingest, or use sampling.
• Trace is incomplete across services: ensure all services propagate trace context. Instrument async and background jobs.

Lectura Adicional

• Documentación oficial: consulta la referencia actualizada del framework o herramienta utilizada.
• Guías relacionadas: explora las guías de slo y reliability para profundizar.
• Patrones complementarios: revisa los patrones de diseño aplicables a tu stack tecnológico.
• Postmortems públicos: estudia incidentes reales de equipos que enfrentaron problemas similares en producción.

Notas de Producción

• Despliega gradualmente usando canary o blue-green para detectar regresiones temprano.
• Configura alertas para errores, latencia p99 y tasa de fallos antes de habilitar en producción.
• Documenta el rollback en el runbook; prueba el procedimiento en staging al menos una vez por trimestre.
• Revisa logs estructurados con correlation IDs para trazar requests end-to-end en incidentes.

Puntos Clave

• Aplica plantilla de objetivo de nivel de servicio (slo) cuando necesites una solución práctica para tu caso de uso.
• Monitorea el rendimiento después de implementar; mide latencia, errores y uso de recursos antes y después.
• Revisa la sección de Troubleshooting ante errores comunes; la mayoría tienen causa raíz documentada con solución.
• Mantén dependencias actualizadas y ejecuta tests en CI para prevenir regresiones en producción.

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.