CMDB na prática: exemplos de CIs, como estruturar e boas práticas
Autor: Pedro Tebaldi PM do KeepGreenGerenciar a infraestrutura de TI sem saber o que existe, onde está e do que depende é como navegar sem mapa. Mudanças viram roleta-russa, incidentes começam sempre do zero e auditorias consomem dias de levantamento manual.
O CMDB (Configuration Management Database) é o repositório que resolve isso: ele registra os Itens de Configuração (CIs) da operação e, principalmente, os relacionamentos entre eles. É o que permite responder, antes de aplicar um patch, quais serviços vão sentir o impacto.
Este guia é prático. Começa pelos exemplos de CIs que entram em um CMDB real, segue pela estrutura de dados, pelo passo a passo de implantação e pelas boas práticas de governança que mantêm a base viva. A diferença para o ITAM, os processos ITIL e a definição formal vêm depois.
Exemplos de CIs: o que realmente entra no CMDB
A primeira pergunta prática de qualquer implantação não é conceitual, é de escopo: o que catalogar? O erro clássico é tentar registrar tudo. Um CMDB inchado envelhece mais rápido do que o time consegue atualizar e perde credibilidade na primeira consulta errada.
A tabela abaixo reúne as categorias de CI que aparecem na maioria dos ambientes corporativos, com os atributos que costumam ser obrigatórios e o tipo de relacionamento que cada uma sustenta. Use-a como ponto de partida e corte o que não se aplica ao seu ambiente.
| Categoria | Exemplos de CI | Atributos essenciais | Relacionamento típico |
|---|---|---|---|
| Servidores físicos | Host de virtualização, servidor de aplicação, appliance | hostname, IP de gerência, modelo, datacenter, criticidade |
Hospeda máquinas virtuais e aplicações |
| Máquinas virtuais e containers | VM, pod, container, cluster | Imagem, recursos alocados, cluster, ambiente | Executa sobre um host; sustenta uma aplicação |
| Rede | Switch, roteador, firewall, link WAN | IP de gerência, VLAN, portas, fabricante |
Conecta servidores e habilita o serviço |
| Armazenamento | Storage, LUN, volume, rotina de backup | Capacidade, tipo de disco, política de retenção | Sustenta bancos de dados e VMs |
| Aplicações | ERP, CRM, portal, API interna | Versão, responsável técnico, ambiente, linguagem | Usa bancos de dados; compõe serviço de negócio |
| Bancos de dados | Instância, schema, réplica | Engine, versão, porta, janela de manutenção | Depende de storage; suporta aplicação |
| Serviços de negócio | Emissão de NF-e, e-commerce, folha de pagamento | SLA acordado, horário de operação, usuários impactados | Composto pelos CIs de aplicação e infraestrutura |
| Software e licenças | Licença, subscrição, contrato de suporte | Quantidade, validade, fornecedor, centro de custo | Instalado em um CI; é a ponte com o ITAM |
| Certificados e domínios | Certificado TLS, domínio, zona DNS | Validade, emissor, algoritmo | Protege a aplicação exposta |
| Documentação | Runbook, diagrama de arquitetura, contrato | Versão, responsável, data da última revisão | Descreve um CI ou um serviço |
A regra de corte é simples: um item merece virar CI se alguém precisaria dele durante um incidente, uma mudança ou uma auditoria. Se ninguém consultaria aquele registro nessas três situações, ele é inventário — e o lugar dele é no ITAM, não no CMDB.
Estrutura técnica do CMDB: CIs e relacionamentos
A arquitetura de um CMDB gira em torno de dois conceitos fundamentais.
Configuration Items (CIs)
Os CIs são os elementos gerenciados no CMDB. Eles são classificados por tipo — hardware, software, serviço, documento — e cada um possui um conjunto de atributos que o descreve: hostname, endereço IP, sistema operacional, versão, responsável técnico, criticidade para o negócio.
Relacionamentos entre CIs
O diferencial do CMDB em relação a uma simples planilha de inventário são os relacionamentos. Um servidor hospeda uma aplicação. Uma aplicação usa um banco de dados. Um banco de dados depende de um storage. Esses vínculos permitem análise de impacto: se um componente falhar, quais serviços serão afetados? Quais usuários serão impactados?
Essa capacidade de análise de impacto é essencial para o gerenciamento de mudanças. Antes de aplicar um patch em um servidor, o time consulta o CMDB e visualiza todos os serviços dependentes, reduzindo o risco de interrupções não planejadas.
Como implementar um CMDB: guia prático
A implementação de um CMDB bem-sucedida segue uma progressão lógica.
O primeiro passo é definir o escopo: não tente catalogar tudo de uma vez. Comece pelos CIs mais críticos — os que suportam serviços com SLA definido. Expanda gradualmente.
O segundo passo é estabelecer o modelo de dados: defina os tipos de CI que serão gerenciados, seus atributos obrigatórios e os tipos de relacionamento relevantes para o seu ambiente.
O terceiro é automatizar a descoberta: ferramentas de auto-discovery reduzem drasticamente o esforço de manutenção. A descoberta manual em ambientes grandes garante uma base desatualizada em semanas.
O quarto é integrar com os processos ITIL: o CMDB só entrega valor pleno quando os analistas o consultam e atualizam como parte natural do fluxo de trabalho de incidentes e mudanças. Sem adoção operacional, vira um inventário caro e estático.
O quinto é definir governança e ciclo de auditoria: estabeleça responsáveis pela acurácia dos CIs por categoria, implemente revisões periódicas e meça a taxa de acurácia do CMDB como KPI operacional.
Boas práticas e governança do CMDB
A implantação é a parte fácil. O que decide se o CMDB continua útil no segundo ano é a governança — o conjunto de regras que define quem responde pela qualidade de cada registro e como a base é verificada.
Atribua um dono por categoria de CI. Sem responsável nominal, a acurácia vira responsabilidade difusa e ninguém a mantém. Cada categoria da tabela acima deve ter um time dono, com autoridade para aprovar ou rejeitar mudanças de atributo.
Meça a acurácia em vez de presumi-la. Auditorias amostrais periódicas — sortear um conjunto de CIs e conferir contra a realidade — dão um percentual acompanhável ao longo do tempo. Uma base que ninguém audita é uma base que o time deixa de consultar assim que erra duas vezes seguidas.
Automatize a descoberta e trate a entrada manual como exceção. Auto-discovery detecta CIs novos, mudanças de atributo e itens que sumiram do ambiente. Registro manual só se justifica para o que nenhuma ferramenta enxerga, como contratos e documentação.
Comece pequeno e expanda por serviço. Um escopo mínimo bem mantido vale mais que um catálogo completo e desatualizado. Cubra primeiro os serviços com SLA acordado e só então avance para o resto do ambiente.
Feche o ciclo de vida. Tão importante quanto registrar um CI novo é retirar o que foi desativado. CIs órfãos distorcem a análise de impacto e inflam o custo aparente do ambiente — é o tipo de sujeira que faz o time desconfiar da base inteira.
Exija a consulta dentro do fluxo. O CMDB só se paga quando consultá-lo é parte natural do atendimento de um incidente e da avaliação de uma mudança. Se a consulta for opcional, a base deixa de ser atualizada e vira um inventário caro.
CMDB vs Gerenciamento de Ativos de TI: qual a diferença?
Esta é a confusão mais frequente no tema. Os dois conceitos são complementares, mas respondem a perguntas diferentes.
Gerenciamento de Ativos de TI (ITAM)
O ITAM (IT Asset Management) foca no ciclo de vida financeiro e de compliance dos ativos: o que foi comprado, quando, por quanto, quando expira a licença, quando precisa ser substituído. Sua perspectiva é financeira e de governança.
CMDB
O CMDB foca no contexto operacional: como os CIs se relacionam, quais serviços eles suportam e qual o impacto de uma mudança ou falha em um deles. Sua perspectiva é técnica e de serviço.
A regra prática: o ITAM diz “temos 50 servidores, cada um custou R$30.000 e o contrato expira em 2027”. O CMDB diz “este servidor suporta a aplicação de CRM, que tem SLA de 99,9% e afeta 800 usuários”. As duas perspectivas juntas formam uma visão completa de gestão de ativos corporativa.
CMDB e os processos ITIL
O CMDB não é um silo isolado: ele alimenta e é alimentado por todos os processos ITSM.
No gerenciamento de incidentes, o analista consulta o CMDB para entender o contexto do CI afetado, identificar dependências e acelerar o diagnóstico. No gerenciamento de mudanças, o CMDB fornece análise de impacto para avaliar o risco de cada Change Request. No gerenciamento de problemas, ele revela padrões de CIs problemáticos que geram incidentes recorrentes. No contexto do SRE, o CMDB alimenta ferramentas de observabilidade com contexto de negócio, permitindo correlacionar alertas técnicos com impacto em serviços específicos.
Ferramentas de CMDB em 2026
A escolha da ferramenta depende do tamanho do ambiente e do nível de integração com ITSM.
Para ambientes corporativos de grande escala, o ServiceNow CMDB é referência de mercado, com descoberta automática de CIs, mapeamento de serviços e integração nativa com todos os módulos ITSM. Para organizações que buscam uma solução open source, o GLPI com o plugin de CMDB oferece capacidade robusta sem custo de licença. O iTop é outra alternativa open source com modelo de dados flexível. O Device42 se destaca em ambientes híbridos (on-premises + cloud), com descoberta automática e mapeamento de dependências. Para times menores com necessidades mais simples, a integração entre o Zabbix e ferramentas de ITSM pode entregar a maior parte dos benefícios de um CMDB sem complexidade adicional.
CMDB e monitoramento: a integração que fecha o ciclo
A maior evolução do CMDB nos últimos anos é a integração com plataformas de monitoramento de TI. Plataformas modernas como o Zabbix e soluções de AIOps enriquecem os CIs do CMDB automaticamente com dados de desempenho em tempo real.
Isso cria o que chamamos de CMDB dinâmico: em vez de uma base de dados estática que envelhece rapidamente, a integração com monitoramento garante que atributos como versão de software, estado do serviço e métricas de capacidade se mantenham atualizados automaticamente.
Essa integração é especialmente valiosa para ambientes de monitoramento em cloud, onde instâncias sobem e descem dinamicamente e o inventário muda continuamente.
O que é CMDB?
CMDB — Configuration Management Database — é um banco de dados que armazena informações sobre todos os Itens de Configuração (CIs — Configuration Items) de uma organização, incluindo seus atributos e os relacionamentos entre eles.
Na definição do ITIL 4, o CMDB é parte da prática de Gerenciamento de Configuração de Serviços (SACM). Seu objetivo é fornecer uma visão precisa e atualizada da infraestrutura para dar suporte a todos os demais processos ITIL: incidentes, mudanças, problemas, capacidade e continuidade.
Um CI pode ser qualquer elemento que contribui para a entrega de um serviço de TI: servidores físicos, máquinas virtuais, aplicações, bancos de dados, roteadores, contratos de software, certificados SSL ou até mesmo documentação crítica. O que torna o CMDB poderoso não é o inventário em si, mas a modelagem dos relacionamentos entre os CIs — permitindo saber, por exemplo, qual banco de dados suporta qual aplicação, que roda em qual servidor.
Conclusão
O CMDB é a espinha dorsal do ITSM moderno. Sem ele, cada incidente começa com um diagnóstico do zero, cada mudança é um risco não calculado e cada auditoria exige horas de levantamento manual. Com ele, a TI opera com visibilidade real sobre o que existe, como funciona e o que impacta o negócio.
Implementar um CMDB exige disciplina, mas os ganhos são imediatos em qualidade de resposta a incidentes e segurança no gerenciamento de mudanças. Se você quer estruturar o CMDB da sua operação com integração a monitoramento e ITSM, fale com nossos especialistas.
Perguntas Frequentes
O que é CMDB em TI?
Qual a diferença entre CMDB e gerenciamento de ativos?
Quais são as principais ferramentas de CMDB?
Como manter um CMDB atualizado?
