下载掌阅APP，畅读海量书库
立即打开
很容易夸大标准化的好处，而这无疑是自动化有效的一个要求。然而，就像任何事情一样，过犹不及。例如，在2019年在Red Hat Enterprise Linux 5.7上构建服务器没有意义，因为它曾经被定义为一个标准（现在已经过时，不再被支持或更新）。类似地，软件供应商有时会在某些特定的Linux发行版或应用程序栈上认证其产品，除非他们的软件在该生态系统中运行，否则不会提供支持。
在这种情况下，有必要偏离SOE，但应以受控方式执行。例如，如果一家企业在Ubuntu 18.04 LTS上建立了自己的Linux服务器，然后购买了一个新的软件栈，该软件栈仅在RHEL 7上获得认证，那么显然需要构建RHEL 7。然而，如果可能的话，这些应该成为一套新标准的一部分，并成为一个二级SOE。
再例如，如果CIS安全加固基准应用于Ubuntu SOE，那么等效的基准也应该应用于RHEL。类似地，如果业务已经在nginx上实现了标准化，那么就应该在环境中使用标准化，除非有令人信服的理由不这样做（提示：令人信服的理由不是因为它是新的和时髦的，而是因为它解决了一个实实在在的问题或者以某种方式改进了一些东西）。
这导致业务从一个Linux SOE变成了两个，这仍然是完全可管理的，当然比回退到妨碍有效自动化的有机增长方法要好。
简言之，期待偏离，不要害怕。相反，处理好它们并使用需求来扩展你的标准，但是尽可能地坚持它们。SOE为每个人都提供了一个平衡点：一方面，它们带来了规模优势，使自动化更容易，并减少了新员工的培训时间（因为所有服务器在构建和配置上或多或少都是相同的），但如果应用过于严格，它们可能会阻碍创新。它们不能被用来作为以某种方式做事的借口，只是因为这是一贯的做法。
偏离标准总是有很好的理由，只需寻找它带来的业务好处，无论是供应商支持、较低的资源需求（因此节省了电力和资金）、较长的支持窗口，还是其他方面。尽量避免仅仅因为一项新技术是新潮的就这么做。只要意识到这一点，你就会做出正确的决定，以避免偏离标准。下面我们将探讨SOE的持续维护。