Es importante para las compañías entender tus SLAs, SLOs y SLIs, los cuales representan las promesas que hacen a los clientes, los objetivos internos que ayudan a cumplirlas y las métricas que permiten demostrar su desempeño.

En este blog ya se ha hablado bastante sobre los SLAs; por eso, en esta ocasión, nos centraremos en los SLOs (Service Level Objectives), conocidos en español como los objetivos de nivel de servicio.

¿Qué es un SLO?

Se trata de un acuerdo dentro del SLA sobre una métrica específica como tiempo de respuesta o de actividad. Entonces, si el SLA es el contrato formal entre la empresa y el cliente, los SLOs son las promesas individuales que se le están haciendo. Estos son los que fijan las expectativas, además que indican al equipo de TI los objetivos que debe cumplir.

Los objetivos de nivel de servicio no son “odiados” como los SLAs, pero sí que pueden crear problemas si son vagos, muy complicados o imposibles de medir. La clave está en la simpleza y claridad. Solo las métricas más importantes deberían ser consideradas por un SLO; los objetivos deben ser explicados con lenguaje sencillo y, como con los SLAs, estos tienen que dar cuenta de problemas como retrasos con los clientes.

Las métricas más comunes asociadas con los SLOs son el tiempo de recuperación ante desastres, disponibilidad de las aplicaciones, tiempo de respuesta, resolución en la primera llamada y mantenimiento de aplicaciones.

¿Quién los necesita?

Si bien los SLAs solo son relevantes con aquellos clientes con los que se tiene un contrato, los SLOs también pueden ser útiles para los clientes que no están pagando, tanto internos como externos.

Sistemas internos, como CRMs, intranet y repositorios de datos del cliente, pueden ser tan importantes como aquellos diseñados para el exterior. Contar con SLOs para los sistemas internos resulta importante para cumplir las metas del negocio y, al mismo tiempo, permitir que los equipos alcancen sus propios objetivos relacionados con los clientes.

También lee: Los beneficios de un SLA en TI

¿Cómo funcionan?

Los SLOs, originados en los requerimientos de un negocio, pretenden definir un rango de los estándares de desempeño, del menos al más aceptado. Su proceso comienza al establecer los Indicadores de Nivel de Servicio (SLIs por sus siglas en inglés).

Ejemplo: Si la latencia de un servicio es el SLI, entonces el SLO debe mostrar cuántas solicitudes serán completadas en un tiempo determinado para definir una tasa de error aceptable. Por su parte, el SLA delineará las acciones a seguir por parte del cliente si el objetivo no es cumplido.

Una vez que las métricas son acordadas, los proveedores deben empezar a recolectar los datos y monitorear. Alertas deben ser enviadas para notificar cuando el SLO se encuentra por debajo del rango aceptable. De esta manera se podrán hacer reportes para ser analizados de acuerdo con los SLIs establecidos.

Consideraciones

• No toda métrica es vital para el éxito del cliente, es decir, no todas deben ser un SLO. Hay que comprometerse con la menor cantidad posible para que los clientes realmente puedan encontrar el valor.
  
  
• De igual forma, no toda métrica rastreable debe ser un SLI. Registrar el desempeño de diez componentes de cada de uno de los SLOs puede representar un problema. En su lugar, lo ideal es escoger de forma estratégica las métricas que más importan a los objetivos de nivel de servicio, para que así los esfuerzos resulten más efectivos.
  
  
• Los SLOs ayudan a priorizar el trabajo para todas las organizaciones que usan la Ingeniería de Confiabilidad de Sitios (SRE por sus siglas en inglés).
  
  
• El SLO puede cambiar con el tiempo conforme el sistema mejora.
  
  
• El objetivo de nivel de servicio se expresa como el porcentaje de un logro en un periodo específico. Entre más cercano al cien por ciento, mejor; sin embargo, rara vez este porcentaje es el objetivo.
  
  
• Un SLO debe proyectar un equilibrio entre velocidad y calidad.

Los datos generados a partir de los objetivos de nivel de servicio pueden ser tremendamente útiles al guiar a los equipos, crear un lenguaje común para entender cómo invertir los recursos de ingeniería y mejorar la confianza con el tiempo.

Fuentes: Blameless, IBM