Hasta el infinito y más allá (de las métricas)

Vale, partimos de la idea de que la medición es una forma de dominio sobre las cosas. 

De hecho, podríamos afirmar que no se puede medir lo que no se controla. 

Por ello es capital elegir deliberadamente lo que se mide (sobre todo con nuestras métricas)

No seas inocente. No todas las métricas son métricas útiles

Hoy hablaremos de las métricas en el contexto del entorno y los objetivos de una organización. Por ello, las mediciones siempre estarán relacionadas con: 

• Datos históricos. 
• Tendencias. 
• Patrones de uso. 
• Líneas típicas. 
• Bases comunes.
• Valores actuales.

Este contexto siempre ha proporcionado importantes y evidentes puntos de referencia a la hora de comparar y analizar el rendimiento de un entorno de TI.

Así determinaremos “lo que es bueno”, “lo que es malo” y lo que nos da redomadamente igual. 

Hay métricas que no dicen toda la verdad

Sabemos que la disponibilidad normalmente se calcula dividiendo la disponibilidad real medida entre la disponibilidad posible total de cierto intervalo.

0,9999 de disponibilidad, por ejemplo, se considera un resultado satisfactorio según la mayoría de los estándares. Peeeero, dependiendo del momento en que se produzca, ese poco tiempo de inactividad puede ser insignificante o importante. 

No es lo mismo esa inactividad entre las 2 y las 3 de la mañana para un minorista online que en un momento de gran actividad, cerca de fin de mes o poco antes del cierre. 

Estamos hablando de que el coste de oportunidad de cada minuto puede oscilar entre decenas de miles de euros y cientos de miles de euros si se produce justo antes de las vacaciones o durante el periodo de mayor actividad comercial.

Con esto queremos ilustrar el relativismo en el que nos sume la vida y lo crucial que es el contexto para entender las medidas. 

A primera vista, el 99,99% está guay. Sin embargo, podría ser algo triste si el 0,1% de los picos de demanda de las aplicaciones y el 0,1% de los tiempos de inactividad coinciden. 

En este caso, el 99,99% de tiempo de actividad crea una imagen excesivamente optimista y puede impedir la investigación de los factores subyacentes que pueden estar causando posibles problemas de rendimiento o una distribución inadecuada de la carga de trabajo.

Además, se plantea una pregunta seria: 

(Tono serio).

La caída en momentos de picos absolutos de uso ¿es una señal de que la aplicación no cuenta con los suficientes recursos, está mal posicionada o es una desafortunada coincidencia?

Los fallos en los picos de carga tienen repercusiones financieras debido a las oportunidades perdidas, pero también requieren un examen minucioso de los KPI de fiabilidad, disponibilidad, rendimiento de la red y capacidad, entre otros, para determinar si es necesario realizar algún ajuste o puesta a punto.

¿Hay costes ocultos?

Algo está claro en esta parte:

El uso de la automatización debe compararse con los tiempos de resolución de los tickets de servicio y de problemas estándar de las organizaciones. 

*En teoría, al menos en teoría, los tickets abiertos deberían resolverse más rápido cuanto más se utilice la automatización.

Por ello, es importante que las organizaciones de TI hagan un seguimiento del tiempo medio de resolución (MTTR) de los tickets de servicio, así como de la cantidad y la eficacia de la automatización que se utiliza en sus flujos de trabajo para:

• La configuración. 
• El aprovisionamiento. 
• El mantenimiento. 
• La resolución de problemas.

Además, será más que nunca necesaria una metamétrica para determinar y controlar el valor de la automatización dentro de la organización. 

Pero queremos que quede claro que, en términos de automatización, más no tiene por qué significar mejor. 

Los portales de autoservicio, las incidencias y las solicitudes de servicio presentan una relación inversa: 

Cuanto más descubran los usuarios finales que el portal de autoservicio satisface sus necesidades de conjuntos de datos, análisis, acceso a servicios y recursos, etc., menos frecuentes serán las solicitudes de servicio de TI.

Esto va más allá de la simple reducción del MTTR. 

También implica el empleo de portales de autoservicio para permitir a los clientes completar las solicitudes de servicio más comunes sin necesidad de crear y cerrar un ticket de servicio.

Si se instala y se mantiene, esto debería conducir a un maravilloso mundo donde haya menos emisión de tickets de servicio, usuarios más felices y productivos, y a la posibilidad, incluso, de que los usuarios sugieran cambios, adiciones y ampliaciones de los portales de autoservicio.

Evaluemos la historia de las métricas

Existen demasiadas herramientas y utilidades de gestión para entornos complejos e híbridos basados en la nube, ¿no os parece?

Las empresas suelen salir ganando si centran su búsqueda en una única plataforma de gestión integral, unificada y completa.

A menudo reducen el número de herramientas de gestión que utilizan, a la vez que agilizan la gestión de sus operaciones de TI al realizar dicha transformación. 

¿El resultado? 

Un tipo de “ciclo virtuoso” que aprovecha la mejora de la automatización y la visibilidad para ampliar las oportunidades de optimización continua y elevar el nivel de los indicadores utilizados para evaluar la salud general de la infraestructura de TI.

Conclusión

Las áreas que más se beneficiarán de la automatización y el acceso de autoservicio se revelarán mediante el establecimiento de métricas de costes útiles que van más allá del coste de las adquisiciones de TI, la amortización y la depreciación, así como el coste del consumo de TI, incluidas las soluciones de software como servicio (SaaS), los recursos en la nube, el uso y las asignaciones de máquinas virtuales permanentes.

Como resultado, identificará los objetivos para una optimización constante y continua y las mejoras que mantendrán los costes en la dirección correcta.

¿Quieres saber más del mundo TI?