Diferencia entre los SLA, los SLO y los SLI

¿Qué es un SLA?

Un SLA (acuerdo de nivel de servicio) es un acuerdo entre el proveedor y el cliente sobre los parámetros cuantificables, como el tiempo de actividad, la capacidad de respuesta y las responsabilidades.

Estos acuerdos suelen redactarlos los equipos jurídicos y de nuevos negocios de la empresa, y representan las promesas que se hacen a los clientes y las consecuencias de no cumplirlas. Por lo general, entre las consecuencias se incluyen sanciones económicas, créditos de servicio o ampliaciones de las licencias.

El reto de los SLA

Los SLA son notablemente difíciles de cuantificar y cumplir, y resulta muy complicado informar sobre ellos. En estos acuerdos, que generalmente redactan personas que no conocen a fondo los entresijos de la tecnología, se suelen hacer promesas que a los equipos les es difícil cuantificar, no se tienen en cuenta los matices y no siempre se está en línea con las prioridades actuales y en constante evolución de la empresa.

Por ejemplo, en un SLA se puede prometer que los equipos resolverán las incidencias notificadas con el producto X en 24 horas. Sin embargo, en ese mismo SLA no se especifica qué ocurre si el cliente tarda 24 horas en responder o enviar capturas de pantalla para ayudar al equipo a identificar el problema. ¿Significa eso que el plazo de 24 horas del equipo se ha consumido debido a la lentitud del cliente o que el reloj se inicia y se detiene en función del momento en que responde el cliente? En los SLA, se debe dar respuesta a estas preguntas, pero a menudo no es así, algo que ha provocado que los responsables de TI sientan una gran aversión hacia ellos.

Para muchos expertos, la respuesta a este reto es, ante todo, que la tecnología debe tener cabida en la creación de los SLA. Cuanto más colaboren los equipos de TI y DevOps con los equipos jurídicos y de desarrollo empresarial para elaborar SLA que aborden situaciones reales, más empezarán a reflejar los SLA las realidades clave, como los retrasos provocados por los clientes en la resolución de sus propias incidencias.

¿Quién necesita un SLA?

Un SLA es un acuerdo entre un proveedor y un cliente de pago. Es poco probable que las empresas que prestan un servicio gratis a los usuarios quieran o necesiten un SLA para esos usuarios gratuitos.

¿Qué es un SLO?

Un SLO (objetivo de nivel de servicio) es un acuerdo enmarcado en un SLA sobre una métrica específica, como el tiempo de actividad o el tiempo de respuesta. Así, si el SLA es el acuerdo formal entre tú y el cliente, los SLO son cada una de las promesas que le haces a ese cliente. Los SLO son los que establecen las expectativas de los clientes e indican a los equipos de TI y DevOps qué objetivos deben alcanzar y cuantificar.

Los retos de los SLO

Los SLO tienen menos detractores que los SLA, pero pueden dar lugar a los mismos problemas si son poco precisos, demasiado complicados o imposibles de cuantificar. La clave para que los SLO no hagan que los ingenieros se tiren de los pelos es la simplicidad y la claridad. Solo las métricas más importantes deberían considerarse SLO, los objetivos deberían exponerse con un lenguaje sencillo y, al igual que con los SLA, siempre deberían dar cuenta de incidencias tales como los retrasos provocados por los clientes.

¿Quién necesita los SLO?

Mientras que los SLA solo son relevantes en el caso de los clientes de pago, los SLO pueden ser útiles para las cuentas tanto de pago como gratuitas, así como para los clientes internos y externos.

Los sistemas internos, como los CRM, los repositorios de datos de los clientes y la intranet, pueden ser igual de importantes que los sistemas orientados a los usuarios externos. Además, disponer de SLO para esos sistemas internos es fundamental no solo para cumplir los objetivos empresariales, sino también para que los equipos internos puedan cumplir sus propios objetivos de cara al cliente.

¿Qué es un SLI?

Un SLI (indicador de nivel de servicio) evalúa el cumplimiento de un SLO (objetivo de nivel de servicio). Por ejemplo, si en tu SLA se especifica que tus sistemas estarán disponibles el 99,95 % del tiempo, el SLO es probablemente el 99,95 % de tiempo de actividad y el SLI es la medida real del tiempo de actividad. Tal vez sea el 99,96 % o quizás el 99,99 %. Para mantener el cumplimiento de tu SLA, el SLI tendrá que cumplir o superar las promesas hechas en ese documento.

Los retos de los SLI

Al igual que con los SLO, el reto de los SLI radica en conseguir que sean simples, elegir las métricas adecuadas para el seguimiento y no complicar demasiado el trabajo del departamento de TI al tener que llevar un registro de demasiadas métricas que, en realidad, no importan a los clientes.

Crea un plan detallado de recuperación ante desastres

¿Qué harás en caso de que se produzca tiempo de inactividad? Si aún no tienes respuesta a esa pregunta, lo habitual será que pierdas un valioso tiempo para determinar qué hacer.

Cuanto mejor sea tu plan de respuesta ante incidentes, más rápida y eficaz será la gestión de los incidentes por parte de los equipos. Por eso, el primer paso de cualquier nuevo programa de gestión de incidentes debería ser el proceso y la planificación.

¿Quién necesita los SLI?

Cualquier empresa que mida su rendimiento con respecto a los SLO necesita los SLI para poder realizar esas evaluaciones. Realmente, no se pueden tener SLO sin SLI.

Elabora los SLA en torno a las expectativas de los clientes

Every part of your customer agreement should be crafted around what matters to the customer. On the back end, an incident may mean addressing 10 different components. But in the client’s view, all that matters is that the system functions as expected.

Tus SLA y SLO deben reflejar esta realidad. No compliques en exceso las cosas entrando en demasiados detalles y haciendo promesas individuales en relación con cada uno de esos 10 componentes. Limita tus promesas a la funcionalidad general orientada al usuario. De este modo, los clientes se sentirán más satisfechos y menos confusos, y harás la vida más fácil a los profesionales de TI responsables de cumplir tus promesas del SLA.

Usa un lenguaje sencillo en los SLA

Los clientes no siempre piden aclaraciones, así que, si el lenguaje de tu SLA es complicado, posiblemente des pie a que se produzcan algunos desagradables malentendidos más adelante. Cuanto más sencillas sean las palabras que utilices, menos probabilidades habrá de que se den conflictos con los clientes en el futuro.

Con los SLO, menos es más

No todas las métricas son esenciales para el éxito del cliente, es decir, no todas ellas deben ser un SLO. Márcate el menor número posible de SLO y céntrate en los que más importen a los clientes.

No todas las métricas trazables deberían ser un SLI

De manera similar, realizar el seguimiento del rendimiento de 10 componentes con respecto a cada uno de los 10 SLO puede resultar difícil muy rápidamente. En su lugar, elige de forma estratégica qué métricas son realmente relevantes para tus SLO principales y dedica tu energía a llevar un registro eficaz de ellas.

Incluye factores que queden fuera del control del equipo de TI

¿Qué ocurre cuando es el cliente el que ralentiza el tiempo de resolución? Si no dejas esto claro en tu SLA, el equipo puede verse obligado a resolver las incidencias del cliente sin que este se involucre.

Incorpora un presupuesto de errores

Contemplar la posibilidad de que se produzcan fallos no solo protege a la empresa frente a las infracciones del SLA y las graves consecuencias, sino que también posibilita una mayor agilidad para que el equipo pueda hacer cambios rápidamente y tenga espacio para probar nuevas soluciones innovadoras que podrían dar lugar a errores.

De hecho, Google recomienda utilizar el presupuesto de errores que sobre para los tiempos de inactividad planificados, lo que puede ayudarte a identificar las incidencias imprevistas (por ejemplo, servicios que utilizan servidores de forma inapropiada) y a mantener unas expectativas adecuadas de los clientes.

No te vengas demasiado arriba

Just because your team can probably maintain 99.99% uptime doesn’t mean that 99.99% should be your SLO number. It’s always better to under-promise and overdeliver. This is especially true for agile teams who want to launch early and often and need an error budget to keep up that quick pace.

¿Cómo afecta esto a los equipos de SRE?

Para aquellos que sigan el modelo de Google y utilicen equipos de ingeniería de fiabilidad del sitio (SRE) con el objetivo de salvar la distancia entre el desarrollo y las operaciones, los SLA, los SLO y los SLI son fundamentales para que todo vaya a la perfección. Los SLA ayudan a los equipos a establecer límites y presupuestos de errores. Los SLO ayudan a definir las prioridades del trabajo. Y los SLI indican a los equipos de SRE cuándo deben congelar todos los lanzamientos para salvar un presupuesto de errores en peligro y cuándo pueden aflojar las riendas.

Mantente al tanto de los SLA para resolver las solicitudes en función de las prioridades y usa reglas de escalación automatizadas para notificar a los miembros adecuados del equipo y evitar incumplimientos de SLA con Jira Service Management.