Si hay algo que todas las empresas de tecnología tienen en común, es esto: los usuarios.
Ya sea que sea el motor de búsqueda de Google, que atiende a mil millones de usuarios activos mensuales que interactúan con su servicio de forma gratuita, o Salesforce, con 3,75 millones de suscriptores de pago, crear un producto tecnológico significa servir a las personas.
Y en el mundo siempre activo de hoy, las expectativas de las personas, tanto de servicios gratuitos como de pago, son altas. Velocidad. Tiempo de actividad. UX útil. La base de usuarios de hoy espera que todo cumpla con un alto estándar.
Looker confía en Opsgenie para ayudar a brindar su servicio a 200,000 usuarios todos los días.
Por eso es importante que las empresas comprendan y mantengan los SLA, SLO y SLI: tres iniciales que representan las promesas que hacemos a nuestros usuarios, los objetivos internos que nos ayudan a cumplir esas promesas y las mediciones rastreables que nos dicen cómo ‘ estás haciendo.
El objetivo de las tres cosas es lograr que todos, tanto proveedores como clientes, estén en la misma página sobre el rendimiento del sistema. ¿Con qué frecuencia estarán disponibles sus sistemas? ¿Con qué rapidez responderá su equipo si el sistema falla? ¿Qué tipo de promesas está haciendo sobre velocidad y funcionalidad? Los usuarios quieren saber, por lo que usted necesita SLA, SLO y 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 métricas mensurables como el tiempo de actividad, la capacidad de respuesta y las responsabilidades.
Por lo general, estos acuerdos los redactan los nuevos equipos comerciales y legales de una empresa y representan las promesas que usted hace a los clientes y las consecuencias si no cumple con esas promesas. Por lo general, las consecuencias incluyen multas 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 comerciales actuales y en constante evolución y no tienen en cuenta los matices.
Por ejemplo, un SLA puede prometer que los equipos resolverán los problemas informados con el Producto X en un plazo de 24 horas. Pero ese mismo SLA no explica qué sucede si el cliente tarda 24 horas en enviar respuestas o capturas de pantalla para ayudar a su equipo a diagnosticar el problema. ¿Significa que la ventana de 24 horas del equipo ha sido consumida por la desaceleración de los clientes o el reloj se pone en marcha y se detiene en función de la respuesta de los clientes? Los SLA necesitan responder estas preguntas, pero a menudo no lo hacen, un hecho que ha creado mucha animosidad hacia ellos por parte 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 SLA. Cuanto más TI y DevOps colaboren con el desarrollo legal y comercial para desarrollar SLA que aborden escenarios del mundo real, más SLA comenzarán a reflejar realidades clave, como que los clientes retrasen la resolución de sus propios problemas.
¿Quién necesita un SLA?
Un SLA es un acuerdo entre un proveedor y un cliente que paga. Es poco probable que las empresas que brindan un servicio a los usuarios de forma gratuita deseen 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 dentro de un SLA sobre una métrica específica como tiempo de actividad o tiempo de respuesta. Entonces, si el SLA es el acuerdo formal entre usted y su cliente, los SLO son las promesas individuales que le hace a ese cliente. Los SLO son los que establecen las expectativas de los clientes y les dicen a los equipos de TI y DevOps qué objetivos deben alcanzar y medir .
Los desafíos de los SLO
Los SLO reciben 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 los pelos es la simplicidad y la claridad. Solo las métricas más importantes deben calificar para el estado de SLO, los objetivos deben especificarse en un 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 solo son relevantes en el caso de clientes que pagan, los SLO pueden ser útiles para cuentas pagadas y no pagadas, así como para clientes internos y externos.
Los sistemas internos, como CRM, repositorios de datos de clientes e intranet, pueden ser tan importantes como los sistemas externos. Y tener SLO para esos sistemas internos es una pieza importante no solo para cumplir los objetivos comerciales, sino también para permitir que los equipos internos cumplan sus propios objetivos de cara al cliente.
SLI: indicador de nivel de servicio
¿Qué es un SLI?
Un SLI (indicador de nivel de servicio) mide el cumplimiento de un SLO (objetivo de nivel de servicio). Entonces, por ejemplo, si su SLA especifica que sus sistemas estarán disponibles el 99,95% del tiempo, es probable que su SLO tenga un tiempo de actividad del 99,95% y su SLI sea la medida real de su tiempo de actividad. Quizás sea el 99,96%. Quizás el 99,99%. Para cumplir con su SLA, el SLI deberá cumplir o superar las promesas hechas en ese documento.
Los desafíos de los SLI
Al igual que con los SLO, el desafío de los SLI es mantenerlos simples, elegir las métricas correctas para rastrear y no complicar demasiado el trabajo de TI al rastrear demasiadas métricas que en realidad no importan a los clientes.
Cree un plan detallado de recuperación ante desastres
¿Qué hará cuando llegue el tiempo de inactividad? Si aún no sabe la respuesta a esa pregunta, la respuesta predeterminada será “perder un tiempo precioso averiguando qué hacer”.
Cuanto mejor sea su plan de respuesta a incidentes , más rápida y eficazmente sus equipos manejarán 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 SLI?
Cualquier empresa que mida su desempeño frente a los SLO necesita SLI para poder realizar esas mediciones. Realmente no puede tener SLO sin SLI.
Mejores prácticas de SLA, SLO y SLI
Elaborar SLA en torno a las expectativas del cliente
Cada parte de su acuerdo con el cliente debe elaborarse en torno a lo que le 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 como se espera.
Sus SLA y SLO deben reflejar esta realidad. No complique demasiado las cosas profundizando hasta un nivel granular y haciendo promesas individuales para cada uno de esos 10 componentes. Mantenga sus promesas limitadas a la funcionalidad de alto nivel orientada al usuario. Esto mantendrá a los clientes más felices y menos confundidos y simplificará la vida de los profesionales de TI responsables de cumplir con sus promesas de SLA.
Utilice un lenguaje sencillo en los SLA
Los clientes no siempre pedirán una aclaración, por lo que si su lenguaje SLA es complicado, probablemente se esté preparando para algunos malentendidos dolorosos en el futuro. Cuanto más simple sea su lenguaje, menos probable será el conflicto con el cliente en su futuro.
Con los SLO, 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 de SLO posible y céntrese en los que más le importan a los clientes.
No todas las métricas rastreables deberían ser un SLI
Del mismo modo, el seguimiento del rendimiento en 10 componentes para cada uno de los 10 SLO puede volverse difícil de manejar muy rápidamente. En su lugar, elija estratégicamente qué métricas realmente importan para sus objetivos de nivel de servicio principales y dedique su energía a rastrearlas 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.
Construya un presupuesto de error
Dejar espacio para fallas no solo protege a la empresa de violaciones de SLA y consecuencias importantes, sino que también deja espacio para la agilidad, para que el equipo haga cambios rápidamente y tenga espacio para probar nuevas soluciones innovadoras que podrían fallar.
De hecho, Google recomienda usar el presupuesto de error sobrante para el tiempo de inactividad planificado, lo que puede ayudarlo a identificar problemas imprevistos (por ejemplo, servicios que usan servidores de manera inapropiada) y mantener las expectativas adecuadas de sus clientes.
No dispares a la luna
El hecho de que su equipo probablemente pueda mantener un tiempo de actividad del 99,99% no significa que el 99,99% deba ser su número de SLO. Siempre es mejor prometer menos y entregar más. Esto es especialmente cierto para los equipos ágiles que desean realizar un lanzamiento temprano y con frecuencia y necesitan un presupuesto de errores para mantener ese ritmo rápido.
¿Cómo afecta esto a las SRE?
Para aquellos de ustedes que siguen el modelo de Google y usan los equipos de Ingeniería de confiabilidad del sitio (SRE) para cerrar la brecha entre el desarrollo y las operaciones, los SLA, SLO y SLI son fundamentales para el éxito. Los SLA ayudan a los equipos a establecer límites y presupuestos de errores. Los SLO ayudan a priorizar el trabajo. Y los SLI les dicen a los SRE cuándo deben congelar todos los lanzamientos para ahorrar un presupuesto de error en peligro, y cuándo pueden soltar las riendas.