Cuando el miércoles pasado, 28 de marzo,
releía lo que había escrito en mi blog, me arrepentía de algunas de las afirmaciones: ¿cómo se puede decir que un eslabón es el más importante en una cadena? Es más bien lo contrario: todos sabemos que una cadena es tan débil como el más débil de sus eslabones … Aun así, decidí mantener los comentarios porque así me daba pie a este nuevo comentario.
Los que tenemos ya cierta edad y hemos conocido las cadenas de música HiFi (no los altamente integrados equipos actuales, que en su mayoría son compactos, pese a tener unas prestaciones envidiables, pues las cadenas se reservan para usos profesionales o usuarios muy selectos) sino los que estaba integrados por varias componentes separados (y , en general, de distintas marcas), cuando éramos más jóvenes discutíamos en ocasiones con nuestros amigos sobre qué elemento era el más importante de la cadena musical: unos afirmaban que el amplificador , otros que los altavoces, mientras que otros el “pick-up” o “tocadiscos” (que era como llamábamos por aquel entonces en España al lector de discos analógicos de vinilo) pues si la señal de origen ya salía con menor calidad de nada servía un buen amplificador o unos buenos altavoces. Siguiendo esta idea, otras personas se remontaban por la cadena hacia el origen de la señal, y justificaban que lo más importante era el disco en sí mismo (en aquellos tiempos de vinilo) pues si el disco estaba rayado o había sido grabado con mala calidad en el estudio de grabación de nada servía una cadena excelente. De esta forma se llegaba al proceso de grabación y salían los pocos equipos que por aquellos tiempos conocíamos de los estudios de grabación … Volviendo a los elementos de la propia cadena de música, yo personalmente solía argumentar que el elemento más importante era el equalizador, pues con un manejo hábil de los filtros era capaz de oír sólo la guitarra, o sólo la batería, etc., y de alguna forma sentía que podía actuar sobre las fuentes de sonido que integraban la canción… en cualquier caso, como se ve, argumentos tan discutibles como cualquier otro, cuando se habla de una cadena de procesos “secuenciales”, pero que guarda cierta relación con lo que voy a exponer.
Lo cierto es que es que los procesos de la ISO 20.000 (o ITIL) sin ser una cadena lineal, sí son un conjunto armónico de forma que el no ejecutar bien uno de ellos, repercute en el resto. Ahora bien, de nuevo a riesgo de arrepentirme, o de que los auténticos expertos en la ISO 20.000 me acribillen, diré que probablemente (con las salvedades ya expuestas) el proceso más importante sea el de la Gestión de la Configuración por el hecho de que es el “dueño” de la CMDB (siglas de Configuration Management Data Base).
Nota. En mi afirmación del día anterior lo que pretendía resaltar era que un proceso (el de la Gestión de la Capacidad) que hasta hace poco solía ser relativamente fácil de gestionar (de hecho, en muchos DataCenter su gestión se articulaba entorno a una hoja de cálculo más o menos compleja) con el tema de la Cloud ha alcanzado una complejidad alta y su importancia sobre la economía de la empresa es elevada.
Retomando la línea argumental sobre la importancia de la CMDB, lo resumiré con la afirmación que oí en uno de los cursos a los que asistí: La CMDB es la “piedra angular” para los procesos y la “biblia” para los técnicos que operan en un DataCenter, deben creer lo que en ella se muestra a “pies juntillas”, si en algún momento llegan a dudar de la información que en ella se contiene, el castillo de naipes se desmorona por completo. Esto es así porque (a modo de resumen simplista para los “profanos”, es decir, para permitir la comprensión por los que no estén familiarizados con el concepto) la CMDB es la Base de Datos donde se guarda, por una parte (el aspecto más clásico) el inventario de todos los componentes de la infraestructura IT (incluyendo, además del inventario puro con sus características físicas, otros aspecto como su proveedor, contrato de mantenimiento, garantías, etc.), y por otra parte (en su aspecto más innovador) todas las “relaciones y dependencias” que existen entre dichos elementos. Estas “relaciones” es una información vital para el buen funcionamiento de las IT: piénsese, por citar un ejemplo, que si se debe realizar alguna intervención sobre un servidor hay que estar totalmente seguro de todos los servicios que directa o indirectamente se van a ver afectados en mayor o menor medida por dicha actuación para poder avisar y negociar con los usuarios de dichos servicios el momento para realizar dichos trabajos; o , por citar, otro aspecto muy importante, dicha relaciones de la CMDB son una fuente muy importante para poder correlacionar eventos entre sí, y buscar la causa origen de problemas.
Ahora bien, por otra parte, el proceso de Gestión de Cambios gira en torno gestionar los cambios que se producen en el entorno operativo y vía el proceso de Gestión de la Configuración actualizar la CMDB de forma coherente: desde su inicio (poblar de contenidos la CMDB) hasta cualquier cambio ulterior que debe ser analizado y autorizado por este proceso. Es decir, se puede decir que la Gestión de la Configuración y la Gestión de Cambios son el núcleo entorno al que pivota el resto de los procesos ISO 20.000, tal como pretende reflejar la siguiente figura:
Por otra parte, volviendo al tema de las relaciones entre elementos de la CMDB, algunas de ellas son evidentes y relativamente estáticas, es decir, se producen muy pocos cambios (en contadas ocasiones) y mediante procedimientos muy llamativos que no pueden pasar desapercibidos: por ejemplo el nº y tipo de procesadores que tiene un servidor físico, o el segmento de red de seguridad en el que está dispuesto un servidor físico. Algunas son algo más dinámicas, por ejemplo el switch del que está colgado un servidor. Y otras pueden ser bastante dinámicas: por ejemplo la relación entre una aplicación y los servidores donde se ejecuta (hoy en día este aspecto es mucho muy dinámico debido a la reciente pero rápida incorporación de las tecnologías de virtualización, de grid, cloud computing, etc.).
Mientras que existen herramientas automáticas que permiten descubrir los cambios físicos (más memoria, más CPU) y de software de base (sistema operativo, etc.) o software estándar, y poblar y gestionar los cambios en la parte de inventario de la CMDB, sin embargo, no existen herramientas avanzadas (solo existe soluciones parciales como, por ejemplo, las que descubre al árbol de router y equipos colgados de un segmento de red) para descubrir automáticamente relaciones entre los elementos de la CMDB: las mismas deben ser introducidas manualmente, y por lo tanto precisan de mucho tiempo no solo para su descubrimiento, sino para su “regulación”, y certificación. El problema se agrava cuando el dinamismo de los cambios es grande, lo que resta tiempo a los técnicos para tenerlos al día, y por otra parte, como efecto secundario, suele conllevar que no se dedica suficiente a descubrir todas las relaciones, pudiendo quedar ocultas las que no son evidentes.
Este dinamismo en los cambios se ha acentuado con la irrupción de la virtualización y mucho más con el Cloud Computing: a modo de ejemplo, y aunque reconocemos que es un caso muy poco habitual, podemos mencionar que un entorno relativamente pequeño (formado por 8 servidores físicos) de un cliente que aloja sus máquinas en uno de los DataCenter de Tissat, se producen unos 4000 cambios al mes que implican el movimiento de una máquina virtual de un servidor físico a otro, con el consiguiente cambio en las relaciones que existen entre ellos. En consecuencia, es muy difícil que está actualizada en tales entornos, en cuyo caso perdería toda su utilidad.
Por lo tanto podemos concluir que el disponer de herramientas adecuadas para la gestión y operación de un entorno tan altamente cambiante y dinámico como es el mundo Cloud se ha convertido en algo indispensable para que la CMDB disponga de información fiable, y los procesos de la ISO 20.000 pueden operar de forma correcta.
Por todo ello Tissat, mediante un proyecto de I+D+i
al que ya se ha aludido anteriormente (el “Predictive I2TM”, y al que le dedicaremos un comentario exprofeso en próximos días), recurrió a técnicas de reconocimiento de patrones de conducta y de modelado predictivo para intentar descubrir las relaciones existentes entre los elementos de nuestras infraestructura TIC, así como los cambios que sufra la misma, de forma que se actualice la CMDB bien de forma automática, o bien, tras la validación (aprobación) por parte de un técnico una vez generada la correspondiente recomendación de cambio. Los resultados de dichos trabajos de I+D+i se han plasmado en una avanzada funcionalidad para nuestro producto I2TM (con el damos soporte a los procesos ISO 20.000 en la operación de los DataCenter de Tissat) que descubre nuevas relaciones entre elementos de la CMDB: algunas de ellas (las previamente autorizadas) las incluye automáticamente en la CMDB (indicando, en un campo ad-hoc, que han sido descubiertas automáticamente, para que en caso de necesidad se pueda depurar mejor un problema) y para otras relaciones (más dudosas) propone su incorporación (mediante un ticket, con todo el workflow y registros pertinente) al Responsable del Proceso de la Configuración para que la revise y le de su visto bueno, o no, tras analizarlo con el Responsable del Proceso de Gestión de Cambios (inicialmente en la propia CMDB ya anuncia la “posibilidad” de dicha relación, por si surgiera un incidente durante el proceso de su aprobación, para aportar dicho posiblemente conocimiento a los técnicos que tratan el incidente).
