CMDB: clases de CI, relaciones, fuentes y reconciliación, calidad del dato y una CMDB que aguanta una auditoría

Qué vas a conseguir

Una CMDB que responde a tres preguntas sin que nadie tenga que comprobarlo después: qué tenemos, de qué depende cada servicio y qué se rompe si toco esto. La diferencia entre una CMDB útil y una lista de equipos no es la herramienta (ServiceNow, EasyVista, Jira Service Management Assets o la que haya): es tener pocas clases bien rellenas, relaciones mantenidas y alguien responsable de cada dato.

Antes de empezar

• Un dueño del proceso de gestión de la configuración: decide qué entra, qué atributos son obligatorios y revisa la calidad cada mes. Sin esa persona, la CMDB se degrada en un trimestre.
• La lista de fuentes que ya existen: AD y Entra ID, Intune o MECM, vCenter, la herramienta de descubrimiento, la nube, el inventario de la sala, compras.
• El catálogo de servicios, aunque sea una hoja: las aplicaciones de negocio y quién responde de cada una.
• Para qué se va a usar primero: análisis de impacto de cambios, incidencias o auditoría. Empieza por ahí, no por "todo".

1. Clases de CI y atributos mínimos

Pocas clases y bien rellenas valen más que cien vacías. Un punto de partida que cubre casi todo:

• Cada atributo obligatorio tiene que tener una sola fuente que manda. Si dos herramientas pueden escribir el sistema operativo, decide cuál gana.
• Estado del ciclo de vida (pedido, en servicio, en reparación, retirado): sin él, un servidor apagado hace tres años sigue contando.
• Fuera de la CMDB quedan los datos que cambian cada minuto (uso de CPU, sesiones): eso es monitorización.

2. Relaciones: del servicio al servidor

Las relaciones son lo que hace útil una CMDB. La cadena mínima:

• Relación servicio → aplicación y aplicación → servidor o base de datos: se mantiene a mano o con mapeo de servicios, y la revisa el dueño técnico cuando cambia la arquitectura.
• Relación servidor virtual → host o clúster: la trae el descubrimiento desde vCenter o Hyper-V. No se escribe a mano porque cambia con cada vMotion.
• Con esta cadena, un cambio sobre CL-MAD-01 muestra que afecta a Nóminas, y el CAB lo ve antes de aprobar.

3. Fuentes y reconciliación

Descubrimiento y alta manual no compiten: cada uno aporta lo que sabe.

• Descubrimiento (agentes, WMI, SSH, SNMP, APIs de vCenter y de la nube): lo técnico. Nombre, serie, sistema, IP, software.
• Alta manual: lo que ningún escáner sabe. Dueño, servicio al que pertenece, criticidad, contrato de soporte.
• Reconciliación: la regla que dice cómo se identifica un CI y qué fuente gana para cada atributo. La identificación va por atributos estables, en orden: número de serie, UUID del hipervisor, y solo al final nombre más dominio. El nombre cambia; la serie no.

Si una fuente no tiene permiso para escribir un atributo, no lo escribe. La CMDB que acepta lo último que llega acaba con el sistema operativo cambiando cada noche entre dos valores.

4. Quién es dueño de cada dato

• Dueño del proceso: define el modelo, las reglas y los informes de calidad.
• Dueño del CI (un equipo, no una persona): responde de que sus CI estén bien. Los servidores de base de datos son del equipo de bases de datos, aunque los descubra otra herramienta.
• Dueño del servicio: confirma, una o dos veces al año, que el mapa de dependencias de su servicio es correcto.
• Un CI sin dueño es una alerta de calidad, no un estado aceptable.

5. Comprobaciones de calidad cada mes

Cuatro listas que salen cada mes y se reparten a los dueños:

• Huérfanos: servidores sin relación con ninguna aplicación, aplicaciones sin servicio. O sobran, o falta la relación.
• Duplicados: el mismo número de serie en dos CI, casi siempre un alta manual hecha antes del descubrimiento.
• Obsoletos: CI en servicio que el descubrimiento no ve desde hace más de 30 días. Apagados, retirados o fuera del alcance del escáner.
• Incompletos: sin dueño, sin estado o sin ubicación.

Una comprobación cruzada sencilla: equipos activos en AD que no están en la CMDB.

›$limite = (Get-Date).AddDays(-30)›$ad = Get-ADComputer -Filter {Enabled -eq $true -and LastLogonDate -gt $limite} -Properties LastLogonDate, OperatingSystem›$cmdb = Import-Csv .\cmdb-servidores.csv›$ad | Where-Object { $_.OperatingSystem -like "*Server*" -and $_.Name -notin $cmdb.Name } | Select-Object Name, OperatingSystem, LastLogonDateName          OperatingSystem                LastLogonDate----          ---------------                -------------SRV-PRUEBA-07 Windows Server 2022 Standard   28/10/2026 23:14:02SRV-SCAN-02   Windows Server 2019 Standard   29/10/2026 06:02:51

Dos servidores activos que la CMDB no conoce: o se dan de alta con su dueño, o se apagan. Lleva la cifra de cada lista mes a mes: que bajen es la prueba de que la CMDB mejora.

6. Incidencias y cambios enlazados a CI

• Cada incidencia se registra contra el CI afectado (el servicio o la aplicación, como mínimo). Así se ve qué CI dan más problemas y se alimentan los problemas recurrentes.
• Cada cambio lista los CI que toca. El análisis de impacto sale de las relaciones, no de la memoria de quien lo propone.
• Al cerrar un cambio, los atributos que ha modificado (versión, firmware, ubicación) se actualizan o los actualiza el siguiente descubrimiento. Un cambio cerrado con la CMDB desfasada es un cambio sin terminar.
• Haz obligatorio el campo de CI en el formulario, pero con una lista que se pueda buscar. Si elegir el CI cuesta un minuto, todo acabará en "Otros".

7. Lo que pide una auditoría

Las auditorías (ISO 27001, auditoría interna, un regulador) suelen pedir lo mismo:

• Inventario de activos con dueño y clasificación, y la prueba de que se mantiene: los informes de calidad de cada mes y las acciones tomadas.
• Una muestra: eligen diez servidores de la CMDB y piden verlos, o eligen diez de la red y piden encontrarlos en la CMDB. Es la prueba que tumba una CMDB descuidada.
• La trazabilidad: para un cambio concreto, qué CI tocó, quién lo aprobó y que la CMDB refleja el resultado.
• El procedimiento escrito: quién da de alta, quién retira y cómo se reconcilia.

Responde con datos de la herramienta y con el histórico de las comprobaciones. Una CMDB perfecta el día antes de la auditoría y descuidada el resto del año se nota en la muestra.

Siguientes pasos

• La guía de Device42 del Sector 5 baja al detalle de racks, posiciones y PDU, que alimentan los CI físicos.
• La guía de Jira Service Management cubre las incidencias y cambios que se enlazan a estos CI.
• El repositorio 38-it-asset-lifecycle-planner de mi GitHub cruza el inventario de hardware por número de serie entre varias fuentes, la misma idea que la reconciliación de esta guía, y el 04-itsm-kpi-dashboard saca indicadores de las incidencias por CI.

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.