Banco de Dados de Gerenciamento de Configuração

Um item de configuração (CI) é qualquer componente que precisa ser gerenciado para entregar um serviço. Exemplos são um servidor, uma estação de trabalho, um switch de rede, uma aplicação, um esquema de banco de dados, uma licença, um contrato ou a documentação que descreve como tudo isso se encaixa. Cada CI tem atributos como proprietário, localização, versão, número de série e status do ciclo de vida. Na maioria dos projetos, ele também guarda o histórico de seus estados ao longo do tempo.

O que define um CMDB é que os relacionamentos têm o mesmo peso dos próprios itens. Um registro de CI diz o que um componente é. Um relacionamento diz que a aplicação de folha de pagamento roda em um cluster específico, que esse cluster depende de um storage e que uma filial se conecta por um roteador específico. Juntos, esses vínculos formam um grafo de dependências. Ele responde perguntas que uma lista simples não consegue: se este dispositivo falhar, quais serviços param e quem é afetado?

No gerenciamento de serviços de TI, o CMDB é o ponto de referência onde outros processos gravam e de onde leem. O gerenciamento de incidentes vincula cada incidente aos CIs envolvidos. Isso acelera a triagem e mostra falhas recorrentes no mesmo componente. O gerenciamento de problemas analisa esses agrupamentos para encontrar causas raiz. O gerenciamento de mudanças é o principal responsável por gravar dados: uma mudança aprovada registra quais CIs vai afetar, e o CMDB deve refletir o novo estado quando a mudança for concluída.

É o grafo de dependências que transforma registros em decisões. Antes de aprovar uma mudança, dá para estimar seu raio de impacto seguindo os relacionamentos a partir dos CIs afetados. Depois de um incidente, o mesmo percurso mostra o que verificar em busca de efeitos colaterais. Um CMDB consultado só durante auditorias entrega apenas uma fração desse valor.

Os dois estão relacionados, mas respondem a perguntas diferentes. O inventário de ativos, parte central da gestão de ativos de TI (ITAM), mostra o que a organização possui, onde cada ativo está e quem é responsável por ele. Seus principais usuários são finanças, compras e facilities. O CMDB mostra como os componentes se relacionam e o que uma mudança em um deles afeta. Seus usuários são as equipes de incidentes, problemas e mudanças.

Na prática, a fronteira é gradual. Muitas organizações começam com um inventário simples e acrescentam relacionamentos conforme seus processos de gerenciamento de serviços amadurecem. Vale um teste simples: um repositório em que nada se conecta a nada é um inventário com campos extras, não importa o nome que tenha.

A maioria dos CMDBs combina a descoberta automatizada com manutenção manual de registros. A descoberta usa coleta por agentes, varredura de rede e integrações com plataformas de nuvem e diretório. Ela encontra o que existe de fato e identifica divergências entre o estado registrado e o real. Contratos, definições de serviço e outros itens que não podem ser varridos são inseridos e mantidos manualmente.

Quando várias ferramentas guardam cada uma parte da verdade, o CMDB as federa ou concilia. Uma fonte é definida como autoritativa para cada tipo de atributo, e conflitos são resolvidos por regra, não por discussão. A precisão é resultado de um processo contínuo, não de uma carga única. Sem um responsável definido, ela se deteriora rapidamente.

No Anexet Inventory, o cartão de cada estação de trabalho lista os dispositivos e aplicativos instalados, com tipo, fabricante, versão e data de instalação. Esses registros são a matéria-prima de que um CMDB precisa para montar seus itens de configuração.

1 / 2

• 
• 

O padrão de fracasso é conhecido. O escopo inicial cobre tudo de uma vez, e o projeto se afoga em trabalho de qualidade de dados antes de entregar qualquer coisa. Os registros só são atualizados quando alguém se lembra. Com o tempo, o banco de dados deixa de refletir a realidade e as pessoas param de confiar nele. Nesse ponto, ele está tecnicamente vivo e praticamente morto. As práticas abaixo separam as implantações que sobrevivem.

Um CMDB é dado de referência, não um coletor. Ele raramente observa o ambiente por conta própria. Em vez disso, agrega o que as ferramentas de descoberta, monitoramento e gerenciamento informam. Em troca, enriquece essas ferramentas. Alertas de monitoramento ganham contexto sobre o que é um host e a qual serviço ele atende. Investigações de segurança partem de um mapa conhecido do que deveria existir. O planejamento de recuperação sabe quais componentes restaurar e em que ordem.

Seus limites vêm do mesmo desenho. Um CMDB não detecta intrusões, não controla dispositivos e não substitui a visibilidade dos endpoints. Ele informa à organização como o ambiente deveria ser, para que outros controles possam interpretar o que veem. Controles como a Prevenção contra Perda de Dados (DLP) atuam onde os dados de fato circulam, como mostra a tabela.

Comece pelos serviços cuja interrupção custaria mais e modele os componentes de que dependem. Manter o modelo próximo da realidade é a disciplina central do gerenciamento de configuração, por isso amplie o escopo só depois de passar em uma auditoria de precisão.