SLA design: cómo diseñar acuerdos de nivel de servicio que funcionen
Por qué la mayoría de los SLAs no sirven para nada
Abre el SLA de cualquier proveedor de servicios tecnológicos y probablemente encontrarás algo así: “Disponibilidad del 99.9%”. Suena bien. Pero qué significa realmente?
Significa que el servicio puede estar caído 8 horas y 45 minutos al año. Eso son más 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 operación logística crítica. Entonces descubres que el SLA no especifica cómo se mide la disponibilidad, que las ventanas de mantenimiento programado están excluidas, que los incidentes de “degradación parcial” no computan, y que la penalización máxima son dos meses de crédito de servicio que nunca vas a reclamar porque el proceso es deliberadamente engorroso.
Un SLA bien diseñado no es un documento legal para archivar. Es un contrato operativo que define expectativas, alinea incentivos y crea un mecanismo de accountability. Hemos diseñado (y operado bajo) decenas de SLAs para nuestros servicios gestionados. Estas son las lecciones.
La jerarquía: SLI, SLO, SLA
Antes de diseñar un SLA, necesitas entender las tres capas de la jerarquía. Google SRE popularizó estos conceptos, y por una buena razón: separan la medición del compromiso.
SLI (Service Level Indicator). La métrica concreta que mides. Ejemplo: “porcentaje de requests HTTP que responden en menos de 500ms con código 2xx”. Un SLI es un número que sale de tu sistema de monitorización. No tiene opinión; 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/éxito”. Un SLO es una decisión de ingeniería. Si es demasiado alto, gastas más 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 más SLOs, con consecuencias definidas si no se cumple. Ejemplo: “si la disponibilidad mensual cae por debajo del 99.5%, el cliente recibe un crédito del 10% de la factura mensual”.
La regla fundamental: tu SLO debe ser más estricto que tu SLA. Si tu SLA garantiza 99.5%, tu SLO interno debería 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.
Selección de métricas: qué medir
El error más común en el diseño de SLAs es medir lo que es fácil 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 está mal configurado.
Las métricas 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 monitorización sintética (checks externos) además de métricas internas. Usamos herramientas como Uptime Robot, Checkly, o nuestro propio sistema de checks vía obs-turbo para medir desde múltiples ubicaciones.
Latencia. Tiempo de respuesta medido en percentiles. La media es inútil porque oculta los outliers. Usamos p50 (mediana), p95 y p99. El SLA debería definir: “el p95 de latencia no superará los 500ms”. Esto significa que el 95% de las requests responden en menos de 500ms. El 5% restante puede ser más 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 cuánto tarda el sistema en recuperarse, sino cuánto tarda el equipo en empezar a trabajar en el problema. Definido por severidad: P1 (servicio caído) -> respuesta en 15 minutos. P2 (degradación) -> respuesta en 1 hora. P3 (problema menor) -> respuesta en 4 horas laborables.
Metodología de medición
Cómo mides importa tanto como qué mides. Un SLA sin metodología de medición definida es una invitación al conflicto.
Ventana de medición. Mensual es el estándar. Anual suaviza demasiado los problemas (puedes tener un mes desastroso y cumplir el SLA anual). Semanal es demasiado granular y genera ruido.
Exclusiones. Define explícitamente qué no cuenta: mantenimiento programado (con preaviso mínimo de 48 horas), incidentes causados por el cliente (cambios de configuración, picos de tráfico no notificados), fuerza mayor. Las exclusiones deben ser específicas, no genéricas. “Circunstancias fuera de nuestro control” es tan amplio que invalida el SLA.
Fuente de datos. Quién provee los datos de medición. Idealmente, un sistema independiente del proveedor. Si el proveedor mide su propia disponibilidad, hay un conflicto de intereses obvio. Herramientas de monitorización de terceros (Datadog, New Relic, o checks sintéticos desde StatusPage) resuelven esto.
Cálculo. La fórmula 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 más de 1 minuto en el que más del 5% de los requests sintéticos desde al menos 2 ubicaciones externas fallan.
Cuanto más específico, menos ambigüedad. Cuanto menos ambigüedad, menos conflictos.
Estructura de penalizaciones
Las penalizaciones deben crear incentivos reales. Un crédito del 5% en un servicio que cuesta 500 EUR/mes no incentiva a nadie a perder el sueño un sábado. Pero tampoco deben ser tan agresivas que el proveedor no pueda operar de forma sostenible.
Un modelo escalonado que funciona:
| Disponibilidad mensual | Crédito |
|---|---|
| >= 99.5% | 0% |
| 99.0% - 99.49% | 10% |
| 98.0% - 98.99% | 25% |
| 95.0% - 97.99% | 50% |
| < 95.0% | 100% + derecho de rescisión |
Para incidentes de latencia o tiempo de respuesta, el modelo es similar pero basado en el número de incumplimientos mensuales.
Dos reglas críticas:
Los créditos deben ser automáticos. Si el cliente tiene que reclamar para obtener el crédito, el 90% no reclamará y el SLA se convierte en teatro. En nuestros servicios gestionados, los créditos se aplican automáticamente en la siguiente factura cuando el sistema detecta incumplimiento.
El SLA debe incluir un mecanismo de rescisión. Si el proveedor incumple repetidamente (por ejemplo, 3 meses de los últimos 6 por debajo del SLA), el cliente debe poder resolver el contrato sin penalización. Esto protege al cliente de un proveedor que prefiere pagar créditos a invertir en mejorar.
Los nueves engañan
Una nota sobre la obsesión con los “nueves” de disponibilidad. La diferencia entre 99.9% y 99.99% es un orden de magnitud en ingeniería y en coste, pero no siempre un orden de magnitud en valor para el negocio.
| Nivel | Downtime anual | Downtime mensual |
|---|---|---|
| 99% | 3.65 días | 7.3 horas |
| 99.5% | 1.83 días | 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 geográfica, failover automático, zero-downtime deployments, y una inversión en infraestructura que puede triplicar el coste. Antes de exigir (o prometer) un cuarto nueve, pregúntate: los 39 minutos menos de downtime al mes justifican duplicar o triplicar la factura?
Para la mayoría 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 crítica: 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 alineación.
Un equipo de plataforma que opera bajo un SLO interno del 99.9% para el servicio de autenticación se comporta de forma diferente a uno que simplemente “intenta que no se caiga”. El SLO crea un error budget que permite tomar decisiones explícitas: si tenemos el 30% del budget consumido a mitad de mes, quizás no es buen momento para ese refactoring agresivo.
El formato puede ser más ligero que un SLA externo (sin penalizaciones económicas, por ejemplo), pero los elementos esenciales son los mismos: métrica, objetivo, medición, y revisión periódica.
Revisión y mejora continua
Un SLA no es un documento estático. Debe revisarse al menos trimestralmente con datos reales. Las preguntas clave:
- Se ha cumplido el SLA? Si no, por qué? Fue un incidente puntual o un patrón?
- El SLO interno es suficientemente estricto? Si nunca te acercas al límite, quizás es demasiado conservador y estás sobreinvirtiendo.
- Las métricas 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 relación adversarial.
Para profundizar en cómo construir esa cultura operativa que hace los SLAs innecesarios de invocar, consulta nuestro artículo sobre mejora continua con Kaizen digital. Y para entender el impacto económico de elegir el modelo de pricing correcto, nuestra guía sobre reducción de costes con servicios gestionados desglosa los números. El mejor SLA es el que nunca necesitas invocar, no porque esté mal diseñado, sino porque las métricas, los SLOs internos, y la cultura operativa del proveedor hacen que el incumplimiento sea raro y la comunicación proactiva cuando ocurre.
