El objetivo de los tres conceptos es conseguir que todos, tanto de proveedor como cliente, tengan el mismo entendido sobre la medición del rendimiento del sistema, ¿Con qué frecuencia estarán disponibles sus sistemas?, ¿Con qué rapidez responderá su equipo si el sistema se apaga?, ¿Qué tipo de promesas se hicieron sobre la velocidad y la funcionalidad?
¿Qué es un SLA?
Un SLA (acuerdo de nivel de servicio) es un acuerdo entre el proveedor y el cliente sobre métricas medibles como el tiempo de actividad, la capacidad de respuesta y las responsabilidades.
Estos acuerdos suelen ser elaborados por los nuevos equipos comerciales y legales de una empresa y representan las promesas que se están haciendo a los clientes así como las consecuencias si no cumple con esas promesas. Normalmente, las consecuencias incluyen sanciones financieras, créditos de servicio o extensiones de licencia.
El desafío de los SLA
Los SLA son notoriamente difíciles de medir, informar y cumplir. Estos acuerdos, generalmente escritos por personas que no están en las trincheras tecnológicas, a menudo hacen promesas que son difíciles de medir para los equipos, no siempre se alinean con las prioridades empresariales actuales en constante evolución, y no tienen en cuenta los matices importantes.
Por ejemplo, un SLA puede prometer que el equipo soporte resolverá los problemas notificados con el Producto X en un plazo de 24 horas. Pero ese mismo SLA no detalla lo que sucede si el cliente tarda 24 horas en enviar respuestas o capturas de pantalla para ayudar al equipo a diagnosticar el problema. ¿Significa que la ventana de 24 horas del equipo ha sido devorada por ralentizaciones del cliente o el reloj comienza y se detiene en función de cuándo responden los clientes?
Los SLA necesitan responder a estas preguntas, pero a menudo no lo hacen, un hecho que ha creado una gran cantidad de animosidad hacia ellos de los administradores de TI.
Para muchos expertos, la respuesta a este desafío es, ante todo, que la tecnología debe participar en la creación de SLAs. Cuanto más colaboración exista entre el equipo de TI y DevOps con el área legal y de negocio para desarrollar acuerdos de nivel de servicio que aborden escenarios del mundo real, más SLA comenzarán a reflejar realidades clave, como los clientes que retrasan su propia resolución de problemas.
¿Quién necesita un SLA?
Un SLA es un acuerdo entre un proveedor y un cliente de pago. Ambas partes requieren conocer este acuerdo.
¿Qué es un SLO?
Un SLO (objetivo de nivel de servicio) es un acuerdo dentro de un SLA sobre una métrica específica como el tiempo de actividad o el tiempo de respuesta. Por lo tanto, si el SLA es el acuerdo formal entre usted y su cliente, los SLO son las promesas individuales que está haciendo a ese cliente. Los SLO son los que establecen las expectativas de los clientes y le dicen a los equipos de TI y DevOps qué objetivos deben alcanzar y medirse a sí mismos.
Los retos de los SLOs
Los SLA tienen menos odio que los SLA, pero pueden crear tantos problemas si son vagos, demasiado complicados o imposibles de medir. La clave de los SLO que no hacen que sus ingenieros quieran arrancarse el pelo es la simplicidad y la claridad. Solo las métricas más importantes deben calificar para el estado de SLO, los objetivos deben deletrearse en lenguaje sencillo y, al igual que con los SLA, siempre deben tener en cuenta problemas como retrasos del lado del cliente.
¿Quién necesita SLO?
Cuando los SLA sólo son relevantes en el caso de los clientes que pagan, los SLO pueden ser útiles tanto para cuentas pagadas como no pagadas, así como para clientes internos y externos.
Los sistemas internos, como los CRM, los repositorios de datos de cliente y la intranet, pueden ser tan importantes como los sistemas externos. Y tener SLOs para esos sistemas internos es una pieza importante no sólo para cumplir con los objetivos de negocio, sino también para que los equipos internos cumplan sus propios objetivos orientados al cliente.
¿Qué es un SLI?
Un SLI (indicador de nivel de servicio) mide el cumplimiento de un SLO (objetivo de nivel de servicio).
Por ejemplo, si su SLA especifica que sus sistemas estarán disponibles el 99,95 % del tiempo, su SLO es probablemente un 99,95% de tiempo de actividad y su SLI es la medida real de su tiempo de actividad. Tal vez sea el 99,96%. Tal vez 99,99%. Para cumplir con su SLA, el SLI tendrá que cumplir o exceder las promesas hechas en ese documento.
Los desafíos de los SLIs
Al igual que con los SLOs, el desafío de los SLIs es mantenerlos simples, elegir las métricas correctas para realizar un seguimiento y no complicar demasiado el trabajo de TI mediante el seguimiento de demasiadas métricas que en realidad no importan a los clientes.
Crear un plan detallado de recuperación ante desastres
¿Qué harás cuando ocurra un tiempo de inactividad? Si aún no conoces la respuesta a esa pregunta, la respuesta predeterminada será “perder un tiempo valioso para averiguar qué hacer”.
Cuanto mejor sea su plan de respuesta a incidentes, más rápido y eficaz su equipo ante sla gestión de los incidentes. Es por eso que el primer paso de cualquier nuevo programa de gestión de incidentes debe ser el proceso y la planificación.
¿Quién necesita SLIs?
Cualquier empresa que mida su rendimiento frente a SLOs necesita SLIs para realizar esas mediciones. Realmente no se puede tener SLOs sin SLIs.
Cada parte de su acuerdo con el cliente debe elaborarse en torno a lo que importa al cliente. En el back-end, un incidente puede significar abordar 10 componentes diferentes. Pero en opinión del cliente, lo único que importa es que el sistema funcione según lo esperado.
Sus SLA y SLOs deben reflejar esta realidad. No complique las cosas profundizando a un nivel granular y haciendo promesas individuales para cada uno de esos 10 componentes. Mantenga sus promesas confinadas a la funcionalidad de alto nivel y orientada al usuario. Esto mantendrá a los clientes más felices y menos confundidos y simplificará las vidas de los profesionales de TI responsables de cumplir sus promesas de SLA.
Utilice lenguaje sencillo en los SLA
Los clientes no siempre pedirán aclaraciones, por lo que si su lenguaje de SLA es complicado, probablemente se esté preparando para los malentendidos. Cuanto más simple sea su idioma, menos probable es el conflicto de clientes en su futuro.
Con los SLOs, menos es más
No todas las métricas son vitales para el éxito del cliente, lo que significa que no todas las métricas deben ser un SLO. Comprométase con el menor número posible de SLO y concéntrese en los que más importa a los clientes.
No todas las métricas rastreables deben ser un SLI
Del mismo modo, el seguimiento del rendimiento en 10 componentes para cada uno de los 10 SLOs puede volverse difícil de manejar muy rápidamente. En su lugar, elija estratégicamente qué métricas realmente importan a sus SLOs principales y ponga su energía en el seguimiento de las mismas de manera efectiva.
Incluya factores fuera del control del equipo de TI
¿Qué sucede cuando el cliente es el que ralentiza el tiempo de resolución? Si no tiene claro esto en su SLA, su equipo puede estar sujeto al estándar imposible de resolver los problemas del cliente sin la participación del cliente.
Construir en un presupuesto de errores
Dejar espacio para las fallas no solo protege a la empresa de las violaciones de SLA y las grandes consecuencias, sino que también deja espacio para la agilidad, para que el equipo realice cambios rápidamente y así pueda probar nuevas soluciones innovadoras que podrían fallar.
En realidad, Google recomienda utilizar el presupuesto de errores sobrantes para el tiempo de inactividad planificado, lo que puede ayudarle a identificar problemas imprevistos (por ejemplo, servicios que utilizan servidores de forma inapropiada) y mantener las expectativas adecuadas de sus clientes.
Fuente: https://landing.google.com/sre/books/
