Base de Datos de Gestión de Configuración

Un elemento de configuración (CI) es cualquier componente que debe gestionarse para prestar un servicio. Puede ser un servidor, una estación de trabajo, un switch de red, una aplicación, un esquema de base de datos, una licencia, un contrato o la documentación que describe cómo encaja todo. Cada CI tiene atributos como propietario, ubicación, versión, número de serie y estado del ciclo de vida. En la mayoría de los diseños, también guarda un historial de sus estados a lo largo del tiempo.

Lo que define a una CMDB es que las relaciones tienen el mismo peso que los propios elementos. Un registro de CI dice qué es un componente. Una relación dice que la aplicación de nóminas se ejecuta en un clúster concreto, que ese clúster depende de una cabina de almacenamiento y que una sucursal se conecta a través de un router específico. Leídos en conjunto, estos vínculos forman un grafo de dependencias. Responde preguntas que una lista plana no puede contestar: si este equipo falla, ¿qué servicios se detienen y a quién afecta?

En la gestión de servicios de TI, la CMDB es el punto de referencia donde otros procesos escriben y del que leen. La gestión de incidentes vincula cada incidente con los CI implicados. Así agiliza el triaje y muestra las fallas recurrentes en un mismo componente. La gestión de problemas analiza esos grupos para encontrar causas raíz. La gestión de cambios es el principal proceso que escribe: un cambio aprobado registra qué CI afectará, y la CMDB debe reflejar el nuevo estado al terminar el cambio.

El grafo de dependencias convierte los registros en decisiones. Antes de aprobar un cambio, se puede estimar su radio de impacto siguiendo las relaciones desde los CI afectados. Tras un incidente, el mismo recorrido muestra qué revisar por posibles efectos colaterales. Una CMDB que solo se consulta durante las auditorías aporta apenas una fracción de ese valor.

Ambos están relacionados, pero responden preguntas distintas. El inventario de activos, parte central de la gestión de activos de TI (ITAM), muestra qué posee la organización, dónde está cada activo y quién es responsable de él. Sus principales usuarios son finanzas, compras e instalaciones. La CMDB muestra cómo se relacionan los componentes y qué afecta un cambio en uno de ellos. Sus usuarios son los equipos de incidentes, problemas y cambios.

En la práctica, el límite es gradual. Muchas organizaciones empiezan con un inventario sencillo y añaden relaciones a medida que maduran sus procesos de gestión de servicios. Hay una prueba sencilla: un repositorio en el que nada se vincula con nada es un inventario con campos adicionales, sea cual sea su nombre.

La mayoría de las CMDB combinan el descubrimiento automatizado con el mantenimiento manual de registros. El descubrimiento usa recopilación con agentes, escaneo de red e integraciones con plataformas de nube y directorio. Encuentra lo que existe de verdad y detecta las diferencias entre el estado registrado y el real. Los contratos, las definiciones de servicio y otros elementos que no se pueden escanear se introducen y mantienen a mano.

Cuando varias herramientas guardan cada una parte de la verdad, la CMDB las federa o las concilia. Se designa una fuente autorizada para cada tipo de atributo, y los conflictos se resuelven por regla, no por debate. La exactitud es resultado de un proceso continuo, no de una carga única. Sin un propietario designado, se degrada con rapidez.

En Anexet Inventory, la tarjeta de cada estación de trabajo enumera los dispositivos y las aplicaciones instaladas, con tipo de dispositivo, fabricante, versión y fecha de instalación. Estos registros son la materia prima con la que una CMDB construye sus elementos de configuración.

1 / 2

• 
• 

El patrón de fracaso es bien conocido. El alcance inicial abarca todo a la vez, y el proyecto se ahoga en trabajo de calidad de datos antes de entregar algo. Los registros solo se actualizan cuando alguien lo recuerda. Con el tiempo, la base de datos deja de reflejar la realidad y el personal deja de confiar en ella. En ese punto está técnicamente viva y prácticamente muerta. Las prácticas siguientes distinguen a las implementaciones que sobreviven.

Una CMDB es un dato de referencia, no un recolector. Rara vez observa el entorno por sí misma. En cambio, agrega lo que reportan las herramientas de descubrimiento, monitoreo y gestión. A cambio, enriquece esas herramientas. Las alertas de monitoreo ganan contexto sobre qué es un host y a qué servicio presta apoyo. Las investigaciones de seguridad parten de un mapa conocido de lo que debería existir. La planificación de recuperación sabe qué componentes restaurar y en qué orden.

Sus límites derivan del mismo diseño. Una CMDB no detecta intrusiones, no controla dispositivos ni sustituye la visibilidad de los endpoints. Indica a la organización cómo debería verse su entorno, para que otros controles puedan interpretar lo que observan. Controles como la prevención de pérdida de datos (DLP) actúan donde los datos realmente se mueven, como muestra la tabla.

Empieza por los servicios cuya caída costaría más y modela los componentes de los que dependen. Mantener el modelo cerca de la realidad es la disciplina central de la gestión de configuración, así que amplía el alcance solo después de superar una auditoría de exactitud.