本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 可变 EC2 实例的修补解决方案设计
<a name="design-standard"></a>

可变实例的修补过程涉及以下团队和操作：
+ **应用程序 (DevOps) 团队**根据应用程序环境、操作系统类型或其他标准为其服务器定义补丁组。它们还定义了每个补丁组特定的维护窗口。此信息存储在 EC2 应用程序实例的**补丁组**和**维护窗口**标签上。在每个补丁周期中，应用程序团队都要为修补做准备，在修补后测试应用程序，并在修补期间对应用程序和操作系统的任何问题进行故障排除。
+ **安全运营团队**为应用团队使用的各种操作系统类型定义补丁基准，批准补丁，并通过 Systems Manager Patch Manager 提供补丁。
+ **自动修补解决方案**定期运行，并根据用户定义的补丁组和维护窗口部署补丁基准中定义的修补程序。补丁合规性信息通过 Systems Manager 清单中的资源数据同步获取，并用于通过快速控制面板报告补丁合规性。
+ **治理和合规团队**定义补丁指南，定义例外流程和机制，并从 Quick 获取合规报告。

欲详细了解成功的操作系统补丁管理解决方案所涉及的主要利益相关者及其职责，请参阅本指南后面的[关键利益相关者、角色和职责](stakeholders.md)一节。

## 自动化流程
<a name="standard-auto-process"></a>

自动修补解决方案使用多项协同工作的 AWS 服务将补丁部署到 EC2 实例。此过程涉及 AWS Config、 AWS Lambda、Systems Manager、亚马逊简单存储服务 (Amazon S3) 和 Quick。下图演示了参考架构和工作流程。

 ![\[Reference architecture and workflow for a standard mutable EC2 instance patching process\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/patch-management-hybrid-cloud/images/patching-process-standard.png) 

该工作流程包括以下步骤，其中步骤编号与图表中的标注相匹配：

1. AWS Config 持续监控以下内容，并发送包含不合规实例和所需配置的详细信息的通知：
   + 修补 EC2 实例的标签合规性。 AWS Config 检查是否有没有**补丁组**和**维护**时段标签的实例。
   + 具有 Systems Manager 角色的 AWS Identity and Access Management (IAM) 实例配置文件，允许系统管理员管理实例。

1. Lambda 函数（我们称之为`automate-patch`）按预定义的计划运行，并收集所有服务器的**补丁组**和**维护窗口**信息。

1. 然后，`automate-patch` 函数创建或更新相应的补丁组和维护窗口，将补丁组与补丁基准关联起来，配置补丁扫描并部署修补任务。或者，该`automate-patch`函数还会在 Amazon Events 中创建 CloudWatch 事件，以通知用户即将发布的补丁。

1. 根据维护窗口，这些事件会向应用程序团队发送补丁通知，其中包含即将进行的修补操作的详细信息。

1. Patch Manager 根据定义的时间表和补丁组执行系统修补。

1. Systems Manager Inventory 中的资源数据同步会收集修补详细信息并将其发布到 S3 存储桶。

1. 补丁合规性报告和仪表板内置于 S3 存储桶信息的 Quick 中。