TMACUL

GESTÃO DE CONFIGURAÇÃO: Famílias, Classes e relacionamentos  18/12/2015

Blog Post created by TMACUL Champion on Jan 1, 2016
GESTÃO DE CONFIGURAÇÃO: Famílias, Classes e relacionamentos
Ontem acabou não dando tempo pra dar continuidade no assunto, mas vamos lá...

FAMÍLIAS & CLASSES
Todos os IC's/ativos no CMDB são divididos em famílias e classes. Dentro de uma mesma família podem existir diferentes classes especialistas.

Um IC pode ser qualquer coisa. Servidor, equipamento, rede, pessoa, local, serviço, organização, contrato, enfim, tudo que sua imaginação permitir. Basta você querer gerenciá-lo.

Na minha opinião, o modelo de dados do CMDB foi muito bem planejado dentro da ferramenta. Dependendo do tipo de IC, poderão existir mais ou menos atributos envolvidos no objeto.

Portanto, todos os itens possuem atributos comuns mas, dependendo da família envolvida, atributos adicionais poderão existir.
Desta forma, é possível de uma forma racional armazenar qualquer tipo de informação na base, gerenciada (IC) ou não (ativo).

O CMDB pode armazenar tanto IC's como ativos patrimoniais. Quando um item for considerado apenas um ativo, por padrão, ele deixará de ser gerenciado pela ferramenta SDM. No lugar dela, a ferramenta CA Asset poderá desempenhar este papel se ela estiver integrada com a SDM.

Sempre lembrando que, quanto mais granular for o seu CMDB, mais famílias e classes serão utilizadas e mais trabalho você terá para administrá-las.

E o mais importante: Nem tudo que pode ser cadastrado precisa ser cadastrado na base. E é por esta razão que é preciso dar foco apenas nos itens de configuração que serão gerenciados por sua empresa.
Essa decisão não é fácil de ser tomada pois envolve algumas questões conceituais que abordarei quando tratar de relacionamentos na base.

RELACIONAMENTOS
Dificilmente um IC está isolado na infraestrutura. Na maioria das vezes, existe um IC provedor e um IC dependente deste IC.
Para exemplificar, pense em um servidor...
Ele está conectado na rede, depende de outros equipamentos para prover serviços, atende clientes específicos, possui softwares, e todos esses relacionamentos "podem" ser considerados IC's.

Portanto, dependendo da finalidade de um IC e da infraestrutura física e lógica envolvida, podem existir dezenas de "elos" que conectam as "peças desse quebra cabeça".

E assim como a base cadastral de IC's, os relacionamentos também precisam ser cadastrados e mantidos no CMDB, manualmemte ou automaticamente.

Pois somente desta forma será possível responder aquelas perguntas que fiz no primeiro post que escrevi sobre a eficiência do processo de configuração.
Para ser mais didático, acompanhe o raciocínio...

Quando uma requisição de mudança é aberta por um analista, no mínimo um IC será modificado e poderá causar impacto na sua infraestrutura. E dependendo do tamanho dessa infraestrutura, é possível que esse analista não consiga avaliar com precisão a repercussão real de sua mudança.
E esse impacto gerado só poderá ser calculado se existirem relacionamentos entre este IC e seus respectivos serviços.

A maior dificuldade nesta avaliação é percorrer todos os níveis de relacionamento para identificar todos os IC's da familia serviço envolvidos. Não esqueça que está relação de dependência pode ser indireta, isto é, podem existir outros IC's em diferentes níveis envolvidos nesta topologia.

Para facilitar este trabalho, os " Gerenciadores de mudança" poderão utilizar a ferramenta "CMDB Visualizer" ou a próprio "Explorador de impacto" da mudança, presente na ferramenta SDM.

Uma das questões mais difíceis que precisam ser respondidas antes que seja iniciado qualquer processo de implantação de relacionamentos é sobre a granularidade que existirá no CMDB.

Um sistema pode ser considerado um único IC da família software. Mas nada impede que este sistema seja "quebrado" em IC's menores do tipo módulos, funcionalidades, serviços de infraestrutura, webservices, URLs, etc.
Tudo isso para prover informações de impacto mais precisas para um serviço de negócio.
O grande problema é que quanto mais partes houverem, mais relacionamentos existirão. E nem todos os relacionamentos podem ser criados automaticamente.

Viu o tamanho da dor de cabeça? Pois é. Minha recomendação é pensar bem antes que as cargas de relacionamentos sejam iniciadas. As vezes não é fácil ser muito especialista.

Semana que vem publicarei uma rotina SPEL que desenvolvi que facilita a varredura de relacionamentos na base e agrega muito valor para as mudanças. Aguarde!

Bom final de semana!

 

 

Publicado Originalmente: 18 de dezembro de 2015 às 23:38

Em: CA SDM Brasil - facebook

Por: daniel-bighelini

Outcomes