SLA que miden lo que le importa al negocio

El informe mensual dice que todos los acuerdos de nivel de servicio se cumplieron. La reunión con el negocio, sin embargo, empieza con quejas: la aplicación móvil estuvo lenta toda la semana del cierre, los pagos fallaron de forma intermitente y nadie avisó. Ambas cosas pueden ser ciertas a la vez. Cuando eso pasa, el problema no está en la operación, sino en lo que el acuerdo eligió medir.

El efecto sandía

Se le llama efecto sandía al indicador que está verde por fuera y rojo por dentro. Sus causas son conocidas:

• Se mide el componente, no el servicio. Por ejemplo, el servidor estuvo disponible el 99,9 % del tiempo, pero la transacción que usa el cliente depende de diez componentes y de un tercero.
• Se mide el promedio, no la experiencia. El tiempo de respuesta medio es bueno, pero una parte de los usuarios espera mucho más, y son justamente los que llaman.
• Se mide el proceso, no el resultado. Por ejemplo, el 98 % de los tickets se respondió dentro del plazo, pero "responder" significa enviar un acuse automático.
• Se excluye lo incómodo. Ventanas de mantenimiento amplias, degradaciones que no cuentan como caída o incidentes reclasificados para no afectar el indicador.

Ninguna de estas prácticas es deshonesta en sí misma. El problema es el resultado: un informe que no le sirve al negocio para decidir y una operación que optimiza el indicador en lugar del servicio.

SLA, OLA y SLO: tres herramientas distintas

Parte de la confusión viene de usar "SLA" para todo. Conviene separar tres conceptos:

Concepto	Entre quiénes	Para qué sirve
SLA (acuerdo de nivel de servicio)	El proveedor del servicio y su cliente, interno o externo	Documentar el nivel de servicio esperado y cómo se medirá, en términos que el cliente entienda
OLA (acuerdo de nivel operativo)	Equipos internos del proveedor (redes, bases de datos, service desk)	Asegurar que cada equipo comprometa lo que el SLA necesita de él
SLO (objetivo de nivel de servicio)	Uso principalmente interno, en la práctica de ingeniería de confiabilidad	Fijar un objetivo medible sobre un indicador concreto, con un margen de error tolerado

A estos se suman los contratos de soporte con terceros, que deben estar alineados con los SLA que dependen de ellos. Un SLA de restauración de cuatro horas no se sostiene si el proveedor del enlace tiene ocho horas para responder.

El enfoque de SLO, popularizado por la ingeniería de confiabilidad de sitios (SRE) de Google, aporta una idea valiosa: el presupuesto de error. Si el objetivo es 99,5 % de solicitudes exitosas, el 0,5 % restante es un margen que el equipo puede consumir en cambios y experimentos. Cuando el margen se agota, la prioridad pasa a ser la estabilidad. Esto convierte el objetivo en una herramienta de decisión, no solo de reporte.

La gestión del nivel de servicio en ITIL 4 y el enfoque de SLO no compiten. Los SLO pueden ser la base técnica sobre la cual se construyen los SLA que se acuerdan con el negocio.

Definir las medidas desde el recorrido del usuario

La pregunta inicial no es "qué podemos medir" sino "qué intenta hacer el usuario y qué significa para él que funcione". Recomendamos este proceso:

1. Identifica los recorridos críticos. Con el dueño de negocio, elige los tres a cinco recorridos que más importan: iniciar sesión, consultar saldo, pagar, emitir una póliza, agendar una cita.
2. Define qué es éxito en cada uno. Por ejemplo: "el pago se completa, sin error técnico, y el usuario ve la confirmación en menos de cinco segundos".
3. Elige el indicador. Proporción de intentos exitosos, percentil de tiempo de respuesta o frescura de los datos, según el recorrido. Evita los promedios.
4. Decide cómo medirlo. Transacciones reales observadas desde la aplicación, transacciones sintéticas que simulan al usuario, o ambas. Las primeras muestran lo que pasó; las segundas detectan fallas cuando hay poco tráfico.
5. Fija el objetivo con datos. Mira varios meses de historia antes de comprometer un número. Un objetivo que se cumple siempre sin esfuerzo no informa; uno que nunca se cumple desmotiva.
6. Derívalo hacia dentro. Traduce cada medida en compromisos para los equipos internos (OLA) y para los terceros.

Medir recorridos exige que la aplicación sea observable: identificadores de correlación, trazas propagadas entre servicios y métricas de negocio que registren operaciones completadas y fallidas. Una plataforma de monitoreo puede capturar mucho, pero si la aplicación no distingue un pago rechazado por fondos de uno fallido por un error técnico, el indicador no será confiable.

Experiencia junto a disponibilidad

La disponibilidad sigue siendo necesaria, pero no alcanza. Un servicio puede estar "arriba" y ser inutilizable. Conviene acompañarla con medidas de experiencia:

• Rendimiento percibido: percentiles altos (por ejemplo, el 95) del tiempo de respuesta en los recorridos críticos.
• Tasa de error del usuario: proporción de operaciones que fallan por causas técnicas.
• Satisfacción tras el contacto: una pregunta corta al cerrar incidentes y solicitudes.
• Esfuerzo: cuántas veces tuvo que contactar el usuario para resolver un mismo tema.

Algunas organizaciones formalizan estas medidas como acuerdos de nivel de experiencia (XLA). El nombre importa menos que la idea: incorporar al acuerdo al menos una medida que refleje lo que el usuario percibe y no solo lo que la infraestructura registra.

Un ejemplo de tabla de SLA

La tabla siguiente es un ejemplo ilustrativo para un servicio de banca en línea. Los objetivos no son recomendaciones: cada organización debe fijarlos a partir de su historia, su riesgo y lo que acuerde con el negocio.

Medida (ejemplo)	Definición	Objetivo (ejemplo)	Período
Éxito del inicio de sesión	Intentos de inicio de sesión que se completan sin error técnico, sobre el total	99,5 % o más	Mensual
Rendimiento de la consulta de saldo	Percentil 95 del tiempo hasta mostrar el resumen de cuentas	3 segundos o menos	Mensual
Éxito de transferencias	Transferencias iniciadas que se completan sin error técnico	99 % o más	Mensual
Restauración de incidentes de prioridad 1	Tiempo desde el registro hasta la restauración del servicio	4 horas o menos en el 95 % de los casos	Trimestral
Satisfacción con el service desk	Promedio de la encuesta al cierre, escala de 1 a 5	4 o más	Mensual

Fíjate en lo que la tabla no incluye: ni la disponibilidad de un servidor concreto ni el tiempo de primera respuesta de un ticket. Esas medidas pueden vivir en los OLA o en los tableros internos, donde son útiles para operar.

Cadencia de revisión e informes

Un SLA no es un documento que se firma y se archiva. Es una conversación periódica. Recomendamos tres niveles:

• Seguimiento continuo (operación): tableros en tiempo real con los indicadores de los recorridos críticos y alertas cuando el consumo del presupuesto de error se acelera.
• Revisión mensual (servicio): informe breve con el cumplimiento, los incidentes que más afectaron cada medida, los problemas abiertos y las acciones en curso. Una página por servicio suele bastar.
• Revisión trimestral o semestral (negocio): con el dueño del servicio, para revisar si las medidas siguen reflejando lo que importa, ajustar objetivos y acordar prioridades de mejora.

Para la revisión mensual, recomendamos una estructura fija: el valor de cada medida frente a su objetivo, la tendencia de los últimos meses, los dos o tres eventos que explican las desviaciones, el estado de los problemas asociados y los compromisos para el período siguiente. Mantener la misma estructura cada mes permite comparar y evita que el informe se convierta en una presentación distinta cada vez, armada para justificar el resultado.

Un buen informe de nivel de servicio responde a tres preguntas: cómo le fue al usuario, por qué y qué haremos al respecto. Si solo responde la primera con un semáforo, es un informe de cumplimiento, no de gestión.

Una señal útil para detectar el efecto sandía: compara cada mes el cumplimiento de los SLA con la satisfacción del negocio y con el volumen de quejas. Si se mueven en direcciones opuestas, el acuerdo necesita revisión.