Close

El camino hacia una mejor gestión de incidentes empieza aquí

SLA vs. SLO vs. SLI: What’s the difference?

Si hay algo que tienen en común todas las empresas tecnológicas, son los usuarios.

Ya seas el motor de búsqueda de Google, atiendas a mil millones de usuarios activos mensuales que interactúan con tu servicio de forma gratuita o seas Salesforce, con 3,75 millones de suscriptores de pago, el diseño de un producto tecnológico implica ponerte al servicio de las personas.

Además, en el mundo actual, siempre conectado, las expectativas de las personas son muy altas, tanto con los servicios gratuitos como con los de pago. Rapidez. Tiempo de actividad. Experiencia de usuario útil. La base de usuarios de hoy en día espera que todo alcance unos elevados estándares.

logotipo de looker

Looker confía en Opsgenie para ayudar a prestar su servicio a 200 000 usuarios a diario.

Por ello, es importante que las empresas entiendan y mantengan unos SLA, SLO y SLI, tres siglas que representan las promesas que hacemos a nuestros usuarios, los objetivos internos que nos ayudan a cumplir esas promesas y las mediciones trazables que nos indican cómo nos va.

El objetivo de estos tres elementos es conseguir que todos, tanto el proveedor como el cliente, estén en sintonía con respecto al rendimiento del sistema. ¿Con qué frecuencia estarán disponibles los sistemas? ¿Con qué rapidez responderá el equipo si el sistema se cae? ¿Qué tipo de promesas se hacen sobre la velocidad y la funcionalidad? Los usuarios quieren saberlo todo; por eso son necesarios los SLA, los SLO y los SLI.

Las diferencias entre los SLA, los SLO y los SLI

SLA: acuerdos de nivel de servicio

¿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.

For many experts, the answer to this challenge is, first and foremost, that tech should be involved in the creation of SLAs. The more IT and DevOps collaborate with legal and business development to develop SLAs that address real-world scenarios, the more SLAs will start to reflect key realities, such as clients delaying their own issue resolution.

¿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.

SLO: objetivos de nivel de servicio

¿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.

SLI: indicadores de nivel de servicio

¿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.

SLA: promesas a los clientes. SLO: objetivos internos. SLI: ¿cómo nos ha ido?

Prácticas recomendadas de los SLA, los SLO y los SLI

Elabora los SLA en torno a las expectativas de los clientes

Cada parte de tu acuerdo con el cliente debería elaborarse en torno a lo que le importa al usuario. En el back-end, un incidente puede significar que se tengan que abordar 10 componentes diferentes. Pero para el cliente, lo único importante es que el sistema funcione según lo previsto.

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

El hecho de que tu equipo probablemente pueda mantener un 99,99 % de tiempo de actividad no significa que ese 99,99 % tenga que ser tu SLO. Siempre es mejor prometer menos de lo que eres capaz de ofrecer. Esto cobra especial relevancia en el caso de los equipos ágiles que quieren lanzar productos pronto y con frecuencia, y necesitan un presupuesto de errores para mantener ese rápido ritmo.

¿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.

A continuación
Error budget