Modulo 01. Introduccion a CMDB y Asset Management

Objetivo del modulo

Comprender la diferencia entre Configuration Management Database y Asset Management dentro de ServiceNow, y saber cuándo usar cada enfoque.

Resultados esperados

• Distinguir CI y asset sin confundir objetivos.
• Explicar qué aporta la CMDB a la operación.
• Relacionar Asset Management con ciclo de vida y propiedad.

Desarrollo teorico

La CMDB (Configuration Management Database) y Asset Management son dos disciplinas que conviven en ServiceNow pero que responden a preguntas fundamentalmente distintas. Confundirlas es uno de los errores mas comunes en implementaciones y genera CMDBs inmanejables, Asset Management sin gobierno y equipos que no saben donde buscar la informacion que necesitan. Entender la diferencia desde el principio ahorra muchos problemas posteriores.

La CMDB guarda configuration items (CIs) y sus relaciones con otros componentes del servicio. Su foco principal es responder preguntas de operacion e impacto: de que depende un servicio de negocio, que CIs se ven afectados por un cambio planificado, que servidor soporta una aplicacion critica, que relacion existe entre una base de datos y la maquina virtual donde corre, o cuantos servicios se verian impactados si cayera un switch de red. La CMDB es una herramienta operativa orientada a entender dependencias tecnicas y calcular impacto. Su tabla base es cmdb_ci y sus subclases especializadas (cmdb_ci_server, cmdb_ci_db_instance, cmdb_ci_service, etc.) definen los atributos relevantes para cada tipo de componente.

Asset Management, en cambio, sigue el ciclo de vida del activo como bien de la organizacion. Un activo tiene dueno, custodio, centro de coste, garantia, contrato de mantenimiento, fecha de compra, fecha de renovacion y estado administrativo (en stock, en uso, en reparacion, retirado, dado de baja). La tabla principal de assets en ServiceNow es alm_asset, y las subtablas como alm_hardware y alm_license especializan la gestion para hardware y licencias respectivamente. Asset Management responde preguntas financieras y de gobierno: cuantos portatiles tenemos sin asignar, que servidores estan fuera de garantia, cuantas licencias de Oracle estamos consumiendo versus las contratadas, o que activos deberiamos renovar en el proximo presupuesto.

Un mismo objeto fisico o logico puede ser simultaneamente un CI y un asset, pero por razones diferentes. Un servidor de produccion que soporta el ERP es un CI porque necesitamos conocer sus dependencias tecnicas, su relacion con servicios de negocio y su impacto en caso de fallo. El mismo servidor es un asset porque tiene un coste de adquisicion, una garantia del fabricante, un centro de coste asignado y una fecha de renovacion prevista. En ServiceNow, esta dualidad se gestiona mediante una relacion entre el registro de CI (cmdb_ci_server) y el registro de asset (alm_hardware). Los campos operativos viven en el CI; los campos financieros y de ciclo de vida viven en el asset.

Un portatil asignado a un empleado es casi siempre un asset porque la organizacion necesita saber quien lo tiene, cuando se compro, que garantia tiene y cuando se debe renovar. Pero ese mismo portatil raramente es un CI relevante para la CMDB, porque su relacion con servicios de negocio es minima y no afecta a analisis de impacto. Registrarlo como CI generico en la CMDB solo anade ruido sin aportar valor operativo. En cambio, un switch de core de red que conecta toda la infraestructura de un centro de datos es claramente un CI critico que debe estar en la CMDB con todas sus relaciones. Probablemente tambien es un asset con su ciclo de vida gestionado, pero su valor principal esta en el mapa de dependencias, no en su ficha administrativa.

El modelo CSDM (Common Service Data Model) de ServiceNow proporciona un marco de referencia para organizar la relacion entre servicios, aplicaciones, infraestructura y los datos que los describen. CSDM define capas conceptuales: la capa de design (business services y technical services), la capa de manage (applications y application services), la capa de sell/consume (service offerings y commitments) y la capa de foundation (infraestructura de servidores, redes, bases de datos y cloud). Aunque CSDM no es obligatorio, seguirlo ayuda a evitar una CMDB desorganizada donde nadie sabe que clases usar ni como conectar los datos con los servicios que la organizacion consume.

Los errores mas comunes al implementar CMDB y Asset Management juntos incluyen: cargar en la CMDB todo lo que aparece en el inventario de activos sin filtrar por relevancia operativa (convirtiendo la CMDB en un inventario duplicado), esperar que Asset Management responda preguntas de impacto de servicio (que solo la CMDB con relaciones bien modeladas puede contestar), duplicar datos entre ambos mundos sin definir una fuente maestra por atributo y no definir criterios claros de que merece ser CI y que solo necesita ser asset. La consecuencia de estos errores es una CMDB con miles de registros que nadie consulta, un Asset Management que no refleja la realidad y equipos que desconfian de ambos sistemas porque los datos no coinciden.

La recomendacion practica es empezar con criterios claros: un objeto merece ser CI en la CMDB si su fallo o cambio puede impactar un servicio de negocio y si necesitamos conocer sus dependencias tecnicas. Un objeto merece ser asset si la organizacion necesita gestionar su ciclo de vida, su coste o su asignacion. Ambas condiciones pueden cumplirse simultaneamente, pero una no implica la otra. Definir estos criterios antes de poblar datos es la base de una CMDB util y un Asset Management gobernable.

Contenido ampliado

Puntos clave

• CMDB y Asset Management no son sinónimos.
• Un objeto puede existir en ambos mundos por motivos distintos.
• La CMDB sirve a operación, impacto y dependencia.
• Asset Management sirve a ciclo de vida, propiedad y gobierno.

Checklist operativa

• Clasifica cinco ejemplos como CI, asset o ambos.
• Revisa qué preguntas operativas responde cada enfoque.
• Detecta si tu organización está mezclando ambos conceptos.
• Define qué datos no deberían vivir en la CMDB si no aportan valor.

Errores frecuentes

• Cargar en CMDB todo lo inventariado sin criterio.
• Esperar que Asset Management explique impacto de servicio.
• Duplicar datos sin definir fuente maestra.
• Confundir ownership técnico con ownership financiero u operativo.

Practica sugerida

Haz una tabla con servidores, portátiles, licencias y aplicaciones, indicando cuándo cada uno debería tratarse como CI, asset o ambos.

Preguntas de autoevaluacion

• ¿Qué diferencia funcional existe entre CI y asset?
• ¿Por qué una CMDB no debería ser solo un inventario más?
• ¿Qué riesgo aparece cuando se mezclan ambos modelos sin criterio?

Cierre

Comprender esta diferencia es la base para que la CMDB sea útil y el Asset Management no se quede en un simple registro administrativo.

Modulo 02. Clases, CIs y modelo de datos

Objetivo del modulo

Entender como ServiceNow organiza las clases de CIs en la CMDB y como modelar una base de datos de configuracion sin perder coherencia, utilidad ni mantenibilidad.

Resultados esperados

• Explicar la jerarquia basica de clases CMDB con ejemplos concretos.
• Distinguir atributos comunes y especificos por clase.
• Evitar modelados demasiado genericos o demasiado fragmentados.
• Relacionar el modelo de clases con reporting, impacto y automatizacion.

Desarrollo teorico

La CMDB de ServiceNow se construye sobre una jerarquia de clases que sigue el mismo principio de herencia de tablas que rige toda la plataforma. La tabla raiz es cmdb y su principal derivada es cmdb_ci (Configuration Item), de la cual heredan todas las clases especializadas. Esta jerarquia permite definir atributos generales que aplican a cualquier CI y luego especializar segun tipo de componente, anadiendo atributos relevantes para cada categoria.

La clase cmdb_ci define los atributos comunes a todos los configuration items: name, sys_class_name (la clase real del CI), operational_status, install_status, asset_tag, serial_number, assigned_to, support_group, managed_by, location, department, company y otros campos generales. Estos campos existen en cualquier CI independientemente de su tipo. A partir de ahi, las subclases anaden especializacion.

Las clases principales siguen una taxonomia logica que ServiceNow denomina CSDM (Common Service Data Model). Algunas de las subclases mas importantes incluyen:

• cmdb_ci_server para servidores fisicos y virtuales, con atributos como cpu_count, ram, os, os_version, ip_address, dns_domain.
• cmdb_ci_db_instance para instancias de base de datos, con atributos como type (MySQL, Oracle, SQL Server), version, port, connection_url.
• cmdb_ci_app_server para servidores de aplicaciones con campos de middleware y configuracion.
• cmdb_ci_service para servicios de negocio, que representan lo que el usuario final consume y permite modelar el impacto de arriba a abajo.
• cmdb_ci_computer para estaciones de trabajo, portatiles y equipos de usuario final.
• cmdb_ci_netgear para dispositivos de red como switches, routers y firewalls.
• cmdb_ci_cloud_service_account para suscripciones cloud en AWS, Azure o GCP.

El CSDM es el modelo de referencia que ServiceNow recomienda para organizar datos de servicio. Define capas conceptuales: la capa de design (business services, technical services), la capa de manage (applications), la capa de sell/consume (service offerings) y la capa de foundation (infrastructure). Aunque no es obligatorio seguir CSDM al pie de la letra, ignorarlo completamente suele llevar a CMDBs desorganizadas donde nadie sabe que clase usar para que tipo de componente.

El error mas comun en modelado es elegir clases demasiado genericas. Cuando todo se registra como cmdb_ci sin especializar, se pierden los atributos especificos que hacen util la informacion. Un servidor registrado como cmdb_ci generico no tiene campos de CPU, RAM ni sistema operativo. Un servicio registrado como CI generico no tiene las relaciones ni la visibilidad de impacto que cmdb_ci_service proporciona. La clase correcta no es un detalle estetico; condiciona que atributos se pueden capturar, que reportes se pueden construir y que automatizaciones se pueden activar.

El error opuesto es hiperfragmentar el modelo creando clases personalizadas para cada variante minima. Si el equipo crea clases separadas para cada version de base de datos o cada modelo de servidor, el mantenimiento se vuelve insostenible, los reportes se fragmentan y la reconciliacion con fuentes de discovery se complica. El criterio general es: crear una subclase nueva solo cuando la diferencia en atributos o comportamiento operativo justifica la complejidad adicional.

Los atributos de cada clase deben responder a preguntas operativas reales. Para un servidor, los atributos criticos pueden ser: sistema operativo, version, direccion IP, funcion (web, app, db), entorno (produccion, test, desarrollo), grupo de soporte y estado operativo. Para una aplicacion, los atributos relevantes serian: owner, criticidad de negocio, tecnologia, version y servicios que dependen de ella. Cada atributo que se decide incluir en el modelo tiene un coste de mantenimiento: alguien debe poblarlo, actualizarlo y validar su exactitud. Un campo que nadie mantiene es peor que un campo que no existe, porque genera falsa confianza.

La calidad de datos en CMDB es un problema cronico que afecta a la mayoria de organizaciones. Los indicadores principales de calidad incluyen: completitud (porcentaje de campos criticos poblados), exactitud (los datos reflejan la realidad), duplicados (CIs que representan el mismo componente con registros distintos) y frescura (los datos se actualizaron recientemente). ServiceNow ofrece CMDB Health Dashboard para monitorizar estos indicadores y detectar degradacion.

La relacion entre el modelo de clases y Discovery merece atencion. Cuando se activa Discovery o se integran fuentes de datos externas (SCCM, Intune, cloud APIs), los datos entrantes deben mapearse a clases CMDB concretas. Si el modelo de clases no esta bien definido antes de activar Discovery, los datos entrantes pueden clasificarse incorrectamente, crear duplicados o poblar clases genericas sin valor. La recomendacion es definir primero el modelo de clases y los criterios de clasificacion, y despues configurar las fuentes de datos.

Finalmente, la eleccion de clases afecta directamente al analisis de impacto. ServiceNow puede calcular automaticamente que servicios de negocio se ven afectados por un fallo en un servidor, pero solo si el servidor esta registrado en la clase correcta con relaciones bien definidas hacia las aplicaciones y servicios que soporta. Sin la clase correcta, sin atributos relevantes y sin relaciones, la CMDB es un inventario caro que no responde las preguntas para las que fue creada.

Contenido ampliado

Puntos clave

• La CMDB necesita una jerarquia de clases bien pensada antes de poblar datos.
• Hay que equilibrar genericidad y detalle: clases demasiado genericas pierden valor, demasiado fragmentadas son insostenibles.
• El modelo de clases condiciona reporting, analisis de impacto y automatizacion.
• Una mala eleccion de clase degrada calidad, mantenimiento y utilidad operativa.
• CSDM proporciona un marco de referencia recomendado para organizar el modelo.
• La calidad de datos (completitud, exactitud, frescura) es tan importante como el modelo.

Checklist operativa

• Revisa las clases mas usadas en tu CMDB y valida que sean las correctas segun tipo de componente.
• Comprueba si hay CIs registrados en cmdb_ci generico que deberian estar en subclases especificas.
• Identifica atributos criticos por clase y mide su porcentaje de completitud.
• Evalua si la jerarquia de clases facilita o entorpece el reporting que necesita la organizacion.
• Verifica que el modelo de clases esta alineado con las fuentes de Discovery configuradas.
• Consulta el CMDB Health Dashboard para detectar problemas de calidad.

Errores frecuentes

• Usar siempre la clase generica cmdb_ci sin especializar.
• Crear clases excesivamente especificas para variantes menores.
• No documentar criterios de modelado: por que se elige cada clase y que atributos son obligatorios.
• Duplicar atributos en clases sin revisar herencia desde la clase padre.
• Activar Discovery antes de tener el modelo de clases definido.
• Poblar campos que nadie mantiene, generando datos obsoletos que se confunden con datos validos.

Practica sugerida

Modela un ejemplo CMDB para una aplicacion web con los siguientes componentes: (1) un servicio de negocio (Tienda Online), (2) una aplicacion (eCommerce Platform), (3) dos servidores (web server y app server), (4) una instancia de base de datos (PostgreSQL). Para cada componente: elige la clase correcta, define cinco atributos criticos y explica por que los elegiste. Finalmente, valida si podrias hacer analisis de impacto con tu modelo: si cae el servidor de base de datos, que servicios se afectan.

Preguntas de autoevaluacion

• ¿Que aporta la jerarquia de clases en CMDB frente a registrar todo como CI generico?
• ¿Cuando una clase es demasiado generica y cuando demasiado especifica?
• ¿Que problemas operativos trae una clasificacion inconsistente?
• ¿Por que es importante definir el modelo de clases antes de activar Discovery?
• ¿Que indicadores de calidad de datos monitorizarias en CMDB?

Cierre

La calidad del modelo de clases condiciona todo lo que la organizacion podra hacer despues con la CMDB: analisis de impacto, enrutamiento de incidentes, evaluacion de cambios y gobierno de infraestructura. Un modelo bien pensado es invisible en el dia a dia; un modelo mal pensado se nota en cada decision operativa.