¿Qué son los SLI, SLO, SLA y error budgets — y cómo cambian en la práctica las decisiones de ingeniería?

#Cuatro términos fáciles de confundir e importantes de distinguir

Estos cuatro términos se usan casi como sinónimos en una conversación informal, y los entrevistadores puntualmente indagan si sabés que no son lo mismo, porque las diferencias son exactamente donde vive el poder real de tomar decisiones.

SLI — Service Level Indicator (Indicador de Nivel de Servicio). Una señal cuantitativa medida directamente sobre el comportamiento visible para el usuario. "Proporción de requests HTTP que devolvieron un status distinto de 5xx," "proporción de requests servidos en menos de 300ms," "proporción de mensajes procesados dentro de los 5 segundos de haber sido encolados." Un SLI es una medición, no un objetivo — es el número crudo que calcularías a partir de tus métricas ahora mismo.

SLO — Service Level Objective (Objetivo de Nivel de Servicio). Un objetivo interno para un SLI sobre una ventana definida: "el 99.9% de los requests responde exitosamente, medido sobre una ventana móvil de 30 días." El SLO es donde una decisión de negocio (qué tan confiable necesita ser esto realmente, dado el costo y las expectativas de los usuarios) se convierte en un objetivo de ingeniería. Es interno — nadie fuera de la empresa tiene una promesa contractual sobre este número, y deliberadamente se fija un poco más estricto que cualquier promesa externa.

SLA — Service Level Agreement (Acuerdo de Nivel de Servicio). Un compromiso externo, generalmente contractual, hecho hacia los clientes, con consecuencias reales asociadas —créditos de servicio, reembolsos, derecho a rescindir el contrato— si se incumple. Un patrón típico es SLA = 99.5% mientras que el SLO interno = 99.9%: la brecha entre ambos es un margen de seguridad deliberado, de modo que en el momento en que empezarías a estar en riesgo real de la consecuencia contractual, tu alerting interno ya viene gritando desde hace un rato.

Error budget. El complemento matemático del SLO: 100% − objetivo del SLO, convertido en una cantidad concreta sobre la ventana del SLO — una cantidad de requests fallidos permitidos, o una cantidad de minutos de downtime permitidos. Es el presupuesto que explícitamente tenés permiso de gastar en riesgo: deploys que podrían salir mal, experimentos, cambios de infraestructura, apuestas calculadas que cambian un poco de confiabilidad por velocidad o aprendizaje.

#Convertir 99.9% en un número que realmente podés gastar

Para un SLO de disponibilidad mensual del 99.9% evaluado sobre una ventana de 30 días: los minutos totales de la ventana son 30 × 24 × 60 = 43.200. El downtime permitido es el 0.1% de eso, que da aproximadamente 43 minutos para todo el mes. Ese es el error budget, expresado como duración. Para un SLO de éxito de requests en lugar de uno de disponibilidad, se expresa como una cantidad de requests: con 10 millones de requests al mes, un objetivo del 99.9% permite aproximadamente 10.000 requests fallidos durante el mes.

#Un mes concreto: gastando el budget, y quedándose sin él

Supongamos que checkout-api tiene un SLO de disponibilidad mensual del 99.9% (≈43 minutos de downtime permitido) y un SLA hacia clientes del 99.5% con créditos financieros asociados. A principios de mes, un mal deploy provoca una caída de 25 minutos antes de que se revierta. Ese único incidente consume alrededor del 58% de todo el error budget mensual (25 de ~43 minutos) — y apenas es el día cinco del mes.

Acá es donde entra en juego una política de error budget —un conjunto de consecuencias acordado y escrito de antemano, no una discusión improvisada en un hilo de Slack—. Una política típica podría decir: una vez que se gastó más del 50% del budget mensual, los releases de features no esenciales se pausan y la prioridad número uno del equipo pasa a ser trabajo de confiabilidad (encontrar la causa raíz de la falla del deploy, agregar una etapa de canary, mejorar la velocidad de rollback); una vez que el budget se agota por completo, cualquier cambio de producción adicional requiere aprobación explícita de un SRE o de un líder de ingeniería, y un postmortem se vuelve un gate obligatorio antes de cualquier deploy adicional, no un gesto opcional.

Contrastá eso con un mes tranquilo donde el equipo no tocó más del 5% del budget para el día 25: esa es una señal real, respaldada por datos, de que el equipo puede asumir más riesgo con seguridad —lanzar una migración más grande, activar un feature flag riesgoso para más usuarios, postergar algo de trabajo de hardening— porque tienen margen para quemar si algo sale un poco mal.

#Por qué esto cambia decisiones de ingeniería reales, no solo dashboards

Antes de los error budgets, la discusión entre "lancemos la feature" y "arreglemos la confiabilidad" suele ser una discusión política —gana quien tenga más peso organizacional en la sala, independientemente de los datos reales—. Un error budget convierte eso en un número objetivo, acordado de antemano, que tanto producto como ingeniería ya firmaron: no hay negociación en medio de un incidente sobre si un freeze es "justo," porque todos acordaron la política antes de que existiera un incidente sobre el cual ponerse emocional.

También funciona en la dirección contraria, que la gente suele olvidar: un error budget no es solo un garrote, es un permiso explícito para tomar riesgos cuando hay margen. Un equipo que tiene el 95% de su error budget intacto con dos semanas restantes en la ventana tiene un argumento legítimo y respaldado por datos para lanzar algo más grande y más riesgoso de lo habitual —el budget existe precisamente para que "cuánto riesgo podemos asumir ahora mismo" tenga una respuesta real en vez de ser una sensación.

Por último, los error budgets le dan a ingeniería una forma defendible de discutir pedidos externos poco razonables: si ventas quiere prometerle a un cliente un SLA del 99.99% y el SLO actual, medido honestamente, es del 99.9%, la matemática del error budget hace que la brecha sea concreta e innegociable —habría que invertir en trabajo de confiabilidad específico (failover multi-región, mejores pruebas, gates de rollout más lentos) antes de que ese número sea creíble, en lugar de simplemente decir que sí porque suena bien en una presentación de ventas.

#Los cuatro términos, lado a lado

🧠 Check your understanding
0/3 · 0/3 answered
1. Un equipo tiene un SLO de 99.9% de disponibilidad mensual y un SLA del 99.5% con los mismos clientes. ¿Por qué el SLO es deliberadamente más estricto que el SLA?
La brecha es un margen de seguridad: el alerting interno y las políticas de error budget se disparan bastante antes de que la empresa esté realmente incumpliendo el SLA contractualEn la práctica no hay ninguna diferencia significativa entre ambos númerosUna regulación de la industria exige que el SLO siempre sea mayor que el SLAEs un error de tipeo — el SLA y el SLO siempre deberían fijarse en el mismo número
2. Un servicio tiene un SLO de disponibilidad mensual del 99.9%. Un único incidente provoca una caída de 25 minutos sobre un error budget mensual de aproximadamente 43 minutos. ¿Cuál es la respuesta de ingeniería apropiada bajo una política de error budget típica?
El incidente debería excluirse del cálculo del SLO porque fue causado por un deploy y no por tráfico orgánicoEl SLO debería bajarse inmediatamente para que el incidente quede dentro de lo permitidoNada — un único incidente siempre está dentro de límites aceptables sin importar el budget consumidoSe gastó aproximadamente el 58% del budget mensual, lo cual debería disparar una respuesta de política acordada de antemano, como pausar trabajo de features no esenciales y priorizar arreglos de confiabilidad el resto del mes
3. ¿Cuál es el principal beneficio práctico de tener una política de error budget explícita y acordada de antemano, comparado con discutir caso por caso confiabilidad vs. trabajo de features?
Garantiza que el servicio nunca más va a tener una caídaElimina la necesidad de medir cualquier SLIConvierte lo que de otro modo sería una negociación política y del momento en una decisión objetiva basada en un número que todos ya habían acordado antes de que ocurriera un incidentePermite renegociar el SLA automáticamente con los clientes