Close

Conheça os bastidores do futuro do gerenciamento de serviços no High Velocity: ITSM World Tour. Faça sua inscrição

Pronto para ITSM em alta velocidade?

Guia para bancos de dados de gerenciamento de configuração (CMDBs)

De acordo com a ITIL 4, um banco de dados de gerenciamento de configuração (CMDB) "é usado para armazenar os registros de configuração durante o ciclo de vida e...manter os relacionamentos [entre eles]".

Em outras palavras: o CMDB armazena informações sobre a configuração dos itens dentro de uma empresa, incluindo hardware, software, sistemas, instalações e, às vezes, pessoal. É o objetivo da empresa de TI definir quais itens devem ser rastreados e como. Estes dados de configuração podem incluir relacionamentos e interdependências entre os itens, histórico de alterações de cada item, classe e atributos — como tipo, proprietário e importância — de cada item.

Dentro de um CMDB, esses itens rastreados são conhecidos como itens de configuração (ICs). Conforme definido pela ITIL 4, os ICs são "qualquer componente que precisa ser gerenciado para oferecer um serviço de TI."

O objetivo de um CMDB é oferecer a uma empresa as informações necessárias para tomar melhores decisões de negócios e executar processos eficientes de ITSM. Ao centralizar todas as informações de configuração, os líderes podem entender melhor os ICs críticos e os relacionamentos. Os CMDBs são importantes para análise de impacto, análise de causa-raiz, conformidade legal, gerenciamento de incidentes e gerenciamento de alterações.

Gerenciamento de ativos de TI (ITAM) vs. gerenciamento de configuração

Quando a gente fala sobre ativos e ICs, gerenciamento de ativos de TI (ITAM) e gerenciamento de configuração, é fácil confundir as coisas. À primeira vista, parece que os termos são intercambiáveis, mas a verdade é que eles podem lidar com alguns dos mesmos componentes de negócios, mas se dedicam a aspectos diferentes.

Então, qual a diferença entre essas práticas? Vamos usar um carro como exemplo, porque ele poderia ser tanto um ativo (algo de valor financeiro para a empresa) e um CI (um componente dinâmico importante para os serviços de uma empresa).

Existem considerações diferentes sobre o carro dentro das diferentes práticas:

Considerações do ITAM

Considerações do gerenciamento de configuração

  • Quando você comprou o carro?
  • De qual vendedor?
  • Quanto custou?
  • Qual é a marca, modelo e acabamento?
  • Qual é a desvalorização?
  • O que a garantia cobre?
  • Qual tipo de óleo está sendo usado?
  • Com que frequência o óleo é verificado?
  • Faltam quantos Km até a próxima troca de óleo?
  • Qual é a configuração do motor?
    • Foi modificado?

Nem todo ativo é também um IC. Para algumas empresas, pode fazer sentido rastrear ativos que não têm a configuração e dependências que os tornem valiosos de rastrear como ICs. Por exemplo, uma empresa de energia pode rastrear postes individuais de energia como ativos. Eles têm valor financeiro para a empresa e pode valer a pena que sejam rastreados quando estão danificados, são substituídos etc. no gerenciamento de ativos.

No entanto, o poste de energia pode não fazer sentido como IC. Não existe uma rede de interdependências a ser rastreada. Não existe uma configuração quando falamos de um pedaço de concreto. E tentar inserir postes de energia como ICs no CMDB pode não adicionar valor suficiente ao sistema para justificar o tempo e o esforço.

Características de um CMDB

Agora a gente entende o que o CMDB faz, sua função no gerenciamento de configuração e como ele se relaciona e difere do gerenciamento de ativos. Mas, qual é a aparência da funcionalidade de CMDB em um nível mais prático?

As principais características funcionais de um CMDB são:

Painéis simples com métricas e análises de CI que facilitam o rastreamento do funcionamento dos ICs, seus relacionamentos, o impacto das alterações, os padrões que levam a incidentes ou problemas e o custo — em dinheiro e recursos — de criar e manter cada serviço dentro de uma empresa.

Recursos de conformidade que oferecem registros e visibilidade detalhados aos auditores sobre não apenas o estado atual dos ICs, mas as alterações históricas, verificações e saldos, incidentes, etc.

Criação e preenchimento adequado dos dados de ICs, compatíveis com três métodos diferentes: inserção manual, integrações (orientadas a API, SCCM) e ferramentas de descoberta que realizam verificações automatizadas de todos os endereços IP na rede de uma empresa para coletar informações de software e hardware, reunindo com eficácia um inventário de cada dispositivo físico e virtual da empresa.

Suporte para conjuntos de dados federados, incluindo normalização e reconciliação de ICs e respectivos dados.

Mapeamento de serviços de TI (costuma ser uma ilustração gráfica dos relacionamentos e dependências).

Controles de acesso que permitem que você forneça diferentes níveis de acesso a diferentes pessoas ou equipes, conforme a necessidade, e rastreie as alterações até a origem, no caso de perguntas ou incidentes.

Benefícios de um CMDB

Os problemas principais que um CMDB aborda são dados em silos e informações desatualizadas. Antes de implementar um CMDB, a maioria das empresas têm dados espalhados em diversos sistemas com diversos proprietários, dificultando a visão geral de todos os ICs e suas interdependências, tornando mais difícil ainda entender quais informações são atuais e quais não são.

Esse quadro impede que as equipes entendam contextos importantes ao tomar decisões, o que pode afetar a avaliação e o relato de riscos, afetar a tomada de decisões, atrasar a resolução do problema e, por último, gerar custos financeiros e à reputação da empresa.

Por exemplo, vamos supor que os dados do IC A estejam hospedados em um departamento e os dados do IC B, em outro. O IC B depende do IC A para o funcionamento adequado. Mas, quando o departamento do IC A resolve colocar o IC off-line para manutenção, o departamento não tem a visibilidade do impacto que está causando no IC B.

Na melhor das hipóteses, esse quadro pode causar confusão entre as equipes. Na pior, pode se tornar um incidente grave. E tudo o que é preciso para evitar esse cenário é um bom CMDB.

A Forrester identificou três casos de uso nos quais o CMDB tem importância vital hoje:

Planejamento

Os gerentes de tecnologia precisam de dados do CMDB para planejar, em alto nível com o gerenciamento de portfólio e arquitetura corporativa e em nível mais detalhado, com gerenciamento de ativos e capacidade.

Contabilidade

As finanças de TI precisam de registros dos códigos de serviços ou aplicativos para alocar demonstrativos de faturamento e fazer o gerenciamento correto das finanças corporativas.

Operação

Um CMDB melhora diversas práticas de ITSM, incluindo o gerenciamento de alterações, o gerenciamento de incidentes e o gerenciamento de problemas.

No gerenciamento de alterações, um CMDB pode melhorar a avaliação de risco antecipando quais usuários, sistemas e outros ICs podem ser afetados. Em setores regulamentados, ele também ajuda a conformidade, auxiliando as equipes a gerenciar os controles e oferecendo uma trilha clara de auditoria.

No gerenciamento de incidentes, um CMDB pode ajudar a identificar as alterações que levam a um incidente e obter uma resolução mais rápida. Os registros de incidentes podem ser associados aos ICs relevantes, ajudando as equipes a rastrear os incidentes ao longo do tempo, junto com os ativos que eles afetam.

No gerenciamento de problemas, um CMDB pode ajudar na análise de causa-raiz, levando as equipes à origem do problema com mais rapidez. Ele também pode dar suporte ao gerenciamento proativo de problemas, ajudando as equipes a identificar ativos que precisam de upgrade para reduzir os custos de serviço e o tempo de inatividade não planejado.

No final das contas, um CMDB deve reduzir a complexidade, evitar os erros, aumentar a segurança e ajudar as práticas de ITSM, como o gerenciamento de alterações e de incidentes, a serem executados sem interrupções.

Desafios dos CMDBs

As estatísticas do setor nos informam que apenas 25% das empresas obtêm valor significativo dos investimentos em CMDB. E essa taxa tão alta de falha deixou a tecnologia com uma reputação bastante problemática.

A boa notícia é que os motivos de falha podem ser evitados e tendem a se encaixar em seis categorias previsíveis:

Cultura

Como com qualquer coisa em uma empresa, a cultura e o comprometimento da equipe são os fatores mais importantes para determinar o sucesso de novas tecnologias e processos. Em um estudo recente da Harvard Business Review, 93% dos executivos disseram que o maior desafio na transformação digital orientada por dados são as pessoas e o processo. A informação continua valendo para os projetos do CMDB.

Relevância

Os CMDBs costumam ser chamados de "fonte única de verdade", o que pode levar as empresas a tentar juntar todos os dados em um, sem pensar nos casos de uso relevantes às respectivas necessidades.

Assim como com qualquer repositório de dados, um CMDB deve conter dados úteis e focados que apoiem os processos internos, como o gerenciamento de alterações. Garanta que o CMDB tenha um objetivo de valor bem definido, um proprietário e uma forma de atualizar os dados para refletir todas as alterações.

Centralização

Dizer que o CMDB é um lugar centralizado para visualizar os dados de ativos não significa que todos os dados de ativos precisam residir apenas no CMDB. Esse equívoco comum pode virar muito trabalho para as equipes, à medida que elas tentam mover todos os dados para essa "fonte única de verdade". A prática recomendada real aqui é federar os dados de outras ferramentas para que a ferramenta mais adequada seja usada para dar suporte a cada caso de uso.

Por exemplo, em geral faz mais sentido manter os dados financeiros em uma ferramenta de gerenciamento financeiro de TI (ITFM) e as informações de licença de software em uma ferramenta de gerenciamento de ativos de software (SAM). Os dados podem ser importados e espelhados no CMDB, mesmo que não seja o espaço de armazenamento primário.

Precisão

Muitas empresas lutam para desenvolver e manter um CMDB preciso. Os problemas mais comuns são: ferramentas de descoberta executadas com pouca frequência, ausência de regras de automação ou dependência de inserções manuais. A resposta comum a esses desafios é a descoberta orientada a eventos, que amplia a descoberta tradicional, de baixo para cima.

Para aqueles que não estão familiarizados com os termos, a descoberta de baixo para cima é quando os ativos são mapeados começando pela infraestrutura e indo para os ICs voltados para o cliente. A descoberta orientada por eventos é quando acontece algo — um evento em um sistema, um problema, etc. — que faz com que os sistemas conversem entre si. Então, com base nesse evento, o sistema mapeia os ICs relacionados e as respectivas conexões.

Nem todo IC é detectável. Por exemplo, a equipe pode querer mapear os monitores no CMDB. Como os monitores não são detectáveis por um sistema automatizado, eles precisariam passar por inserção manual por meio de uma planilha (ou método semelhante).

A chave da precisão é aproveitar o poder da descoberta de baixo para cima e da descoberta orientada a eventos para obter a imagem mais clara dos ativos e conexões.

Processo

Existe uma percepção em algumas empresas de que os CMDBs são para a modelagem de infraestrutura e software legados, em vez de uma nova pilha de infraestrutura de nuvem e definida por software e os fluxos de trabalho modernos hospedados neles.

A verdade aqui é que não devemos deixar o debate sobre semântica nos impedir de explorar o valor genuíno de rastrear os ICs —legados e modernos — em uma ferramenta que oferece uma visão geral dos ecossistemas técnicos.

Ferramentas

Escolher a ferramenta certa é fundamental se você quiser evitar as infelizes estatísticas de falha acima. Algumas ferramentas de CMDB são pouco mais do que repositórios de ativos — estruturas de dados fixas em infraestrutura física legada e ferramentas de descoberta que reagem com lentidão às alterações. Para ter sucesso com um CMDB, você precisa de uma conta compatível com novos tipos de ativos e que seja capaz de alterações rápidas.

Como escolher o que gerenciar no CMDB

Não existe uma abordagem adequada a todos os casos de quais ICs você deve gerenciar com o CMDB. Os objetivos e os casos de uso de cada empresa devem determinar o nível de amplitude e profundidade que faz sentido para a configuração de CMDB. Em geral, faz sentido começar em alto nível e colocar os serviços em funcionamento e depois ampliar ou aprofundar onde necessário para atender aos objetivos da empresa.

Ainda assim, o agrupamento de ICs pode ser feito em grupos mais amplos, como entidades técnicas ou não técnicas.

As Entidades técnicas incluem serviços corporativos, serviços técnicos, aplicativos, software, bancos de dados, contêineres, máquinas virtuais, sistemas operacionais, hardware, redes, portas, etc.

As Entidades não técnicas podem ser modeladas também no CMDB caso você precise representar elas como dependentes ou afetadas por outros ativos no mapeamento do serviço de TI. As entidades não técnicas podem incluir usuários, clientes, empresas, locais, acordos de serviço, documentos, etc.

Por último, os serviços de nuvem devem ser considerados no desenvolvimento de um modelo de CMDB. Tanto as ofertas de SaaS (ex.: aplicativos do Google, Dropbox, Salesforce etc.) e as ofertas de IaaS (ex.: DigitalOcean, Linode, Rackspace, Amazon Web Services etc.) podem ser representadas como ICs conforme a necessidade.

Ao contrário de CMDBs legadas, o Insight for Jira Service Management oferece uma estrutura flexível e de dados abertos para que você gerencie todos os recursos.