组合谬误（为什么部署到生产环境如此困难）

使 DevOps 能够很好地交付软件的基本规则之一是“尽早测试，经常测试”。 实际上，CI/CD（持续集成/持续交付）领域的一部分是构建和这些构建的自动测试。 不只是单个组件，而是整个应用。

测试驱动开发 (TDD) 是一种方法，另一种方法只是将单元测试和系统测试集成为构建和发布过程本身的一部分。 功能和回归测试是必要的，在高度敏捷的环境中，通常由对存储库的简单“提交”触发。

因此，人们希望，当软件“交付”到负责部署生产的人员手中时，他们对其准备就绪程度会有很大信心。

当然，如果有的话，我就不会写这篇文章了，不是吗？

软件交付到生产过程中所跨越的那堵墙（毫无疑问，那堵墙仍然存在）是我们经常遇到的哲学上所谓的“合成谬误”。 这种逻辑谬误通常适用于论证和证明，但有趣的是，软件是作者阿里·阿尔莫萨维在《糟糕论点之书》 （我强烈推荐给各个年龄段的崭露头角的哲学家/辩论冠军）中对这种“糟糕论点”进行简单解释的基础：

非形式谬误、无根据假设、组合与划分

该软件系统中的每个模块都经过了一组单元测试，并全部通过。 因此，当模块集成时，软件系统不会违反任何由那些单元测试验证的不变量。 事实是，由于依赖关系，各个部分的集成会给系统带来新的复杂性，而这反过来又可能引入潜在故障的额外途径。—— https://bookofbadarguments.com/ p.46

现在，处于 CI/CD 流程的最后阶段，软件不一定容易出现这种谬论。 它不仅经过了单元测试，还经过了这些单元的集成测试，以形成完整的“系统”或应用。

然而，一旦投入生产，我们又回到了原点。 我们不能根据这些测试假设系统将继续按预期运行。 这是因为应用的定义已经发生了变化，不仅包括软件和平台，还包括运行应用程序所需的网络和应用服务组件，并将其交付给热切的消费者和企业用户的屏幕。

网络和应用服务会影响请求和响应必须遍历的数据路径。 事实上，许多（但不是全部）服务可能会以开发人员未曾预料到的方式修改这些请求和响应。 因此，一旦进入生产环境，即使每个单独的服务和应用程序组件都经过了严格的测试，应用也有可能（而且往往很可能）出现故障。 失败。 犯一个错误。

这是因为我们在生产环境中陷入了合成谬误。 虽然应用程序开发人员（和 DevOps）了解这个谬论并在预生产测试中解决它，但我们仍然常常未能认识到网络层的集成仍然是集成，并且实际上可能会影响整体的运行完整性。

答案似乎很明显：好吧，那我们就在生产中进行测试吧！

但我们不会这么做，你我都知道我们不会。 因为生产是一个共享环境，在生产环境中进行严格的测试会增加共享资源和系统受到附带损害的风险，从而导致停机。 停产意味着利润和生产力下降，没有人愿意为此负责。 在生产中执行可能的单个测试要容易得多，然后当出现故障或无法按宣传的那样运行时再指责开发人员。

这最终是正在侵蚀生产网络的软件革命的静默驱动力之一。 在过去，复制和维护与生产环境相匹配的测试环境非常困难且成本高昂。 一些共享基础设施价格昂贵，而且占用大量空间。 复制该网络从财务和运营角度来说都是不明智的。

然而，由于云计算和虚拟化的引入以及随后软件的普及，人们开始认识到，基于软件的网络的复制不仅价格合理，而且由于基础设施即代码等概念而变得更加容易。 不仅如此，您还可以复制它、对其进行测试以及将其拆除，这意味着资源可以被重复使用，对其他applications执行相同的操作。

我们还没有到达那里，但我们正在接近它。 将基于虚拟（软件）的网络和应用服务集成到 CI/CD 管道中实际上比有些人想象的要真实得多。 传统上基于基础设施（网络）的服务——负载平衡、应用程序路由、Web 应用程序安全——由于集成在基于容器的架构等环境中，而被高度集成到软件构建周期中。 作为基于软件的解决方案，它们至少可以包含在构建过程的测试阶段，从而提高生产部署不会引入故障或错误的信心。

在该软件的基础上，“基础设施即代码”的应用将更进一步。 当可以在构建和发布周期中设计和微调策略和配置，然后在几乎不做任何改变的情况下部署到生产中时，我们肯定更接近消除生产中存在的组合谬误。

这些服务（最以应用为中心的应用服务）越多地集成到 CI/CD 测试阶段，每个人对成功的生产部署就越有信心。

因为当今存在的另一个谬论是针对“生产”进行测试意味着“生产系统”。 它通常不包括在生产中形成数据路径的应用服务。 它需要这样做，这样我们才能将错误减少到真正深奥的错误，并有时间和资源来解决它们。