补丁管理最佳实践

作为一名解决方案架构师，经常有人问我，红帽的补丁管理最佳实践是什么。在本文中，我将剔除繁杂的信息，酌情介绍一些相关的工作和资料，围绕什么是最佳实践，以及您可以在补丁管理中利用哪些工具，提供一些有针对性的指导。

阅读本文后，您将更清楚地了解在为公司交付补丁时可以利用的工具和方法，以及补丁管理过程中的最佳实践。

诚然，称某件事为“最佳实践”有些自以为是。对一个企业来说有效的可能对另一个企业无效。因此，我认为最好不要将一种方法标记为“最佳”，在补丁管理过程中，应该根据给定的风险级别寻找最适合的方法。当谈论补丁管理时，归根结底，其实涉及的是风险管理或变更管理。

每个企业都需要一种应对风险的方法。但是，每个企业都需要一种独特的方法来定义风险，明确应该重点关注什么，以及如何权衡各种业务限制、影响或结果。

我认为使用“良好实践”这个术语更为恰当。例如，自动化实践社区（Automation Community of Practice）根据在现场帮助客户的经验和见解，发布了一份《自动化良好实践》文档。

我们可以利用哪些内容来构建自己的补丁管理工具包和方法？

有一些工具和方法可用于明确如何管理基础架构中的补丁。

1.勘误表定义

红帽将代码更改或内容更改（勘误表）分为 三个不同的类别。每个类别都有不同的用途和不同的更改频率。根据企业的目标和对更改的风险承受能力，有些选项可能更符合目标和更改频率。

• 红帽安全公告（RHSA）：已进行紧急更改以保护您的系统
• 红帽漏洞公告（RHBA）：修复可能影响您的漏洞
• 红帽增强公告（RHEA）：添加了新功能

有关更多详细信息，请参阅红帽的向后移植安全实践和什么是向后移植，它如何应用于 RHEL 和其他红帽产品？

利用上述原则，您可以按类型和风险划分勘误表，然后选择您认为必要和可选的补丁。 

例如，对于一个面向互联网的基础架构或具有高安全配置文件的 DMZ（非军事区），您可以选择每当有补丁发布时仅应用红帽安全公告勘误表。这可以满足高风险基础架构的需求，同时将补丁更改分解为易于处理的小批次。 

以下链接是如何在补丁过程中仅应用安全勘误表的示例：

• 是否可以限制 Yum，使其仅列出或安装安全更新？
• 如何从红帽卫星应用安全勘误表？

另一种可以考虑的方法是仅在部分软件包中应用补丁，以进一步降低补丁更改带来的风险。这样，万一应用补丁后发现系统有异常，也可以更灵活地进行回退。与任何方法一样，凡事都需要权衡取舍。对于某些人来说，这种流程可能过于精细，而对于另一些人来说，这可能正适合他们对于更改的风险承受能力。

2. 构建标准操作环境（SOE）的 10 个步骤

这篇文章提供了有关如何使用红帽卫星来启用和管理标准操作环境的详尽指南。其中非常详细地介绍了每个主题，可作为解答有关最佳实践的常见问题的参考。虽然这些内容是在几年前红帽卫星 6 首次发布时编写的，但其中的基本概念至今仍然适用。

内容管理和内容暂存对于补丁管理过程至关重要，不仅为如何向基础架构呈现补丁内容奠定了基础，而且在风险管理和降低风险的补丁管理过程中发挥着重要作用。

尤其值得关注的是红帽卫星的生命周期环境和内容视图。这些是内容暂存和基础架构升级（或回退）中涉及的关键概念。

另外，要重点关注 Organizations、Locations 和 Host Groups，以对基础架构和清单进行分类。我经常看到有些人在使用生命周期环境或内容视图时过于精细，试图使用这些结构来解决地理位置、云环境、相似基础架构或企业内不同团队的分类问题。

3.实时内核修补

实时内核修补已推出多年，是多个主要 RHEL 版本的一部分。您可以在不重启系统的情况下对内核进行实时修补，非常快速地修复漏洞。这使管理员能够立即应对风险，并有机会在可以重新启动时安排更合适的维护窗口。 

这也可以通过红帽卫星进行编排。

4.识别需要在更新后重启系统的软件包

对于有些更新和勘误表内容，可能无需在应用补丁后重新启动系统。有时，可能只需要在更新后重新启动相应的服务，即可使用更新的二进制文件。 

从 RHEL 7 开始，yum-utils 中包含了一个名为 needs-restarting 的插件这个实用程序会指出应用补丁后是否需要重新启动系统。这可以帮助您了解在系统中进行更改所对应的需求，并减少应用补丁时执行系统重启的必要性。

红帽卫星还具有一项称为 Tracer 的功能。Tracer 会从红帽卫星的角度执行与上述插件相同的功能，帮助管理员识别在系统应用补丁后哪些应用需要重新启动。

5.考虑预先提交一个红帽支持案例

事先对特定的维护活动有所了解，并有机会提前收集信息和数据，有助于减少停机时间，降低与补丁相关的一些风险。

预先提交一个支持案例可以显著减少恢复服务所需的故障排查时间，并使相关人员有机会提前查看相应的程序或方法。这对于减少中断和 MTTR（平均恢复时间）指标有显著的效果。

6.实现自动化！

众所周知，用自动化方法取代手动操作可以减少人为错误，提高可靠性，并加快补丁管理过程。要为您的企业采用适当的最佳实践，自动化是关键。

红帽卫星能够将远程执行与 Ansible 搭配使用。红帽卫星可以在 RHEL 清单上运行 Ansible Playbook 和角色，并且可以轻松地自动执行和调度补丁活动。

事实上，借助红帽 Ansible 自动化平台中提供的官方 redhat.satellite Ansible 内容集，您可以自动化和编排红帽卫星的整个内容管理，并在暂存后应用补丁内容。

更进一步，您可以使用 Ansible 模块对 Web 服务进行功能测试，或在应用补丁后进行服务验证。

总结

红帽发布了开放的漏洞管理方法，以简明而全面的方法阐述了企业应如何进行漏洞管理。风险管理是一项您必须在考虑和权衡业务限制、影响和结果后做出的决策。

问题是：是否所有漏洞都事关重大？本文重点介绍了与评估业务限制、影响和结果相关的一些实际情况和权衡，很好地示范了如何在所需的结果、成本和所能获得的效益之间进行权衡。虽然每一种风险都应予以考虑，但并非所有风险都应赋予相同权重，而且不可能有无限的资源来应对每一种风险。文中介绍了如何优先考虑最重要的事情，并制定策略来对值得缓解的风险和可以暂时搁置的风险进行分类。

简而言之，需要投入时间反复权衡。文中所有示例所对应的策略都不是头一次应用。我们早已对这些策略逐一进行反复审视和细化，直至找到适合红帽的风险管理平衡点。随着我们不断学习新事物和行业格局的变化，上述方法将继续得到完善。不仅需要持续评估风险承受能力和态势，也需要优先确立相应的方法。持续的调整和完善才是真正让“最佳实践”成为“最佳”的原因。