Para una gestión eficaz de los activos de IT es fundamental contar con una Base de Datos de Gestión de la Configuración (CMDB - Configuration Management Database), que centraliza la información de los componentes que intervienen en la prestación de servicios de una organización, así como las relaciones entre ellos.
Pero ¿Cómo crear una CMDB que sea útil y se mantenga actualizada para que el equipo de IT pueda identificar los posibles riesgos cuando se producen cambios, incidentes o interrupciones?
En las siguientes secciones, explicamos qué es una CMDB, cómo construir una con InvGate Asset Management, qué cargar primero, de qué manera relacionar los elementos y cuáles son los errores que hacen que pierda su utilidad con el tiempo.
Cómo crear una CMDB y mapear toda tu infraestructura de IT
¿Qué es una CMDB?
Una CMDB es un repositorio centralizado que almacena información sobre los componentes que conforman el entorno de IT de una organización y las relaciones entre ellos. Estos componentes se denominan elementos de configuración (CIs - Configuration Items) e incluyen hardware, software, aplicaciones, servicios y otros ítems necesarios para prestar los servicios de IT.
¿Cómo crear una CMDB paso a paso?
Comenzar por un servicio crítico
La creación de una CMDB se hace de forma gradual mediante la priorización de los servicios críticos del negocio y aprovechando la información existente, como bases de datos técnicas, hojas de cálculo o inventarios ya consolidados.
Por eso, lo aconsejable es comenzar por un servicio crítico y mapearlo por completo. Aquí un ejemplo:
- Servicio esencial: servicio de facturación.
- Aplicación: ERP que interviene en el proceso de facturación.
- Servidores y bases de datos: físicos y virtuales, y las bases que alojan dicha aplicación.
- Infraestructura de red: switches, routers, firewalls y balanceadores de carga que conectan todo lo anterior.
- Nube y SaaS: si el ERP depende de servicios en la nube, como AWS o Azure, o SaaS.
- Endpoints: portátiles, ordenadores de sobremesa y dispositivos móviles, cuando son relevantes para el servicio crítico.
El objetivo no es incorporar todos los activos de la organización desde el primer día, sino construir una representación confiable de un servicio crítico y utilizarla como modelo para ampliar posteriormente la CMDB.
Documentar las dependencias
Una lista de activos sin conexiones entre sí constituye un inventario, no una CMDB. El valor real aparece cuando se documentan las dependencias de la base de datos de configuración: desde la aplicación que presta el servicio hasta la infraestructura que la sostiene. Ese primer mapeo sirve como plantilla: una vez validado el proceso, se repite con el siguiente servicio.
Para hacerlo, conviene apoyarse en una herramienta que sugiera automáticamente las relaciones entre los CIs a partir de los datos ya existentes (auto-mapping), en lugar de vincularlos manualmente. Esto resulta especialmente útil en la configuración inicial, después de cambios importantes en la infraestructura o como parte del mantenimiento continuo.
Las herramientas de Gestión de Configuración también pueden ayudar a automatizar el seguimiento y la actualización de los elementos de configuración.
Mantener la CMDB
Una CMDB que nadie mantiene pierde fiabilidad con el tiempo. Para evitarlo, hay que considerar lo siguiente:
- Asignar un responsable a cada CI y servicio del negocio: debe validar la información.
- Integrar la CMDB en los procesos diarios: las tareas cotidianas aportan los datos necesarios para mantener actualizada la base de datos de configuración. Así, por ejemplo, el service desk puede detectar y corregir atributos desactualizados durante la atención de los incidentes. Del mismo modo, la Gestión de Cambios establece la actualización de los CIs afectados como requisitos antes de cerrar una modificación técnica. Y la Gestión de Problemas utiliza la CMDB para analizar las causas raíz y los errores conocidos.
- Reducir el mantenimiento manual gracias al descubrimiento automático y a las reglas del auto-mapping.
También aquí el uso de una herramienta facilita el proceso de construcción inicial y mantenimiento posterior de una CMDB.
¿Cómo crear una CMDB con InvGate Asset Management?
Creación de un inventario
Como una CMDB se sustenta en información sobre los activos y demás CIs del entorno, el primer paso es disponer de un inventario. InvGate Asset Management permite agregar activos de forma rápida y sencilla de cinco maneras: manualmente, mediante la instalación de un agente, cargando un archivo CSV o XLS, a través de servicios en la nube o una API, o con la función de Discovery.
El método elegido dependerá de dónde se encuentren actualmente los datos de los activos, de si se prefiere que los dispositivos envíen información automáticamente y de cuál opción resulta más conveniente.
Construcción de una aplicación empresarial
En InvGate Asset Management, la aplicación empresarial es una entidad lógica que se utiliza para modelar y agrupar CIs relacionados que trabajan conjuntamente para proporcionar un servicio crítico para el negocio. Actúa como una capa de abstracción que proporciona visibilidad sobre las dependencias y los vínculos, ayudando a los equipos a comprender cómo los componentes de IT respaldan las operaciones centrales del negocio.
Para empezar, cliquear en el botón “Crear nuevo CI”, luego seleccionar la opción “Aplicación empresarial” y completar los siguientes campos:
- Nombre: debe ser fácil de identificar (por ejemplo, Active Directory, Data Center, CRM o Red de la oficina de Nueva York).
- Propietario: seleccionar al usuario responsable de la aplicación empresarial.
- Ubicación: elegir una de las localizaciones creadas previamente en la herramienta.
- Etiquetas: incluir todas las relevantes para la aplicación empresarial.
Hacer click en “Crear” y listo.
Organización de la visualización de la CMDB
La visualización de la CMDB en InvGate Asset Management se realiza mediante diagramas interactivos que representan las relaciones entre los elementos de configuración.
Estos diagramas se pueden crear manualmente desde la pestaña “Diagrama” y seleccionando “Agregar CIs”. Pero además InvGate Asset Management cuenta con capacidades de auto-mapping, que sugieren automáticamente las relaciones a partir de los datos existentes. Esto permite agilizar la creación de la CMDB, reducir el trabajo manual y mantener los diagramas alineados con el funcionamiento real del entorno.
Ejemplo: la ficha de un Elemento de Configuración, campo por campo
Para entender cómo se estructura un Elemento de Configuración, veamos un ejemplo concreto de un servidor que forma parte de la infraestructura de una aplicación crítica.
Algunos de los campos que pueden resultar relevantes en la ficha de un CI son:
-
Nombre/identificador: SRV-CRM-01.
-
Tipo: servidor.
-
Descripción: servidor que aloja componentes del CRM.
-
Propietario: equipo de Infraestructura.
-
Ubicación: centro de datos principal.
-
Estado: activo.
-
Modelo: según corresponda.
-
Fabricante/proveedor: Dell.
-
Detalles técnicos: sistema operativo, IP y otras características.
-
Relaciones: CRM-servidor-base de datos.
-
Dependencias: elementos en los que depende para ofrecer el servicio.
-
Información de soporte: datos para el mantenimiento.
-
Garantía: detalles si corresponden.
Cabe aclarar que no todos los CIs necesitan la misma cantidad de campos. La cantidad de información debe responder a los requerimientos de la organización y, sobre todo, a su capacidad para mantenerla actualizada.
Los cuatro errores que hacen que una CMDB se abandone
El abandono de una CMDB no suele deberse únicamente a la herramienta elegida, sino a un alcance mal definido, datos que pierden vigencia y procesos de mantenimiento poco claros.
Aquí, los errores más comunes que hacen que se abandone la CMDB:
1. Intentar inventariarlo todo desde el principio
- El error: incorporar todos los activos y servicios de la organización antes de haber definido qué información es realmente necesaria. Esto puede generar una CMDB demasiado grande, difícil de validar y costosa de mantener.
- Cómo evitarlo: comenzar por el servicio más crítico para el negocio y mapearlo de punta a punta como prueba piloto. Una vez validado, ampliar progresivamente el alcance.
2. Depender de la actualización manual de los datos
- El error: confiar en que los técnicos ingresarán o actualizarán manualmente cada cambio puede provocar que la información quede desactualizada con el tiempo.
- Cómo evitarlo: utilizar el descubrimiento automático e integraciones con las fuentes de información relevantes, así como el auto-mapping para sugerir relaciones. Además, vincular la CMDB a otros procesos de rutina.
3. No asignar un dueño a cada CI
- El error: si un CI no tiene un responsable claro, no existe nadie encargado de corregir la información incorrecta o actualizar su estado cuando cambia.
- Cómo evitarlo: asignar responsables. Si bien no necesariamente tendrá que introducir los datos manualmente, debe validarlo y constatar que quede corregido cuando alguien detecte un error. Complementariamente hay que establecer revisiones periódicas.
4. Tratar a la CMDB como un proyecto que termina
- El error: considerar que la implementación finaliza cuando se cargan los CIs y se crean las relaciones. Sin embargo, a partir de ese momento, los cambios en activos, aplicaciones e infraestructura pueden hacer que la información pierda vigencia.
- Cómo evitarlo: incorporar la actualización de la CMDB a los procesos habituales de IT.
CMDB vs. inventario: En qué se diferencian
Un inventario de activos registra que activos posee una organización, el lugar donde se encuentran y su estado. Su objetivo principal es proporcionar visibilidad y control sobre ellos y su ciclo de vida.
El inventario utilizado para la gestión de activos puede incluir hardware, dispositivos, software y licencias, junto con información como propietario, ubicación, estado y datos del ciclo de vida.
Una CMDB, que administra los CIs y sus relaciones, aporta contexto: muestra cómo funcionan los sistemas en conjunto y de qué manera los cambios o interrupciones en un componente pueden afectar a los demás.
En definitiva, una CMDB va un paso más allá: además de almacenar información sobre los elementos de configuración, modela las relaciones y dependencias entre ellos. De esta forma, permite entender cómo operan conjuntamente los distintos componentes de IT y analizar cómo un cambio, fallo o interrupción en un CI afecta a otros elementos y, en última instancia, a un servicio.
