La Configuration Manager Database (CMDB), es una base de datos dónde se encuentran todos los configuration ítems o elementos de configuración (CIs) de la infraestructura IT de la empresa detallados, ordenados, y lo más importante, relacionados.
Es decir, en la CMDB podremos encontrar los detalles de un CI concreto, por ejemplo, si es un servidor podremos ver sus características hardware y software, las incidencias o cambios que ha tenido a lo largo del tiempo, los contratos de mantenimiento asociados, los técnicos responsables, caducidad de certificados instalados, etc… pero también podremos consultar su relación con el resto de componentes de nuestra infraestructura, es decir, qué servicios hacen uso de él, si es de manera crítica o no, y qué otros componentes necesita el propio servidor para funcionar correctamente.
Todo lo anterior es indispensable para poder tener un mapa, dónde consultar información y generar caminos, que nos lleven por ejemplo a conectar 2 puntos en principio sin relación aparente. ¿Y a qué me refiero con lo anterior?
Pues a que la mayor parte de servicios IT, sobre todo sin son críticos poseen una relación entre sí, mucho mayor de lo que pensamos.
Por ejemplo, un fallo en un datastore puede afectar a los servidores virtuales contenidos en el mismo, a la propia gestión del entorno, y a sistemas secundarios como backups. Pero es que además cada máquina virtual tendrá unas relaciones a mayores, si se ve afectado el servidor virtual de DHCP, los equipos de los usuarios en la empresa no tendrán acceso a red, aunque este servicio a priori nada tiene que ver con un fallo de disco el Datastore. Podemos por tanto, encontrarnos un síntoma crítico: no hay acceso a la intranet ni internet, y el origen del problema nada tiene que ver con la red propiamente dicha.
Ante una situación crítica, uno puede encontrarse “perdido” y sin saber por dónde vienen los tiros, con decenas de sistemas remitiendo alertas que no sabes muy bien por dónde coger.
Para evitar estas situaciones, que normalmente conducen a un estado de estrés que no facilita salir de la situación de coyuntura, son importantes 2 actores:
- Un buen sistema de monitorización, que pueda darnos una visión concreta de lo que en un momento dado está fallando, y desde qué momento falla cada cosa para establecer un origen del caos. (en su momento hablamos por ejemplo de soluciones gratuitas como Centreon y Veeam One)
- Un mapa (la CMDB), que nos permita ver por qué un servicio aparentemente sin relación a otro falla.
El mantenimiento y actualización de la CMDB es fundamental, y una de las tareas obligatorias si decidimos certificarnos en normativas de calidad de servicio IT como ISO 20000.
Por otro lado, hay que tener en cuenta la realidad, el escenario típico incluso teniendo una CMDB actualizada, es que cuando aparece una catástrofe, todo depende de la figura del héroe sysadmin, es decir, el típico mañoso, que además conoce al dedillo todos los sistemas, porque durante el paso de los años los ha implantado directamente o ha participado activamente en levantarlos, y en el momento de caos total debe dar la cara, plingando como un campeón para restaurar los servicios en el menor tiempo posible, pille en fin de semana, festivo, noche o vacaciones.
Además en este sentido, la valoración de este personaje por parte de la empresa suele ser más bien poca, es decir, la perspectiva del empresario es la siguiente: un servicio informático cae, esto se traduce en pérdida de dinero, hay que levantarlo ya, y además que no se repita. Todas las demás circunstancias alrededor de la caída pasan a un segundo plano, y en este sentido hay una verdad absoluta, cualquier cosa se puede romper, puedes por ejemplo adquirir un modelo de coche de Toyota (normalmente líder en fiabilidad), pasar todas las revisiones en el concesionario oficial, hacer un mantenimiento más que correcto, y terminar sin embargo tirado en un puerto de montaña por un fallo mecánico.
En este escenario “real” y tan típico, hay varias consideraciones:
- La primera consideración es la necesidad de desarrollar un correcto plan de crisis, dónde es imprescindible disponer de una CMDB, que es el eje fundamental de este artículo, y dónde debe haber implicado más que un solo actor. ¿Qué ocurre si el héroe sysadmin está de baja o no puede por otro tipo de circunstancias resolver el marrón? La CMDB es el mapa, pero se necesita personal que sepa consultarlo.
- La segunda es la valoración del sysadmin que actúa como héroe o plingado según se mire. Un trabajador que es crítico en una empresa, pero a la vez poco valorado, puede llegar a traducirse en un problema, ya sea porque deje la empresa por otras oportunidades, lo que se traduce en que la empresa pierde un activo difícil de suplir percatandose tarde de lo que tenía, o provoca un desánimo en el desarrollo del trabajo por parte de éste actor, lo cual se traduce en productividad.
Por último creo interesante hacer mención a GLPI, una herramienta de la que hablamos anteriormente: https://ciberseguridadtotal.com/glpi-herramienta-imprescindible-en-todo-entorno-it/ y que nos puede ayudar a generar y mantener una CMDB con miles de opciones avanzadas. Esta herramienta no obstante puede y debe complementarse con otras, más adecuadas a albergar procedimientos complejos o gestionar proyectos, ya sea tipo MediaWiki, Redmine o simplemente documentación ofimática en repositorio compartido por parte del equipo IT.
Como última reflexión, una pregunta sobre la que reflexionar:
¿Disponéis de una CMDB? ¿Creéis posible resolver una caída crítica sin ella?
