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:
| Clase | Atributos mínimos | Fuente principal |
|---|---|---|
| Servicio de negocio | Nombre, dueño de negocio, criticidad, horario de servicio | Manual (catálogo) |
| Aplicación | Nombre, versión, dueño técnico, entorno (producción, pruebas) | Manual |
| Servidor (físico o virtual) | Nombre, número de serie o UUID, sistema operativo, IP, ubicación, estado | Descubrimiento |
| Base de datos | Motor, versión, instancia, servidor donde corre | Descubrimiento |
| Equipo de red | Nombre, modelo, serie, firmware, rack | Descubrimiento SNMP |
| Equipo de usuario | Nombre, serie, usuario asignado, estado | Intune o MECM |
- 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-01muestra 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:51Dos 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.
What you'll get
A CMDB that answers three questions without anyone having to double-check afterwards: what we have, what each service depends on and what breaks if I touch this. The difference between a useful CMDB and a list of devices isn't the tool (ServiceNow, EasyVista, Jira Service Management Assets or whatever is in place): it is having a few well-populated classes, maintained relationships and someone accountable for each piece of data.
Before you start
- A process owner for configuration management: decides what goes in, which attributes are mandatory and reviews quality every month. Without that person, the CMDB degrades within a quarter.
- The list of sources that already exist: AD and Entra ID, Intune or MECM, vCenter, the discovery tool, the cloud, the comms room inventory, purchasing.
- The service catalogue, even if it is a spreadsheet: the business applications and who answers for each one.
- What it will be used for first: change impact analysis, incidents or audit. Start there, not with "everything".
1. CI classes and minimum attributes
A few well-populated classes are worth more than a hundred empty ones. A starting point that covers almost everything:
| Class | Minimum attributes | Main source |
|---|---|---|
| Business service | Name, business owner, criticality, service hours | Manual (catalogue) |
| Application | Name, version, technical owner, environment (production, test) | Manual |
| Server (physical or virtual) | Name, serial number or UUID, operating system, IP, location, status | Discovery |
| Database | Engine, version, instance, server it runs on | Discovery |
| Network device | Name, model, serial, firmware, rack | SNMP discovery |
| End-user device | Name, serial, assigned user, status | Intune or MECM |
- Every mandatory attribute must have a single authoritative source. If two tools can write the operating system, decide which one wins.
- Lifecycle status (ordered, in service, in repair, retired): without it, a server switched off three years ago still counts.
- Data that changes every minute (CPU usage, sessions) stays out of the CMDB: that is monitoring.
2. Relationships: from service to server
Relationships are what make a CMDB useful. The minimum chain:
- Service → application and application → server or database relationships: maintained by hand or with service mapping, and reviewed by the technical owner when the architecture changes.
- Virtual server → host or cluster relationship: discovery brings it from vCenter or Hyper-V. It isn't written by hand because it changes with every vMotion.
- With this chain, a change on
CL-MAD-01shows that it affects Payroll, and the CAB sees it before approving.
3. Sources and reconciliation
Discovery and manual entry don't compete: each contributes what it knows.
- Discovery (agents, WMI, SSH, SNMP, vCenter and cloud APIs): the technical side. Name, serial, OS, IP, software.
- Manual entry: what no scanner knows. Owner, the service it belongs to, criticality, support contract.
- Reconciliation: the rule that says how a CI is identified and which source wins for each attribute. Identification uses stable attributes, in order: serial number, hypervisor UUID, and only at the end name plus domain. Names change; serials don't.
If a source isn't allowed to write an attribute, it doesn't write it. A CMDB that accepts whatever arrives last ends up with the operating system flipping between two values every night.
4. Who owns each piece of data
- Process owner: defines the model, the rules and the quality reports.
- CI owner (a team, not a person): answers for its CIs being right. Database servers belong to the database team, even if another tool discovers them.
- Service owner: confirms, once or twice a year, that their service's dependency map is correct.
- A CI with no owner is a quality alert, not an acceptable state.
5. Monthly quality checks
Four lists that come out every month and go to the owners:
- Orphans: servers with no relationship to any application, applications with no service. Either they are surplus or the relationship is missing.
- Duplicates: the same serial number on two CIs, almost always a manual entry made before discovery.
- Stale: in-service CIs that discovery hasn't seen for more than 30 days. Switched off, retired or outside the scanner's reach.
- Incomplete: no owner, no status or no location.
A simple cross-check: active computers in AD that aren't in the CMDB.
$limit = (Get-Date).AddDays(-30)$ad = Get-ADComputer -Filter {Enabled -eq $true -and LastLogonDate -gt $limit} -Properties LastLogonDate, OperatingSystem$cmdb = Import-Csv .\cmdb-servers.csv$ad | Where-Object { $_.OperatingSystem -like "*Server*" -and $_.Name -notin $cmdb.Name } | Select-Object Name, OperatingSystem, LastLogonDateName OperatingSystem LastLogonDate---- --------------- -------------SRV-TEST-07 Windows Server 2022 Standard 28/10/2026 23:14:02SRV-SCAN-02 Windows Server 2019 Standard 29/10/2026 06:02:51Two active servers the CMDB doesn't know about: either they are registered with their owner, or they are switched off. Track the count of each list month by month: seeing them go down is the proof the CMDB is improving.
6. Incidents and changes linked to CIs
- Every incident is logged against the affected CI (the service or application, at least). That shows which CIs cause the most trouble and feeds recurring problems.
- Every change lists the CIs it touches. Impact analysis comes from the relationships, not from the memory of whoever proposes it.
- When a change closes, the attributes it modified (version, firmware, location) are updated, or the next discovery run updates them. A change closed with the CMDB out of date is an unfinished change.
- Make the CI field mandatory on the form, but with a searchable list. If picking the CI takes a minute, everything will end up under "Other".
7. What an audit asks for
Audits (ISO 27001, internal audit, a regulator) usually ask for the same things:
- An asset inventory with owner and classification, and proof that it is maintained: the monthly quality reports and the actions taken.
- A sample: they pick ten servers from the CMDB and ask to see them, or pick ten from the network and ask to find them in the CMDB. It is the test that brings down a neglected CMDB.
- Traceability: for a specific change, which CIs it touched, who approved it and that the CMDB reflects the result.
- The written procedure: who registers, who retires and how reconciliation works.
Answer with data from the tool and with the history of the checks. A CMDB that is perfect the day before the audit and neglected the rest of the year shows up in the sample.
Next steps
- The Device42 guide in Sector 5 goes into the detail of racks, positions and PDUs, which feed the physical CIs.
- The Jira Service Management guide covers the incidents and changes linked to these CIs.
- The 38-it-asset-lifecycle-planner repository on my GitHub matches the hardware inventory by serial number across several sources, the same idea as reconciliation in this guide, and 04-itsm-kpi-dashboard builds indicators from incidents per CI.
Is something missing, or different in your environment? Get in touch and I'll fix it.
Tech Career Lab · newsletter
¿Te ha servido? Cada dos semanas envío una idea práctica para perfiles IT: LinkedIn, proyectos, networking y procesos de selección.Found this useful? Every two weeks I send one practical idea for IT professionals: LinkedIn, projects, networking and hiring processes.
Apúntate y llévate las 33 ideasSign up and get the 33 ideas →