dependencies - 如何跟踪系统依赖关系？

Question

介绍

在我目前的组织中，我们有许多桌面和 Web 应用程序都在某个时候相互提供。在维护旧应用程序或创建新应用程序时，很难尝试记住哪个系统依赖于其他系统才能工作。我不是在谈论诸如 DLL 和图像之类的软件依赖项，而是在谈论整个系统，例如依赖于 HR 系统的财务系统等。

我的问题

跟踪一个整个系统如何依赖另一个系统的最佳方法是哪一种？

_{答案可以建议执行上述操作的方法、软件包或文档技术。}

_{在我的特定情况下，许多意味着十几个服务器上的 20 多个 Web 和桌面应用程序。}

score 6 · Accepted Answer

我想说在您的架构设计文档中明确说明这一点。有一些很好的工具，比如Enterprise Architect。此工具允许您使用 UML 标准创建图表，以便以清晰直观的方式描述这些依赖关系。

score 4 · Accepted Answer

最好的信息来源通常在 Config 文件中。这通常具有连接字符串、Web 服务 url 等，它们可以很好地了解外部依赖关系。

另一种技术是通过使用分析或跟踪并应用过滤器，我们可以轻松跟踪任何外部调用。大多数情况下，依赖关系在数据库层，检查链接服务器并跟踪它们的依赖关系可以挖掘大量信息。

我不确定是否有任何自动获取此信息的方法，特别是如果系统位于多个平台上。将涉及大量手动工作来记录所有这些。

score 4 · Accepted Answer

这是我们在Tideway Systems生产的那种应用程序，许多大型组织正是为此目的使用它。您可以使用该产品来发现您的资产，并使用建模功能来描述您的业务应用程序（通常由多个软件和跨服务器组成）。

听起来您有资格使用免费的 Foundation 社区版，您可以在多达 30 台服务器上使用它 - 只需下载并查看。那么请让我们知道您的想法！

免责声明：我在Tideway管理开发团队。该产品非常酷 IMO，虽然我自己没有直接写过任何一个:)

score 4 · Accepted Answer

一台一台地关掉每台机器，看看有什么坏处.. ;p

不过说真的，这个问题没有简单的答案。使用一组系统，您可以创建一个显示基本依赖关系的图表，但除非您了解依赖关系是什么，否则它不会有很大的意义。通常，您的目标是确定在更改另一个系统时需要“重新验证”什么，而不是确定可以随机关闭哪些机器。但是这种信息需要大量的细节，而且一开始就很难积累。

所有这一切最终都会导致您的系统领先于自动化。您永远找不到能够跟上潮流的收缩包装自动化工具。另一方面，由于需要如此多的细节，任何可以处理一半甚至三分之一工作量的东西都将是有价值的。

score 2 · Accepted Answer

这是一个很好的问题——我们似乎每次都在为此苦苦挣扎。

在过去一年左右的时间里，我们试图做的是在两件事上“无情”：

自动化——如果你自动化它并经常构建/部署，那么自动化过程往往会在大多数时候让事情变得正确（配置设置等）
wiki、wiki、wiki——我们努力保持团队和项目 wiki 的最新状态。

好奇地看到其他回应。

score 1 · Accepted Answer

听起来像是一项尽可能自动化的企业发现工作。根据您的组织规模和环境，有不同的解决方案。对于大环境，无论如何您都需要一个 CMDB（配置管理数据库）。HP Universal CMDB等产品可以发现和跟踪大规模环境中的依赖关系。

例如，它可以发现 SAP 系统与其相关数据库以及运行分布式系统的主机之间的关系，并向您显示依赖关系。更重要的是，它可以在对实际环境进行一些未经授权的更改时向您发出警告。

所以答案取决于你认为什么是“很多”。

score 1 · Accepted Answer

涉及两类问题：

a.) 对于那些想知道如何确定每个组件的依赖关系的人

b.) 对于那些想要在组件系统中跟踪相互依赖关系及其优先级的人。（例如，哪个组件首先安装到测试环境中等等......）

如果您拥有的是一系列组件，您知道每个组件的依赖关系，并且您想要整个组件列表的依赖顺序，您可能会发现一个名为 Algorithm::Dependency::Ordered 的 Perl 模块具有一定的价值. 还有其他相关模块可以处理组件的数据库记录等，甚至是简单的文件记录。但是一个警告：我在让它工作时遇到了问题。

或者，绘图工具可能是有价值的。

score 1 · Accepted Answer

这是“配置管理”组的功能。要开始，您必须与公司的“专家”交谈并创建应用程序地图/图表。使用 graphviz/dot 生成图表，它不会很漂亮，但它会给你一个依赖关系的可视化表示。

这是一个例子：

digraph g {
 rankdir=LR;
 app1->app2->db1;
 app1->app3;
}

希望这可以帮助，

score 0 · Accepted Answer

系统依赖映射是一回事。真正的环境设置、uid、密码、模拟设置、数据库名称和其他从开发到 qa 到 uat 到生产的数据是真正的挑战。

谁存储/记住它们？

开发人员不知道他的应用程序将驻留在哪个生产服务器上。他只记录了他的开发数据库的名称、uid、pwd，并描述了他的数据库表、conn 字符串等。

一旦它被检入代码存储库并迁移到 QA 环境，谁是使用正确值更新这些配置文件所需的数据的保管人？

再次迁移到 QA 和 UAT 时，谁？

谁有责任通知下一个迁移组需要更改的内容？

在我公司，这是最让我们头疼的问题。当它被内部变更控制流程批准并创建迁移请求以将应用程序迁移到生产环境时，只需忘记一个配置设置就可以破坏整个实现，并且它一直在发生，因为没有明确的责任线（在我看来）。

我认为超越责任是这些信息的中央存储库。

IE。存储所有项目/应用程序的所有配置设置的系统，并且根据您的“角色”，您可以/看不到实际值。

开发人员完成他的构建，并在“系统”中创建迁移请求。QA 人员收到构建### 已准备就绪的通知。QA 人员登录“系统”并检索迁移指令。现在他们清楚地知道需要做什么，并且开始执行代码检查和迁移过程。

重复 UAT 并最终刺激。

当有人建立这个迁移系统时，请告诉我，因为这会帮助很多人。

也许我会自己建造……谁想和我签约？

score 0 · Accepted Answer

我是新来的工作，有人建议我去识别系统依赖项作为第一个任务。事实证明，我老板的意思是去和人交谈——这样我就能知道谁是谁。我以为我的老板想让我写一个计算机程序来做到这一点。所以我做到了。我的假设是，如果一个程序是另一个程序（服务或服务器）的客户端，netstat -pant那么netstat -panugrep for ESTABLISHED 会给你这个。您可以通过对 LISTENING 的输出进行 grepping 来识别服务。

这只是部分解决方案。是的，它告诉您哪些应用程序与哪些应用程序通信，但还有其他依赖项。因此，例如，一些应用程序使用 DNS 来查找它们的服务器，而其他应用程序则是硬编码或在配置文件中。任何使用 TCP 或 UDP 的东西都依赖于 IP。在大多数地方，IP 依赖于 ARP 以及以太网或 WiFi。任何依赖于另一个 LAN 上的服务的东西都依赖于至少一个路由器。

如果你有一个负载均衡器或某种集群，那么问题就会变得更有趣。如果我的服务来自负载平衡器，并且防火墙后面的任一“真实”服务器出现故障，则该服务已降级但仍处于运行状态。

它变得更加有趣，因为服务（程序）依赖于服务器（硬件）。反过来，服务器依赖于电力和空调。

因此，当我的想法失控时，事情变得更加复杂，我考虑创建一种领域特定语言 (DSL) 来捕获所有这些依赖关系。我认为，例如，server_1、server_3 和 server_5 处于电源阶段 1；server_2、server_4 和 server_6 在电源阶段 2。Server_1、Server_3 和 server_5 几乎同时发生故障：可能阶段 1 发生故障。我还没有完全弄清楚。显然，情况可以用有向图来表示，只是我还没有弄清楚细节。

dependencies - 如何跟踪系统依赖关系？

10 回答 10

Related

Reference