Gerenciamento de configuração e requisitos modernos de CMDB

Neste artigo, consideraremos problemas reais de formação e operação de bancos de dados de gerenciamento de configuração (CMDB) e mostraremos as formas mais promissoras de resolvê-los.

Além disso, falaremos sobre o gerenciamento de configuração usando o CMDB, e não sobre o gerenciamento de ativos, embora muitas vezes esses conceitos não sejam separados.

CMDB e gerenciamento de configuração

O CMDB é um dos principais elementos do Gerenciamento de configuração, originalmente concebido como um banco de dados que contém informações sobre serviços, itens de configuração contabilizados e as relações entre esses itens.

Quando criado com sucesso e usado regularmente, o CMDB ajuda a atingir as metas estabelecidas na ITIL:

• controlar todas as configurações em uma organização;
• fornecer informações precisas sobre a configuração para dar suporte aos processos de gerenciamento de serviços;
• fornecer informações para os processos de gerenciamento de incidentes, problemas, alterações e liberações;

No entanto, um CMDB não é um banco de dados no sentido usual. Na maioria das vezes, é mais correto falar sobre um conjunto de repositórios separados combinados em um único modelo ou não combinados de forma alguma.

Em geral, a situação é parecida com a seguinte:

• o software é gerenciado em um sistema de informações;
• as licenças de software são gerenciadas em outro sistema de informações;
• servidores físicos, estações de trabalho, redes e outros equipamentos são gerenciados em um terceiro;
• objetos de infraestrutura de nuvem – em mais um sistema.

Na maioria das vezes, os dados nesses sistemas são apresentados em diferentes formas, o que é conveniente para o gerenciamento local. Nesse caso, reduzir as informações a um único formato de dados, conveniente para o gerenciamento centralizado, ou não é possível ou exige custos significativos de mão de obra.

A qualidade dos processos de gerenciamento é extremamente dependente da relevância das informações.

Enquanto a organização for pequena, temos a capacidade de transmitir informações atualizadas sobre nossos ativos e configurações. Em algum momento, no entanto, a organização “supera” o gerenciamento em tempo real e há a necessidade de um armazenamento ordenado de informações de configuração atualizadas.

Desafios da atualização de dados no CMDB

O setor de TI mudou bastante nos últimos 10 anos. Com abordagens ágeis para o gerenciamento de projetos, a velocidade de entrega de valor comercial da TI (Time To Value) aumentou várias vezes. A aplicação das práticas de DevOps pode fornecer código para ambientes produtivos até 200 vezes mais rápido do que antes.

As infraestruturas estáticas que eram gerenciáveis “no papel” ou no Excel estão dando lugar a infraestruturas dinâmicas. A virtualização e as nuvens entraram em nossas vidas: servidores virtuais implantados para necessidades temporárias, componentes virtuais que se deslocam de um host físico para outro e uma série de outras mudanças que ocorrem constantemente na infraestrutura. Há uma enorme quantidade de software que está sendo constantemente atualizada, revertida e refinada.

Cada uma dessas alterações precisa ser rastreada e registrada para garantir que você possa acessar informações atualizadas

Nessas condições, o principal problema do CMDB se torna a complexidade de atualizar as informações que ele contém.

Esses problemas decorrem do fato de que a ideia do CMDB foi formada em uma era dominada por unidades de configuração “rígidas”. Para um gerenciamento eficaz, bastava uma lista de elementos de infraestrutura com explicações sobre as tarefas que cada elemento específico realiza.

A ideia era relevante para volumes de infraestrutura bastante modestos para os padrões modernos.

Atualmente, as infraestruturas de grandes organizações não só consistem em milhares de unidades de configuração, o que torna impossível gerenciá-las manualmente de forma eficaz, mas também são híbridas, ou seja, além dos elementos de configuração física, elas contêm seus próprios recursos de nuvem internos e externos com um alto grau de dinâmica de alteração. Resolver a tarefa de gerenciar um banco de dados de itens de configuração tão díspares e que mudam rapidamente é um grande desafio para o gerenciamento de TI.

Abordagens para criar e gerenciar um CMDB

Manual

A entrada manual de informações no CMDB, por um lado, exige um investimento significativo de tempo humano e, por outro lado, leva a erros e dados inconsistentes.

Essa abordagem é relevante para pequenas organizações com infraestrutura estática.

Mas justamente essas organizações estão entre as que provavelmente não precisam de CMDBs. Para corporações modernas, essa opção definitivamente não é adequada. Parece lógico usar ferramentas de automação.

Discovery

O Discovery é um software especializado que permite coletar dados de infraestrutura em um modo automatizado. O mecanismo do Discovery contém componentes para endereçar dispositivos conectados à rede corporativa. A rede envia solicitações para o equipamento usando vários protocolos, o equipamento responde à solicitação com suas informações de identificação e, assim, o CMDB é gerado automaticamente.

O Discovery automatiza as seguintes tarefas:

• identifica novos CIs e os adiciona ao CMDB;
• atualiza os dados de configuração;
• mantém o controle de versão das configurações;
• forma um mapa de elementos de infraestrutura que, quando os dados sobre inter-relações com serviços são inseridos, transforma-se em um modelo de serviço de recursos completo.

Abordagem semi-automatizada

O software Discovery CMDB coleta automaticamente dados sobre a infraestrutura existente. Os dados ausentes e as relações entre os elementos são inseridos manualmente.

As infraestruturas modernas são dinâmicas, estão em constante mudança e, portanto, para manter o CMDB atualizado, a atualização do disco deve ser regular e, com uma vasta infraestrutura, esse não é um processo rápido. A solução lógica é executar a descoberta fora do horário de expediente.

Para usá-la de forma eficaz, ela precisa de uma estreita integração com os processos de ITSM, portanto, esse mecanismo provavelmente fará parte de uma solução de ITSM. E se ele for iniciado durante o horário de trabalho, é muito provável que o desempenho do sistema caia, o que é inaceitável.

É possível que uma mudança de disco tenha ocorrido à noite e, pela manhã, os desenvolvedores tenham implantado dezenas de máquinas virtuais, por exemplo, para fins de teste. Nesse momento, devido à falta de memória, ocorre um incidente no host físico em que essas máquinas virtuais estão localizadas. No processo de resolução do incidente, recorremos ao modelo de serviço de recursos e não vemos os motivos, porque nosso CMDB ainda não sabe sobre essas máquinas virtuais e o próximo diskover será em algumas horas. Mas, no momento em que ele começar, é bem possível que esses servidores virtuais não existam mais porque já cumpriram sua função e não são mais necessários.

Assim, chegamos à conclusão de que o diskaveraging nem sempre resolve o problema da relevância dos dados no CMDB.

IaC – Infraestrutura como código

Os profissionais de DevOps nos apresentaram novas possibilidades para o gerenciamento de infraestrutura.

A infraestrutura definida por software é o futuro que já chegou.

A essência da IaC é que as configurações completas são empacotadas em contêineres que são implantados usando scripts com essas configurações armazenadas como código. Agora não há necessidade de configurar servidores manualmente ou mesmo clonar os existentes, pois um administrador pode manter centenas desses servidores simultaneamente.

As configurações são armazenadas no CMDB na forma de código e também são gerenciadas usando código. E, como se trata de código, pode ser testado sem intervenção humana. Com a IaC, não precisamos ir até o servidor e verificar se todas as bibliotecas estão instaladas, se todos os conectores estão ativos, se toda a configuração atende às nossas necessidades etc. Em vez disso, um teste automatizado é escrito. Se o teste falhar, a infraestrutura implantada é removida com dois cliques e um novo script de implantação é iniciado.

Com processos de gerenciamento de infraestrutura criados como código, os dados da infraestrutura implantada estarão sempre atualizados.

Com a IaC, o CMDB se torna uma fonte de dados de infraestrutura de referência em vez de um agregador de dados de infraestrutura.

Anteriormente, precisávamos descobrir um item de configuração, reconhecê-lo e enviar informações sobre ele para o CMDB. Com o uso do gerenciamento de infraestrutura como código, a situação é oposta: primeiro criamos um modelo do item de configuração e, em seguida, criamos qualquer número de unidades de configuração necessárias, conforme necessário.

Na combinação de descoberta automática e gerenciamento de infraestrutura como código, nasce um ideal: geração contínua de CMDB.

Abordagem contínua para a geração de CMDB

Descoberta contínua, IaC como fonte de informações de referência e configuração sempre atualizada e, em alguns aspectos, gerenciamento manual (infelizmente, você não pode prescindir dele, mas é importante que seja a quantidade mínima de operações necessárias).

Quando os três componentes são combinados, obtemos um CMDB com dados atualizados. E um CMDB atualizado é uma ferramenta poderosa no gerenciamento de TI.

Como criar e gerenciar um CMDB?

• Tudo o que reside na nuvem deve ser gerenciado em uma abordagem de “infraestrutura como código”.
• Unidades de configuração localizadas em data centers físicos – gerenciadas usando uma abordagem de “descoberta contínua”.
• Os elementos de infraestrutura de escritório podem ser gerenciados usando a descoberta contínua e manualmente.

Os CMDBs devem mudar. As abordagens para sua formação devem mudar. Hoje em dia, os CMDBs não devem apenas armazenar dados sobre os elementos de infraestrutura contabilizados e as conexões entre eles, mas devem ser totalmente integrados a hipervisores, orquestradores e sistemas de gerenciamento de configuração dinâmica.

Ao mesmo tempo, as operações com CMDBs devem ser correta e convenientemente integradas aos processos associados ao gerenciamento de configuração. Os CMDBs devem se tornar flexíveis e dinâmicos, gerando valor objetivo em vez de serem uma fonte de problemas.

SimpleOne SACM

O roteiro para o desenvolvimento de soluções ITSM na plataforma SimpleOne inclui todas as abordagens acima para preencher e atualizar os dados do CMDB. Em breve, o SimpleOne SACM (Service Asset and Configuration Management) fornecerá ferramentas flexíveis, convenientes e eficientes para o gerenciamento de configurações e ativos.

A solução comercial abrangente do SimpleOne SACM incluirá os módulos:

• SimpleOne CMDB – módulo CMDB com ferramentas de descoberta contínua, componentes necessários para organizar o gerenciamento de infraestrutura como código (IaC) e ferramentas para formar e gerenciar o modelo de serviço de recursos da organização;
• SimpleOne ITAM – Módulo de gerenciamento de ativos de TI