Qu'est-il recommandé de documenter une pile de technologies informatiques, y compris leur relation les unes avec les autres, dans une base de données graphiques?

Travaillant pour une grande entreprise avec plus de 500 informaticiens et plus de 1000 serveurs, chaque serveur exécutant ses propres applications métier, nous avons un énorme défi en matière d'information et de coordination pour savoir quel membre du personnel informatique contacter pour quel serveur. Le problème de la coordination est aggravé par le fait que différents informaticiens sont responsables des différentes couches de la pile informatique. Par exemple, différentes équipes sont responsables du matériel, de la virtualisation, des systèmes d'exploitation, des serveurs d'applications et des applications elles-mêmes.

Compte tenu de ce défi, au sein de DevOps, il est nécessaire de définir et de documenter tous les composants qui constituent les différentes piles technologiques dans un environnement informatique. Traditionnellement, cela aurait pu être accompli avec une solution CMDB propriétaire.

J'ai étudié des solutions CMDB typiques telles que BMC Atrium et d'autres à cet effet, le problème est cependant qu'elles s'arrêtent au niveau de la documentation des actifs informatiques eux-mêmes, à un niveau élevé, conformément au cadre ITIL, mais pour ne pas traiter la documentation de la pile des technologies de l'information en détail. J'ai également étudié des outils tels que Puppet , Ansible et Salt , mais ces outils se concentrent davantage sur le déploiement et la configuration des logiciels, et non sur la coordination des personnes autour des logiciels.

Une solution viable, par exemple, définirait les différents concepts, ainsi que les attributs clés importants pour ces concepts:

• Matériel
• Virtualisation
• Systèmes d'exploitation
• Serveurs d'applications
• Applications

Ces concepts seraient alors associés les uns aux autres en termes de leurs relations afin de former des solutions. Par exemple, une application dépendrait d'un serveur d'application, qui dépendrait d'un système d'exploitation, etc., Ensemble, cette solution serait définie au niveau du "Système financier". Après avoir défini un système, toutes les métadonnées associées à ces systèmes seraient capturées afin de faciliter la coordination pour chaque couche de la pile. C'est-à-dire la coordination du personnel de support technique pour chaque couche.

Le but d'une telle solution serait d'effectuer diverses requêtes sur les piles technologiques, telles que:

• Pour déterminer qui prend en charge quels composants
• Quels composants sont obsolètes
• Quels composants doivent être patchés

Dans cet esprit, quels outils open source existent pour définir tous les composants d'une pile de technologies informatiques, y compris leur relation les uns avec les autres, dans une base de données graphique telle que Neo4J?

Compte tenu de votre premier paragraphe, l'organisation que vous décrivez est une organisation hautement cloisonnée, ce qui est exactement ce qu'une organisation DevOps a tendance à éviter.

Compte tenu de ce défi, au sein de DevOps, il est nécessaire de définir et de documenter tous les composants qui constituent les différentes piles technologiques dans un environnement informatique. Traditionnellement, cela aurait pu être accompli avec une solution CMDB propriétaire.

Ce que vous décrivez ici pourrait être ITIL, qui est un système de gestion nécessitant de la documentation et vous le mélangez avec le fait qu'une équipe DevOps définira généralement les couches sous-jacentes comme du code, en tant que tel, il revient à toute documentation de développement avec les mises en garde de Code La documentation est souvent vue dans la méthodologie Scrum pour une méthodologie de développement agile (itérations rapides et courtes visant à une solution de travail minimale à la fin de l'itération)

Avis de non-responsabilité pour le reste de cette réponse: je connais plus le chef et l'inspec et c'est pourquoi je les prends comme exemple ici; mais ce ne sont pas les seuls outils existant sur le marché, je n'ouvrirai pas de débat sur eux car le meilleur est celui avec lequel vous êtes le plus à l'aise.

En tant que tel, le reste de la question est un peu biaisé et je n'ai personnellement rencontré aucune organisation documentant la relation de couche que vous décrivez plus que l'infrastructure en tant que documentation de code de système de gestion de configuration et de code. (Encore une fois, cela ne signifie pas que personne ne le fait, je n'en ai jamais entendu parler).
Pour illustrer mon entreprise dans un environnement de chef, un livre de recettes d'application déclarera ses dépendances (tomcat, jboss, nginx / php et sur quel système d'exploitation, les points de montage nécessaires pour certaines données partagées et son nom de schéma de base de données principalement) et exposera ses URI de services à être consommé par le chef pour la configuration d'autres applications, cela ressemble à la définition de votre «système financier» et la documentation est sur ce livre de recettes d'application README, avec quelques fichiers supplémentaires si vraiment nécessaire.

Les systèmes de gestion de la configuration ont généralement un lieu de rapport central, "chef-serveur" pour les données et "gérer l'interface utilisateur" pour la présentation dans le monde du chef "tour ansible" pour le monde ansible pour n'en nommer que deux, mais ils visent généralement davantage à donner une surveillance de le système géré global que de représenter graphiquement les dépendances.

Cela dit, pour chef, le chef-serveur agit également comme une CMDB que vous pouvez interroger avec divers outils (il renvoie des données JSON à partir de requêtes HTTP), les dépendances inter-applications peuvent être exprimées de différentes manières et il n'y a pas de `` prêt à l'emploi '' , chaque entreprise aura sa propre façon de les déclarer dans le système à des fins de configuration et en tant que tel, vous pouvez en tirer parti pour construire votre graphique, mais c'est de votre côté.

Dans une infrastructure en tant que point de vue code, les besoins en infrastructure seraient conservés avec l'application, c'est toujours l'application qui sait de quoi elle a besoin en tant que middleware, quel système d'exploitation, avec quel environnement local, quelles sont les autres dépendances des services et quels services cette offre d'application).

La dernière chose à laquelle je peux penser si vous voulez gérer ces dépendances uniquement pour la documentation sont des outils comme glpi qui est principalement une CMDB et un système de ticket, il profite de la documentation des actifs et de leur relation pour pouvoir dire ce qui est impacté lorsque vous ouvrez un ticket indiquant qu'une application est en baisse. couplé à ng-inventaire, il permet d'interroger les états du système et, en tant que tel, peut répondre à votre requête pour les besoins de correctifs, mais à mon avis, il s'agit d'une tâche de système d'audit, comme pourrait le faire une inspection intégrée dans un chef exécuté par exemple, comme la phase suivante le ferait être de réparer les systèmes obsolètes en les mettant à jour / en les corrigeant.