下载掌阅APP，畅读海量书库
立即打开
尽管本书后面我们将更详细地讨论修补和维护，但值得一提的是，它与关于共性和偏差的讨论非常吻合。
如果没有其他问题，你将不得不修补你的Linux环境。仅出于安全原因，这是一种既定的良好做法，即使在气隙环境中也是如此。假设你的环境完全由虚拟机组成，并且你不久前决定在CentOS 7.2上进行标准化。你构建了一个虚拟机，执行了所有必需的配置步骤以将其转换为SOE映像，然后将其转换为虚拟化环境的模板。这就是你的黄金构建（gold build）。到目前为止，还不错。
然而，CentOS 7.2是在2015年12月发布的，如果你今天要部署这样一个映像，首先要做的就是修补它。这将取决于构建定义（以及其中包含的包的数量），可能涉及下载一个或多个千兆字节的包以使其达到最新标准，并确保你在运行时修补了所有发现的漏洞，以及所有必要的错误修复。
很明显，如果你大规模地这样做，则是低效的——每一个新的服务器将通过网络（或更糟的，如果没有一个内部镜像，则通过互联网）拉取所有的数据，然后消耗大量的I/O时间和CPU时间应用补丁，在此期间，服务器不能用于任何有意义的事情。如果每隔几个月只部署一台服务器，那么你可能可以忍受这种情况。但如果你经常部署它们，那么这将浪费大量宝贵的时间和资源。
因此，除了执行环境本身的持续维护外，执行标准的持续维护也很重要。2019年，将CentOS版本更新为7.6是有意义的。至少，你正在进行的维护计划应该包括定期更新黄金构建。
我们将在本书后面更详细地讨论如何执行这一点。但是，对于那些现在就想知道的人来说，这可能很简单，比如启动虚拟机映像、执行更新、清理它（例如，删除克隆模板时将复制的SSH主机密钥），然后从中创建一个新模板。显然，如果自上一个维护周期以来对SOE进行了任何其他更改，那么这些更改也可以合并。
你应该期望你的SOE会随着时间的推移而不断发展，这一点可能很容易理解，但在创建和维护标准以及对标准过于严格之间有一个重要的平衡点。你必须接受，有些时候你将需要偏离它们，正如我们在上一节中讨论的那样，并且随着时间的推移，它们将不断演进。
简言之，SOE应该成为你常规IT流程的一部分。如果运用得当，它们不会阻碍创新——相反，它们会积极支持创新，将时间回馈给那些与它们一起工作的人，并确保它们花更少的时间执行平凡、重复的任务，从而有更多的时间评估新技术并找到更好的解决方案。毕竟，这是SOE直接支持的自动化的关键好处之一。