CMDB na prática: exemplos de CIs, como estruturar e boas práticas

Autor: Pedro Tebaldi PM do KeepGreen

Publicado ago/2019Atualizado set/2026

Gerenciar a infraestrutura de TI sem saber o que existe, onde está e do que depende é como navegar sem mapa. Como resultado, mudanças viram roleta-russa, incidentes começam do zero e auditorias consomem dias de levantamento manual.

O CMDB (Configuration Management Database) é o repositório que resolve isso. Nele ficam os Itens de Configuração (CIs) da operação e, principalmente, os relacionamentos entre eles. Assim, dá para responder antes de aplicar um patch: quais serviços vão sentir o impacto?

Este guia é prático. Ele começa pelos exemplos de CIs que entram em um CMDB real. Em seguida, passa pela estrutura de dados, pelo passo a passo de implantação e pelas boas práticas que mantêm a base viva. No final das contas, vêm a diferença para o ITAM, os processos ITIL e a definição formal.

Exemplos de CIs: o que realmente entra no CMDB

Toda implantação começa por uma pergunta de escopo, não conceitual: o que catalogar? O erro clássico é tentar registrar tudo. Um CMDB inchado, por exemplo, envelhece mais rápido do que o time atualiza e perde credibilidade na primeira consulta errada.

A tabela abaixo reúne as categorias de CI que aparecem na maioria dos ambientes corporativos. Para cada uma, ela traz os atributos que costumam ser obrigatórios e o tipo de relacionamento que sustenta. Portanto, use-a como ponto de partida e corte o que não se aplica ao seu ambiente.

A regra de corte é simples: um item merece virar CI se alguém precisaria dele durante um incidente, uma mudança ou uma auditoria. Ou seja, se ninguém consultaria aquele registro nessas três situações, ele é inventário: o lugar dele é no ITAM, não no CMDB.

Estrutura técnica do CMDB: CIs e relacionamentos

Dois conceitos sustentam a arquitetura de um CMDB.

Configuration Items (CIs)

Os CIs são os elementos gerenciados no CMDB. Eles se classificam por tipo: hardware, software, serviço ou documento. Além disso, cada um carrega atributos que o descrevem, como hostname, endereço IP, sistema operacional, versão, responsável técnico e criticidade.

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. Logo, os 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 pesa direto no gerenciamento de mudanças. Antes de aplicar um patch, o time consulta o CMDB e vê todos os serviços dependentes. Como resultado, reduz o risco de interrupção não planejada.

Análise de impacto: a pergunta que o inventário não responde

Para medir quanto isso vale, montamos um CMDB de laboratório no GLPI 11.0.8, em 3 de setembro de 2026. Ele tem 17 CIs e três serviços de negócio. A tela abaixo é a aba de análise de impacto do switch de núcleo, sem nenhum plugin instalado.

 
As setas vermelhas apontam o que o switch derruba; a azul mostra de quem ele depende. A cadeia sai do equipamento de rede, passa pelo banco e pela aplicação. Na ponta dela estão três serviços que a área de negócio reconhece pelo nome.

Em seguida veio a pergunta que só o relacionamento responde. A consulta abaixo percorre o grafo inteiro e mede, para cada equipamento de rede, o tamanho real do estrago.

-- Percorre o grafo de impacto do GLPI e conta, por equipamento de rede,
-- quantos servicos de negocio param e quantos ativos sao afetados.
WITH RECURSIVE alcance AS (
  SELECT ne.id AS raiz_id, ne.name AS raiz,
         r.itemtype_impacted AS tipo, r.items_id_impacted AS id, 1 AS salto
    FROM glpi_impactrelations r
    JOIN glpi_networkequipments ne ON ne.id = r.items_id_source
   WHERE r.itemtype_source = 'NetworkEquipment' AND ne.is_deleted = 0
  UNION
  SELECT a.raiz_id, a.raiz, r.itemtype_impacted, r.items_id_impacted, a.salto + 1
    FROM glpi_impactrelations r
    JOIN alcance a ON r.itemtype_source = a.tipo AND r.items_id_source = a.id
   WHERE a.salto < 10
)
SELECT a.raiz AS equipamento,
       COUNT(DISTINCT CASE WHEN a.tipo =  'Appliance' THEN a.id END) AS servicos_parados,
       COUNT(DISTINCT CASE WHEN a.tipo <> 'Appliance' THEN CONCAT(a.tipo, a.id) END) AS ativos_afetados
  FROM alcance a
 GROUP BY a.raiz_id, a.raiz
 ORDER BY servicos_parados DESC, ativos_afetados DESC;

No laboratório, o resultado foi este:

+--------------+------------------+-----------------+
| equipamento  | servicos_parados | ativos_afetados |
+--------------+------------------+-----------------+
| FW-BORDA-01  |                3 |               4 |
| SW-CORE-01   |                3 |               3 |
| SW-ACESSO-3A |                0 |               4 |
+--------------+------------------+-----------------+

Repare no switch de acesso. Ele afeta quatro ativos, um a mais que o de núcleo. Ainda assim, não derruba serviço nenhum: só alcança estações de trabalho.

Portanto, quem prioriza manutenção por quantidade de ativos coloca o equipamento errado no topo da fila. É essa inversão que o relacionamento corrige. Nenhuma planilha de inventário enxerga isso sozinha.

Como implementar um CMDB: guia prático

Uma implantação de CMDB que dá certo 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, ou seja, os que suportam serviços com SLA definido. A partir daí, expanda aos poucos.

Em seguida vem o modelo de dados. Defina os tipos de CI que serão gerenciados, seus atributos obrigatórios e os relacionamentos relevantes para o seu ambiente.

O terceiro passo é automatizar a descoberta: o auto-discovery corta o esforço de manutenção. Por outro lado, a descoberta manual em ambiente grande garante uma base desatualizada em semanas.

Depois disso, é hora de integrar com os processos ITIL. O CMDB só entrega valor quando os analistas o consultam e atualizam dentro do fluxo de incidentes e mudanças. Sem adoção operacional, vira um inventário caro e estático.

Por fim, defina governança e ciclo de auditoria. Estabeleça responsáveis pela acurácia por categoria de CI, implemente revisões periódicas e acompanhe a taxa de acurácia como KPI.

Boas práticas e governança do CMDB

A implantação é a parte fácil. No entanto, o que decide se o CMDB segue útil no segundo ano é a governança. São as regras que definem quem responde pela qualidade de cada registro e como a base é conferida.

Atribua um dono por categoria de CI. Sem responsável nominal, a acurácia vira responsabilidade difusa e ninguém a mantém. Portanto, cada categoria da tabela acima precisa de 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 dão um percentual que dá para acompanhar: sorteie um conjunto de CIs e confira contra a realidade. Em contrapartida, a base que ninguém audita é a que o time abandona assim que erra duas vezes seguidas.

Automatize a descoberta e trate a entrada manual como exceção. O auto-discovery detecta CIs novos, mudanças de atributo e itens que sumiram do ambiente. Por isso, o registro manual fica só 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 inteiro e desatualizado. Assim, cubra primeiro os serviços com SLA acordado e só depois 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. Além disso, são o tipo de sujeira que faz o time desconfiar da base inteira.

Como achar os CIs órfãos antes que a auditoria ache

O ServiceNow organiza a saúde do CMDB em três medidas: completude, correção e conformidade. A correção é a que pega o órfão. Vale dizer que ela não depende de ferramenta: qualquer CMDB responde a isso com uma consulta.

No mesmo laboratório do GLPI 11.0.8, a consulta abaixo procura computadores cadastrados que não aparecem em nenhuma ponta de relacionamento.

-- CIs que nao participam de nenhum relacionamento: nem impactam,
-- nem sao impactados. Invisiveis para a analise de impacto.
SELECT c.name AS ci,
       CASE WHEN c.is_dynamic = 1 THEN 'auto-discovery' ELSE 'manual' END AS origem,
       DATEDIFF(NOW(), c.date_mod) AS dias_sem_revisao
  FROM glpi_computers c
 WHERE c.is_deleted = 0
   AND NOT EXISTS (
       SELECT 1 FROM glpi_impactrelations r
        WHERE (r.itemtype_source   = 'Computer' AND r.items_id_source   = c.id)
           OR (r.itemtype_impacted = 'Computer' AND r.items_id_impacted = c.id))
 ORDER BY dias_sem_revisao DESC;

O ambiente tinha 11 computadores. Quatro voltaram na lista:

+-------------------+----------------+------------------+
| ci                | origem         | dias_sem_revisao |
+-------------------+----------------+------------------+
| NB-COM-027        | manual         |               16 |
| NB-DIR-001        | manual         |               16 |
| NB-MIG-014        | auto-discovery |                8 |
| SRV-INVENTARIO-01 | auto-discovery |                1 |
+-------------------+----------------+------------------+

A mesma consulta nos dispositivos de rede trouxe outros três. Ou seja, 7 dos 17 CIs cadastrados não participam de cadeia nenhuma, incluindo dois que o auto-discovery criou sozinho e ninguém amarrou depois.

Esse é o número que vale acompanhar mês a mês. Um CI órfão nunca aparece numa análise de impacto, logo não protege ninguém no dia do incidente. A coluna de dias sem revisão diz por onde começar a limpeza.

Exija a consulta dentro do fluxo. O CMDB só se paga quando consultá-lo faz parte do atendimento de um incidente e da avaliação de uma mudança. Caso contrário, a base para 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. Ele responde o que foi comprado, quando, por quanto, quando expira a licença e quando trocar. Nesse sentido, a perspectiva é financeira e de governança.

CMDB

Já o CMDB foca no contexto operacional: como os CIs se relacionam e quais serviços eles suportam. Ele também diz qual o impacto de uma mudança ou falha em cada um. A perspectiva, portanto, é técnica e de serviço.

Na 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”. Em suma, juntas elas formam a visão de gestão de ativos corporativa.

CMDB e os processos ITIL

O CMDB não é um silo isolado. Ao mesmo tempo, 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, achar dependências e acelerar o diagnóstico. Já no gerenciamento de mudanças, ele fornece a análise de impacto que mede o risco de cada Change Request.

No gerenciamento de problemas, o CMDB revela padrões de CIs que geram incidentes recorrentes. No SRE, ele alimenta a observabilidade com contexto de negócio. Dessa forma, o time correlaciona alerta técnico com impacto em serviço específico.

Ferramentas de CMDB em 2026

A escolha da ferramenta depende, sobretudo, do tamanho do ambiente e do nível de integração com ITSM.

Para ambientes corporativos de grande escala, o ServiceNow CMDB é a referência de mercado. Além disso, ele traz descoberta automática de CIs, mapeamento de serviços e integração nativa com os módulos ITSM.

Para quem busca open source, o GLPI traz o CMDB no próprio núcleo. A aba de análise de impacto existe desde a versão 9.5 e não depende de plugin, como detalha a documentação oficial.

O iTop é outra alternativa open source, com modelo de dados flexível. Já o Device42 se destaca em ambientes híbridos, com descoberta automática e mapeamento de dependências. Em contrapartida, para times menores, a integração entre Zabbix e GLPI entrega boa parte desse benefício com bem menos esforço de modelagem.

CMDB e monitoramento: a integração que fecha o ciclo

Nos últimos anos, a maior evolução do CMDB foi a integração com plataformas de monitoramento de TI. Ferramentas como o Zabbix e soluções de AIOps enriquecem os CIs com dados de desempenho em tempo real.

Isso cria o que chamamos de CMDB dinâmico. Em vez de uma base estática que envelhece rápido, a integração com o monitoramento mantém os atributos em dia sozinha. A saber: versão de software, estado do serviço e métricas de capacidade.

Em ambientes de monitoramento em cloud, essa integração vale ainda mais: instâncias sobem e descem o tempo todo, enquanto o inventário muda sem parar.

O que é CMDB?

CMDB, ou Configuration Management Database, é o banco de dados que guarda todos os Itens de Configuração (CIs) de uma organização. Ele registra os atributos de cada item e, principalmente, os relacionamentos entre eles.

No ITIL 4, o CMDB pertence à prática de Gerenciamento de Configuração de Serviço. O nome mudou por um motivo: a sigla SACM é da versão 3, que tratava configuração e ativos como uma coisa só.

Já a versão 4 separou as duas em práticas distintas, uma de configuração e outra de gestão de ativos. O objetivo do CMDB seguiu o mesmo: dar uma visão atualizada da infraestrutura para incidentes, mudanças, problemas, capacidade e continuidade.

Um CI pode ser qualquer elemento que contribui para a entrega de um serviço de TI. Por exemplo: servidores físicos, máquinas virtuais, aplicações, bancos de dados, roteadores, contratos de software, certificados SSL ou documentação crítica.

O que dá força ao CMDB não é o inventário em si, mas a modelagem dos relacionamentos. É ela que permite saber qual banco de dados suporta qual aplicação e em qual servidor essa aplicação roda.

Conclusão

Em resumo, o CMDB é a espinha dorsal do ITSM moderno. Sem ele, cada incidente começa do zero, cada mudança é um risco não calculado e cada auditoria exige horas de levantamento manual. Com ele, a TI enxerga 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.