CMDB minima viable: empezar con 5 tipos de CI, no con un inventario exhaustivo

La CMDB es una de esas iniciativas que se arranca con entusiasmo y muere en el mes 8 cuando nadie tiene tiempo de mantener el inventario exhaustivo prometido. La version viable es distinta: empezar chico y crecer con disciplina.

Por que fallan las CMDBs ambiciosas

Un proyecto tipico de CMDB arranca con la promesa de modelar todo: servidores, aplicaciones, bases de datos, redes, servicios, contratos, licencias, usuarios, ubicaciones. Al mes 3 el alcance es enorme, al mes 6 la data esta desactualizada, al mes 12 el equipo reconoce que la CMDB miente mas de lo que ayuda.

Las causas:

• Alcance muy grande sin priorizacion
• Sin proceso de mantenimiento claro
• Sin integracion con fuentes de verdad existentes
• Sin consumidor real de la data

Una CMDB sin consumidor es documentacion; sin actualizacion es mentira.

Los 5 tipos de CI para empezar

La version minima viable para una empresa mediana:

1. Servicios de negocio. Lo que ve el cliente/empleado. Ejemplo: "Sistema de facturacion", "Portal de clientes", "ERP".

Campos minimos: nombre, duenno de negocio, duenno tecnico, criticidad, horario de operacion.

2. Aplicaciones. Los sistemas de software que soportan los servicios. Ejemplo: "SAP", "Salesforce", "Freshdesk".

Campos: nombre, version mayor, proveedor, contrato de soporte, ambiente (prod/staging), duenno tecnico.

3. Servidores / Infraestructura. Donde corren las aplicaciones. Fisicos, virtuales o cloud.

Campos: nombre, tipo (VM, bare metal, cloud), ubicacion o cloud provider, sistema operativo, ambiente.

4. Bases de datos. Donde vive la data critica.

Campos: nombre, motor, version mayor, servidor donde corre, frecuencia de backup, RTO/RPO definido.

5. Integraciones externas. Los servicios cloud de terceros criticos.

Campos: nombre del proveedor, servicio, responsable interno de la cuenta, contrato renovacion, criticidad.

Con estos 5 tipos cubres el 80% de escenarios de impacto en incidentes, cambios y planeacion.

Relaciones minimas

No modelar todas las relaciones posibles. Solo las que se consumen:

• Servicio de negocio --depende de--> Aplicacion
• Aplicacion --corre en--> Servidor
• Aplicacion --usa--> Base de datos
• Aplicacion --se integra con--> Integracion externa

Con estas 4 relaciones, cuando cae un servidor puedes saber que aplicaciones afecta y que servicios de negocio se impactan.

Lo que dejar fuera al inicio

Tentacion clasica de incluir todo esto el dia 1:

• Cada licencia individual de software
• Cada sitio/ubicacion fisica
• Cada contrato con su renovacion
• Redes, firewalls, switches individuales
• Cada estacion de trabajo
• Cada usuario con sus accesos

Esto puede venir despues, cuando haya un consumidor real de la data. Si no hay un proceso que use "cuantas licencias de Office tenemos por ubicacion" cada mes, no se modela.

Fuente de verdad e integracion

La CMDB no debe ser la fuente original de la data. Debe alimentarse de sistemas donde la data ya vive:

• Servidores cloud: API de AWS/Azure/GCP
• VMs on-premise: vCenter o similar
• Aplicaciones SaaS: CSV periodico manual al inicio, API despues
• Servicios de negocio: mantenimiento manual (no hay fuente automatica)

Freshservice tiene conectores nativos para varios de estos. Configurarlos el mes 1 ahorra meses de mantenimiento manual.

Proceso de mantenimiento

Sin proceso, muere. Con proceso simple, vive.

Mensual:

• Discovery automatico corre y detecta drift
• Owner de cada tipo de CI revisa cambios sospechosos
• Nuevos CIs se aprueban o rechazan

Trimestral:

• Revision de servicios de negocio con los duenos (el unico tipo sin discovery)
• Limpieza de CIs retirados
• Reporte de salud de CMDB (% de CIs con data completa, % actualizado en los ultimos 90 dias)

Anual:

• Revision de alcance: agregar un tipo nuevo si hay consumidor claro
• Retiro de campos que nadie consulta

Casos de uso que justifican la CMDB

La CMDB se justifica cuando la usas para:

• Analisis de impacto en cambios. "Si reinicio el servidor X, que aplicaciones afecta, que servicios de negocio, a quien notifico?"
• Investigacion de incidentes. "Este error se origina en la BD Y. Que aplicaciones la usan?"
• Planeacion de mantenimientos. "Que ventanas afectan a servicios criticos?"
• Continuidad de negocio. "Cuales son los 10 servicios criticos y su dependencia tecnica?"

Si no usas la CMDB para nada de esto, o arrancas a usarla o cancela el proyecto. Pero no la mantengas por inercia.

Crecimiento disciplinado

De 5 tipos de CI bien mantenidos puedes crecer a 8-10 en el ano 2 si cada nuevo tipo cumple:

• Tiene consumidor claro y documentado
• Tiene fuente de verdad definida (automatica o manual con responsable)
• Tiene campos minimos necesarios, no exhaustivos
• Tiene proceso de revision

Una CMDB con 10 tipos bien mantenidos vale mas que una con 40 tipos desactualizados. El criterio de exito no es cuanto modelas; es cuanto usa la organizacion para tomar decisiones.