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

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?

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.