Para partir debemos tener claro que es una CMDB. Quizás en muchas empresas y departamentos TI tienen una implementada pero no lo saben. CMDB es un término acuñado en ITIL, pero se utiliza desde mucho antes.

La CMDB (Configuration Management DataBase) o Base de datos de gestión de la configuración no es más ni menos que un repositorio de todos los elementos (ítem de configuración, CI), la relación que existe entre ellos, su historial y otros detalles no menores.

Partamos por lo básico. En una empresa que presta soporte remoto a servidores, debe haber algún lugar en el que se almacenen algunos datos básicos de acceso para cada servidor. En este caso, IP, nombre de usuario y contraseña. Además de esto, ya que la conexión es remota, se debe tener información sobre la VPN del cliente para acceder a su red interna. Los datos que se deben tener sobre esta VPN son similares, IP, nombre de usuario y contraseña, pero dependiendo del tipo de VPN, se podría necesitar software adicional y quizás algunos datos más. Como podrán ver, no es poca la información que se necesita para acceder a un solo servidor de forma remota. Ahora imaginen que toda esa información, se encuentra replicada en el computador de trabajo de cada agente que preste soporte a dicho servidor. También deben considerar que cada agente presta soporte a más de un cliente (y que cada cliente tiene al menos 3 servidores). ¿Pueden ver los problemas que se presentan en este escenario?

El primero es un tema muy grave. Seguridad. ¿Se imaginan alguien ajeno a la empresa de soporte logra tener acceso a la información de conexión de uno de los clientes? ¿Qué puede hacer con esa información? La CMDB es un lugar único para almacenar toda esta información, por lo que el riesgo disminuye considerablemente al tener menos puntos de falla (o fuga). Claramente por el hecho de tener una CMDB no aseguras una protección completa de toda esta información, dado que esta debe ser respaldada con políticas de seguridad, pero se disminuye el riesgo notablemente.

Ahora que tenemos claro como esto impacta en la seguridad de la información de nuestros clientes, vamos al siguiente problema. ¿Qué pasa si el cliente cambia la contraseña de la cuenta de acceso asignada al proveedor? En este escenario, cada agente tendrá que modificar la información que tiene almacenada en su computador. En los departamentos TI, las políticas de seguridad nos exigen que cambiemos las contraseñas cada cierto tiempo (esto varía en cada departamento). ¿Se imaginan a cada agente modificando la información sobre sus clientes a cada momento? ¿Qué pasa cuando un agente se ausentó por vacaciones o licencia médica o no tuvo acceso a la nueva información? ¿Quién es el responsable de comunicar la nueva contraseña? El cliente no puede enviar esta información a cada agente. Generalmente lo hace al responsable del servicio o a una persona designada como líder técnico del cliente. En estos casos es muy común que, tras un tiempo no muy considerable, cada agente tenga distintas credenciales para un mismo cliente. Si el cliente tiene un incidente en un servidor productivo en un horario en el que debe estar operando sin problemas, la conexión a dicho servidor tardará bastante más de lo esperado. Me ha tocado ver casos en los que el cliente termina resolviendo los problemas, ya que el proveedor no se pudo conectar por no tener las credenciales actualizadas. No creo que sea necesario que explique qué repercusiones puede traer esto, sobre todo si es algo repetitivo. Bueno, con la CMDB, esto se soluciona fácilmente. Generalmente hay un encargado de actualizar toda esta información por servidor o cliente (dependiendo del escenario). Lo bueno es que se actualiza en un solo lugar, y se puede ver el historial de cambios de dicho componente, por lo que puedes acceder a la fecha en la que se realizó el último cambio, y quien lo realizó.

En el mismo escenario, nos llega un correo informativo de que se encuentra disponible un parche de seguridad para el SO de algunos servidores, pero solo sirve para las versiones 1.0.1.2 ¿Cómo sabemos a qué clientes debemos recomendar dicho parche? En la CMDB se puede almacenar la versión del sistema operativo de cada componente de tipo servidor. Por lo que puedes detectar rápidamente que servidores tienen el sistema operativo la que se le debe aplicar el parche. Y no solo eso, puedes ver que software está instalado en el servidor para ver si es compatible con el parche a instalar. Todo en el mismo lugar. Esto facilita mucho el análisis de factibilidad de instalación.

Además de esto, si la CMDB se encuentra integrada con sistema de tickets (hoy en día hay muchas opciones pagadas o gratis), puedes ver el historial de requerimientos o incidentes sobre una máquina o servidor. Es como tener el historial médico de un paciente. Puedes saber de qué adolece, ver si tiene muchos incidentes repetitivos y generar gestión de problemas. Pero eso es para otra entrada.

Una buena CMBD puede almacenar muchos tipos de componentes; maquinas, servidores, máquinas virtuales, tarjetas de red, laptops, aparatos telefónicos, contactos, routers, y un gran etc. Todos esos componentes se pueden relacionar entre sí, lo que nos da una gran ventaja a la hora de realizar análisis y estadísticas, o de buscar información relevante sobre un componente. Como ejemplo daré uno muy simple. Puedo relacionar a un cliente a un servidor específico. En caso de que se requiera hacer algún cambio en ese servidor, puedo contactar directamente al responsable de tomar las decisiones en ese componente, y no pasar por una serie de escalamientos que podrían demorar las gestiones. Además, al conocer las relaciones, se puede ver qué impacto puede tener un cambio o un incidente sobre un componente, y los recursos que puedes llegar necesitar. Si un servidor de base de datos con middleware de la misma marca está relacionado a otro servidor con otra marca de base de datos, puedes ver claramente cuantos y que especialistas necesitas.

Espero se haya entendido cuales son las ventajas de tener una buena CMDB y bien actualizada. Destaqué solo algunas de sus ventajas, pero para mí, las más importantes.

No duden en hacer preguntas relacionadas a esta publicación.

Que tengan una buena semana.


POWER DESK Nicolás Fritsch N.
Gerente de Operaciones
POWER DESK
             
ITIL V.3 Foundation Certificate in IT Service Management

Jueves, 28 de Abril, 2016, Santiago, Chile.