O que é recomendado para documentar uma pilha de tecnologia de TI, incluindo o relacionamento entre si, em um banco de dados de gráficos?

12

Trabalhando para uma grande empresa com mais de 500 funcionários de TI e mais de 1.000 servidores, com cada servidor executando seus próprios aplicativos de negócios, temos um tremendo desafio de informações e coordenação em saber qual membro da equipe de TI entrará em contato para qual servidor. O problema da coordenação é agravado, com diferentes equipes de TI sendo responsáveis ​​por diferentes camadas da pilha de TI. Por exemplo, existem equipes diferentes que são responsáveis ​​por hardware, virtualização, sistemas operacionais, servidores de aplicativos e os próprios aplicativos.

Considerando esse desafio, no DevOps, é necessário definir e documentar todos os componentes que constituem as várias pilhas de tecnologia em um ambiente de TI. Tradicionalmente, isso pode ter sido realizado com uma solução CMDB adequada.

Eu investiguei soluções CMDB típicas, como BMC Atrium e outras para essa finalidade, no entanto, o problema é que elas param no nível de documentação dos ativos de TI, em um nível alto, conforme a estrutura ITIL, mas para não abordar a documentação da pilha de tecnologia de TI em detalhes. Também investiguei ferramentas como Puppet , Ansible e Salt , mas essas ferramentas se concentram mais na implantação e configuração de software, e não na coordenação de pessoas em torno de software.

Uma solução viável, por exemplo, definiria os vários conceitos, juntamente com os principais atributos importantes para esses conceitos:

  • Hardware
  • Virtualização
  • Sistemas operacionais
  • Servidores de aplicativos
  • Formulários

Esses conceitos seriam então associados entre si em termos de seus relacionamentos, a fim de formar soluções. Por exemplo, um aplicativo dependeria de um servidor de aplicativos, que dependeria de um sistema operacional, etc. Juntas, essa solução seria definida no "Sistema Financeiro". Tendo definido um sistema, todos os metadados associados a esses sistemas seriam capturados para facilitar a coordenação de cada camada na pilha. Ou seja, a coordenação da equipe de suporte técnico para cada camada.

O objetivo de uma solução desse tipo seria fazer várias consultas em relação às pilhas de tecnologia, como:

  • Para determinar quem suporta quais componentes
  • Quais componentes estão desatualizados
  • Quais componentes precisam ser corrigidos

Com isso em mente, quais ferramentas de código aberto existem para definir todos os componentes de uma pilha de tecnologia de TI, incluindo seu relacionamento entre si, em um banco de dados gráfico como o Neo4J?

Grant Durr
fonte
Qual é o tamanho da organização em termos de sistemas, pessoal, equipes etc.?
030
1
Para fornecer mais informações sobre os motivos do fechamento, há muita pergunta aqui, parte disso é sobre o CMDB e os outros pontos são sobre auditoria e conformidade. Não existe uma bala de prata para isso e isso depende muito do seu ambiente real e do que você está usando. Você usa um gerenciador de configuração? Você olhou em volta e não encontrou nenhuma ferramenta adequada às suas necessidades? Como esta pergunta é uma pesquisa de orientação e todos terão a sua solução preferida, isso não é adequado para este site, tente dar uma olhada nas ferramentas existentes e perguntar algo mais específico uma vez feito.
Tensibai 22/08
isso pode parecer estranho, mas também pode ser uma solução de armazenamento empresarial mais geral, mas personalizável?
Peter Muryshkin
Obrigado e parabéns pela edição, essa é uma pergunta muito mais respondível agora. Ainda não sinto necessidade de ter um banco de dados gráfico (isso não é necessário), mas presumo que isso possa ser omitido se houver uma resposta correta.
Tensibai
@J. Doe Uma solução corporativa de armazenamento pode funcionar, mas existem soluções de código aberto que resolveriam esse problema. Acredite ou não, temos uma infinidade de ferramentas, nenhuma das quais realmente é capaz de resolver esse problema. No lado do gerenciamento de servidores, usamos o BMC ADDM, mas a principal vantagem desta ferramenta é que ela é centrada no servidor, e não no aplicativo. Como conseqüência, quando um servidor hospeda muitos aplicativos, não há uma maneira fácil de associar vários proprietários de aplicativos, porque apenas a associação no nível do servidor é atendida.
Grant Durr

Respostas:

5

Considerando seu primeiro parágrafo, a organização que você está descrevendo é uma organização altamente isolada, que é exatamente o que uma organização de DevOps costuma evitar.

Considerando esse desafio, no DevOps, é necessário definir e documentar todos os componentes que constituem as várias pilhas de tecnologia em um ambiente de TI. Tradicionalmente, isso pode ter sido realizado com uma solução CMDB adequada.

O que você está descrevendo aqui pode ser o ITIL, que é um sistema de gerenciamento que requer documentação e você o mistura com o fato de que a equipe do DevOps geralmente define as camadas subjacentes como código, e assim retorna a qualquer documentação de desenvolvimento com as ressalvas do Código é Documentação frequentemente vista na metodologia Scrum para uma metodologia ágil de desenvolvimento (iterações rápidas e curtas visando uma solução de trabalho mínima no final da iteração)

Isenção de responsabilidade para o restante desta resposta: conheço mais sobre chef e inspec e é por isso que tomo como exemplo aqui; mas elas não são as únicas ferramentas existentes no mercado, não vou abrir um debate sobre elas, pois a melhor é aquela com a qual você se sente mais confortável.

Como tal, o restante da pergunta é um pouco tendencioso e eu, pessoalmente, não encontrei uma organização documentando a relação de camada que você descreve mais do que a infraestrutura como documentação de código do sistema de gerenciamento de código e configuração. (Novamente, isso não significa que ninguém faz isso, eu nunca ouvi falar disso).
Para ilustrar da minha empresa em um ambiente de chef, um livro de receitas de aplicativos declarará suas dependências (tomcat, jboss, nginx / php e em qual SO, pontos de montagem necessários para alguns dados compartilhados e principalmente o nome do esquema de banco de dados) e expõe os URIs de serviços a ser consumido pelo chef para a configuração de outras aplicações, isso soa como definir seu 'Sistema Financeiro' e a documentação para isso está no livro de receitas README deste aplicativo, com mais alguns arquivos, se realmente necessário.

Os sistemas de gerenciamento de configuração geralmente têm um local central de geração de relatórios, "chef-server" para dados e "UI de gerenciamento" para apresentação no mundo dos chefes "torre ansible" para o mundo ansible nomear dois deles, mas eles geralmente buscam dar uma visão geral sobre o sistema gerenciado geral do que representar graficamente as dependências.

Dito isto, para chef, o chef-server também atua como um CMDB, que você pode consultar com várias ferramentas (ele retorna dados JSON de solicitações HTTP), as dependências entre aplicativos podem ser expressas de várias maneiras e não há 'out of the box' Como método, cada empresa terá sua própria maneira de declará-las no sistema para fins de configuração e, como tal, você poderá aproveitar isso para criar seu gráfico, mas isso é do seu lado.

Em uma infraestrutura como ponto de vista do código, as necessidades de infraestrutura seriam mantidas com o aplicativo, ainda é o aplicativo que sabe o que precisa como middleware, qual SO, com qual local, quais são as outras dependências de serviços e quais serviços esta oferta de aplicação).

A última coisa que consigo pensar é que, se você deseja gerenciar essas dependências para documentação, são apenas ferramentas como o glpi, que é principalmente um CMDB e um sistema de emissão de bilhetes, tira proveito da documentação de ativos e sua relação para poder dizer o que é impactado quando você abre um ticket informando que um aplicativo está inoperante. juntamente com o ng-inventário, ele permite consultar os estados do sistema e, como tal, pode atender à sua consulta quanto às necessidades de correção, mas, na minha opinião, essa é uma tarefa do sistema de auditoria, como poderia inspecionar integrado a um chef executado por exemplo, como a próxima fase para corrigir os sistemas desatualizados, atualizando / corrigindo-os.

Tensibai
fonte