1.3.2　SOE对软件测试的好处

我在许多环境中看到的一个常见问题是，一个新的软件部署在一个隔离的预生产环境中成功地进行了测试，但在发布到生产环境中时却不能正常工作。通常，这个问题可以归结到生产环境和预生产环境之间的根本区别。因此，要使测试有效，两个环境必须尽可能相似。

事实上，像Docker这样的容器化平台要解决的问题之一就是这个问题，因此可移植性是容器环境的一个核心特性。部署在Docker上的代码构建在容器映像之上，简单地说，就是一个精简的操作系统映像（还记得JeOS吗？）。实际上，这是一个非常小的SOE，只是在容器中运行，而不是在裸机服务器或虚拟机上运行。然而，值得考虑的是，如果通过环境标准化实现的可移植性是容器技术的一个关键特性，那么我们不应该尝试在不考虑基础设施的情况下全面实现这一点。

毕竟，如果生产服务器的配置与预生产服务器不同，那么测试的有效性如何？如果预生产环境是在CentOS 7.6上构建的，但是生产环境是落后于它的CentOS 7.4，那么你真的能确保在一个环境中成功的测试结果将保证在另一个环境中成功吗？从理论上讲，它应该可以工作，但由于环境之间的软件和库版本存在根本性差异，这永远无法得到保证。这甚至是在我们考虑配置文件和安装的软件之间可能存在的差异之前需要考虑的。

因此，如果所有的环境都按照相同的标准构建，那么从理论上讲，它们都应该是相同的，那么SOE在这方面可以提供帮助。那些目光敏锐的人会注意到“应该”这个词在前一句中的用法，这是有充分理由的。SOE在定义解决测试失败的方案方面向前迈出了一大步，但它们并不是全部。

一个环境只有在没有人修改它的情况下才是标准的，如果所有用户都有管理员级别的权限，那么很容易有人登录并进行更改，这意味着环境偏离了标准。

这个问题的答案是自动化，SOE不仅仅是促进和实现自动化，它们还依赖于自动化来保持最初要求的标准化水平。两者直接相互支持，理想情况下应该是不可分割的伙伴：SOE是环境本身的定义，自动化提供标准的实现、执行和审计。实际上，这正是本书的前提，即环境应该尽可能地标准化，并且应该尽可能多地更改自动化。

本书的重点将放在这个等式的自动化方面，因为除了坚持本章概述的原则之外，所采用的标准对于每个环境都是独特的，本书的目标不是在微观级别上确定它们。以前面的示例为例，Apache和nginx都有它们的优点，适合一个用例的可能不适合另一个用例。

操作系统也是如此，一些机构可能依赖Red Hat Enterprise Linux提供的支持软件包，而其他机构则不需要支持软件包，但需要Fedora提供的前沿技术。定义一个标准没有对错之分，只要满足它所支持的服务的需求。到目前为止，我们非常关注通用性和标准；然而，在需要替代解决方案的情况下，总会有一些边缘案例。在下一节中，我们将确定如何知道何时应该偏离标准。