¿Qué es la gestión de SLA?

¿Qué es la gestión de SLA?

La gestión de SLA es el trabajo de definir, medir e informar de los niveles de servicio que has prometido a tus clientes. Un acuerdo de nivel de servicio (SLA) es un contrato que asocia consecuencias, como créditos de servicio, al incumplimiento de objetivos pactados como la disponibilidad o el tiempo de respuesta. Gestionarlo implica fijar objetivos medibles, instrumentarlos, alertar antes del incumplimiento, informar del cumplimiento y tramitar los créditos.

SLI, SLO y SLA: la diferencia

El libro SRE de Google define los tres términos así, y la distinción aclara quién es responsable de qué:

• SLI (indicador de nivel de servicio): una medida cuantitativa bien definida de un aspecto del servicio, por ejemplo el porcentaje de peticiones que terminan bien.
• SLO (objetivo de nivel de servicio): un valor o rango objetivo para un SLI, por ejemplo que el 99,9 % de las peticiones tenga éxito en 28 días.
• SLA (acuerdo de nivel de servicio): un contrato con los usuarios que incluye las consecuencias de cumplir o incumplir los SLO que contiene. Si no hay una consecuencia explícita, casi seguro se trata de un SLO.

El libro SRE añade que los SLA están ligados a decisiones de negocio y de producto, y que un SLO interno más estricto que el público deja margen para resolver problemas crónicos antes de que los usuarios los noten. La práctica general se explica en ingeniería de fiabilidad.

Qué significan los porcentajes de disponibilidad en tiempo

Un objetivo de disponibilidad solo se vuelve concreto al convertirlo en tiempo de caída permitido. Las cifras son aritmética simple: (1 menos el objetivo) por la duración de la ventana, con una semana de 7 días, un mes de 30 días y un año de 365 días.

Comprueba qué ventana usa el contrato. Un mes natural de 31 días permite más caída que uno de 28, y el 99,99 % deja unos cuatro minutos al mes, que un solo despliegue lento puede consumir.

Cómo funciona la gestión de SLA

1. Redactar términos medibles. Define el alcance (qué endpoints o funciones), la ventana de medición, cómo se cuenta una petición fallida y las exclusiones, como el mantenimiento programado anunciado con antelación.
2. Medir el SLI desde fuera. Mide lo que vive el cliente, no lo que cree tu servidor. Las comprobaciones externas desde varias ubicaciones son más difíciles de discutir que los logs internos solos.
3. Fijar un SLO interno más estricto. Si el SLA promete el 99,5 % mensual, un SLO interno del 99,9 % deja unas 2 horas y 53 minutos de margen al mes (172,8 minutos en un mes de 30 días) antes de poner en riesgo el contrato.
4. Alertar sobre el SLO, no sobre el SLA. Cuando se incumple el SLA, el cliente ya lo ha notado.
5. Informar del cumplimiento. Publica la cifra mensual de forma automática, por ejemplo en una página de estado, para que nadie tenga que discutirla.
6. Gestionar los incumplimientos. Calcula los créditos según el calendario del contrato, avisa al cliente y haz una revisión. La comunicación de incidentes durante la caída forma parte de la experiencia del SLA.

Ejemplo

Una empresa SaaS promete un 99,5 % de disponibilidad mensual para su API y mantiene un SLO interno del 99,9 %. En un mes de 30 días el SLO permite 43 minutos de caída y el SLA 3 horas y 36 minutos. Un mal despliegue causa 52 minutos de errores: se incumple el SLO, así que el equipo abre una revisión del incidente, pero el SLA se cumple y no se debe ningún crédito. Sin SLO interno, nadie habría mirado hasta cruzar la línea del contrato.

Errores frecuentes

• Prometer un SLA sin SLO ni medición asociados, de modo que el cumplimiento se discute de memoria.
• Elegir una cifra de una tabla, como los cinco nueves, en lugar de lo que la arquitectura puede ofrecer.
• Medir la disponibilidad desde una sola ubicación, que no distingue un problema regional de uno global.
• Contar solo las caídas totales e ignorar las respuestas lentas que el cliente vive como fallos.
• Dejar vagas las exclusiones, de modo que cada incidente se convierte en una disputa.

Gestión de SLA con pruebas y monitorización

La monitorización produce el SLI. La monitorización de API comprueba tus endpoints de forma programada y registra fallos y tiempos de respuesta. La monitorización de API de LoadFocus ejecuta comprobaciones en 25 regiones en la nube, avisa por correo, Slack, Microsoft Teams y otros canales, y muestra la disponibilidad en el periodo que elijas. El plan gratuito comprueba cada 5 minutos e incluye una página de estado; los informes de SLA frente a un objetivo están en los planes de pago.

Las pruebas muestran si el objetivo es realista. No se puede defender una promesa de latencia con tráfico máximo sin pruebas de carga y pruebas de capacidad. Para la parte de monitorización, lee el artículo en inglés buenas prácticas de monitorización para DevOps y desarrolladores.

Preguntas frecuentes: gestión de SLA

¿Cuál es la diferencia entre SLA, SLO y SLI?

Un SLI es una medición, un SLO es un objetivo para esa medición y un SLA es un contrato que asocia consecuencias al incumplimiento del objetivo. Los equipos suelen operar con SLO internos y prometer un SLA más flexible hacia fuera.

¿Cuánta caída permite el 99,9 %?

Unos 43 minutos en un mes de 30 días y unas 8 horas y 46 minutos en un año de 365 días. Cada nueve adicional divide el margen entre diez.

¿Qué ocurre cuando se incumple un SLA?

Depende del contrato. Lo habitual es un crédito de servicio calculado según un baremo del acuerdo. Consulta tu propio contrato para ver los términos exactos, el proceso de reclamación y las exclusiones.

¿Debe el SLO ser más estricto que el SLA?

Sí. Un SLO interno más estricto te avisa antes de que el contrato corra riesgo y deja margen para resolver problemas antes de que los clientes los noten.

¿Quién se encarga de la gestión de SLA?

Varios equipos. Ingeniería se ocupa de la medición y la arquitectura, producto y éxito del cliente del contrato y su redacción, y finanzas de los créditos.