Olvídese del tiempo de actividad. Un MTTR bajo es el nuevo '5 9' para TI
Las interrupciones del servicio son costosas. No es tan relevante si en última instancia son el resultado de un ataque o de un fallo de software o hardware. Los costos por minuto de inactividad están aumentando, gracias a la creciente dependencia de las API y las aplicaciones web de la economía digital moderna.
Para algunos, esos costos son asombrosos. Se estima que los 40 minutos de inactividad de Amazon en 2013 le costaron 2,64 millones de dólares. Eso supone 1.100 dólares por segundo para aquellos que no quieran hacer cálculos. Si piensa que eso es horrible, piense en Google, cuyo tiempo de inactividad de 5 minutos en el mismo año les costó $109,000 por minuto. (o $1.816,67 por segundo) por un total enorme de $545.000. Durante 5 minutos. Técnicamente, si eso fue todo lo que sufrieron, esos son los famosos “5 9” que la TI tiene la tarea de lograr.
¿Con qué frecuencia ocurren cortes de suministro eléctrico? Con demasiada frecuencia, aparentemente. Si nunca has visto esto, echa un vistazo al mapa de interrupciones en vivo de pingdom . Está construido a partir de datos recopilados de sus más de 700.000 usuarios en todo el mundo. Este mapa morbosamente fascinante muestra los cortes eléctricos ocurridos durante la última hora en todo el mundo. Los destellos brillantes que representan las interrupciones son un buen detalle que realmente resalta el revuelo que causan entre los usuarios.
Es decir, una no deseada.
La economía digital agrava este problema. A principios de este año, una interrupción del sistema S3 en Amazon provocó el colapso de una gran cantidad de aplicaciones y sitios web de sus clientes. Pero para no achacar este problema a los proveedores de nube pública, una visita rápida al sitio builtwith.com borrará rápidamente esa creencia. Los porcentajes de sitios que aprovechan las CDN y las API son quizás alarmantemente altos si se considera la dependencia que esto implica del tiempo de actividad de terceros . Es difícil encontrar un sitio que no dependa de al menos una API o servicio externo, lo que aumenta la posibilidad de tiempo de inactividad porque si ese servicio externo está inactivo, usted también lo está.
Básicamente, TI se conformó con “5 9” porque es imposible lograr una disponibilidad del 100%. La clave hoy, cuando los costos por segundo se disparan gracias a la transición de la economía hacia el ámbito digital, es minimizar el tiempo de inactividad. En otras palabras, establecer objetivos que requieran un tiempo medio de resolución (MTTR) bajo es tan importante (quizás más) que intentar eliminar el tiempo de inactividad.
Una de las medidas clave de las “organizaciones de alto rendimiento” en el Informe sobre el estado de DevOps 2016 de Puppet Labs es el MTTR, definido como el tiempo que lleva restaurar el servicio cuando ocurre un incidente (por ejemplo, una interrupción no planificada o un deterioro del servicio). Las organizaciones con mayor rendimiento (según la evaluación del informe) tardan menos de una hora, mientras que las organizaciones con rendimiento medio y bajo tardan “menos de un día”. “En otras palabras”, señala el informe, “los empleados de alto rendimiento tuvieron un MTTR 24 veces más rápido que los de bajo rendimiento”.
Notarás que la pregunta no era "si" hay un incidente de servicio. Era “cuando” hay un incidente de servicio. Se supone que ocurrirá un incidente y, por lo tanto, la clave es minimizar el tiempo hasta su resolución. Una encuesta de 2016 realizada por IHS informó que “en promedio, los encuestados experimentan 5 eventos de inactividad por mes, y 27 horas de inactividad por mes”, lo que le cuesta a una organización mediana promedio $1 y a sus contrapartes más grandes hasta $60 millones.
Si asumimos que la Ley de Murphy todavía rige a Moore y Conway, la respuesta es tratar de minimizar el MTTR para reducir el tiempo (y los costos) asociados con el inevitable tiempo de inactividad.
Esto significa que la visibilidad es fundamental, lo que implica seguimiento. Mucho, mucho seguimiento. Pero no solo el sitio web, o la aplicación web, o la API: necesitamos monitorear la pila completa . Desde la red hasta los servicios de la aplicación y la propia aplicação . Eso es algo que no todo el mundo hace, y cuando lo hacen, parecen hacerlo de forma inconsistente.
Consideremos la encuesta xMatters|Atlassian DevOps Maturity de 2017 en la que el 50 % de los encuestados declaró que “espera a que el departamento de operaciones declare un incidente importante” antes de responder. Un alarmante 1/3 de las empresas “se enteran de las interrupciones del servicio a través de sus clientes”.
En una economía digital, cada segundo importa. No sólo porque cuesta dinero, sino también porque afecta negativamente los ingresos futuros . La disminución del valor de la marca y de la confianza de los clientes da como resultado menos compras, menos usuarios y, en última instancia, un estancamiento del crecimiento. Esa no es la dirección que deberían tomar las organizaciones.
El monitoreo es el primer paso para detectar problemas que causan interrupciones. Pero el monitoreo por sí solo no ayuda al MTTR. La comunicación lo hace. Alertar a las partes interesadas relevantes lo antes posible y brindarles la información que necesitan para solucionar el problema ayudará a alcanzar una resolución más rápida. Esto significa que compartir , uno de los cuatro pilares clave de DevOps, es clave para mejorar el MTTR. Incluso si aún no estás adoptando otros aspectos de DevOps a nivel corporativo, compartir es una iniciativa que deberías considerar elevar a un nivel superior. Ya sea a través de ChatOps o correo electrónico, una aplicación móvil o una página wiki actualizada dinámicamente, es imperativo que la información obtenida a través del monitoreo se comparta ampliamente en toda la organización.
Un problema en un conmutador o servidor puede parecer inofensivo, pero si no se soluciona, podría terminar dejando fuera de servicio la mitad de los servicios de los que depende una aplicación crítica. En el estudio Estado de la red de 2017 realizado por Viavi , el 65 % de los administradores de redes y sistemas citan “determinar si el problema es causado por la red, el sistema o las aplicaciones” como su principal desafío al solucionar problemas de aplicação . Una mayor visibilidad y una monitorización completa son una forma de abordar este desafío, garantizando que los responsables de encontrar la causa raíz tengan a mano la mayor cantidad de información posible sobre el estado y la salud de todos los componentes en la ruta de datos .
La visibilidad es clave para el futuro de la TI. Sin ella, no podemos lograr el nivel de automatización necesario para corregir las interrupciones antes de que ocurran. Sin visibilidad no podemos reducir el MTTR de manera significativa. Sin ella, realmente no podemos mantener el negocio creciendo a un ritmo sostenible.
La visibilidad, al igual que la seguridad, debe ser un elemento de primera clase en la pila de estrategias que impulsa el avance de la TI. Porque las interrupciones ocurren, y es la visibilidad la que permite a las organizaciones recuperarse de manera rápida y eficiente, con el menor daño posible a su marca y sus resultados finales.