总结：我感兴趣的是，在尝试解决具有许多变量的问题时，是否有理由选择采用加法方法而不是减法方法进行故障排除，或反之亦然。
问题概述：
我正在与一群人合作，尝试解决暂存系统中间歇性但影响很大的问题，该问题阻止我们采用这种新配置。
我们有一台 Citrix XenApp 应用服务器运行在虚拟化基础设施上，通过 WAN 为远程站点上运行的客户端提供应用。在 WAN 与托管虚拟化服务器的物理服务器之间的网络头端，有多个加密/安全/防火墙设备。
所以基本上我们遇到了一个由许多变量引起的问题，我们正在尝试解决它。到目前为止，我们采用的是减法——尝试一次从系统中移除一个东西，如果问题消失，则尝试排除这一个东西。这种方法不太奏效。我考虑建议采用加法，即我们从应用程序将在其下工作的最低限度的系统组件开始，然后开始以各种组合添加东西。
根据您的经验，是否有理由选择加法故障排除而非减法故障排除，反之亦然？
答案1
我实际上更喜欢迭代调试方法：使用症状、日志文件、网络捕获、最佳实践和/或设计意图与构建环境的比较等进行分析，以尝试找到实际问题。你会发现，在许多情况下，不仅一报告的性能问题的原因。可能存在多个瓶颈，或者问题可能是由于多个组件的交互而发生的。
我发现这比盲目移除东西或仅为了排除故障而构建全新环境更有效。尽管后一种方法非常适合提前规划和测试：我们将其称为“开发”、“测试”或“暂存”环境，具体取决于它如何融入整体架构。然而，它确实要求您提前进行规划和测试，并且并非每个组织都有资源来正确执行此操作。