Um inventário responde "o que é que tenho". Uma CMDB responde "o que é que cai em conjunto quando isto falhar". A ponte entre os dois no GLPI não é o separador Ligações, como muitos assumem - é a análise de impacto, e é exatamente aí que a maioria dos projetos de CMDB encalha. Este guia mostra os quatro mecanismos de relação que o GLPI oferece, qual usar em cada caso, e as consultas que executamos na manutenção para encontrar a CMDB cega.
Inventário vs CMDB: a diferença que muda a resposta a incidentes
O inventário é um registo: marca, modelo, número de série, garantia, responsável. É controlo patrimonial e é por aí que toda a gente começa - com o inventário automático do GLPI Agent, povoa centenas de ativos em dias. A CMDB é o que vem a seguir: a camada de relação que responde à pergunta que importa a meio de um incidente - se este switch cair, que servidores, serviços e utilizadores param com ele?
| Aspeto | Inventário | CMDB |
|---|---|---|
| Pergunta que responde | O que é que tenho? | O que depende de quê? |
| Unidade | Ativo (item) | Relação entre CIs |
| Como se povoa | Automático (GLPI Agent) | Manual, uma decisão de modelação |
| Valor durante um incidente | Encontrar o equipamento | Prever o raio de impacto |
O erro estratégico comum é tratar a CMDB como "inventário mais detalhado" e tentar preencher uma relação para tudo. Não escala e ninguém a mantém. Uma boa CMDB é enxuta: apenas os CIs críticos e as dependências que usaria mesmo numa análise de impacto.
Os quatro mecanismos de relação no GLPI
O GLPI não tem um único "campo de relação" - tem quatro mecanismos distintos, cada um na sua tabela, e escolher o errado é a raiz da maioria das CMDB que não funcionam. Na manutenção, o engano número 1 é montar tudo no separador Ligações a pensar que aquilo é a CMDB, e depois descobrir que a análise de impacto está vazia.
| Mecanismo | Tabela | Modela | Orientado? | Povoado por |
|---|---|---|---|---|
| Ligações diretas | glpi_computers_items | Periférico ligado a um computador (ecrã, impressora, telefone) | Não | Inventário ou manual |
| Portas de rede | glpi_networkports_networkports | Cablagem entre duas portas (switch ↔ host) | Não | SNMP/LLDP ou manual |
| Aplicações (Appliances) | glpi_appliances_items | Um serviço/aplicação como CI + a infraestrutura que o sustenta | Não (agrupamento) | Manual |
| Análise de impacto | glpi_impactrelations | Grafo de dependência para calcular o raio de impacto | Sim (origem → impactado) | Manual (separador Impacto) |
Ligações e portas de rede modelam a ligação física. Aplicações agrupa a infraestrutura de um serviço. E a análise de impacto - a única orientada - é o grafo de dependência que realmente responde "o que cai em conjunto". Os quatro coexistem; a confusão vem de esperar que um faça o trabalho do outro.
Modele o serviço como um CI: Aplicações (Appliances)
O passo que falta na maioria dos inventários é dar existência própria ao serviço. "Correio", "ERP", "Portal do cliente" não são hardware - são serviços que correm sobre hardware. No GLPI, o objeto certo para isto é a Aplicação (Appliances, menu Ativos), disponível desde o GLPI 9.5. Uma Aplicação é um CI lógico ao qual liga os itens que o sustentam:
- Crie a Aplicação (por ex. "Serviço de Correio").
- No separador de itens associados, ligue os CIs de suporte: o servidor, o switch core, o armazenamento, a ligação à internet. Isto é gravado em glpi_appliances_items.
- Registe o responsável técnico, o contrato de suporte e o fornecedor na própria Aplicação.
A partir daí o serviço existe como entidade consultável: abre "Serviço de Correio" e vê a lista da infraestrutura que o sustenta, sem depender da memória de ninguém.
A CMDB a sério: a análise de impacto
Agrupar infraestrutura numa Aplicação diz quem sustenta o quê, mas não calcula o raio de impacto de uma falha. Isso é trabalho do separador Análise de impacto (presente desde o GLPI 9.4), que desenha um grafo orientado de dependências guardado em glpi_impactrelations. Cada aresta tem uma origem e um destino: itemtype_source, items_id_source impacta itemtype_impacted, items_id_impacted.
A direção é o detalhe que separa quem percebe de quem apenas arrastou caixinhas. Uma aresta do switch para o servidor significa "o switch impacta o servidor". Quando o switch cai, segue as setas para a frente e vê tudo o que para com ele. O erro comum é desenhar a seta invertida - ligar o servidor a impactar o switch - e então a análise de impacto do switch em falha sai vazia, precisamente quando mais precisa dela. Modele sempre no sentido do fluxo de dependência: da infraestrutura de base até ao serviço no topo.
Um cuidado de terreno: o grafo é desenhado no navegador e fica lento com centenas de nós. Não tente desenhar o parque inteiro. Use a criticidade de negócio (a lista pendente Criticidade, em Configurar > Listas pendentes) para marcar os CIs críticos e coloque só esses no grafo. Uma CMDB densa é uma CMDB abandonada.
SQL de diagnóstico: encontrar a CMDB cega
À entrada de um contrato de manutenção, antes de discutir processo, corremos uma auditoria de cobertura: que CIs críticos estão no inventário mas fora de qualquer relação de impacto. São os pontos onde a análise de impacto vai mentir, a dizer "nada é afetado" quando na verdade ninguém o modelou. A consulta lista os computadores sem qualquer aresta - nem como origem, nem como destino:
-- Computadores SEM qualquer relacao de impacto:
-- existem no inventario, mas sao invisiveis para a analise de impacto.
SELECT c.id, c.name
FROM glpi_computers c
LEFT JOIN glpi_impactrelations r
ON (r.itemtype_source = 'Computer' AND r.items_id_source = c.id)
OR (r.itemtype_impacted = 'Computer' AND r.items_id_impacted = c.id)
WHERE c.is_deleted = 0
AND r.id IS NULL
ORDER BY c.name;E o outro lado: dado um serviço modelado como Aplicação, que CIs agrupa. Útil para confirmar se "Serviço de Correio" aponta mesmo para o servidor e o switch certos antes de confiar nele numa madrugada de incidente:
-- Itens que sustentam uma Aplicacao (servico) especifica:
SELECT ai.itemtype, ai.items_id
FROM glpi_appliances_items ai
INNER JOIN glpi_appliances a ON a.id = ai.appliances_id
WHERE a.name = 'Servico de Correio';Corremos estas duas consultas diretamente na base de dados (através de um cliente SQL só de leitura), nunca por um LIKE na interface, porque queremos o número exato de órfãos para dimensionar o esforço de modelação.
A descoberta automática não monta a CMDB por si
Vale a pena desfazer uma expectativa que aparece em todos os projetos: o inventário de rede por SNMP descobre as ligações físicas - se o GLPI Agent varre os switches por SNMP e o LLDP/CDP está ativo, as portas de rede entre switch e host são povoadas sozinhas em glpi_networkports_networkports. Isso é ótimo e não deve fazer à mão. Mas a dependência lógica de serviço - "o correio depende deste servidor" - nenhum protocolo a descobre. O agente não sabe que aquele processo Exchange é o seu serviço de correio crítico. Essa camada é sempre uma decisão humana, e é justamente ela que transforma inventário em CMDB.
Mantenha o grafo vivo ou ele mente
Uma CMDB desatualizada é pior do que uma CMDB inexistente: dá falsa confiança. Troca um switch, esquece-se de atualizar a relação e, na falha seguinte, a análise de impacto aponta para um equipamento que já não existe. Prenda a manutenção do grafo ao processo de gestão de alterações - toda a alteração num CI crítico deve rever as suas relações de impacto antes de fechar. Sem essa disciplina, o grafo envelhece em semanas. É o mesmo princípio da base de conhecimento: uma relação que ninguém mantém torna-se ruído.
Precisa de uma CMDB no GLPI que sustente uma análise de impacto a sério, com o grafo modelado nos CIs certos e mantido a par das alterações? Conheça o serviço de manutenção de GLPI da NexTool.
Revisto pela equipa NexTool Solutions.
