CMDB y RFCs, mejor juntas

Una de las dificultades a la que se enfrentan las organizaciones a la hora de montar una nueva CMDB es cómo mantenerla actualizada durante la etapa inicial de creación. ¿Si estoy revisando la infraestructura para meterla en la CMDB a la vez que sigo haciendo cambios, cómo garantizo que la versión inicial de mi CMDB no está ya obsoleta? Fácil, haciendo que la gestión de cambios y la gestión de configuración vayan de la mano

La antigua ITIL v2 relacionaba muy estrechamente los procesos de Gestión de Configuración (y su CMDB), Gestión de Cambios (RFCs) y Gestión de Entregas, e incluso les daba un nombre conjunto: “procesos operacionales”. Tanto era así, que en muchas ocasiones se planteaba la necesidad de implantarlos al mismo tiempo.

Como en todo, aquí no hay nada mandatorio, y nadie nos obligará a implantar los 3 procesos simultáneamente, pero si decidimos hacerlo, tendremos muchas ventajas. Una de ellas, entre otras, será que podremos minimizar el riesgo de que nuestra recién creada CMDB ya nazca obsoleta, desactualizada.

El proceso de configurar y meter todos los datos en una nueva CMDB puede ser relativamente laborioso, sobre todo en organizaciones de un tamaño relativamente importante, en las que existe un catálogo de servicios grande, con mucha infraestructura. En ese entorno, identificar los CIs que forman parte de la CMDB, ver cómo se relacionan, determinar qué servicios prestan, e introducir la información en la CMDB puede llevar un tiempo no despreciable, y durante ese intervalo, podrían seguir realizándose cambios que modifiquen la información de la CMDB.

Para evitar las situaciones anteriores, la solución pasa por incorporar la gestión de configuración al proceso de gestión de cambios desde el primer momento, no al final como se hace muchas veces: desde el primer momento, cualquier cambio que se realice, ya debería ser notificado directamente a la CMDB para su actualización.

Algunos pasos (simples, muy simples), de cómo podría realizarse esto:

· Cualquier cambio debería llevar desde el primer momento el detalle de los elementos de configuración que va a actualizar (aunque no esté todavía la CMDB, como ya tendremos el alcance y tipos de elementos, la gestión de cambios podría listarlos, aunque sea de manera textual)

· Los responsables de la gestión de configuración recibirán esa información, y podrán encontrarse ante varios casos distintos:

– Si los CIs ya están en la CMDB, podrán actualizarla sin ningún problema

– Si los CIs no están en la CMDB, ni tampoco forman parte del grupo de CIs con el que estamos trabajando en este momento, no hará falta hacer nada de momento

– Si los CIs no están en la CMDB, pero forman parte de los elementos involucrados en la prestación del servicio que estamos modelando en la CMDB, tendremos que tener muy en cuenta esos cambios para que ya vayan incluidos directamente en nuestro modelado del servicio

Con este planteamiento (muy sencillo), surge además una idea de fondo, que es la necesidad de alimentar la CMDB de manera gradual e iterativa, modelando servicio a servicio (siempre relacionados con el Catálogo de Servicios)

Parece una receta sencilla, y realmente lo es, y permitirá que nuestra CMDB luzca reluciente y actualizada desde el primer día¡! No hay nada más frustrante que invertir el esfuerzo de varias semanas o meses en modelar una CMDB, y que en el momento de su “puesta de largo” tengamos fundadas sospechas de que ya no está actualizada; si nos ha ocurrido eso, sin duda nuestro proyecto ha fracasado, algo hemos hecho mal.

Jandro Castro