 |
Configurar métricas, hacer monitoreo y programar alarmas son el tipo de tareas importantes que se pierden en medio de la urgencia de “apagar incendios” en el día a día del equipo de TI. Son pocos los que pueden responder, si se les toma por sorpresa, a preguntas como: ¿Cuál es el consumo de CPU promedio de tus servidores? ¿La aplicación utiliza más memoria o más procesador? ¿Cuáles tipos de ataques se han detectado en el último mes? Y suponiendo que las métricas existan son pocos los profesionales de TI que han llegado a hacer algo con esta información para que cada vez sean menos las urgencias que hay que atender.
A continuación, resaltaré cuatro beneficios por los cuales es necesario (obligatorio) medir y monitorear los recursos del área de TI.
Optimización
En el mejor de los casos, las cosas están funcionando bien, el sistema se comporta como debe, los usuarios tienen una experiencia relativamente buena con la aplicación y la información parece estar segura. ¿Por qué debería medir y monitorear? Los cambios de la nube son acelerados, los servicios siempre están mejorando para ajustarse mejor a las necesidades de los usuarios y lo mismo debemos hacer nosotros con nuestros servicios. La mejora continua es clave para lograr una diferenciación y poder leer las tendencias del mercado, pero “lo que no se mide, no se puede mejorar”. Entonces, el primer paso para hacer mejoras es entender el estado actual de los recursos y para eso hay que tener tanto históricos como métricas en tiempo real. Ese sería el insumo para tomar decisiones que ayuden a mejorar los procesos y servicios.
Limitar costos
La mayor ventaja de la nube es realmente un arma de doble filo si no se sabe manejar, la elasticidad de la nube le permite ajustarse rápidamente a la demanda que se hace de sus servicios, pero cuando eso se une con una metodología de pago por uso y no se pone un límite a tal crecimiento, las probabilidades de desbordar el presupuesto son muy altas. Por eso es muy importante poner una cota a este crecimiento, y para esto es necesario conocer la aplicación, los servicios que utiliza y las variables que son más sensibles y los factores que generan cambios en esas variables.
Al conocer cuáles son las métricas clave de un servicio y entender su comportamiento, se pueden definir políticas de control para evitar el crecimiento desmedido.
Alarmas de falla
Una alarma no solo debe informar cuando la aplicación falla, sino que debe comprender unas alertas tempranas que ayuden a prever la falla e inclusive a automatizar procesos para evitarlas. Una vez más la necesidad de conocer la aplicación y la plataforma se hace notar. Por ejemplo, si se tiene una partición de 50GB para el almacenamiento de logs no se debería configurar la alarma para cuando llegue al tope, sino que se programa en un 70 – 80% y se automatiza un proceso de depuración para reducir el uso de almacenamiento y así asegurar la correcta escritura de futuros logs.
Autoescalamiento
Seguramente todos han escuchado de lo fácil que es aumentar la capacidad de un servidor. Apagar un servidor, aumentar su capacidad y encenderlo nuevamente es mucho más fácil que importar un nuevo servidor, para repartir la carga de un servidor físico que ya está saturado. Pero mejor que eso, la nube permite aprovechar las métricas y alarmas configuradas, para que sean una señal que le indica a la plataforma que debe ajustar las capacidades a la nueva demanda.
Como hemos notado, la medición y monitoreo nos permite desde algo tan sencillo como conocer los recursos con los que cuenta el área de TI, hasta automatizar tareas.
La gran ventaja que representa la nube es que los principales proveedores saben que la medición y monitoreo son necesarios, por eso proveen herramientas grandiosas que centralizan la información, permitiendo incluso capturar información de recursos en sitio.
Las métricas básicas que deben ser configuradas son: uso de RAM, uso de CPU, consumo de disco. Pero, si se quiere ir más allá, se puede llegar a medir los ciclos de lectura y escritura, disponibilidad de la aplicación, tiempo entre fallas, latencia, etc.
Deja un comentario