La CMDB en la que nadie confía

Son las dos de la mañana y una aplicación orientada a clientes está caída. El ingeniero de guardia abre la CMDB, encuentra el servidor y ve un propietario que dejó la empresa hace un año. La base de datos de la que depende la aplicación no está registrada en absoluto. Lo que sigue es una ronda de llamadas telefónicas, una búsqueda en hojas de cálculo compartidas y un debate sobre quién es responsable de qué. La incidencia se prolonga y a la mañana siguiente alguien dice de nuevo: "No se puede confiar en la CMDB de todos modos".

A menudo vemos el mismo patrón. La base de datos de configuración existe, cuesta un esfuerzo real mantenerla y, sin embargo, nadie confía en ella. Así que la gente mantiene sus propios registros en hojas de cálculo, wikis o en sus cabezas. Eso cierra el círculo: cuanto menos se utiliza la CMDB, menos se actualiza y menos merece la pena confiar en ella. Detrás de todo esto hay personas cansadas que reconstruyen una imagen de la infraestructura desde cero cada vez que algo se rompe.

Por qué las soluciones habituales no duran

La respuesta típica es un proyecto de limpieza. Un equipo pasa semanas revisando registros, los datos parecen buenos durante un tiempo y seis meses después están de vuelta donde empezaron. El problema no es una mala importación. Es la forma en que se crea los datos y la forma en que envejecen.

• Entrada manual sin comprobaciones. Varias personas crean elementos de diferentes maneras y nadie verifica si el resultado tiene sentido.
• No hay historial. Cuando un valor es incorrecto, no hay forma de averiguar quién lo cambió, cuándo o de dónde vino.
• Más de una verdad. La organización mantiene una CMDB principal en una herramienta y datos operativos en otra. Sin un enlace fiable, los registros se desvían.
• No hay bucle de retroalimentación. Las inconsistencias surgen en el peor momento posible: durante una incidencia.

Una mejor forma de pensar sobre la calidad de los datos

La confianza en una CMDB no proviene de la perfección. Proviene de la transparencia. La gente confiará en los datos cuando pueda ver de dónde vienen, cuándo se confirmaron por última vez y qué está mal con ellos. Recomendamos basarnos en cuatro principios:

1. Automatizar donde sea posible. El descubrimiento automático y las importaciones superan la copia manual.
2. Cada cambio tiene un autor y una fuente. El historial de versiones es la base para rastrear errores y auditorías.
3. Comprobar la calidad de forma continua. Es mucho mejor encontrar una inconsistencia en una tranquila tarde de martes que durante un apagón nocturno.
4. Ser claro sobre el registro principal. Si otra CMDB es el sistema de registro, debe ser inequívoco qué elemento coincide con cuál.

Cómo lo maneja Eywo Stratum

Eywo Stratum funciona con 34 clases de elementos, desde servicios de negocio y aplicaciones hasta bases de datos, servidores virtuales y físicos, IBM Power, contenedores y almacenamiento, hasta dispositivos de red y OT. Puede poblarlo de varias maneras y combinarlas:

• a través de la API de descubrimiento, que alimentan herramientas de escaneo e inventario,
• importando archivos CSV o Excel, normalmente durante la implantación o migración,
• creando elementos manualmente donde nada más puede capturarlos,
• sincronizando con una CMDB principal como ServiceNow o SMAX a través de IDs externos, para que siempre esté claro qué registro corresponde a cuál.

Cada cambio en un elemento crea una nueva versión. El historial muestra quién realizó el cambio, cuándo, exactamente qué cambió y de dónde vino los datos: descubrimiento, importación, sincronización o una persona. Cuando un valor resulta ser incorrecto, su origen se puede rastrear en momentos.

Encima de eso se sitúan comprobaciones de calidad de datos. Stratum señala inconsistencias y registros incompletos para que el equipo pueda solucionarlos como parte del trabajo normal en lugar de bajo la presión de una incidencia. Con el tiempo, la CMDB se convierte en el primer lugar donde la gente busca, porque sabe qué encontrará allí.

Conclusión

Una CMDB en la que nadie confía no es realmente un problema técnico. Es un problema de confianza, y la confianza no se puede mandar. Solo se puede ganar: a través de la población automatizada, el historial transparente, comprobaciones continuas y un enlace claro al registro principal. La recompensa es una operación en la que el ingeniero de guardia encuentra la respuesta en los datos por la noche, no en el teléfono de un colega.

La gestión de CMDB, el historial de versiones, las importaciones y las comprobaciones de calidad de datos son parte de la edición Estándar; la sincronización con una CMDB principal a través de IDs externos está disponible en la edición Enterprise.