Amigo Cohen, Saiba que você tem em mim um admirador de seu estilo de escrever, e sempre pontuado pela franqueza.
Bacana mesmo sua postura e transparência. Mas olha só... É da minha natureza tentar sempre compartilhar com os demais o pouco (e como é pouco !) de conhecimento ou experiência (principalmente a experiência) adquirida nestas estradas da vida (e que nem sempre são estradas retas e planas). São incontáveis as pedras e buracos ! Como tive a oportunidade de participar por um bom tempo de um projeto de CMDB como peão (não como gerente ou líder técnico) tive sempre a preocupação, durante estes vários meses, de documentar as coisas. Aliás tarefa tida por muitos como menos nobre. Geralmente adoramos fazer, mas torcemos o nariz quando no pedem para documentar. E, mais recentemente, fazendo parte deste Fórum, resolvi escrever um pouco tentando dar uma conotação de contribuição. Afinal, como costumo dizer: "...se tive a oportunidade de agachar e sujar as mãos trocando pneus, por que não contar um pouco destas experiências ?" Como não sei o quanto que você já andou se envolvendo e "sujando a mão com isso", absolutamente não tomo como crítica não, meu amigo, fique tranqüilo em relação a isso. Mas, se tomarmos as recomendações, preceitos e Melhores Práticas do ITIL como verdade, ou ao menos como um Norte a ser seguido / perseguido, seguramente temos que passar por estes trechos da estrada sim, já que não existem atalhos para se chegar ao objetivo ou destino maior. E, nestas horas, o tal do CMDB, ou o nome que se queira dar, terá um papel chave como um grande aglutinador ou amálgama entre os módulos que vierem a implementar algumas das melhores práticas segundo o ITIL. Minha preocupação e fidelidade ao grupo foi a de absolutamente não falar de fabricantes, marcas, logos ou bandeiras, mas a de passar sempre as informações sobre pontos ou aspectos importantes, características a serem buscadas, pontos de atenção, cuidado com as armadilhas, etc. Seguramente não falei de Porsche, nem de Daslu. Seguindo nesta sua linha, achei por bem passar umas informações sobre que recursos, ou facilidades, ou capacidades, ou funcionalidades buscar quando tivermos que entrar numa "agência" para comprar o tal "carro", ou quando tivermos que ir a uma "loja" para adquirir um "produto específico". E, por favor, não existe este nível de competência e/ou de detalhe no Rui Natal. Passei sim por algumas experiências bem sucedidas e quero gritar aos quatro cantos sobre elas, por que não ? Quantos pontos são levantados aqui em que eu permaneço quietinho no meu canto observando e absorvendo, registrando, aprendendo, acumulando !!! São muitos meu amigo, Cohen. Mas, em compensação, uma coisa este tal de Rui Natal seguramente não sabe fazer: Sentar em cima do pote da informação para ser reconhecido como detentor único daquilo e com isso criar um diferencial, não contando para mais ninguém. Que bobagem, que coisa pequena, mesquinha uma conduta como estas ! Sou da teoria daquela senhora aeromoça (ou seria aerovelha) da falecida PAN AM (de saudosa recordação) quando ela dizia: Tudo na vida é Passageiro. E, como diria o nosso querido técnico Zagallo: "vocês vão ter que me engolir", pois daqui a mais uns dias (porque atualmente estou super enrolado), quero escrever um pouco sobre Gerenciamento de Ativos de TI. Você(s) não imagina(m) como tem muito dim-dim jogado fora e que vai embora pelo ralo oriundo da falta de Gerenciamento dos Ativos de TI. Amigo Cohen. Continue sendo esta pessoa bacana, sincera, transparente e espirituosa. E como diz meu amigo El Cohen Abrazon Rui Natal ________________________________ De: [email protected] [mailto:[email protected]] Em nome de Roberto Cohen Enviada em: quarta-feira, 4 de agosto de 2010 13:01 Para: [email protected] Assunto: Re: [itsm_br] CMDB - Características de uma Solução - Federação Rui, Isso parece grego para mim... Perdão pela franqueza, mas no meu mundo não consegui encontrar alguém que tivesse (orgulho do seu) CMDB. Quanto mais uma federação. Obviamente isso não desacredita o conhecimento que compartilhas, mas parece-me alguém exclamando: "- O meu Porsche tem um botão y..." ou "- Na Daslu tem uma sala exclusiva para...". Quisera eu chegar neste nível de detalhe e competência. Katzo, como me sinto desesperançado ao ler seus artigos... Preciso fazer um upgrade no meu universo, hehehe. :-( Abrazon e não tome isso como uma crítica, mas como um desabafo de necedade (a palavra existe!!) EL Cohen 2010/8/1 Rui Natal <[email protected] <mailto:[email protected]> > Compartilhando com os amigos de Forum... Características de uma solução de CMDB Hoje vamos nos concentrar tão somente em Federação. Dados federados são dados armazenados fora do CMDB, mas ligados a IC's e que serão acessados através do CMDB. São informações relacionadas que por si não qualificam um IC de forma significativa e que, portanto, devem ficar armazenadas fora do CMDB. Um exemplo, no caso de um Incidente relacionado a um IC, seriam atributos (campos) detalhados que por si não são importantes para estarem no contexto do CMDB ==> informações do registry de uma máquina. Um exemplo típico é o de uma bibliotecária que acessa algumas informações básicas e importantes a partir de uma ficha sobre o livro ou sobre a obra. E, efetivamente o livro e a obra encontram-se em outra localidade. Por que usar Federação ? O CMDB deve ser a fonte única de referência ou de verdade (SST - single source of truth) sobre seu ambiente, porém não necessariamente o repositório único destas referências. Os produtos e ferramentas consumidoras devem utilizar o CMDB para encontrar todos os dados de Configuração. O CMD deve ser o catálogo ou índice que fornece as informações básicas sobre o que a empresa possui e como e onde acessar o restante. Em geral, deveremos encontrar mais dados federados do que armazenados no CMDB. A criação de links federados aos dados existentes a partir do CMDB não significa que se precisará acessar estes dados sempre através do CMDB. A federação evita que seja necessário reescrever um aplicação para que seus dados sejam lidos do CMDB, ao invés de seus databases atuais. Que dados devem ser federados ? Atributos que raramente mudam, ou que mudam mais de uma vez ao dia; atributos que usualmente não serão necessários para se tomar decisões de negócio; informações específicas sobre um IC, tais como: requisições de mudança ou registro de incidente. Em julho de 2009, a DMTF anunciou que aprovou o padrão Configuration Management Database Federation (CMDBf) para faciltar o compartilhamento de informações entre CMDB's e outros repositórios com dados de gerenciamento (Management Data Repositories - MDR). Este novo padrão é a primeira tecnologia a prover uma solução "cross-vendor" padronizada para federar dados de gerenciamento de sistemas. A novidade com a introdução da versão 3 do ITIL foi o conceito de Sistema de Gerenciamento de Configuração (CMS - Configuration Management System). É o sistema responsável por manter informações sobre os itens de configuração requeridos na entrega de um serviço de TI, incluindo seus relacionamentos. Em nível de dados, o CMS pode requerer dados de vários CMDB's físicos, os quais, juntos, constituem um "CMDB federado". Outras fontes de dados também são conectadas ao CMS, como a DML (Definitive Media Library). Bom dia a todos. Rui Natal
