Guía sobre bases de datos de gestión de la configuración (CMDB)

Características de una CMDB

Ya sabemos lo que hace una CMDB, cuál es su papel en la gestión de la configuración y en qué se relaciona y diferencia de la gestión de activos. Pero ¿cómo es la funcionalidad de una CMDB en un nivel más práctico?

Estas son las principales características funcionales de una CMDB:

Paneles con métricas y análisis de los elementos de configuración con los que es muy sencillo seguir el estado de dichos elementos, sus relaciones, el efecto de los cambios, los patrones que causan incidentes o problemas y el coste (en dinero y recursos) de crear y mantener cada servicio dentro de una organización.

Funciones de cumplimiento que proporcionan a los auditores registros detallados y visibilidad sobre el estado actual de los elementos de configuración, sus cambios históricos, controles y balances, incidentes, etc.

Creación de elementos de configuración y recopilación puntual de sus datos, a través de tres métodos diferentes: entrada manual, integraciones (basadas en API, SCCM) y herramientas de detección que llevan a cabo exploraciones automáticas de todas las direcciones IP de la red de una organización, para recopilar información de software y hardware de manera eficaz, y elaborar un inventario de todos los dispositivos físicos y virtuales de la empresa.

Compatibilidad para conjuntos de datos federados, incluidas la normalización y la conciliación de los elementos de configuración y sus datos.

Mapa de servicios de TI (habitualmente, un gráfico de relaciones y dependencias).

Controles de acceso que permiten conceder diferentes niveles de acceso a diferentes personas o equipos, según sea necesario, y rastrear los cambios hasta la fuente, en caso de que surjan preguntas o incidentes.

Ventajas de una CMDB

Los principales problemas para una CMDB son los datos en silos y la información obsoleta. Antes de implementar una CMDB, la mayoría de las organizaciones tienen datos dispersos en diferentes sistemas con diferentes propietarios. Esto dificulta tener una visión general de todos los elementos de configuración y sus interdependencias, lo que a su vez hace más difícil saber qué información está al día y cuál no.

Esto impide que los equipos tengan información de contexto importante a la hora de tomar decisiones, lo que puede afectar la evaluación de riesgos y la elaboración de informes, perjudicar la toma de decisiones, ralentizar la resolución de incidencias y, en última instancia, suponer costes para la empresa, tanto desde el punto de vista financiero como de su reputación.

Imagina, por ejemplo, que los datos del elemento de configuración A están alojados en un departamento y los del elemento de configuración B, en otro. El elemento B depende del A para funcionar correctamente. Sin embargo, cuando el departamento del elemento A decide desconectarlo para hacer un mantenimiento, no tiene visibilidad del impacto que está causando en el elemento B.

En el mejor de los casos, esto puede causar confusión entre los equipos. En el peor, puede dar lugar a un incidente grave. Y todo esto, cuando lo único que se necesitaría para evitar esta situación es una buena CMDB.

Forrester define tres aplicaciones en las que una CMDB es de vital importancia en la actualidad:

Planificación

Los gestores de tecnología necesitan datos de CMDB para planificar, tanto a un nivel general (con arquitectura empresarial y gestión de carteras) como a un nivel más detallado (con la gestión de activos y capacidades).

Contabilidad

El equipo de finanzas de TI necesita registros de aplicaciones o códigos de servicio para asignar extractos de facturación y gestionar adecuadamente las cuentas.

Operaciones

Una CMDB mejora una serie de prácticas básicas de ITSM, incluidas la gestión de los cambios, de incidentes y de problemas.

En lo que respecta a la gestión de los cambios, una CMDB puede mejorar la evaluación de riesgos, anticipando qué usuarios, sistemas y otros elementos de configuración podrían verse afectados. En las industrias reguladas, también puede contribuir al cumplimiento normativo, al ayudar a los equipos a gestionar los controles y proporcionar un registro de auditoría claro.

En la gestión de incidentes, una CMDB puede servir para identificar los cambios que ocasionaron un incidente y agilizar la resolución. Los registros de incidentes se pueden asociar con los elementos de configuración relevantes, lo que ayuda a los equipos a hacer un seguimiento de los incidentes a lo largo del tiempo, junto a los activos que afectan.

En la gestión de problemas, una CMDB puede ayudar con el análisis de la causa raíz, para que los equipos puedan dar con ella más rápidamente. También puede facilitar la gestión proactiva de problemas, al ayudar a los equipos a identificar activos que deben mejorarse para reducir los costes de servicio y los tiempos de inactividad no planificados.

En última instancia, una CMDB debería reducir la complejidad, prevenir errores, aumentar la seguridad y ayudar a que las prácticas de ITSM (como la gestión de incidentes y de los cambios) funcionen sin problemas.

Los desafíos de las CMDB

Las estadísticas de la industria señalan que solo el 25 % de las organizaciones obtienen un valor significativo de sus inversiones en CMDB. Este es un índice de error tan elevado que ha dado mala reputación a esta tecnología.

La buena noticia es que las razones del fracaso se pueden prevenir y habitualmente suelen estar dentro de seis categorías también predecibles:

Cultura

Como ocurre con cualquier elemento de una organización, la cultura y el compromiso de equipo son factores esenciales para el éxito de las nuevas tecnologías y procesos. En un estudio reciente de Harvard Business Review, el 93 % de los ejecutivos señalaba que los mayores retos para la transformación digital basada en datos son las personas y los procesos. Lo mismo cabe señalar en los proyectos de CMDB.

Relevancia

Las CMDB suelen considerarse la "única fuente de información", lo que a veces puede llevar a las organizaciones a hacer entrar con calzador todos sus datos en una, sin pensar en las aplicaciones que son relevantes para sus necesidades.

Como con cualquier repositorio de datos, una CMDB debe contener datos seleccionados y útiles que sirvan para respaldar procesos internos como la gestión de los cambios. Asegúrate de que tu CMDB tiene un objetivo de valor claramente definido, un responsable y una forma de actualizar los datos que refleje todos los cambios.

Centralización

Cuando decimos que una CMDB es un lugar centralizado para ver datos de activos, no significa que todos los datos de activos tengan que residir únicamente en ella. Este error habitual puede dar mucho trabajo a los equipos, que intentarán mover todos sus datos a esa "única fuente de información". Aquí, la práctica recomendada es, en realidad, federar datos de otras herramientas para que se use la herramienta más adecuada para respaldar cada aplicación.

Por ejemplo, suele ser más práctico mantener los datos financieros en una herramienta de gestión financiera de TI (ITFM) y la información de licencias de software, en una herramienta de gestión de activos de software (SAM). Los datos pueden importarse y reflejarse en la CMDB, aunque ese no sea su lugar de almacenamiento principal.

Precisión

Muchas organizaciones tienen dificultades para crear y mantener una CMDB precisa. Los problemas más habituales son la poca frecuencia con la que se ejecutan las herramientas de detección, la ausencia de reglas de automatización o la dependencia de la introducción manual de los datos. La respuesta habitual a estas dificultades es la detección basada en eventos, que potencia la detección tradicional de abajo arriba.

Si no estás familiarizado con esos términos, basta con saber que, en la detección de abajo arriba, los activos se asignan a partir de la infraestructura y se ramifican en elementos de configuración orientados al cliente. La detección basada en eventos se da cuando algo (un evento dentro de un sistema, un problema, etc.) hace que los sistemas se comuniquen. Luego, a partir de ese evento, el sistema asigna los elementos de configuración relacionados y traza sus conexiones.

No todos los elementos de configuración son detectables. Por ejemplo, puede que tu equipo quiera asignar monitores en la CMDB. Un sistema automatizado no puede detectar los monitores, por lo que habría que introducirlos manualmente a través de una hoja de cálculo (u otro método similar).

La clave para garantizar la exactitud de los datos es valerse de las ventajas de la detección de abajo arriba y de la detección basada en eventos, para obtener una imagen lo más clara posible de los activos y sus conexiones.

Procesos

En algunas organizaciones existe la idea de que las CMDB sirven para modelar la infraestructura y el software heredados, y no la nueva pila de infraestructura definida por software y nube, ni los flujos de trabajo modernos alojados allí.

No deberíamos dejar que un debate puramente semántico nos impida explorar el valor de llevar un seguimiento de nuestros elementos de configuración (heredados y modernos) en una herramienta que nos proporcione una visión general de nuestro ecosistema técnico.

Herramientas

Elegir la herramienta correcta es fundamental para no tener las cifras de error anteriores. Algunas herramientas de CMDB son poco más que repositorios de activos: estructuras de datos incrustadas en infraestructuras físicas heredadas y herramientas de detección con una respuesta lenta ante los cambios. Para que una CMDB sea realmente útil, debe tener en cuenta los nuevos tipos de activos y ser capaz de cambiar rápidamente.

Elegir qué se gestiona en la CMDB

No hay ninguna fórmula válida para todos los equipos que diga qué elementos de configuración hay que gestionar con una CMDB. Las aplicaciones y los objetivos de cada organización deben determinar el nivel de amplitud y de profundidad idóneo para tu CMDB particular. En la mayoría de los casos, lo práctico es comenzar con una solución general y con los servicios adecuados. Después, se irá ampliando o profundizando allí donde sea necesario para cumplir con los objetivos organizativos.

Dicho esto, los elementos de configuración pueden agruparse en dos grandes categorías generales: entidades técnicas y no técnicas.

Son "entidades técnicas" los servicios empresariales y técnicos, aplicaciones, software, bases de datos, contenedores, máquinas virtuales, sistemas operativos, hardware, redes, puertos, etc.

Tu CMDB también puede modelar entidades no técnicas si necesitas representar sus dependencias o influencias de otros activos en el mapa de servicios de TI. Pueden ser entidades no técnicas los usuarios, clientes, organizaciones, emplazamientos, acuerdos de servicio o documentos, entre otros.

Por último, al diseñar un modelo de CMDB se deben tener también en cuenta los servicios en la nube. Tanto los servicios SaaS (p. ej., aplicaciones de Google, Dropbox, Salesforce, etc.) como los servicios IaaS (p. ej., DigitalOcean, Linode, Rackspace o Amazon Web Services) pueden representarse como elementos de configuración en caso necesario.