SLIs y SLOs para equipos sin SRE
Contratar SRE no es prerrequisito para ingeniería de confiabilidad. Tres SLIs elegidos con honestidad — disponibilidad, latencia, corrección — con objetivos SLO y presupuestos de error dan a equipos pequeños lo que un muro de dashboards no puede: una definición compartida de «roto».
El muro de Grafana tiene cuarenta y siete paneles. Durante el incidente, nadie sabía cuál importaba. La tasa de error estaba elevada en un endpoint no crítico. La latencia p99 en checkout estaba bien. Un job en background estaba en rojo. On-call recorrió paneles veinte minutos antes de que alguien hiciera la pregunta que debía estar respondida antes de que sonara la alerta: ¿cómo se ve «roto» para este producto? Los SLIs y SLOs sin equipo SRE no son headcount — son tres números con los que toda la org de ingeniería acuerda medir confiabilidad visible para el usuario, más objetivos que convierten métricas en decisiones.
Site Reliability Engineering popularizó el vocabulario. Las prácticas no exigen títulos de trabajo SRE. Una startup de cinco personas con clientes en producción necesita SLOs más que un equipo de cincuenta con una plataforma de observabilidad que nadie configuró. Los SLOs son decisiones de producto expresadas como matemática: qué tan confiable debe ser el checkout, qué tan rápida debe sentirse la búsqueda, con qué frecuencia pueden estar mal los datos antes de que los usuarios se vayan.
SLI, SLO y presupuesto de error en términos simples
| Term | Definition | Example |
|---|---|---|
| SLI (Service Level Indicator) | Proxy medible de la experiencia de usuario | Requests de checkout exitosos / total de requests de checkout |
| SLO (Service Level Objective) | Rango objetivo para un SLI en una ventana | 99,9% de éxito en checkout por ventana móvil de 30 días |
| Error budget | Fiabilidad permitida por debajo del 100% | 0,1% = ~43 minutos de downtime/mes al 99,9% |
| SLA (Service Level Agreement) | Compromiso contractual con consecuencias | Suele ser SLO más estricto + términos legales — no requerido para SLOs internos |
Los SLIs deben ser medibles, centrados en el usuario y honestos — no «CPU bajo 80%» sino «requests completándose con éxito bajo 500 ms».
Los SLOs deben ser alcanzables y con dueño — un número que nadie puede cumplir entrena a todos a ignorar los SLOs.
Los presupuestos de error conectan confiabilidad con velocidad de producto: presupuesto restante → enviar features con agresividad. Presupuesto agotado → congelar deploys riesgosos, enfocarse en estabilidad. Sin presupuestos de error, los SLOs son pósters.
Un dashboard sin SLO es una prueba de Rorschach durante incidentes.
Tres SLIs con los que la mayoría de equipos debería empezar
No empezar con quince SLIs. Empezar con tres que mapeen al dolor del usuario.
1. Disponibilidad / tasa de éxito
SLI = (successful requests) / (total valid requests)
Definir «exitoso» por endpoint — HTTP 2xx/3xx para APIs, finalización de job para async. Excluir errores de cliente (4xx) salvo que indiquen mala configuración del servidor.
Punto de partida SLO: 99,9% para API core, 99,5% para caminos no críticos. Ajustar según rendimiento real — fijar 99,99% cuando el actual es 99,5% produce agotamiento permanente del presupuesto.
2. Latencia
SLI = proportion of requests completing under threshold T
Usar percentiles alineados a la experiencia de usuario — p95 o p99, no promedio. El promedio oculta latencia de cola que impulsa churn.
Ejemplo SLO: 95% de requests de búsqueda completan bajo 300 ms por 30 días.
Medir en el load balancer o edge — no solo dentro del servicio — para incluir overhead de red y gateway.
3. Corrección / frescura (cuando aplique)
Más difícil de medir de forma universal. Ejemplos:
- Pipeline de datos: % de agregados horarios publicados dentro de 15 minutos del cierre de hora
- Pagos: tasa de desajuste en reconciliación bajo 0,01%
- Índice de búsqueda: % de queries devolviendo resultados de índice actualizado en 60 segundos
Omitir SLI de corrección si aún no existe un contrato de datos claro visible para el usuario. No inventar uno para llenar una plantilla.
Implementar SLOs sin equipo de plataforma de observabilidad
Stack mínimo viable de SLO:
Fuente de métricas. APM existente, Prometheus, métricas del cloud provider o logs estructurados agregados a series temporales. La perfección no es requerida — la medición consistente sí.
Reglas de grabación de SLI. recording_rules de Prometheus, monitores de Datadog o SQL semanal contra log warehouse — calcular ratio SLI sobre ventana móvil.
Alertas de burn rate. Alertar cuando el consumo del presupuesto de error se acelera — no cuando el SLO ya está roto del mes.
| Alert type | When it fires | Purpose |
|---|---|---|
| Fast burn | 2% del presupuesto mensual consumido en 1 hora | Página a on-call — incidente activo |
| Slow burn | 10% del presupuesto mensual consumido en 6 horas | Ticket — investigar tendencia |
| Budget exhausted | 100% consumido | Congelar releases riesgosos |
Página de estado única. Una URL o doc: estado SLO actual por SLI, presupuesto restante, impacto del último incidente. Actualizado automáticamente si es posible.
Los feature flags como infraestructura de release se integran con presupuestos de error — cuando el presupuesto SLO de checkout está bajo, los flags deshabilitan caminos no críticos antes de que el próximo deploy arriesgue otro burn.
La cadencia de revisión SLO reemplaza el turismo de dashboards
Revisión SLO semanal o quincenal de 30 minutos:
- Presupuesto restante por SLI
- Incidentes que consumieron presupuesto — causa raíz, ¿fix enviado?
- Correlación con deploys — ¿los releases precedieron burns?
- Propuestas de ajuste de objetivo SLO — solo con datos
Mensual: ¿siguen siendo los tres SLIs correctos? Los cambios de producto desplazan lo que sienten los usuarios. SLOs que midieron el producto del año pasado pueden no medir el de este año.
Los objetivos SLO no son permanentes. Ajustar hacia arriba cuando mejora la confiabilidad y los usuarios esperan más. Aflojar cuando los objetivos eran fantasía — pero objetivos más laxos deben ser decisiones de producto explícitas, no rendición silenciosa.
¿Cómo deben elegir y hacer cumplir SLOs los equipos pequeños?
Estas preguntas evitan programas SLO que mueren tras una hoja de cálculo.
¿Cuántos SLIs son suficientes?
Tres a cinco para todo el producto al inicio. Un SLI primario por journey crítico de usuario — checkout, auth, read path core. Más SLIs diluyen atención; menos omiten dolor real.
¿Qué política de presupuesto de error deberían adoptar equipos sin SRE?
Regla simple: presupuesto bajo 25% restante → sin deploys riesgosos discrecionales sin ack explícito. Presupuesto agotado → sprint de estabilidad hasta recuperar presupuesto. Escribir la política antes del primer agotamiento — no durante la discusión.
¿Los SLOs reemplazan runbooks de on-call?
No. Los SLOs dicen que está roto y cuánto presupuesto queda. Los runbooks dicen qué hacer. Emparejar alertas de burn SLO con árboles de decisión de estrategia de rollback — alertas sin acciones desperdician páginas.
Una visión opuesta
Un argumento frecuente sostiene que los SLOs son overhead enterprise — que equipos pequeños deberían moverse rápido y arreglar incidentes cuando ocurren en lugar de medir confiabilidad matemáticamente.
Los equipos pequeños sienten los incidentes con más agudeza porque nadie más absorbe el dolor. Los SLOs no frenan la velocidad — los presupuestos de error autorizan velocidad cuando la confiabilidad lo permite. Sin ellos, cada discusión de deploy es subjetiva («se siente riesgoso») y cada retrospectiva de incidente reinventa qué significa «roto».
El overhead de tres SLIs es una tarde de definición y una revisión recurrente de treinta minutos. El overhead de cuarenta y siete paneles Grafana durante un incidente confuso se mide en confianza del cliente.
Key takeaways
- Los SLIs miden confiabilidad visible para el usuario; los SLOs fijan objetivos; los presupuestos de error conectan confiabilidad con decisiones de release.
- Empezar con tres SLIs: disponibilidad, latencia y corrección/frescura donde aplique.
- Las alertas de burn rate disparan antes de agotar el presupuesto mensual — fast burn pagina, slow burn abre ticket.
- Los objetivos SLO deben ser alcanzables — objetivos fantasía entrenan a equipos a ignorar SLOs.
- La política de presupuesto de error bloquea deploys riesgosos con presupuesto bajo — escribir la política antes del primer agotamiento.
- Revisar SLOs quincenalmente; ajustar objetivos y selección de SLI según evolucione el producto.
Conclusion
Un equipo SRE es un modelo de staffing, no un prerrequisito de confiabilidad. Los SLIs y SLOs son cómo los equipos acuerdan qué significa roto antes de que suene el pager — tres indicadores honestos, objetivos anclados en el rendimiento actual y presupuestos de error que hacen de la confiabilidad un input para decisiones de envío en lugar de un arrepentimiento post-incidente.
El ejercicio de la tarde: elegir el journey de usuario cuyo fallo terminaría mal la semana. Definir su SLI. Fijar un SLO con datos del mes pasado. Configurar una alerta de burn rate. Todo lo demás es iteración.