SLA design: como disenar acuerdos de nivel de servicio que funcionen

Por que la mayoria de los SLAs no sirven para nada

Abre el SLA de cualquier proveedor de servicios tecnologicos y probablemente encontraras algo asi: “Disponibilidad del 99.9%”. Suena bien. Pero que significa realmente?

Significa que el servicio puede estar caido 8 horas y 45 minutos al ano. Eso son mas de 43 minutos al mes. Parece asumible, hasta que esas 43 minutos caen en medio de un pico de ventas, un cierre contable, o una operacion logistica critica. Entonces descubres que el SLA no especifica como se mide la disponibilidad, que las ventanas de mantenimiento programado estan excluidas, que los incidentes de “degradacion parcial” no computan, y que la penalizacion maxima son dos meses de credito de servicio que nunca vas a reclamar porque el proceso es deliberadamente engorroso.

Un SLA bien disenado no es un documento legal para archivar. Es un contrato operativo que define expectativas, alinea incentivos y crea un mecanismo de accountability. Hemos disenado (y operado bajo) decenas de SLAs para nuestros servicios gestionados. Estas son las lecciones.

La jerarquia: SLI, SLO, SLA

Antes de disenar un SLA, necesitas entender las tres capas de la jerarquia. Google SRE popularizo estos conceptos, y por una buena razon: separan la medicion del compromiso.

SLI (Service Level Indicator). La metrica concreta que mides. Ejemplo: “porcentaje de requests HTTP que responden en menos de 500ms con codigo 2xx”. Un SLI es un numero que sale de tu sistema de monitorizacion. No tiene opinion; es un hecho.

SLO (Service Level Objective). El objetivo interno que te marcas para un SLI. Ejemplo: “el 99.5% de los requests deben cumplir el SLI de latencia/exito”. Un SLO es una decision de ingenieria. Si es demasiado alto, gastas mas de lo necesario en redundancia. Si es demasiado bajo, los usuarios se quejan.

SLA (Service Level Agreement). El compromiso contractual con el cliente, basado en uno o mas SLOs, con consecuencias definidas si no se cumple. Ejemplo: “si la disponibilidad mensual cae por debajo del 99.5%, el cliente recibe un credito del 10% de la factura mensual”.

La regla fundamental: tu SLO debe ser mas estricto que tu SLA. Si tu SLA garantiza 99.5%, tu SLO interno deberia ser 99.8% o 99.9%. El margen entre los dos es tu error budget: el espacio que tienes para fallos, mantenimiento, y experimentos antes de incumplir el compromiso contractual.

Seleccion de metricas: que medir

El error mas comun en el diseno de SLAs es medir lo que es facil de medir en lugar de lo que importa al cliente. El uptime del servidor no es lo mismo que la disponibilidad del servicio para el usuario final. Un servidor puede estar “up” al 100% mientras el usuario ve un error 503 porque el balanceador esta mal configurado.

Las metricas que recomendamos para SLAs de servicios web:

Disponibilidad (success rate). Porcentaje de requests que responden correctamente (HTTP 2xx o 3xx). Medido desde el punto del usuario, no desde el servidor. Esto implica monitorizacion sintetica (checks externos) ademas de metricas internas. Usamos herramientas como Uptime Robot, Checkly, o nuestro propio sistema de checks via obs-turbo para medir desde multiples ubicaciones.

Latencia. Tiempo de respuesta medido en percentiles. La media es inutil porque oculta los outliers. Usamos p50 (mediana), p95 y p99. El SLA deberia definir: “el p95 de latencia no superara los 500ms”. Esto significa que el 95% de las requests responden en menos de 500ms. El 5% restante puede ser mas lento sin incumplir.

Durabilidad de datos. Para servicios que almacenan datos, la probabilidad de no perder datos. AWS S3 ofrece 99.999999999% (once nueves). Tu servicio probablemente no necesita tanto, pero la expectativa debe estar definida. No confundir disponibilidad con durabilidad: el dato puede estar disponible al 99.9% (puedes acceder casi siempre) pero tener una durabilidad del 99.999% (es casi imposible que se pierda).

Tiempo de respuesta a incidentes. No cuanto tarda el sistema en recuperarse, sino cuanto tarda el equipo en empezar a trabajar en el problema. Definido por severidad: P1 (servicio caido) -> respuesta en 15 minutos. P2 (degradacion) -> respuesta en 1 hora. P3 (problema menor) -> respuesta en 4 horas laborables.

Metodologia de medicion

Como mides importa tanto como que mides. Un SLA sin metodologia de medicion definida es una invitacion al conflicto.

Ventana de medicion. Mensual es el estandar. Anual suaviza demasiado los problemas (puedes tener un mes desastroso y cumplir el SLA anual). Semanal es demasiado granular y genera ruido.

Exclusiones. Define explicitamente que no cuenta: mantenimiento programado (con preaviso minimo de 48 horas), incidentes causados por el cliente (cambios de configuracion, picos de trafico no notificados), fuerza mayor. Las exclusiones deben ser especificas, no genericas. “Circunstancias fuera de nuestro control” es tan amplio que invalida el SLA.

Fuente de datos. Quien provee los datos de medicion. Idealmente, un sistema independiente del proveedor. Si el proveedor mide su propia disponibilidad, hay un conflicto de intereses obvio. Herramientas de monitorizacion de terceros (Datadog, New Relic, o checks sinteticos desde StatusPage) resuelven esto.

Calculo. La formula exacta. Por ejemplo:

Disponibilidad mensual (%) = ((Total minutos en el mes - Minutos de downtime) / Total minutos en el mes) * 100

Donde “downtime” se define como: cualquier periodo de mas de 1 minuto en el que mas del 5% de los requests sinteticos desde al menos 2 ubicaciones externas fallan.

Cuanto mas especifico, menos ambiguedad. Cuanto menos ambiguedad, menos conflictos.

Estructura de penalizaciones

Las penalizaciones deben crear incentivos reales. Un credito del 5% en un servicio que cuesta 500 EUR/mes no incentiva a nadie a perder el sueno un sabado. Pero tampoco deben ser tan agresivas que el proveedor no pueda operar de forma sostenible.

Un modelo escalonado que funciona:

Disponibilidad mensual	Credito
>= 99.5%	0%
99.0% - 99.49%	10%
98.0% - 98.99%	25%
95.0% - 97.99%	50%
< 95.0%	100% + derecho de rescision

Para incidentes de latencia o tiempo de respuesta, el modelo es similar pero basado en el numero de incumplimientos mensuales.

Dos reglas criticas:

Los creditos deben ser automaticos. Si el cliente tiene que reclamar para obtener el credito, el 90% no reclamara y el SLA se convierte en teatro. En nuestros servicios gestionados, los creditos se aplican automaticamente en la siguiente factura cuando el sistema detecta incumplimiento.

El SLA debe incluir un mecanismo de rescision. Si el proveedor incumple repetidamente (por ejemplo, 3 meses de los ultimos 6 por debajo del SLA), el cliente debe poder resolver el contrato sin penalizacion. Esto protege al cliente de un proveedor que prefiere pagar creditos a invertir en mejorar.

Los nueves enganan

Una nota sobre la obsesion con los “nueves” de disponibilidad. La diferencia entre 99.9% y 99.99% es un orden de magnitud en ingenieria y en coste, pero no siempre un orden de magnitud en valor para el negocio.

Nivel	Downtime anual	Downtime mensual
99%	3.65 dias	7.3 horas
99.5%	1.83 dias	3.65 horas
99.9%	8.76 horas	43.8 minutos
99.95%	4.38 horas	21.9 minutos
99.99%	52.6 minutos	4.38 minutos

Pasar de 99.9% a 99.99% requiere redundancia geografica, failover automatico, zero-downtime deployments, y una inversion en infraestructura que puede triplicar el coste. Antes de exigir (o prometer) un cuarto nueve, preguntate: los 39 minutos menos de downtime al mes justifican duplicar o triplicar la factura?

Para la mayoria de las aplicaciones de negocio (ERPs, CRMs, webs corporativas, herramientas internas), 99.5% a 99.9% es el rango correcto. Los cuatro nueves se reservan para infraestructura critica: pasarelas de pago, sistemas de salud, plataformas de trading.

SLAs internos

Los SLAs no son solo para relaciones con proveedores. Los SLAs internos entre equipos (plataforma -> producto, datos -> analytics, IT -> operaciones) crean las mismas dinámicas de accountability y alineacion.

Un equipo de plataforma que opera bajo un SLO interno del 99.9% para el servicio de autenticacion se comporta de forma diferente a uno que simplemente “intenta que no se caiga”. El SLO crea un error budget que permite tomar decisiones explicitas: si tenemos el 30% del budget consumido a mitad de mes, quizas no es buen momento para ese refactoring agresivo.

El formato puede ser mas ligero que un SLA externo (sin penalizaciones economicas, por ejemplo), pero los elementos esenciales son los mismos: metrica, objetivo, medicion, y revision periodica.

Revision y mejora continua

Un SLA no es un documento estatico. Debe revisarse al menos trimestralmente con datos reales. Las preguntas clave:

• Se ha cumplido el SLA? Si no, por que? Fue un incidente puntual o un patron?
• El SLO interno es suficientemente estricto? Si nunca te acercas al limite, quizas es demasiado conservador y estas sobreinvirtiendo.
• Las metricas del SLA reflejan la experiencia real del usuario? Un SLA de disponibilidad al 99.9% no dice nada si el servicio es inutilizablemente lento sin llegar a caerse.
• Las penalizaciones son proporcionales? Demasiado bajas no incentivan. Demasiado altas crean una relacion adversarial.

Para profundizar en como construir esa cultura operativa que hace los SLAs innecesarios de invocar, consulta nuestro articulo sobre mejora continua con Kaizen digital. Y para entender el impacto economico de elegir el modelo de pricing correcto, nuestra guia sobre reduccion de costes con servicios gestionados desglosa los numeros. El mejor SLA es el que nunca necesitas invocar, no porque este mal disenado, sino porque las metricas, los SLOs internos, y la cultura operativa del proveedor hacen que el incumplimiento sea raro y la comunicacion proactiva cuando ocurre.