Todos los equipos de ingeniería con los que hablo tienen SLOs. La mayoría tiene SLOs que no sirven para nada.

Están en una página de Notion en algún lugar, actualizados una vez al año cuando alguien recuerda que existen, y tienen cero influencia en las decisiones de ingeniería del día a día. Mientras tanto, el equipo funciona por intuición, despliega los viernes y se entera de los problemas de fiabilidad a través de sus clientes.

Aquí está por qué ocurre esto y cómo arreglarlo.

La confusión entre SLOs y SLAs

Un Service Level Agreement (SLA) es un contrato con consecuencias externas. Si lo incumples, los clientes reciben créditos, los contratos se revisan y los abogados intervienen. Los SLAs miran hacia atrás: miden si fallaste.

Un Service Level Objective (SLO) es un objetivo de ingeniería interno. Su propósito es impulsar decisiones antes de que falles. Los SLOs miran hacia adelante: te dicen si estás en el camino correcto.

La mayoría de equipos lo hace al revés. Definen su SLO como una versión ligeramente más laxa de su SLA, y luego lo tratan exactamente como un SLA.

El error budget es el punto clave

El concepto que hace útiles a los SLOs — y que la mayoría de equipos omite — es el error budget.

Si tu SLO es 99.9% de disponibilidad en 30 días, tu error budget es el 0.1% de 30 días = 43.2 minutos. Ese es el downtime permitido del mes.

La pregunta no es “¿cumplimos nuestro SLO?” La pregunta es “¿cuánto de nuestro error budget hemos gastado, y en qué?”

Cuando lo enmarcan así, el SLO se convierte en una herramienta de gestión de recursos. Estás asignando un presupuesto finito — riesgo de fiabilidad — y tomando decisiones conscientes sobre dónde gastarlo.

Cómo hacer SLOs que funcionen

Defínelos cerca del usuario. Mide lo que experimenta el usuario, no lo que reporta tu infraestructura.

Usa ventanas móviles, no calendarios. Una ventana móvil de 30 días significa que tu SLO siempre mide los últimos 30 días. Las ventanas de calendario crean incentivos perversos.

Ponlos en un dashboard que todos vean. Si tu SLO vive en un documento, no existe. Debe vivir junto a tu pipeline de despliegues.

Conéctalos a tu proceso de despliegue. Cuando el error budget cae por debajo del 50%, tu CI/CD debería requerir aprobación adicional. Cuando se agota, los despliegues deberían bloquearse automáticamente.

Los equipos que más valor obtienen de los SLOs son los que los tratan como una herramienta de comunicación, no como un ejercicio de cumplimiento.