简介
在我目前的组织中，我们有许多桌面和Web应用程序在某些时候互相帮助。在查看旧应用程序或创建新应用程序时，很难尝试并记住哪个系统依赖其他系统才能工作。我不是在讨论像DLL和图像这样的软件依赖，我说的是整个系统，比如依赖HR系统的财务系统等。
我的问题
哪种方法可以追踪整个系统如何依赖另一个系统？
答案可以建议采用上述方法，软件包或文档技术。
在我的特定情况下，许多意味着超过20个服务器上的20个Web和桌面应用程序。
答案 0 :(得分：6)
我想在您的架构设计文档中明确说明。有一些很好的工具，如Enterprise Architect。此工具允许您使用UML标准创建图表，以清晰直观的方式描述这些依赖关系。
答案 1 :(得分：4)
最好的信息来源通常可以在Config文件中找到。这通常有连接字符串，Web服务URL等，它们可以很好地了解外部依赖关系。
另一种技术是使用分析或跟踪并应用过滤器，我们可以轻松跟踪任何外部调用。大多数情况下，依赖项在数据库层中，检查链接服务器并跟踪它们的依赖关系可以发现大量信息。
我不确定是否有任何自动方式来获取此信息，尤其是在系统位于多个平台上时。将涉及许多手工工作来记录所有这些。
答案 2 :(得分：4)
这是我们在Tideway Systems处生成的应用程序，许多大型组织正是出于此目的而使用的应用程序。您可以使用该产品来发现您的产品，并使用建模功能来描述您的业务应用程序（通常包含多个软件和跨服务器）。
听起来您有资格使用免费的Community Edition of Foundation，您可以在最多30台服务器上使用它 - 只需download并查看它。然后告诉我们您的想法！
免责声明：我在Tideway运行开发小组。该产品非常酷IMO，虽然我没有直接自己写过任何一个：）
答案 3 :(得分：4)
逐个关闭每台机器，看看有什么断裂..; p
但说真的，这个问题没有简单的答案。通过一系列系统，您可以创建一个显示基本依赖关系的图表，但除非您了解依赖关系是什么，否则它不会有很多意义。通常，您的目标是确定在更改另一个系统时需要“重新验证”的内容，而不是随机关闭哪些机器。但是这种信息需要大量的细节，而且很难在最初积累。
所有这一切最终都会导致您的系统处于自动化之前。你永远不会找到一个能够跟上的收缩包装自动化工具。另一方面，如果需要太多细节，任何能够处理一半甚至三分之一工作量的事情都将是有价值的。
答案 4 :(得分：2)
这是一个很好的问题 - 我们每次都在努力解决这个问题。
我们在过去一年左右尝试做的事情是两件事情“无情”：
自动化 - 如果您自动化并经常构建/部署，那么自动化过程将倾向于在大多数时候将事情做好（配置设置等）
wiki，wiki，wiki - 我们努力保持团队和项目wiki的最新状态。
很想看到其他回复。
答案 5 :(得分：1)
听起来像企业发现的工作，尽可能自动化。根据您的组织规模和环境，有不同的解决方案。对于大型景观，无论如何您都需要CMDB（配置管理数据库）。像HP Universal CMDB这样的产品可以在大规模环境中发现和跟踪依赖关系。
E.g。它可以发现SAP系统及其相关数据库与运行分布式系统的主机之间的关系，并向您显示依赖关系。更重要的是，如果对实际环境进行了一些未经授权的更改，它可以发出警告。
所以答案取决于你认为'很多'。
答案 6 :(得分：1)
涉及两类问题：
a。）为那些想知道如何确定每个组件的依赖关系的人
b。）对于那些想要跟踪组件系统中的依赖关系及其优先级的人。 （例如，哪个组件首先安装到测试环境中等等......）
如果您拥有的是一系列组件，对于每个组件都知道依赖关系，并且您想要整个组件列表的依赖顺序，您可能会发现一个名为Algorithm :: Dependency :: Ordered的Perl模块一些价值。还有其他相关模块可以处理组件的数据库记录等，甚至简单的文件记录。但是警告：我在使用它时遇到了问题。
或者，图形工具可能是有价值的。
答案 7 :(得分：1)
这是“配置管理”组的功能。首先，您必须与贵公司的“专家”交谈并创建应用程序的地图/图表。使用graphviz / dot生成图表，它不会很漂亮，但它会为您提供依赖关系的直观表示。
以下是一个例子：
digraph g {
rankdir=LR;
app1->app2->db1;
app1->app3;
}
希望这有帮助，
答案 8 :(得分：0)
系统依赖关系映射是一回事。 真正的环境设置，uid，密码，模拟设置，数据库名称以及从开发到qa到uat再到生产的其他数据是真正的挑战。
谁存储/记住所有人？
开发人员不知道他的应用程序将驻留在哪个生产服务器上。 他只记录了他的开发数据库的名称，uid，pwd，并描述了他的数据库表，conn字符串等。
一旦检入代码库并迁移到QA环境，谁是使用正确值更新这些配置文件所需的数据的守护者？
再次迁移到QA和UAT时，谁？
谁有责任告知下一个迁移小组需要改变什么？
在我的公司，这是导致我们最头痛的原因。当它被内部变更控制流程批准并创建迁移请求以将应用程序迁移到生产环境时，只需要忘记一个配置设置就会破坏整个实现，并且它始终发生，因为没有明确的责任范围（在我的意见中）。
除了责任之外，我认为这是此信息的中央存储库。
即。一个存储所有项目/应用程序的所有配置设置的系统，根据您的“角色”，您可以/不能看到实际值。
开发人员完成构建，并在“系统”中创建迁移请求。 质量检查人员会收到构建###准备就绪的通知。 QA人员登录“系统”并检索迁移说明。 现在他们清楚地知道需要做什么，并且他们正在进行代码检查和迁移过程。
重复UAT并最终生产。
当有人构建此迁移系统时，请告诉我，因为这会帮助很多人。
也许我会自己建造......谁想和我签约？
答案 9 :(得分：0)
我是一名新工作，我建议将其作为第一项任务来确定系统依赖关系。事实证明，我老板的意思是与人交谈 - 这样我就会知道谁是谁。我以为我的老板要我写一个计算机程序来做那件事。所以我做到了。
我的假设是，如果一个程序是另一个程序（服务或服务器）的客户端，那么netstat -pant和netstat -panu那么grep for ESTABLISHED会给你这个。您可以通过为LISTENING设置输出来识别服务。
这只是部分解决方案。是的，它告诉您哪些应用程序与哪些应用程序进行通信，但还有其他依赖项。因此，例如，某些应用程序使用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失败。我仍然没有想到这一点。显然，情况可以用有向图来表示，我还没有弄清楚细节。