AWS 上的变更管理指南

实施资源

• 建立变更管理流程

  • 场景
  • 概述
  • 实施

  • 场景

  • 建立变更管理流程

    • 定义变更管理范围、类别、优先级和审批流程
    • 定义变更请求中包含的所需信息
    • 选择用于管理和跟踪变更的变更管理工具
    • 建立变更计划和沟通流程
    • 建立紧急变更部署和解决流程
    • 建立变更审批和沟通流程，以处理在服务之间存在相互依赖关系的变更
  • 概述

  • 变更管理实践旨在减少事故并满足监管标准要求。这些实践可确保高效、及时地处理 IT 基础设施和代码的变更。现代变更管理方法包括推出新服务、管理现有服务、解决代码问题、打破孤岛、提供背景和透明度、消除瓶颈以及最大程度地降低风险。

    变更控制实践可确保正确评测风险、授权变更进行，并管理变更计划以最大程度地增加成功的服务和​​产品变更的数量。

    

    变更管理范围

    变更管理是监控资源配置以建立和管理基线的实践。基线是给定时间点的一组配置的快照。您可以通过此快照识别给定配置项的不同配置状态（特定配置在某个时间点的快照）。变更管理的目的应该是以安全且受控的方法控制对基线所做的更改。需要定义环境基线的范围，使其不会与通过发布管理流程提供自己的变更管理的任何 DevSecOps 实践相冲突。任何不受 DevSecOps 发布管理流程管理的配置都应作为变更管理流程进行跟踪。变更控制的常见配置项包括：

    • 通过手动操作一次性完成的企业范围配置
    • 暂时中止企业范围的策略
    • 用户对组的访问或成员资格变更
    • 影响多个组的集中变更

    注意：DevSecOps 是实施变更的首选方法，应遵循变更控制的一般原则。此功能中定义的变更管理包括 DevSecOps 变更，即使用基础设施即代码将变更实施推进到自动化流程。

    变更管理类别和优先级

    类别
    可以根据感知到的影响程度和紧急程度对变更进行分组和分类。变更分为三个类别：标准、常规和紧急。

    • 标准变更 — 此变更是低风险且易于理解的既定变更；因此，它不需要正式的审查和批准流程。这些变更使用常规变更程序的精简版本，可简化流程，以快速满足变更请求者的需求。例如，当用户请求在您的环境中创建内部存储资源时。此变更请求风险较低，并且通常可以通过自助变更管理履行服务自动执行。标准变更使用变更请求流程提交，并由审批机构 [有时称为变更咨询委员会（CAB）] 审查。
    • 常规变更 — 此变更是独一无二的，预期结果的不确定性风险较高。这通常被定义为默认变更，并且需要正式的审查和审批流程才能启动变更实施。例如，当新服务需要更新防火墙规则以允许来自非标准端口的传入时。
    • 紧急变更 — 此变更解决不可预见的运营问题，例如故障、安全威胁和漏洞。这种类型的变更是继续或恢复业务运营、应对重大风险或解决紧急业务需求所需的快速变更。紧急变更仍应遵循记录的程序并使用组织紧急变更管理流程；但是，通过定义一个较小的审批机构 [通常称为紧急变更咨询委员会（ECAB）]，可以简化审批流程。ECAB 是一个特别小组，负责就批准/拒绝和规划紧急变更提供建议。ECAB 的成员包括具有相关的经验和权力，可承担风险以快速做出决策的人员。

    根据您选择的类别，您需要提供审批流程。标准变更需要正式的审查流程，并获得变更审批机构（例如您将设置的 CAB）的批准。紧急情况需要快速反应；但是，它们仍然需要审批机构。根据您的组织想要承担的风险，应将变更审批记录在案，并且对于日常变更之外的任何事项，都应具有某种类型的审批权限。但是，并非所有变更都需要正式的审查和审批；它们仅需要某种形式的请求提交和自动化审批。随着客户向自动化迈进，变更管理可以以高度自动化和脚本化的方式进行，只需极少的手动输入即可完成。

    注意：任务风险较低的经常性变更应归类为标准和自动审批的变更。变革管理应侧重于赋能，而不应成为实现价值的官僚障碍。

    优先级
    还应定义变更的优先级，以帮助确定其影响力和紧急程度。

    • 影响力衡量事件、问题或变更对业务流程的影响。影响力通常基于服务水平将受到的影响程度。
    • 紧急程度衡量事件、问题或变更需要多长时间才会对业务产生重大影响。例如，如果某个高影响力事件在财政年度结束前不会对业务产生影响，则其紧急程度可能较低。

    创建矩阵来帮助确定变更请求的优先级有助于促进标准化流程，以确定变更的优先级并适当安排变更的实施。
    

    发起变更请求

    变更管理的一个重要部分是变更请求流程、文档和最终用户的变更请求，这些变更请求将启动审查和审批流程。属于变更管理流程范围内的变更需要提交变更请求（RFC）以供审核和审批。变更请求是寻求对变更管理系统范围内的一个或多个配置项进行修改的正式通信。变更请求可以包括以下内容：

    • RFC 文档
    • 服务台呼叫
    • 项目启动文件
    • 由 IT 支持服务生成的票证

    我们建议您确定适用的信息，以支持您的变更控制流程。根据变更类别，变更请求可以捕获不同级别的详细信息。需要捕获的基本信息包括将要更改的服务或配置项、提交变更的人员以及变更的理由。需要捕获足以支持审批机构批准或拒绝变更的信息。下表给出了应在所有 RFC 上捕获的基本信息的示例：

    RFC 数据点	描述
    提交者	启动变更的联系人
    请求日期	提交变更请求的日期
    变更标题	变更的标题
    变更描述	对变更的简要描述
    变更理由	必须提供变更原因
    已确定的风险	已确定的风险及其风险缓解措施的列表
    影响范围	变更将在环境内产生的影响
    日程安排	完成变更的维护时段的日程安排
    建议的实施方案	实施变更的计划
    回滚	必要时回滚变更的计划

    变更沟通

    变更管理流程将完成变更的审查、批准和编排。协调一致的沟通计划是成功的关键要素，有助于在进行 IT 变更时进一步降低风险。如果所有合适的人员（技术经理、业务经理、进行变更的人员和业务用户）都参与其中，提供了所有合适的工具，并且测试了所有合适的后备操作，沟通计划就有助于确保全面而成功的变更。

    该流程的一个重要部分是传达预期的变更，并在必要时协调维护时段以实施变更。变更管理要求，如果变更会影响利益相关者的服务或运营，则向所有利益相关者发出通知。

    变更管理工具

    可以使用手动或自动工具来简化配置和变更管理。工具选择应基于项目利益相关者的需求，包括组织和环境方面的考虑因素和/或要求。

    变更管理工具可以与操作环境集成，以促进实施沟通、变更编排、审批流程以及配置项基线跟踪和监控的工作流程。这种类型的变更管理工具通常需要支持自动化工作流程模板的高级环境设置，并且可能需要进行大量的规划和设置。它们需要了解您要管理的变更范围以及明确定义的变更实施脚本步骤。

  • 实施
  • 定义变更管理的范围、类别、优先级及其审批流程

    您的变更管理框架需要明确定义范围、类别、优先级和批准变更的流程。定义这些领域有助于您控制如何将变更引入 AWS 环境。这是为了确保您的组织清楚了解将在变更管理流程下管理的内容，以及如何提交和批准这些变更。

    范围
    在您的 AWS 环境中，您需要界定通过变更管理流程管理的内容，以及通过使用基础设施即代码（IaC）的持续集成/持续交付（CI/CD）流程管理的内容。变更管理和 CI/CD 流程都是基本变更控制的一部分，需要注意的是，变更管理流程应作为 CI/CD 流程的补充。但是，变更管理和 CI/CD 不应相互重叠或相互阻碍。变更管理流程通过正式组建的变更管理委员会（CAB）定期审批变更。如果它们试图对所有变更都实施 CAB 审批，那么。您的 DevSecOps 团队将会发现其技术速度变慢，进而减缓增长。无论内容如何界定，您环境中的所有变更都应通过审查、审批和沟通方法来管理，这一点十分重要。

    通过变更管理流程进行的变更应被视为需要正式审批和审查的变更。对于您的基线基础环境，AWS 环境中的许多变更都将纳入变更控制的适用范围。但是，随着您的环境逐渐成熟，向更敏捷的 CI/CD 流程转变，您会发现，那些通常只执行一次或影响范围广泛的变更将需要通过正式的变更管理流程来进行。

    在开始使用 AWS 时，我们建议将以下领域纳入变更管理范围：

    1. AWS 服务控制策略的部署或变更
    2. AWS Organization 服务集成支持
    3. 金融购买，例如预留实例或节省计划
    4. AWS Resource Access Management（RAM）
    5. 任何集中式联网配置

    您可以在 AWS 环境中跟踪许多不同的服务。AWS Config 是一项基于区域的托管服务，支持跟踪 AWS 资源基线在一段时间内的变化。该服务可以部署到您环境中的特定账户和区域。可以将其进一步配置为仅监控特定的 AWS 服务。AWS Config 可以帮助您确定您可能要监控哪些服务的变化，以及您想在何处监控这些服务。要查看 AWS Config 跟踪的最新 AWS 服务，请参阅“支持的资源类型”。

    类别
    在定义将在变更管理框架中管理的范围之后，您需要确定要支持的类别，以定义在变更请求履行中提交的变更。在 AWS 中，您可以遵守 ITIL 框架中支持的标准类别。

    • 常规变更：AWS 中已确定的常规变更需要自动执行请求履行，以确保以受控且可预测的方式完成变更。这些任务可以包括授予用户访问权限、创建内部低风险 AWS 资源或对您的 AWS 环境产生的风险较低、影响较小的 AWS 账户级配置变更。常规变更通常可以通过 AWS Service Catalog 或 AWS Systems Manager（SSM）Automation 实现自动化。

    注意：任务风险较低、影响较小的经常性变更应归类为常规和自动审批的变更。变革管理应侧重于赋能，而不应成为实现价值的官僚障碍。
    

    • 标准变更：AWS 中的标准变更需要经过您指定的变更批准委员会（CAB）的正式审查和审批。这些类型的变更应定义它们将影响哪些 AWS 服务、服务将受到何种影响，并提供根据需要实施和回滚的计划。考虑到 AWS 环境中变更的范围，需要提前将 AWS 环境中的标准变更传达给必要的利益相关者。AWS 中的标准变更被视为广泛的一次性变更，其中包括购买节省计划和预留实例、启用 AWS Organization 配置、设置可能影响多个 AWS 账户或服务的 AWS 账户级配置等活动。
    • 紧急变更：AWS 中的紧急变更是指加快实施，以修复持续的运营或安全问题的变更。实施紧急变更仍涉及文档和批准流程；但是，应简化流程以便及时实施。为您的 AWS 环境使用紧急 CAB（ECAB）有助于加快实施速度。AWS 的紧急变更通常需要临时提升对 AWS 账户的权限。

    确定优先级
    变更优先级基于变更的紧急程度和影响力。变更请求者将就初始影响力和紧急程度提出建议。为了帮助变更请求适当地识别影响力和紧急程度，请对其应用矩阵。这有助于加快和记录环境变更。经过进一步评测后，CAB 可以修改或更新初始优先级。

    下表列出了确定变更影响力的标准以及应对各种影响力所需的审批操作：

    影响力等级	定义
    广泛	由于此变更的影响范围较广，因此会对业务服务产生重大影响。此变更将影响多个 AWS 账户或工作负载，进而影响多个面向客户的服务。此 RFC 必须在 CAB 会议上讨论并获得批准。
    重大	会对服务产生显著的影响，因为此变更将影响至少一项面向客户的服务。此 RFC 必须在 CAB 会议上讨论并获得批准。
    中等	对支持面向客户的工作负载的当前服务影响不大，此变更的影响范围不止一个 AWS 账户。
    轻微	此变更的影响范围较小，仅影响一个 AWS 账户，不影响面向客户的工作负载。

    下表列出了确定变更紧急程度的标准：

    紧急程度	需要采取的行动
    严重	此变更必须立即进行，以防止严重的持续或显著的业务影响。此变更将发送给紧急 CAB 进行审批。
    高	此变更需要尽快进行，因为它可能会对服务造成破坏性影响。此变更将在获得批准后立即实施。
    中等	此变更将解决轻微的性能下降或令人烦恼的问题。此变更可以安排，不需要在 CAB 批准后立即进行。
    低	此变更将带来改进、工作流程或配置的变更。 此变更可以安排，不需要在 CAB 批准后立即进行。

    根据紧急程度和标准，可以为任何变更请求确定优先级。以下矩阵将影响力和紧急程度结果关联起来，以定义云环境中变更的优先级。

    优先级标准：
    

    	紧急程度
    影响力	严重	高	中等	低
    广泛	1	1	2	4
    重大	1	2	3	4
    中等	2	2	3	4
    轻微	2	3	3	4

    审批流程
    建立变更咨询委员会（CAB）可以帮助您确定负责审查和审批标准或紧急变更的小组。它是一个咨询机构，支持变更授权，并且可以帮助变更管理团队进行变更评测、优先级排序和日程安排。CAB 还可以批准哪些标准变更可以在不经过 CAB 审查的情况下实施，从而满足每个请求的变更。要定义 CAB 的成员资格，您可以使用云团队，或者让团队的部分成员充当 CAB 的成员。

    云团队可以负责在您的 AWS 环境中建立变更管理审查和批准流程。一个有效的云团队可以从小规模起步，为您的组织制定大规模实施云技术的方法，并且可以成为您的组织改变技术服务业务方式的支点。该团队还可以充当管理机构，负责召集、审查请求的变更、协调、批准和传达变更。

    云团队会在整个组织中推行既定标准，帮助推动组织内部的增值变革，同时识别和减少可能存在的限制性和不必要的官僚流程。此外，云团队还能识别出可归类为标准变更的变更，并开发自动化流程，以自助履行服务变更请求。

    定义变更请求中包含的所需信息

    首次在 AWS 中实施变更管理时，您可以使用现有的变更管理方法手动记录对您的 AWS 环境所做的任何和所有更改。您可能需要更新变更管理流程，以包括 RFC 流程的新数据点。考虑从 RFC 提交流程中收集以下数据点，这些数据点反映了 AWS 特有的关键变更评测细节。

    RFC 数据点	描述	AWS 环境注意事项
    提交者	变更实施的联系人	映射到业务部门或工作负载联系人
    请求日期	提交变更请求的日期
    变更标题	变更的可识别标题
    变更描述	对变更的简要描述
    变更理由	必须进行变更的原因	更改 AWS 账户基线的业务原因
    已确定的风险	已确定的风险及其风险缓解措施的列表	已知风险有哪些，如何在 AWS 环境中缓解或回滚这些风险？
    影响范围	变更将在环境内产生的影响	考虑按 AWS 组织、账户 ID、工作负载或工作负载环境定义范围。定义受影响的用户，例如内部用户或外部客户。
    日程安排	完成变更的维护时段的日程安排	受影响的 AWS 环境中还有哪些其他计划事件在运行
    建议的实施方案	实施变更的计划	AWS 环境中的哪些配置项将发生更改或受到影响
    回滚	必要时回滚变更的计划	所有变更请求都应包括将请求的变更回滚到先前基准的计划。需要制定计划来详细说明和估计时间表。

    确定用于管理和跟踪变更的变更管理工具

    AWS Config
    要管理 AWS 云中的配置项，可以使用 AWS Config 来评测、审计和评估 AWS 资源的配置，让您能够持续监控和记录 AWS 资源配置。借助 AWS Config，您可以跟踪资源之间的关系，并在进行更改之前查看资源依赖关系。发生变更后，您可以快速查看资源的配置历史记录并确定过去任一时间点上的资源配置详情。AWS Config 会向您提供相关信息，以便您评测资源配置变更对其他资源有何影响，从而最大程度地降低与变更相关的事件所产生的影响。

    如果您尚未设置 AWS Config，则可以通过以下方式之一进行设置：

    • 控制台或 CLI — 您可以使用 AWS Config 控制台或 CLI 手动启用 AWS Config。请参阅《AWS Config 开发人员指南》中的 AWS Config 入门。
    • AWS CloudFormation 模板 — 如果您已与 AWS Organizations 集成或想要在大量账户上启用 AWS Config，则可以使用 CloudFormation 模板 Enable AWS Config 轻松启用 AWS Config。要访问此模板，请参阅《AWS CloudFormation 用户指南》中的 AWS CloudFormation StackSets 示例模板。有关使用此模板的更多详细信息，请参阅使用 AWS Config 和 AWS CloudFormation StackSets 管理 AWS Organizations 账户。
    • GitHub 脚本 — Security Hub 在 GitHub 中提供了一个脚本，允许您跨区域启用多个账户。如果您尚未与 Organizations 集成，或者拥有不属于组织的账户，则此脚本很有用。当您使用此脚本启用 Security Hub 时，它还会自动为这些账户启用 AWS Config。

    有关更多信息，请参阅启用和配置 AWS Config，以获取有关在您的环境中部署 AWS Config 的详细说明。根据您定义的范围（关于您将监控哪些配置项以及哪些环境是变更管理的一部分），您应该将 AWS Config 部署到适当的 AWS 账户和区域。

    注意：AWS Config 是一项基于区域的服务，这意味着您需要将 AWS Config 部署到您为 AWS 环境启用的所有适用区域。要部署到多个区域，请使用 AWS CloudFormation 模板和来自 Ops Tooling 账户或您已将 AWS Organizations CloudFormation 服务委托到的任何 AWS 账户的 StackSet 部署。

    注意：注意：对于 AWS Control Tower 用户，在部署 Control Tower 时，将自动完成具有变更管理跟踪的 AWS Config 部署。有关部署及其相关配置的最新详细信息，请参阅 Control Tower 使用 AWS Config 管理资源配置文档。

    部署 AWS Config 后，您可以查看配置项的历史记录。有关最新文档，请参阅关于查看配置历史记录的 AWS Config 文档。可以查询 AWS Config 的数据。

    建立变更计划和沟通流程

    AWS 中的变更计划和沟通要求您的 AWS 运营和开发团队了解即将发生、正在进行和已完成的变更。AWS 现代变更管理的原则是逐一进行许多小的增量变更；这是敏捷开发的核心。对于您的基础环境，您的某些变更将是广泛的，并会影响整个 AWS 组织。这些类型的变更要求您安排和传达变更请求和变更实施。

    您的所有 AWS 账户都应建立电子邮件分发列表，用于通知账户所有者和利益相关者变更详细信息、变更状态以及配置的任何变更监控警报。AWS 提供管理服务和内置联系人以帮助识别这些联系人，并适当地确定您的日程安排和沟通方式。您的云团队应制定变更沟通计划，并在适用于您的 AWS 环境时包括以下一些电子邮件分发组：

    分发组	描述
    [Account-Alias]-ChangeNotification	发送到此分发组的通信将发送给受影响的 AWS 账户的所有利益相关者。
    [Workload]-ChangeNotification	针对在您的环境中运行的 AWS 工作负载创建的分发组。仅当适用的工作负载受到影响时，才会发送此类通信。
    Production-ChangeNotification	发送到此分发组的通信将发送给所有受所有生产账户变更影响的利益相关者。
    Development-ChangeNotification	发送到此分发组的通信将发送给所有受所有开发账户变更影响的利益相关者。
    Sandbox-ChangeNotification	发送到此分发组的通信用于影响您的 AWS 环境中所有沙盒账户的变更。
    AwsOrganization-ChangeNotification	当变更影响在 AWS Organization 中运营的所有账户时，将向此分发组发送通信。

    AWS Simple Notification Service
    Amazon Simple Notification Service（Amazon SNS）是一项用于应用程序到应用程序（A2A）和应用程序到个人（A2P）通信的完全托管型消息服务。使用 AWS SNS 创建和配置主题，这些主题可以针对每个账户的特定利益相关者发送任何变更通知。然后，应通过作为组分发列表的电子邮件地址订阅这些主题。为每个 AWS 账户创建一个 SNS 主题，以传达影响适用 AWS 账户的任何变更详细信息，并使用这些 SNS 主题发送变更监控警报。要配置 SNS 主题，请参阅配置 Amazon SNS。

    AWS 账户备用联系人
    AWS 为每个账户提供标准化的备用联系人，这可以反映当变更影响 AWS 账户时需要通知的直接利益相关者。确保在您的环境中为每个 AWS 账户填写此信息，有助于简化变更沟通过程，并根据受影响的 AWS 账户定位特定的利益相关者群体。

    信息：AWS 使用 AWS 账户备用联系人向联系人发送业务相关通信。请确保您提供适当的联系人，因为 AWS 将根据业务功能联系每位联系人。

    可用的备用联系人基于 AWS 账户的一般业务功能，包括计费、运营和安全。AWS 建议使用电子邮件分发列表，使多个收件人能够通过单个电子邮件地址接收通知。按照访问或更新备用联系人中的说明，为单个账户或使用 AWS Organizations 的所有账户添加、更新或删除备用联系人。

• 定义变更管理请求履行流程

  • 场景
  • 概述
  • 实施

  • 场景

  • 定义变更管理请求履行流程

    • 定义要实施的每个变更管理类别的标准流程
    • 使用标准化流程通过自动化部署变更
    • 制定通用变更管理运行手册
    • 制定预先批准的自动化变更管理模板
    • 将变更管理流程与变更管理履行系统集成
  • 概述

  • 已批准的 RFC 需要经过一个履行过程，其中包括安排和实施已批准的变更。一个关键考虑因素是了解将变更部署到云的风险。变更管理实施过程旨在了解风险并提供风险迁移工作。减轻变更风险的一种行之有效的策略是标准化实施变更类型的方法。组织可以创建自己的运行手册来实施一系列标准化或编码的步骤，包括变更验证和潜在的回滚计划。这样可以确保跨多个环境的可重复性和一致性，并实现软件测试、合规性测试、安全测试和功能测试的自动化。

    变更管理流程应始终致力于自我完善，并丰富其运行手册，以促进更快、风险更低的变更。在编写您自己的运行手册时，您应审视变更分类，尝试将任何常规变更转变为可通过集成变更管理服务或解决方案实现自助服务的自动化标准变更。

  • 实施
  • 定义要实施的每个变更管理类别的标准流程

    AWS 中的标准变更
    AWS 中已确定的标准变更需要自动执行请求履行，以确保以受控且可预测的方式完成变更。AWS 提供 AWS Systems Manager Automation 运行手册，使您的团队能够基于脚本、API 操作、AWS Lambda 函数、AWS Step Functions 和其他各种 AWS 自动化服务创建工作流。

    AWS 中的常规变更
    在基础环境中，常规变更通常在经过协调并沟通的变更或维护时段内手动实施。这些变更应通过您建立的 RFC 流程进行，并由 CAB 进行审核和审批。常规变更应在变更之前传达给您环境中的相应 AWS 账户利益相关者。成功实施变更后，应向相同的利益相关者传达变更结束信息。确定经常性常规变更的类型后，您应该努力创建可以安全满足变更请求的 AWS SSM Automation 运行手册。

    AWS 中的紧急变更
    在 AWS 中，紧急变更是指需要尽快实施以修复受影响服务的变更。此类变更是手动实施的，并且通常需要在您的环境中获得更高的访问权限，并且可以通过在受影响的 AWS 账户或环境中正确设置紧急访问权限来完成。在紧急变更下实施的变更应由紧急变更咨询委员会（ECAB）团队成员（CAB 小组成员）进行审核和审批。审批紧急变更的 ECAB 成员必须能够承担审批变更的责任，而无需召集 CAB 进行审批。

    使用标准化流程通过自动化部署变更

    Systems Manager Automation
    使用 AWS Systems Manager，您可以自动执行操作任务，以帮助提高团队的效率，并创建标准化流程来实施归类为标准的变更。借助具有丰富文本描述的自动批准工作流和运行手册，您可以减少人为错误、实施风险缓解操作并简化对 AWS 资源实施变更的流程。您可以使用预定义的自动化运行手册，也可以构建自己的手册来共享常见的操作任务，例如停止和重新启动 EC2 实例。Systems Manager 还具有内置的安全控件，使您能够逐步推出变更，并在发生错误时自动停止推出。

    使用 AWS 提供的预定义 SSM 自动化运行手册将帮助您初步确定环境中的常规变更，并确定您可以通过 SSM Automation 使用自助变更履行流程实施的任务。首先登录 SSM Web 控制台（需要登录），然后在左侧垂直菜单下的共享资源链接下进行搜索，以查看可用的 AWS SSM 文档列表。要寻找其他搜索 AWS 提供的预定义 SSM 文档的方法，请参阅搜索 SSM 文档。

    SSM 文档促进了代码化管理，用于远程管理实例，确保资源处于所需状态，并自动化 IT 运营。您可以使用预定义的文档，或者以 JSON 或 YAML 格式创作自己的文档。您的变更管理流程应该首先从使用提供的 SSM 文档开始，以帮助部署您的常规变更。

• 从失败的变更操作中恢复

  • 场景
  • 概述
  • 实施

  • 场景

  • 从失败的变更操作中恢复

    • 将应急规划融入失败变更的变更管理流程
    • 定义为从失败的变更中恢复而采取的补救措施的标准
    • 自动检测失败的变更并从中恢复
  • 概述

  • 在批准变更之前，必须考虑到失败或性能下降的后果。应当制定回退或回滚计划，用于将资源恢复到实施变更之前的初始基线配置。云环境允许使用可重复的过程来完全自动化回滚计划。并非所有变更都是可逆的。然而，恢复失败变更的过程应当被记录下来，并且在批准变更时接受相关风险。如果由于回滚的速度和一致性，失败变更的影响较小，那么应将激活回滚视为正常流程的一部分。特别是当有可能迅速解决问题并通过相同的自动化流程进行推送，以快速实现变更原本预期的业务价值时，这一点尤为重要。

  • 实施
  • 将应急规划融入失败变更的变更管理流程

    对 AWS 资源的变更应当为您的环境带来积极影响，并符合您在 RFC 中定义的预期结果。任何会对 AWS 环境产生不利影响的变更都应当被回滚，以将受影响的资源恢复到先前的基线状态。

• 建立评测、审查和监控变更的机制

  • 场景
  • 概述
  • 实施

  • 场景

  • 建立评测、审查和监控变更的机制

    • 评测和评估变更的影响
    • 跟踪环境基线变更
    • 监控环境基线中的变更
    • 审计所有变更管理活动和时间表
  • 概述

  • 应监控和跟踪变更管理范围内的所有变更，包括环境中已批准的和未批准的变更。已批准并实施的每项变更都应对整体服务产生积极影响，如提升环境的安全性或性能。对于已跟踪且对环境产生不利影响的变更，应立即进行回滚，以将基线恢复至其先前状态。持续监控基线并对配置项变更发出警报是为了确保环境中引入的所有变更都受到控制。对于未通过管理流程实施的变更，需要跟踪其来源并将其恢复到先前的基线状态，或在变更管理系统中进行记录。

  • 实施
  • 评测和评估变更的影响

    对于 AWS 环境中的每项变更，您都需要进行评测以确保其正确完成，然后进行监控以确保不会对资源实施任何未经过变更管理流程的变更。

    AWS Config 聚合器高级查询
    AWS Config 提供基于单个账户和 AWS 区域或多个 AWS 账户和区域的配置属性查询 AWS 资源当前配置状态的功能。您可以根据需要，针对当前 AWS 资源状态元数据在 AWS Config 支持的资源列表中执行基于属性的查询。

    要集中评测在 AWS 环境中所做的变更，请使用 AWS Organization 与 AWS Config 的集成，并在安全工具账户中设置 AWS Config 聚合器。有关更多信息，请参阅多账户、多区域数据聚合。

    重要提示：如果您使用的是 AWS Control Tower，则在部署 Control Tower 时，将自动完成 AWS Config 聚合器部署。参考 Control Tower 的 AWS Control Tower 工作原理文档，查看审计账户服务以获取有关部署及其相关配置的最新详细信息。

    一旦聚合器被委托并配置完成，所有 AWS Config 数据都将返回至集中的委托账户。如果成员账户中未设置 AWS Config 服务，则聚合器不会收集该账户的详细信息。委托 AWS Config 聚合器并不会在成员账户中设置 AWS Config；它仅在存在 AWS Config 数据时读取数据。

    通过 AWS Config 聚合器，您可以对报告的数据编写自定义查询，这样就可以查看所有配置的当前状态。AWS Config 聚合器数据使您能够评测和验证资源配置的当前状态，以确认变更是否已正确执行。有关如何在 AWS 管理控制台或 AWS 命令​​行界面（AWS CLI）中创建自己的 AWS Config 高级查询的详细信息，请参阅查询 AWS 资源的当前配置状态。

    CloudTrail
    AWS CloudTrail 是一项 AWS 服务，可帮助您实现 AWS 账户的运营和风险审计、治理和合规性。用户、角色或 AWS 服务采取的操作将作为事件记录在 CloudTrail 中。事件包括在 AWS 管理控制台、AWS 命令​​行界面以及 AWS SDK 和 API 中执行的操作。可以筛选这些事件，以识别在变更控制下对 AWS 资源所做的更改或修改。

    CloudTrail 在您的 AWS 账户中默认启用，并跟踪所有管理活动。当您的 AWS 账户中发生活动时，该活动将记录在 CloudTrail 事件中。如果不创建跟踪，CloudTrail 会将事件存储 90 天。您可以通过转到事件历史记录轻松查看 CloudTrail 控制台中的近期事件。要使 CloudTrail 事件在您的 AWS 账户中的保留时长超过默认时间（90 天），并允许集成其他服务（例如 CloudWatch Logs），请参阅 AWS CloudTrail 文档中的创建跟踪。
    

    重要提示：如果您使用的是 AWS Control Tower，则在部署 Control Tower 时，可以自动完成 CloudTrail 部署。有关部署及其相关配置的最新详细信息，请参阅 Control Tower 使用 CloudTrail 监控事件文档。
    

    Amazon CloudWatch
    Amazon CloudWatch 是一种专门为 DevOps 工程师、开发人员、站点可靠性工程师（SRE）、IT 经理和产品拥有者设计的监控和可观测性服务。CloudWatch 为您提供相关数据和切实洞察，以监控应用程序、响应系统范围的性能变化并优化资源利用率。CloudWatch 以日志、指标和事件的形式收集监控和运营数据。这些数据可用于监控资源是否存在变更或变更带来的不利影响。

    CloudTrail 跟踪可以将事件数据发送到 CloudWatch Logs，以分析和检测会更改 AWS 资源的事件。有关将 AWS CloudTrail 设置为 Amazon CloudWatch Logs 的详细指导，请参阅 AWS CloudTrail 文档中的将事件发送到 CloudWatch Logs。创建警报以查找 AWS 资源（例如 VPC、AWS IAM 实体、网络 ACL、安全组、CloudTrail 变更等）上的创建、更新或删除活动。

    跟踪环境基线变更

    您定义的变更管理流程范围内的所有变更都应引入计划内和受控的变更。需要识别、评测未经过变更控制流程实施的变更，并将其重新引入变更管理流程，以控制和降低风险。AWS Config 提供了跟踪变更并集中向利益相关者报告这些变更的功能。

    AWS Config 交付渠道

    重要提示：如果您使用的是 AWS Control Tower，则在部署 Control Tower 时，将自动完成带有变更通知的 AWS Config 部署。使用 SNS 主题 aws-controltower-AllConfigNotifications 可以向集中来源报告环境内的任何变更。有关最新详细信息和配置，请参阅 Control Tower 的 SNS 的 Guardrail 合规性通知文档。

    由于 AWS Config 会持续记录您的 AWS 资源发生的变更，因此它会通过交付渠道发送通知和更新的配置状态，这些通知和配置状态可以定位到您的变更管理分发组。您可以管理交付渠道以控制 AWS Config 发送配置更新的位置。仅当 AWS Config 检测到资源基线发生变更时，才会发送通知。使用 AWS Config 交付渠道时，您应将正在部署的受控变更与资源变更通知同步。此外，当没有安排变更时，通知交付可以告知您的团队，存在未通过变更管理流程进行的变更。需要跟踪并评测这类未经授权的变更（如果在监控范围内且未归类为常规变更），以查明变更者、变更原因，以及如何将该变更纳入已记录在案的变更流程。

    注意：AWS Config 是一项基于区域的服务，这意味着您需要将 AWS Config 部署到您为 AWS 环境启用的所有区域。
    

    设置 AWS Config 时，必须创建一个配置记录器和一个交付渠道。交付渠道需要有一个 S3 存储桶来存储历史数据，以实现持久的日志存储。您可以在 AWS 环境中部署一个集中式日志解决方案，而不必为每个交付渠道单独设置 S3 存储桶。请参阅日志存储功能。交付渠道允许您为其分配 SNS 主题，并将这些变更通过电子邮件发送给订阅了该 SNS 主题的任何邮箱。使用在 CF30 — S1：建立变更计划和沟通流程部分创建的 [Account-Alias]-ChangeNotification，将其应用于交付渠道。AWS Config 记录器监控的任何 AWS 资源变更都会通过电子邮件发送给电子邮件分发组的成员。