La importancia de las métricas de uso en gestión de servicios TI en la nube

En nuestro último proyecto de migración a la nube, uno de mis colaboradores insistió en hacer una comunicación abierta y asertiva con nuestra comunidad de usuarios. Hicimos 3 sesiones de presentación y, para mi sorpresa, tuvo una alta participación. Explicamos lo que veníamos planificando, los objetivos y lo que debieran esperar de la migración.

Se trataba de una migración de IAAS. Esto quiere decir que la aplicación no cambia, pero sí puede haber cambios en performance. Tuvimos que sincerar que el principal objetivo era alcanzar menores costos. Nuestra comunidad de usuarios estaba consciente que estábamos en un ciclo contractivo, seguramente comenzaron a hacerse la idea que la performance iba a ser mucho peor.

El dilema de este tipo de empatía de parte de los usuarios es que dejan de reclamar. Y en ambientes de soporte es fácil caer en el vicio de problema-no-reclamado-no-existe. Precisamente eso nos ocurrió. Para poder tener feed back, dependimos mucho de las métricas que ofrece la plataforma de nube particular que estábamos adoptando. Tuvimos que hacer un crash course para sacarles provecho.

Este ejercicio nos permitió detectar problemas en el diseño del provisionamiento inicial, ubicar dónde estaba el cuello de botella y ajustar los tamaños para ir mejorando la experiencia de los usuarios.

Los proveedores de servicio de nube ofrecen métricas del nivel de uso de los recursos. Aquí dejo algunas recomendaciones y apuntes al respecto.

Buscar relacionar con percepción de usuarios. En una de nuestras instalaciones, repetidos cambios del emplazamiento de la conexión de internet habían terminado con un enlace muy defectuoso. Obviamente, la experiencia de los usuarios en las aplicaciones era muy mala. A pesar de que conocíamos el origen del problema, hicimos mediciones para comparar con el resto de nuestras sedes. Resultó ser la latencia de red la variable fundamental en este caso. Con ello, para siempre pudimos relacionar una mala latencia con una mala experiencia de los usuarios.

Las métricas permiten optimizar costos. En el caso de máquinas virtuales, un proveedor de nube pública ofrece generalmente algunos cientos de tamaños disponibles off-the-shelf. Seguramente, muchos estarán sobredimensionados de acuerdo a las necesidades que uno tenga, mientras que otros estarán subdimensionados. Esto todavía deja unas docenas de tamaños que más o menos se adecúan, con una variedad de precio suficientemente amplia como para dudar. ¿Cuánto es mucho? ¿Cuánto es poco?

El consumo monetario también se puede considerar una métrica. Un indicador muy utilizado es el costo total diario.

Hay que imaginarse que el tope del gráfico es la superficie del agua. Si uno está en una situación de control de costos, buscará el máximo precio que no genere demasiados problemas. Es decir, en la curva de costo diario se alcanza un punto de flotación desde abajo, en que se puede respirar la mayor parte del tiempo. Quien tenga mayor libertad de gastar, buscará el precio mínimo que no le dé ningún problema. En la curva, se busca estar lo más cerca del agua sin mojarse. Desde esa perspectiva, las métricas se usan para saber qué tan lejos se está de la superficie.

Establecer objetivos cuantitativos. Un proveedor de una aplicación web que utilizo mucho se definió objetivos respecto a los milisegundos que tienen que demorar dos consultas esenciales que todo usuario realiza. Esto, en términos del máximo lapso que los usuarios considerarían razonable. Como a veces sucede, cuando comenzó a tomar en serio esta métrica, el desempeño real de la aplicación tenía un gap considerable respecto al objetivo. Luego de mucho trabajo en rediseño de bases de datos, logró llegar al objetivo. Desde ese momento en adelante, cualquier cambio que introducen en la aplicación tiene como límite el objetivo que se pusieron.

Las métricas ayudan a informar problemas. El iPhone 4 se lanzó al mercado en el 2010. A las pocas semanas, varios usuarios se quejaron de problemas de calidad de recepción de la red. Han pasado varios años y ya nadie recuerda el incidente, pero en ese tiempo, medios especializados hicieron críticas negativas en base al resultado de pruebas con el nuevo iPhone. El equipo de Apple consiguió rápidamente con AT&T los datos duros de porcentaje de llamadas interrumpidas, del iPhone 4 y los demás teléfonos del mercado, incluyendo las generaciones iPhone anteriores. Llegaron a la conclusión que (i) el problema era real y existía y (ii) el tamaño del problema era mucho menor de lo que los medios anunciaban. Resulta que la introducción de un marco de acero que en el diseño para la 4° generación había perjudicado la recepción de la señal. Como resultado del análisis de los datos, Apple ofreció compensaciones a los consumidores e incorporó esta variable en el diseño de futuras versiones del producto.

Es importante recalcar que contar con métricas permite no sólo saber si hay o no hay, problemas, también ayuda a entender el tamaño del problema.

He seguido este ejemplo siempre en la relación con mis proveedores de servicio. Cuando hago un reclamo de servicio, es inútil decir algo así como “el sistema anda lento”, “no funciona”. Siempre van a contestar con una lesera del tipo “reinició ud el router?”. Es necesario ser más asertivo y establecer el reclamo con algo del tipo: “tenemos 12% de paquetes perdidos, cuando lo normal es 1%”.