考虑到这一挑战，在DevOps中需要定义和记录所有构成组件的组件。构成IT环境中的各种技术堆栈。传统上，这可能是通过适当的CMDB解决方案来完成的。根据ITIL框架在较高级别上本身拥有资产，但并未详细介绍IT技术堆栈的文档。我还研究了Puppet，Ansible和Salt等工具，但这些工具更多地侧重于软件部署和配置，而不是围绕软件的人员协作。例如，一个可行的解决方案将定义各种概念，以及对这些概念重要的关键属性：硬件
虚拟化
操作系统
应用程序服务器
应用程序
这些概念然后将根据它们之间的关系相互关联，以形成解决方案。例如，一个应用程序将取决于一个应用程序服务器，而该服务器将取决于一个操作系统等。该解决方案将一起在“财务系统”中定义。定义了系统后，将捕获与这些系统关联的所有元数据，以便于堆栈中各层的协调。即
这种解决方案的目的是针对技术堆栈进行各种查询，例如：
确定谁支持哪些组件
哪些组件已过期
哪些组件需要修补
考虑到这一点，存在哪些开源工具可以定义所有组件诸如Neo4J之类的图形数据库中的IT技术堆栈，包括它们之间的关系？
#1 楼
考虑到您的第一段，您所描述的组织是一个高度孤立的组织，这正是DevOps组织倾向于避免的组织。考虑到这一挑战，在DevOps中需要定义和记录构成IT环境中各种技术堆栈的所有组件。传统上，这可能是通过适当的CMDB解决方案来完成的。
您在这里描述的可能是ITIL，这是一个需要文档的管理系统，并将其与DevOps团队通常会将底层定义为代码，因此它会返回到任何带有代码警告的开发文档，这是Scrum方法中经常看到的用于敏捷开发方法的文档（快速而短暂的迭代旨在最小化工作迭代结束时的解决方案）
此答案其余部分免责声明：我对Chef和Inspec的了解更多，这就是为什么我在这里以它们为例；但是它们并不是市场上仅有的唯一工具，我不会就它们进行辩论，因为更好的工具是您更熟悉的工具。
其余的问题有一点偏见，我个人没有遇到一个组织来记录您描述的层关系，而不是将基础结构描述为代码和配置管理系统代码。 （再次，这并不意味着没有人这样做，我只是从未听说过。）
为了在厨师环境中向我的公司进行说明，应用程序食谱将声明其依赖项（tomcat，jboss，nginx / php以及在哪个OS上，大多数共享数据需要挂载点及其DB模式名称），并公开其服务URI，以便厨师将其用于其他应用程序配置，这听起来像是在定义“财务系统”及其文档在此应用程序食谱自述文件中，如果确实需要，还有更多文件。
配置管理系统通常具有中央报告位置，用于数据的“厨师服务器”用于在厨师世界中显示的“管理UI”，用于可管理世界的“可管理塔”中可以列举其中两个，但它们通常更多地是为了监督整个受管系统要比绘制依赖关系图好。
也就是说，对于厨师而言，厨师服务器还充当CMDB，您可以使用各种工具进行查询（它从HTTP请求返回JSON数据），应用程序间的依存关系可以通过多种方式表示没有“开箱即用”的方法，每个公司都有自己的方式在系统中声明它们以进行配置，因此您可以利用它来构建图形，但这只是在您的身边。
从代码的角度来看，在基础架构中，基础架构的需求将与应用程序保持一致，仍然是应用程序知道作为中间件，哪种操作系统，哪种语言环境，还有哪些其他服务依存关系以及此应用程序提供什么服务。）
我最后想到的是，如果您只想管理文档的依赖项，则是glpi之类的工具，主要是CMDB和票务系统，它利用了文档编制的优势资产及其关系，以便能够在您打开时分辨出受影响的因素一张表明申请失败的票。与ng-inventory结合使用，它可以查询系统状态，因此可以满足您对补丁程序需求的查询，但是在我看来，这是一项审核系统任务，就像可以在厨师运行中集成检查示例一样，下一阶段将通过更新/修补过时的系统来修复它们。
评论
在系统，人员，团队等方面，组织的规模是多少？为了提供更多有关结案原因的见解，这里有太多问题，部分与CMDB有关，其他与审计和合规性有关。没有万灵药，这在很大程度上取决于您的实际环境和使用的东西。您是否使用配置管理器？您环顾四周，没有找到适合您需求的工具吗？因为这个问题是一个意见征询，每个人都会有其首选的解决方案，但这并不适合该网站，请尝试查看现有工具并在完成后提出更具体的要求。
这听起来可能很奇怪，但也可以使用更通用但可自定义的企业仓储解决方案吗？
谢谢并祝贺您的编辑，现在这是一个更加可回答的问题。我仍然不希望在其下有一个图形数据库（这不是必需的），但是我认为如果有正确的答案，可以将其省略。
@J。 Doe企业仓库解决方案可能会起作用，但是有开源解决方案可以解决此问题。信不信由你，我们有很多工具，实际上没有一个能够解决这个问题。在服务器管理方面，我们使用BMC ADDM，但是此工具的主要缺点是它以服务器为中心，而不是以应用程序为中心。因此，当一台服务器托管许多应用程序时，没有简单的方法可以关联多个应用程序所有者，因为只满足服务器级别的关联。