SLA, SLO y error budget: qué significa de verdad un 99,9% de disponibilidad

Un 99,9% no es "casi siempre disponible"

Los porcentajes de disponibilidad engañan porque nuestra intuición los lee como notas de examen. Traducidos a tiempo, la cosa cambia:

| Disponibilidad | Caída al día | Al mes (30 d) | Al año | | --- | --- | --- | --- | | 99% | 14 min 24 s | 7 h 12 min | 3 d 15 h | | 99,5% | 7 min 12 s | 3 h 36 min | 1 d 19 h | | 99,9% | 1 min 26 s | 43 min 12 s | 8 h 45 min | | 99,95% | 43 s | 21 min 36 s | 4 h 22 min | | 99,99% | 8,6 s | 4 min 19 s | 52 min 35 s | | 99,999% | 0,9 s | 26 s | 5 min 15 s |

Dos lecturas prácticas. La primera: con tres nueves, un solo reinicio mal planificado puede consumir el mes entero. La segunda: los cinco nueves son incompatibles con cualquier intervención manual, porque nadie recibe la alerta, diagnostica y arregla en cinco minutos al año. Cuatro nueves ya exige automatización de la recuperación; cinco exige redundancia activa-activa y failover sin intervención humana.

SLI, SLO y SLA: tres cosas que se confunden a diario

• SLI (Service Level Indicator): la métrica que mides. No "el servidor está encendido", sino algo que refleje la experiencia del usuario: porcentaje de peticiones HTTP con respuesta correcta, porcentaje de peticiones por debajo de 300 ms, porcentaje de trabajos de cola completados en plazo.
• SLO (Service Level Objective): el objetivo interno para ese SLI, por ejemplo "99,95% de peticiones correctas en ventana de 30 días".
• SLA (Service Level Agreement): el compromiso contractual con el cliente, con penalizaciones si se incumple.

La regla de oro: el SLO siempre más exigente que el SLA. Si firmas 99,9%, trabaja internamente con 99,95%. Ese colchón es lo que te permite tener un mal mes sin pagar penalizaciones ni perder credibilidad.

Y elige bien el SLI: medir con un ping al puerto 443 es cómodo pero miente. Un servicio que responde 200 con una página de error, o que tarda 12 segundos, está caído desde el punto de vista del usuario aunque tu monitorización lo pinte verde.

Error budget: convertir la fiabilidad en un presupuesto

Si el SLO es 99,9% mensual, tienes 43 minutos de indisponibilidad. Eso no es un fracaso a evitar: es un presupuesto a gastar. El planteamiento de SRE que popularizó Google es sencillo y desactiva la eterna tensión entre desarrollo y operaciones:

• Mientras quede error budget, el equipo despliega con normalidad y asume riesgo: es la señal de que el sistema tiene margen.
• Cuando se agota, se congelan las novedades y todo el esfuerzo va a fiabilidad hasta que la ventana se recupera.

La virtud del mecanismo es que es objetivo. Nadie discute "si esto es lo bastante estable"; se mira el presupuesto consumido. Y también evita el extremo opuesto: si acabas mes tras mes sin gastar nada, estás sobreinvirtiendo en fiabilidad y probablemente desplegando demasiado despacio.

Dependencias en serie: la matemática incómoda

La disponibilidad de componentes en serie se multiplica. Un servicio que necesita balanceador, aplicación y base de datos, cada uno al 99,9%:

0,999 × 0,999 × 0,999 = 0,997 → 99,7%

Has pasado de 43 minutos a más de dos horas de caída mensual sin que ningún componente incumpla su propio objetivo. Añade una API de pago externa al 99,9% y bajas al 99,6%.

La redundancia funciona al contrario: dos instancias independientes al 99% en paralelo dan 1 − (0,01 × 0,01) = 99,99%. La clave es la palabra independientes: dos VMs en el mismo host, el mismo bastidor o la misma zona de disponibilidad comparten modos de fallo y no multiplican nada. Ahí es donde el diseño multi-AZ deja de ser un lujo.

La letra pequeña de los SLA comerciales

Antes de apoyarte en el SLA de un proveedor, comprueba tres cosas:

1. Qué se mide. Muchos SLA de cloud cubren la disponibilidad de la API de gestión o de la instancia individual, no del servicio que tú compones encima. Y suelen exigir arquitectura multi-zona para que el compromiso aplique. 2. Qué se excluye. Mantenimiento planificado y anunciado, fuerza mayor, ataques, fallos de configuración del cliente, betas y regiones nuevas. 3. Cómo se compensa. La compensación típica es un crédito del 10-25% de la factura del mes afectado, previa reclamación tuya en un plazo determinado. No cubre tu pérdida de negocio, así que un SLA no es una póliza de seguro: es una declaración de intenciones con una multa simbólica.

Tabla de downtime permitido por SLO

| SLO | Al mes | Al trimestre | Al año | | --- | --- | --- | --- | | 99 % | 7 h 18 min | 21 h 54 min | 3,65 días | | 99,5 % | 3 h 39 min | 10 h 57 min | 1,83 días | | 99,9 % | 43 min 50 s | 2 h 11 min | 8 h 46 min | | 99,95 % | 21 min 55 s | 1 h 5 min | 4 h 23 min | | 99,99 % | 4 min 23 s | 13 min 9 s | 52 min 36 s | | 99,999 % | 26 s | 1 min 19 s | 5 min 15 s |

Ejemplo de error budget consumido

SLO del 99,9 % mensual = 43 min 50 s de presupuesto. En marzo tuviste una caída de 12 minutos por un despliegue y otra de 25 minutos por un fallo de disco: 37 minutos gastados, 84 % del presupuesto consumido con una semana por delante. Decisión objetiva: congelar despliegues no críticos y dedicar el sprint a fiabilidad.

Ejemplo con SLI basado en peticiones

Si mides disponibilidad como peticiones correctas / peticiones totales, con 20 millones de peticiones al mes y un SLO del 99,95 %, el presupuesto son 10.000 errores. Un pico de 4.000 respuestas 5xx en un despliegue se gasta el 40 % del mes en diez minutos, aunque el servicio "estuviera arriba".

Cómo pasar de porcentaje a minutos a mano

Downtime = (1 − SLO) × minutos del periodo
99,9 % mensual → 0,001 × 43.200 = 43,2 min

Cómo empezar mañana

1. Define un SLI que refleje la experiencia real del usuario y mídelo desde fuera de tu infraestructura. 2. Fija un SLO alcanzable a partir del histórico de los últimos tres meses, no del que te gustaría tener. 3. Calcula el error budget del periodo y publícalo en un panel que vea todo el equipo. 4. Acuerda por escrito qué pasa cuando se agota, antes de que se agote.

Traduce cualquier porcentaje a minutos con la calculadora de SLA y uptime, y si estás dimensionando la redundancia que ese objetivo exige, apóyate en la calculadora de coste de servidor, la de coste cloud y la de recursos para VMs. Para automatizar los chequeos periódicos, genera la tarea con el generador de crontab o un timer de systemd.