Imagen de Alex Proimos

Si alguna vez te ha tocado vivir un proyecto de CMDB, sabrás que es un quebradero de cabeza.

Os voy a hablar de dos experiencias de CMDB grandes y los errores que los llevaron al fracaso.

Os dejo con las historias de CMDB que no me dejan dormir:

Entradas manuales

También lo llamaría: exceso de confianza y delegación. Suele venir acompañado de frases como: “Al coordinador del Cambio (o release) no le cuesta nada actualizar los activos”. Yo ya no creo que ni en proyectos pequeños sea conveniente hacer altas, bajas y modificaciones a mano.

Está claro que se puede necesitar modificación manual de erratas, pero la entrada manual debe ser la excepción y no la regla.

Encuentra herramientas de descubrimiento que se integren en tu CMDB, busca lectores de códigos de barras o QR que te ayuden a inventariar elementos. Pero no aceptes el input manual.

Pensar que el input manual es gratis, es también un error.

Falta de continuidad

Finish, by Joshya Aanstey

¿Tu organización deja de cambiar? Si la respuesta es sí, eres seguramente alguna religión.

Pero por lo general las organizaciones cambian. De la misma forma, los activos cambian, y esos cambios se deben reflejar.

Es un error pensar que la CMDB es un proyecto con principio y fin. Va a requerir de actualizaciones y revisiones periódicas.  Así que no le pongas fecha de fin de proyecto.

Modelizacion de abajo, hacia arriba

Cómo sabemos qué servidores forman parte de la aplicación X, lo modelaremos así.

Project manager de CMDB

El problema es que mañana, la aplicación X tendrá un servidor más, y si tu mapeo es desde los servidores, hacia la aplicación o servicio, acabará por estar desactualizado muy pronto.

Las modelizaciones bottom-up son malas, tienden a ser estáticas y a requerir mantenimiento. Prueba modelizaciones basadas en patrones, en segmentación de red…

Lo quiero todo, papi

Quiero simulaciones de impacto,Informes de índice de obsolescencia, quiero llevar el control de licencias, y quiero que todo sea gráfico, sencillo, barato y que esté disponible desde ayer.

Carta de cliente a los reyes magos de la CMDB

¿Qué tal si empezamos por modelar bien las cosas antes? ¿Qué tal si conseguimos antes de eso, definir indicadores de calidad del dato?

Empieza por lo básico, no abarques más de lo que puedas, intenta que tu herramienta de descubriemiento, mediante el uso de patrones, saque el mapa completo de una aplicación. Desde ahí, averigua como puedes separar, de nuevo mediante patrones, los diferentes entornos que tiene esa aplicación…

Claves para tu proyecto de CMDB

  • No confíes en las actualizaciones manuales, huye de las frases: “en el procedimiento de cambios dice que el coordinador del cambio actualizará la cmdb”.
  • Busca una herramienta de descubrimiento que se ajuste a tus necesidades.
  • Ves poco a poco, ayúdate de los expertos en las aplicaciones para buscar patrones y luego validar los datos.
  • Define frecuencias de revisión e indicadores que te permitan ver y valorar el grado de avance y la calidad.
  • Huye del todo para ayer, ves poco a poco, gana confianza demostrando avances con un ritmo constante.