修补过程

修补解决方案的主要用户是应用程序开发和运营团队。每个应用程序通常部署到多个环境中，例如开发、测试（集成、用户验收等）和生产。应用程序团队必须为每个环境规划修补计划，因此，在将补丁应用于生产环境时，该补丁已经过测试并确定不会对应用程序产生不利影响。

以下工作流程提供了一个示例，说明如何为部署在多个环境中的应用程序规划修补窗口以及如何配置标记。

• 第 1 步。每个应用程序团队都为其服务器在不同环境中规划维护时段，并相应地设置代表服务器补丁组和维护时段的标签：

  • 补丁组标签表示应用程序环境中作为特定补丁基准目标的服务器。补丁组根据正确的实例集，帮助确保您将合适的补丁部署到正确的实例集。修补程序组还有助于避免在生产环境中部署未经充分测试的修补程序。

  • 如果应用程序服务器包含多个操作系统，则应用程序团队将根据环境和操作系统的组合创建补丁组。一个补丁组只能注册一个补丁基准，一个实例只能注册一个补丁组。

    例如：appname-DEV-WIN 和 appname-DEV-RHEL

  • 维护时段标签表示修补服务器的时间表。补丁组中的所有服务器都应处于同一个维护时段内。维护时段标签应遵循一致的 cron 和 rate 表达式格式，以便您定义的 Lambda 函数可以轻松解析表达式。（在本指南中，我们将这个 Lambda 函数称为 automate-patch。）

    例如：schedule-duration-cutoff-timezone

    cron(0 2 ? * SAT#3 *) 代表每个月的第三个星期六上午 02:00。有关 cron 和 rate 表达式的详细信息，请参阅 Systems Manager 文档。

• 第 2 步。Systems Manager Patch Manager 根据定义的配置，通过特定于操作系统的补丁基准定期提供新的补丁。

  • 对于每个操作系统，您可以定义自定义补丁基准，其中包括批准规则和需要应用于整个云环境中实例的补丁。

• 第 3 步。您的自定义自动化代码将 Patch Manager 配置为根据补丁组和维护时段标签设置补丁，并将补丁应用于开发环境。

  • 修补完成后，应用程序开发和支持团队将对应用程序进行测试并验证一切是否正常运行。

  • 如果应用程序在新补丁中遇到任何问题，应用程序团队会要求云服务团队通过禁用维护窗口或取消注册补丁任务执行来停止对其他补丁组和其他环境的修补。

• 第 4 步。成功修补开发环境后，会将补丁部署到任何其他非生产环境中。与开发环境一样，应用程序经过测试和验证，可在所有非生产环境中正常运行。如果有任何问题，应用程序团队会要求云服务团队停止对生产环境的修补。

• 第 5 步。成功修补所有非生产环境后，将对生产环境进行修补。