{"id":121,"date":"2020-06-25T15:28:52","date_gmt":"2020-06-25T20:28:52","guid":{"rendered":"https:\/\/www.zies.com.mx\/blog\/?p=121"},"modified":"2021-05-04T17:18:36","modified_gmt":"2021-05-04T22:18:36","slug":"slas-slos-y-slis-cual-es-su-diferencia-y-para-que-me-sirven","status":"publish","type":"post","link":"https:\/\/www.zies.com.mx\/blog\/slas-slos-y-slis-cual-es-su-diferencia-y-para-que-me-sirven\/","title":{"rendered":"\u00bfSLAs, SLOs y SLIs? \u00bfCu\u00e1l es su diferencia y para qu\u00e9 me sirven?"},"content":{"rendered":"\n

El objetivo de los tres conceptos es conseguir que todos, tanto de proveedor como cliente, tengan el mismo entendido sobre la medici\u00f3n del rendimiento del sistema, \u00bfCon qu\u00e9 frecuencia estar\u00e1n disponibles sus sistemas?, \u00bfCon qu\u00e9 rapidez responder\u00e1 su equipo si el sistema se apaga?, \u00bfQu\u00e9 tipo de promesas se hicieron sobre la velocidad y la funcionalidad?<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

\u00bfQu\u00e9 es un SLA?<\/h2>\n\n\n\n

Un SLA (acuerdo de nivel de servicio) es un acuerdo entre el proveedor y el cliente sobre m\u00e9tricas medibles como el tiempo de actividad, la capacidad de respuesta y las responsabilidades.<\/strong><\/p>\n\n\n\n

Estos acuerdos suelen ser elaborados por los nuevos equipos comerciales y legales de una empresa y representan las promesas que se est\u00e1n haciendo a los clientes as\u00ed como las consecuencias si no cumple con esas promesas. Normalmente, las consecuencias incluyen sanciones financieras, cr\u00e9ditos de servicio o extensiones de licencia.<\/p>\n\n\n\n

El desaf\u00edo de los SLA<\/h2>\n\n\n\n

Los SLA son notoriamente dif\u00edciles de medir, informar y cumplir. Estos acuerdos, generalmente escritos por personas que no est\u00e1n en las trincheras tecnol\u00f3gicas, a menudo hacen promesas que son dif\u00edciles de medir para los equipos, no siempre se alinean con las prioridades empresariales actuales en constante evoluci\u00f3n, y no tienen en cuenta los matices importantes.<\/p>\n\n\n\n

Por ejemplo, un SLA puede prometer que el equipo soporte resolver\u00e1 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. \u00bfSignifica que la ventana de 24 horas del equipo ha sido devorada por ralentizaciones del cliente o el reloj comienza y se detiene en funci\u00f3n de cu\u00e1ndo responden los clientes?<\/p>\n\n\n\n

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\u00edo es, ante todo, que la tecnolog\u00eda debe participar en la creaci\u00f3n de SLAs. Cuanto m\u00e1s colaboraci\u00f3n exista entre el equipo de TI y DevOps con el \u00e1rea legal y de negocio para desarrollar acuerdos de nivel de servicio que aborden escenarios del mundo real, m\u00e1s SLA comenzar\u00e1n a reflejar realidades clave, como los clientes que retrasan su propia resoluci\u00f3n de problemas.<\/p>\n\n\n\n

\u00bfQui\u00e9n necesita un SLA?<\/strong>
Un SLA es un acuerdo entre un proveedor y un cliente de pago. Ambas partes requieren conocer este acuerdo.<\/p>\n\n\n\n

\u00bfQu\u00e9 es un SLO?<\/strong><\/h2>\n\n\n\n

Un SLO (objetivo de nivel de servicio) es un acuerdo dentro de un SLA sobre una m\u00e9trica espec\u00edfica como el tiempo de actividad o el tiempo de respuesta. <\/strong>Por lo tanto, si el SLA es el acuerdo formal entre usted y su cliente, los SLO son las promesas individuales que est\u00e1 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\u00e9 objetivos deben alcanzar y medirse a s\u00ed mismos.<\/p>\n\n\n\n

Los retos de los SLOs<\/strong>
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\u00e9tricas m\u00e1s 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.<\/p>\n\n\n\n

\u00bfQui\u00e9n necesita SLO?<\/strong>
Cuando los SLA s\u00f3lo son relevantes en el caso de los clientes que pagan, los SLO pueden ser \u00fatiles tanto para cuentas pagadas como no pagadas, as\u00ed como para clientes internos y externos.<\/p>\n\n\n\n

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\u00f3lo para cumplir con los objetivos de negocio, sino tambi\u00e9n para que los equipos internos cumplan sus propios objetivos orientados al cliente.<\/p>\n\n\n\n

\u00bfQu\u00e9 es un SLI?<\/strong><\/h2>\n\n\n\n

Un SLI (indicador de nivel de servicio) mide el cumplimiento de un SLO (objetivo de nivel de servicio). <\/strong><\/p>\n\n\n\n

Por ejemplo, si su SLA especifica que sus sistemas estar\u00e1n 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\u00e1 que cumplir o exceder las promesas hechas en ese documento.<\/p>\n\n\n\n

Los desaf\u00edos de los SLIs<\/strong>
Al igual que con los SLOs, el desaf\u00edo de los SLIs es mantenerlos simples, elegir las m\u00e9tricas correctas para realizar un seguimiento y no complicar demasiado el trabajo de TI mediante el seguimiento de demasiadas m\u00e9tricas que en realidad no importan a los clientes.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Crear un plan detallado de recuperaci\u00f3n ante desastres<\/strong><\/h2>\n\n\n\n

\u00bfQu\u00e9 har\u00e1s cuando ocurra un tiempo de inactividad? Si a\u00fan no conoces la respuesta a esa pregunta, la respuesta predeterminada ser\u00e1 “perder un tiempo valioso para averiguar qu\u00e9 hacer”.<\/p>\n\n\n\n

Cuanto mejor sea su plan de respuesta a incidentes, m\u00e1s r\u00e1pido y eficaz su equipo ante sla gesti\u00f3n de los incidentes. Es por eso que el primer paso de cualquier nuevo programa de gesti\u00f3n de incidentes debe ser el proceso y la planificaci\u00f3n.<\/p>\n\n\n\n

\u00bfQui\u00e9n necesita SLIs?<\/strong>
Cualquier empresa que mida su rendimiento frente a SLOs necesita SLIs para realizar esas mediciones. Realmente no se puede tener SLOs sin SLIs.<\/p>\n\n\n\n

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\u00f3n del cliente, lo \u00fanico que importa es que el sistema funcione seg\u00fan lo esperado.<\/p>\n\n\n\n

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\u00e1 a los clientes m\u00e1s felices y menos confundidos y simplificar\u00e1 las vidas de los profesionales de TI responsables de cumplir sus promesas de SLA.<\/p>\n\n\n\n

Utilice lenguaje sencillo en los SLA<\/strong>
Los clientes no siempre pedir\u00e1n aclaraciones, por lo que si su lenguaje de SLA es complicado, probablemente se est\u00e9 preparando para los malentendidos. Cuanto m\u00e1s simple sea su idioma, menos probable es el conflicto de clientes en su futuro.<\/p>\n\n\n\n

Con los SLOs, menos es m\u00e1s<\/strong>
No todas las m\u00e9tricas son vitales para el \u00e9xito del cliente, lo que significa que no todas las m\u00e9tricas deben ser un SLO. Comprom\u00e9tase con el menor n\u00famero posible de SLO y conc\u00e9ntrese en los que m\u00e1s importa a los clientes.<\/p>\n\n\n\n

No todas las m\u00e9tricas rastreables deben ser un SLI<\/strong>
Del mismo modo, el seguimiento del rendimiento en 10 componentes para cada uno de los 10 SLOs puede volverse dif\u00edcil de manejar muy r\u00e1pidamente. En su lugar, elija estrat\u00e9gicamente qu\u00e9 m\u00e9tricas realmente importan a sus SLOs principales y ponga su energ\u00eda en el seguimiento de las mismas de manera efectiva.<\/p>\n\n\n\n

Incluya factores fuera del control del equipo de TI<\/strong>
\u00bfQu\u00e9 sucede cuando el cliente es el que ralentiza el tiempo de resoluci\u00f3n? Si no tiene claro esto en su SLA, su equipo puede estar sujeto al est\u00e1ndar imposible de resolver los problemas del cliente sin la participaci\u00f3n del cliente.<\/p>\n\n\n\n

Construir en un presupuesto de errores<\/strong>
Dejar espacio para las fallas no solo protege a la empresa de las violaciones de SLA y las grandes consecuencias, sino que tambi\u00e9n deja espacio para la agilidad, para que el equipo realice cambios r\u00e1pidamente y as\u00ed pueda probar nuevas soluciones innovadoras que podr\u00edan fallar.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Fuente: https:\/\/landing.google.com\/sre\/books\/<\/p>\n","protected":false},"excerpt":{"rendered":"

El objetivo de los tres conceptos es conseguir que todos, tanto de proveedor como cliente, tengan el mismo entendido sobre la medici\u00f3n del rendimiento del sistema, \u00bfCon qu\u00e9 frecuencia estar\u00e1n disponibles sus sistemas?, \u00bfCon qu\u00e9 rapidez responder\u00e1 su equipo si el sistema se apaga?, \u00bfQu\u00e9 tipo de promesas se hicieron sobre la velocidad y la […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2],"tags":[],"class_list":["post-121","post","type-post","status-publish","format-standard","hentry","category-blog"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.zies.com.mx\/blog\/wp-json\/wp\/v2\/posts\/121","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.zies.com.mx\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.zies.com.mx\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.zies.com.mx\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.zies.com.mx\/blog\/wp-json\/wp\/v2\/comments?post=121"}],"version-history":[{"count":8,"href":"https:\/\/www.zies.com.mx\/blog\/wp-json\/wp\/v2\/posts\/121\/revisions"}],"predecessor-version":[{"id":177,"href":"https:\/\/www.zies.com.mx\/blog\/wp-json\/wp\/v2\/posts\/121\/revisions\/177"}],"wp:attachment":[{"href":"https:\/\/www.zies.com.mx\/blog\/wp-json\/wp\/v2\/media?parent=121"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.zies.com.mx\/blog\/wp-json\/wp\/v2\/categories?post=121"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.zies.com.mx\/blog\/wp-json\/wp\/v2\/tags?post=121"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}