ArquitecturaCMDBITOMGobernanza

Como sostener una CMDB saludable en ServiceNow

Por Equipo Optimo Tech9 min de lectura

La CMDB es el sistema de registro de la infraestructura, las aplicaciones y los servicios de una organizacion. En teoria. En la practica, la mayoria de las CMDBs que visitamos tienen tres problemas comunes: datos desactualizados, relaciones incompletas y ningun proceso que las mantenga vivas. El resultado es predecible: nadie confia en ellas, los equipos vuelven a sus hojas de calculo y la inversion de ServiceNow se diluye.

Que significa saludable

Una CMDB saludable no es una CMDB completa. Es una CMDB correcta en los dominios que importan. Los indicadores que miramos en una auditoria son completitud por clase critica (no total), frescura de datos (cuantos CIs actualizados en los ultimos 30 dias), densidad de relaciones (CIs sin ningun dependsOn) y consistencia de nomenclatura. Si los cuatro estan en verde para las clases criticas (aplicaciones, bases de datos, servidores productivos), la CMDB esta cumpliendo su proposito.

Donde fallan la mayoria

  • Discovery activo pero sin revision periodica de rangos de red y credenciales
  • Clases extendidas sin documentacion y con solapes con clases estandar
  • Flujos que crean CIs manualmente sin regla de reconciliacion
  • Sin ownership de datos por clase: cuando algo esta mal, nadie lo arregla

Las cinco practicas que marcan la diferencia

1. Gobernanza con dueños reales

Cada clase critica tiene un dueño nombrado. No el equipo de ServiceNow, sino el equipo que entiende el dato: red para Network Gear, DBAs para Database, infraestructura para Servers. El dueño aprueba cambios en la clase, revisa reportes de calidad y responde cuando hay inconsistencias.

2. Identification and Reconciliation Engine bien configurado

IRE es el corazon de la CMDB. Debe tener reglas de identificacion por clase, precedencia de fuentes y de-duplicacion activa. La mayoria de las CMDBs rotas que vemos tienen IRE en configuracion default o reglas que se acumularon sin criterio.

3. Multi-source con precedencia explicita

Discovery, Service Mapping, integraciones con herramientas de monitoreo y cargas manuales conviven. La precedencia entre ellas debe ser explicita y documentada, no implicita en el orden de configuracion.

4. Reportes de salud automaticos

Un dashboard mensual con los indicadores de salud, compartido con los dueños de clase. Si nadie mira el estado de la CMDB, nadie lo sostiene. Los dashboards automatizan la conversacion.

5. Servicios antes que infraestructura

La CMDB sirve para mapear servicios. Si el modelo de servicios esta pobre, la CMDB pierde valor de negocio. Service Mapping y Business Services bien definidos convierten una CMDB tecnica en una herramienta de gestion.

Por donde empezar si heredas una CMDB rota

No intentes arreglar todo. Elige tres servicios criticos de negocio, haz que sus CIs y relaciones esten correctos, pon un dueño para cada clase involucrada y mide semana a semana. Expandes desde ahi. Intentar arreglar toda la CMDB en un sprint es la receta clasica del fracaso.