建议如何在图形数据库中记录IT技术堆栈，包括它们之间的关系？

在一家拥有500多名IT员工和1000多台服务器的大型公司中工作，每台服务器都运行自己的业务应用程序，因此在了解与哪个IT员工联系哪个服务器方面，我们面临着巨大的信息和协调挑战。由于不同的IT人员负责IT堆栈的不同层，因此协调问题变得更加复杂。例如，有不同的团队负责硬件，虚拟化，操作系统，应用程序服务器和应用程序本身。

考虑到这一挑战，在DevOps中需要定义和记录构成IT环境中各种技术堆栈的所有组件。传统上，这可以通过适当的CMDB解决方案来完成。

为此，我已经研究了典型的CMDB解决方案，例如BMC Atrium和其他解决方案，但是问题是，按照ITIL框架，它们停留在对IT资产本身进行文档化的层次上，而在更高层次上却没有解决文档问题IT技术堆栈的详细信息。我还研究了Puppet，Ansible和Salt等工具，但这些工具更多地侧重于软件部署和配置，而不是围绕软件的人员协作。

例如，一个可行的解决方案将定义各种概念，以及对这些概念重要的关键属性：

• 硬件
• 虚拟化
• 操作系统
• 应用服务器
• 应用领域

这些概念随后将根据它们之间的关系相互关联，以形成解决方案。例如，一个应用程序将取决于一个应用程序服务器，该服务器将取决于一个操作系统等。此解决方案将一起在“财务系统”中定义。定义了系统后，将捕获与这些系统关联的所有元数据，以便于堆栈中各层的协调。即，每一层的技术支持人员的协调。

这种解决方案的目的是对技术堆栈进行各种查询，例如：

• 确定谁支持哪些组件
• 哪些组件已过期
• 哪些组件需要打补丁

考虑到这一点，在诸如Neo4J之类的图形数据库中，存在哪些开源工具来定义IT技术堆栈的所有组件，包括它们之间的关系？

考虑到您的第一段，您描述的组织是一个高度孤立的组织，这正是DevOps组织倾向于避免的组织。

考虑到这一挑战，在DevOps中需要定义和记录构成IT环境中各种技术堆栈的所有组件。传统上，这可以通过适当的CMDB解决方案来完成。

您在这里描述的可能是ITIL，这是一个需要文档的管理系统，您将其与一个事实相结合，DevOps团队通常会将底层定义为代码，因此，它会回馈所有带有代码警告的开发文档。是 Scrum方法中经常看到的用于敏捷开发方法的文档（快速迭代和短迭代旨在在迭代结束时提供最小的工作解决方案）

对于此答案的其余部分免责声明：我对厨师和检查员了解更多，这就是为什么我在这里以他们为例；但是它们并不是市场上仅有的唯一工具，我不会就它们进行辩论，因为更好的工具就是您更习惯的工具。

因此，其余问题有些偏颇，我个人没有遇到组织文档来记录您描述的层关系，而不是将基础结构描述为代码和配置管理系统代码文档。（再次，这并不意味着没有人这样做，我只是从未听说过）。
为了在我的厨师环境中向我的公司说明，一个应用程序食谱将声明其依赖项（tomcat，jboss，nginx / php以及在哪个OS上，某些共享数据需要安装点以及主要是其DB模式名称），并将其服务URI公开给由厨师使用，用于其他应用程序配置，这听起来像在定义您的“财务系统”及其文档时在此应用程序手册README中，如果确实需要，还可以添加一些文件。

配置管理系统通常具有中央报告位置，用于数据的“ chef-server”和用于厨师世界的“ manage tower”，用于表示ansible世界的“管理塔”，以命名其中两个，但它们通常更多地是为了监督整个受管系统要比对依赖关系作图。

就是说，对于厨师而言，厨师服务器还充当CMDB，您可以使用各种工具进行查询（它从HTTP请求返回JSON数据），应用程序间的依存关系可以以多种方式表示，并且没有“开箱即用”的功能方法，每个公司都有自己的方式在系统中声明它们以进行配置，因此您可以利用它来构建图形，但这只是您的责任。

从代码的角度来看，在基础架构中，基础架构的需求将与应用程序保持一致，仍然是应用程序知道作为中间件，哪种操作系统，哪种语言环境，其他服务依赖项以及哪些服务是什么此应用程序提供）。

我最后想到的是，如果您只想管理文档的依赖项，就可以使用glpi之类的工具（主要是CMDB和票务系统），它利用文档化资产及其关系的优势，可以在您打开资产时知道受影响的内容一张表明申请失败的票。与ng-inventory结合使用，它可以查询系统状态，因此可以满足您对补丁程序需求的查询，但是在我看来，这是一项审计系统任务，就像可以在厨师运行中集成检查示例一样，下一阶段将通过更新/修补过时的系统来修复它们。