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

# 升级推出政策
<a name="orgs_manage_policies_upgrade_rollout"></a>

AWS Organizations 升级推出策略允许您集中管理和错开组织中多个 AWS 资源和帐户的自动升级。通过这些策略，您可以定义资源接受升级的顺序，从而确保更改在进入生产之前在不太重要的环境中得到验证。

在当今复杂的云环境中，管理大量资源和账户的升级可能具有挑战性。升级推出政策通过提供实施升级的系统方法来应对这一挑战。通过使用这些政策，您可以使升级过程与组织的变更管理实践保持一致，从而降低风险并提高运营效率。

升级推出策略利用的分层结构 AWS Organizations 将策略应用于整个组织或特定组织单位 (OUs)。这种集成允许您大规模管理升级，无需手动协调或自定义自动化脚本。

## 主要功能和优势
<a name="orgs_manage_policies_upgrade_features_benefits"></a>

升级推出策略为管理升级提供了全面的功能，同时为跨多个账户和环境管理资源的组织提供了显著的优势。下表概述了主要功能及其相关优势：


**升级推出政策的特点和优势**  
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/organizations/latest/userguide/orgs_manage_policies_upgrade_rollout.html)

有关策略继承的更多信息，请参阅[了解管理策略继承](orgs_manage_policies_inheritance_mgmt.md)。

## 什么是升级推出政策？
<a name="orgs_manage_policies_upgrade_rollout_what_are"></a>

升级推出策略是一组规则，用于确定如何以及何时将自动升级应用于您的 AWS 资源。这些策略允许您为资源指定不同的升级顺序，通常与您的开发、测试和生产环境保持一致。通过这样做，您可以确保首先将升级应用于不太重要的系统，从而使您能够在任何问题影响生产工作负载之前发现并解决这些问题。

这些策略支持三个升级订单：第一个、第二个和最后一个。这些命令创建了一种分阶段的升级方法，指定为 “第一” 的资源最初接受升级，然后在等待期后获得 “第二”，在另一个等待期之后最后是 “最后”。这种错开的方法使您有时间在升级进入更关键的系统之前在每个阶段对其进行验证。

升级推出政策对于具有复杂的多账户结构或具有严格变更管理要求的组织特别有价值。它们在维护 up-to-date系统和最大限度地降低与升级相关的关键服务中断风险之间取得了平衡。

## 升级推出政策的工作原理
<a name="orgs_manage_policies_upgrade_rollout_how_work"></a>

升级推出策略可与您的现有 AWS 基础架构和流程无缝集成。当您创建升级推出策略并将其附加到组织单位时，该策略将应用于该组织单位内的所有账户。然后，您可以使用资源标签或补丁单来指定应按哪个顺序升级哪些资源。

当支持的 AWS 服务发布升级时，它会参考升级推出政策，以确定资源应按何种顺序接收升级。该服务首先在配置的维护时段内将升级应用于标记为 “第一” 的资源。在服务特定的等待期（通常为一周左右）之后，标记为 “第二” 的资源将有资格进行升级。最后，经过另一个等待期，标记为 “Last” 的资源将获得升级。

此过程可确保以可控、可预测的方式在整个组织中应用升级。它允许您在每个阶段监控升级的影响，并在更改到达最关键的环境之前根据需要采取纠正措施。此过程的自动化性质减少了管理升级的运营开销，同时仍为您提供维护 AWS 资源稳定性和安全性所需的控制和可见性。

## 术语
<a name="orgs_manage_policies_upgrade_syntax_terminology"></a>

以下是您在使用升级推出策略时应了解的关键术语：


**升级推出政策条款**  

| 租期 | 定义 | 
| --- | --- | 
| 活跃日期 | amVu 在 “描述待处理的维护操作” API 中变为可见并可供应用程序使用的日期。 | 
| amVu（自动次要版本升级） | 数据库引擎次要版本的自动升级过程。 | 
| 有效策略 | 在考虑所有继承和直接关联的策略后，适用于账户或资源的最后一组规则。 | 
| 维护窗口 | 可以对资源应用自动升级的重复时间段。升级推出策略在这些配置的维护时段内起作用。 | 
| 组织部门（OU） | 组织中 AWS 账户的容器。可以在 OU 级别附加升级推出政策，以影响其中的所有账户。 | 
| 补丁顺序 | 资源获得升级的顺序（第一个、第二个、最后一个）。 | 
| 政策目标 | 升级推出政策的适用范围，可以是整个组织 OUs、特定账户或个人账户。 | 
| 资源标签 | 键值对，可用于确定哪些资源应遵循策略中的特定升级顺序。 | 
| 日程安排窗口 | 特定补丁顺序的资源获得升级的时间范围。 | 
| 特定服务的等待期 | 升级不同升级顺序的资源之间的指定时间间隔。此期限因 AWS 服务和升级类型而异。 | 
| 升级顺序 | 一种指定，用于确定资源何时获得相对于其他资源的升级。可以设置为 “第一个”、“第二个” 或 “最后一个”。 | 
| 升级推出政策 | 用于管理跨资源的升级计划的 AWS Organizations 策略类型。 | 

## 升级推出策略的用例
<a name="orgs_manage_policies_upgrade_rollout_use_cases"></a>

不同规模和行业的组织可以从升级推出政策中受益。以下虚拟场景演示了常见的升级管理难题以及升级推出策略如何提供有效的解决方案。这些示例基于典型的客户体验，但经过简化以突出关键优势和实施模式。

许多组织面临着类似的挑战：他们需要将资源 up-to-date保留在最新版本上，同时最大限度地降低生产环境的风险。如果没有基于策略的集中式方法，团队通常会诉诸手动流程或复杂的自动化脚本。以下示例演示了两个不同的组织如何使用升级推出策略来解决类似的难题：

### 示例用例：全球金融服务公司
<a name="orgs_manage_policies_upgrade_rollout_use_case_financial"></a>

一家金融服务公司在多个账户中运营着数百个 Aurora PostgreSQL 数据库。 AWS 在制定升级推出政策之前，他们的 DevOps 团队每月花几天时间手动协调数据库升级，确保更改在进入生产系统之前在开发环境中进行测试。通过实施升级推出政策，他们：
+ 使用升级顺序标记为 “First” 的开发数据库
+ 已将 QA 数据库分配到升级顺序 “第二”
+ 将生产数据库指定为升级顺序 “Last”
+ 将升级协调时间从几天缩短到几分钟
+ 首先在较低的环境中自动验证更改
+ 保持对变更管理要求的合规性

### 示例用例：物联网设备平台提供商
<a name="orgs_manage_policies_upgrade_rollout_use_case_iot"></a>

一家物联网公司每天使用多个 Amazon RDS 数据库处理数百万个设备事件。他们需要确保自动次要版本升级不会中断其生产服务。使用升级推出策略，他们：
+ 制定了适用于其组织结构的政策
+ 已将金丝雀环境配置为先接收升级
+ 在早期升级环境中设置监控
+ 在产品升级之前，有时间检测和响应任何问题
+ 用简单的策略取代了复杂的自定义升级自动化
+ 保持其生产工作负载的高可用性，同时保持数据库版本的最新状态

## 支持的 AWS 服务
<a name="orgs_manage_policies_upgrade_services"></a>

升级推出策略与以下 AWS 服务集成，同时支持自动次要版本升级：


**升级推出策略支持的服务**  

| 服务名称 | 用途 | 
| --- | --- | 
| Amazon Aurora PostgreSQL 兼容版 | [自动次要版本升级](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html#Aurora.Maintenance.AMVU) | 
| Amazon Aurora MySQL 兼容版 | [自动次要版本升级](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html#Aurora.Maintenance.AMVU) | 
| 适用于 PostgreSQL 的亚马逊关系数据库服务 | [自动次要版本升级](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.PostgreSQL.Minor.html) | 
| 适用于 SQL Server 的 Amazon Relational Database Service | [自动次要版本升级](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.SQLServer.html) | 
| 适用于 Oracle 的亚马逊关系数据库 Service | [自动次要版本升级](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.Oracle.Minor.html#oracle-minor-version-upgrade-tuning-on) | 
| 适用于 MariaDB 的亚马逊关系数据库服务 | [自动次要版本升级](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.MariaDB.Minor.html) | 
| 适用于 MySQL 的亚马逊关系数据库服务 | [自动次要版本升级](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.MySQL.Minor.html) | 
| 适用于 Db2 的亚马逊关系数据库服务 | [自动次要版本升级](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Db2.Concepts.VersionMgmt.html) | 

## 先决条件
<a name="orgs_manage_policies_upgrade_rollout_prerequisites"></a>

以下是在中管理升级推出策略所需的先决条件和必需权限： AWS Organizations
+ AWS Organizations 管理账户或委派管理员访问权限
+ 支持的服务（目前为 Amazon Aurora 和亚马逊关系数据库服务数据库引擎）中的资源
+ 管理升级推出策略的正确 IAM 权限

## 后续步骤
<a name="orgs_manage_policies_upgrade_rollout_next_steps"></a>

要开始使用升级推出策略，请执行以下操作：

1. 查看[升级推出政策入门](orgs_manage_policies_upgrade_getting_started.md)以了解如何创建和管理策略

1. 探索如何[使用升级推出策略的最佳实践](orgs_manage_policies_upgrade_best_practices.md)实施升级推出政策

1. 明白 [升级推出策略语法和示例](orgs_manage_policies_upgrade_syntax.md)

# 升级推出政策入门
<a name="orgs_manage_policies_upgrade_getting_started"></a>

按照以下步骤在您的组织中实施升级推出政策。每个步骤都链接到详细信息，以帮助您成功完成实施。

## 开始前的准备工作
<a name="orgs_manage_policies_upgrade_getting_started_prerequisites"></a>

确保您具备以下条件：
+ 对的管理访问权限 AWS Organizations
+ 支持的 AWS 服务（例如 Aurora 或 Amazon Relational Database Service）中的资源
+ 已配置必要的 IAM 权限

## 实现步骤
<a name="orgs_manage_policies_upgrade_getting_started_steps"></a>

1. [为您的组织启用升级推出政策。](enable-policy-type.md)

1. [了解升级推出政策的工作原理。](orgs_manage_policies_upgrade_rollout.md#orgs_manage_policies_upgrade_rollout_how_work)
   + 识别开发、测试和生产环境
   + 确定哪些资源应该先升级、第二次升级、最后一次升级
   + 记录您的标记策略以进行资源识别

1.  [创建升级推出策略](orgs_policies_create.md#create-upgrade-rollout-policy-procedure): 
   + 定义默认部署顺序（组织单位或账户级别）
   + 使用标签指定资源定位
   + 配置所有策略排除项

1. [将升级推出政策附加到可用于测试的单个成员账户。](orgs_policies_attach.md) : 
   + 从测试组织单元开始
   + 验证策略继承
   + 确认策略附件状态

1. 根据您的升级顺序策略标记您的资源：
   + 将标签应用于开发资源以进行首次升级
   + 标记用于二阶升级的测试资源
   + 为最后一笔订单升级指定生产资源

1. 监控和验证策略：
   + 查看升级订单分配
   + 验证策略对测试资源的影响

1. 测试升级过程：
   + 等待服务升级可用
   + 在您的环境中监控升级进度
   + 验证升级是否遵循您的指定顺序

1. 根据需要为其他组织单位启用升级推出策略

**其他信息**
+ [了解升级推出策略语法并查看策略示例](orgs_manage_policies_upgrade_syntax.md)

# 使用升级推出策略的最佳实践
<a name="orgs_manage_policies_upgrade_best_practices"></a>

AWS 为使用升级推出策略推荐了以下最佳实践。

**Topics**
+ [从小规模开始，逐步扩展规模](#orgs_manage_policies_upgrade_best_practices_scale)
+ [建立审查流程](#orgs_manage_policies_upgrade_best_practices_review)
+ [有效验证政策变更](#orgs_manage_policies_upgrade_best_practices_validate)
+ [监控和传达变更](#orgs_manage_policies_upgrade_best_practices_monitor)
+ [维护合规性和安全性](#orgs_manage_policies_upgrade_best_practices_compliance)
+ [优化运营效率](#orgs_manage_policies_upgrade_best_practices_optimize)

## 从小规模开始，逐步扩展规模
<a name="orgs_manage_policies_upgrade_best_practices_scale"></a>

在非关键环境中，先将测试策略附加到单个账户。这种方法使您能够验证升级推出策略的行为和影响，而不会造成关键工作负载中断的风险。确认该政策按预期运行后，请逐步将其向上移动组织结构，以包括更多的账户和组织单位。

这种渐进式扩展有助于您在实施过程的早期发现和解决任何问题。考虑创建一组试点资源，既能代表环境的多样性，又能将运营风险降至最低。记录每个扩展阶段的结果，为未来的政策推出和调整提供信息。

## 建立审查流程
<a name="orgs_manage_policies_upgrade_best_practices_review"></a>

实施定期审查流程，以监控新的升级推出策略属性并评估政策异常。这些审查应符合贵组织的安全和运营要求。制定审查政策有效性的时间表，并保存所做任何调整的文档。

您的审查流程应包括定期评估哪些资源受政策管辖，验证升级订单是否符合您的预期策略，以及评估任何政策例外情况。考虑为何时需要更新策略制定标准，并维护变更日志，以跟踪策略随时间的演变。

## 有效验证政策变更
<a name="orgs_manage_policies_upgrade_best_practices_validate"></a>

对升级推出政策进行更改后，请查看组织各个级别的代表性客户的有效政策。使用 AWS 管理控制台或 `DescribeEffectivePolicy` API 操作来验证您的更改是否产生了预期影响。这种验证应包括检查不同组织单位的资源，并确认继承是否按预期进行。

要特别注意分配了明确升级命令的资源，而不是使用默认值的资源。制定验证清单，包括验证基于标签的定位、确认维护时段对齐以及测试策略继承。

## 监控和传达变更
<a name="orgs_manage_policies_upgrade_best_practices_monitor"></a>

对您的升级推出政策进行全面监控，并为共享升级相关信息创建清晰的沟通渠道。记录处理升级失败的明确程序，并针对不同的情况制定响应计划。

与管理受升级政策影响的资源的团队保持定期沟通。可以考虑创建仪表板，以便了解即将进行的升级及其在您的环境中的预期进展。

## 维护合规性和安全性
<a name="orgs_manage_policies_upgrade_best_practices_compliance"></a>

定期审核您的升级推出政策，确保它们符合您的合规性要求。记录所有政策决策，并清晰记录升级模式和异常情况。围绕策略修改实施安全控制，并使用对策略变更进行审计跟踪 AWS CloudTrail。

定期查看策略管理功能的访问权限，并对策略管理实施最低权限访问权限。创建紧急策略修改程序，并保存与安全相关的升级要求的文档。

## 优化运营效率
<a name="orgs_manage_policies_upgrade_best_practices_optimize"></a>

设计您的策略以最大限度地减少运营开销，同时保持必要的控制。为防止意外行为，请勿在不同的用例中重复使用标签。尽可能自动检查策略合规性，并为常见的策略管理任务创建标准操作程序。

考虑为不同类型的升级方案创建模板，并保留成功策略模式的文档。定期审查运营指标可以帮助确定政策优化和流程改进的机会。

# 升级推出策略语法和示例
<a name="orgs_manage_policies_upgrade_syntax"></a>

升级推出策略定义了 AWS 服务如何对您的资源进行自动升级。了解策略语法有助于您创建符合组织升级要求的有效策略。

**Topics**
+ [注意事项](#orgs_manage_policies_upgrade_syntax_considerations)
+ [基本策略结构](#orgs_manage_policies_upgrade_syntax_structure)
+ [策略组件](#orgs_manage_policies_upgrade_syntax_components)
+ [升级推出策略示例](#orgs_manage_policies_upgrade_syntax_examples)

## 注意事项
<a name="orgs_manage_policies_upgrade_syntax_considerations"></a>

在实施升级推出策略时，请考虑以下重要因素：
+ 策略名称在您的组织中必须是唯一的，并且应清晰且具有描述性。选择能反映政策目的和范围的名称。有关更多信息，请参阅 [优化运营效率](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_optimize)。
+ 在广泛部署之前，测试至关重要。首先在非生产环境中验证新策略，然后逐步扩展以确保所需的行为。有关更多信息，请参阅 [从小规模开始，逐步扩展规模](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_scale)。
+ 政策变更可能需要几个小时才能在整个组织中传播。相应地规划您的实施，并确保进行适当的监控。有关更多信息，请参阅 [监控和传达变更](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_monitor)。
+ JSON 格式必须有效，并且保持在 5,120 字节的最大策略大小之内。在满足您的要求的同时，尽可能简化政策结构。
+ 定期的政策审查有助于保持有效性。安排对您的政策进行定期评估，以确保它们继续满足您的组织需求。有关更多信息，请参阅 [建立审查流程](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_review)。
+ 未分配升级顺序的资源默认为 “第二” 顺序。考虑为关键资源明确设置升级顺序，而不是依赖默认值。有关更多信息，请参阅 [有效验证政策变更](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_validate)。
+ 手动升级优先于策略定义的升级订单。确保您的变更管理流程同时考虑自动和手动升级方案。有关更多信息，请参阅 [建立审查流程](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_review)。

**注意**  
在管理账户中实施基于标签的升级推出策略时，请注意，管理账户无法直接查看或访问成员账户中的资源级标签。我们建议建立一个流程，让成员账户应用一致的资源标签，然后创建引用这些标签的组织级策略。这确保了资源级标记和组织策略实施之间的适当协调。在整个组织中[标签策略](orgs_manage_policies_tag-policies.md)对资源进行标记时，您还可以使用来帮助保持标签的一致性。

## 基本策略结构
<a name="orgs_manage_policies_upgrade_syntax_structure"></a>

升级推出策略使用包含以下主要元素的 JSON 结构：
+ 策略元数据（例如版本信息）
+ 资源定位规则
+ 升级订单规格
+ 可选的异常消息
+ 特定于服务的属性

以下示例显示了基本的升级部署策略结构：

```
{
   "upgrade_rollout":{
      "default":{
         "patch_order":{
            "@@assign":"last"
         }
      },
      "tags":{
         "devtag":{
            "tag_values":{
               "tag1":{
                  "patch_order":{
                     "@@assign":"first"
                  }
               },
               "tag2":{
                  "patch_order":{
                     "@@assign":"second"
                  }
               },
               "tag3":{
                  "patch_order":{
                     "@@assign":"last"
                  }
               }
            }
         }
      }
   }
}
```

## 策略组件
<a name="orgs_manage_policies_upgrade_syntax_components"></a>

升级推出策略由两个关键组件组成，它们协同工作以控制如何在您的资源中应用升级。这些组件包括默认行为和基于标签的覆盖的配置选项。了解这些组件的交互方式有助于您制定符合组织需求的有效策略。

### 默认补丁顺序设置
<a name="orgs_manage_policies_upgrade_syntax_components_default"></a>

当您在不指定任何资源特定覆盖的情况下创建升级推出策略时，所有资源都默认为基本升级顺序。您可以使用策略中的 “默认” 字段设置此默认值。没有通过标签明确分配升级顺序的资源将遵循此默认顺序。

**注意**  
当今的主机体验需要指定默认顺序。

以下示例说明如何将所有资源设置为在默认情况下最后接收升级，除非被标签覆盖。当您想要确保大多数资源在升级周期的后期更新时，这种方法非常有用：

```
"upgrade_rollout": {
    "default": {
        "patch_order": "last"
    }
}
```

### 通过标签覆盖资源级别
<a name="orgs_manage_policies_upgrade_syntax_components_tags"></a>

您可以使用标签覆盖特定资源的默认升级顺序。这使您可以精细控制哪些资源按哪个顺序接受升级。例如，您可以根据环境类型、开发阶段或工作负载重要程度分配不同的升级顺序。

以下示例说明如何将开发资源配置为先接收升级，将生产资源配置为最后接收升级。此配置可确保您的开发环境可以在升级进入生产环境之前对其进行验证：

```
"upgrade_rollout": {
    "tags": {
        "environment": {
            "tag_values": {
                "development": {
                    "patch_order": "first"
                },
                "production": {
                    "patch_order": "last"
                }
            }
        }
    }
}
```

## 升级推出策略示例
<a name="orgs_manage_policies_upgrade_syntax_examples"></a>

以下是常见的升级推出策略方案：

### 示例 1：首先是开发环境
<a name="orgs_manage_policies_upgrade_syntax_example1"></a>

此示例说明如何在开发环境中配置资源以首先接收升级。通过定位带有 “开发” 环境标签的资源，可以确保您的开发环境是第一个接收和验证新升级的环境。此模式有助于在升级到达更关键的环境之前识别潜在的问题：

```
{
    "tags": {
        "environment": {
            "tag_values": {
                "development": {
                    "upgrade_order": "first"
                }
            }
        }
    }
}
```

### 示例 2：生产环境最后一个
<a name="orgs_manage_policies_upgrade_syntax_example2"></a>

此示例演示如何确保您的生产环境最后获得升级。通过将带有生产标签的资源明确设置为上次升级顺序，可以保持生产环境的稳定性，同时允许在预生产环境中进行充分的测试。这种方法对于具有严格变更管理要求的组织特别有用：

```
{
    "tags": {
        "environment": {
            "tag_values": {
                "production": {
                    "upgrade_order": "last"
                }
            }
        }
    }
}
```

### 示例 3：使用标签的多个升级订单
<a name="orgs_manage_policies_upgrade_syntax_example3"></a>

以下示例演示如何使用具有不同值的单个标签键来指定所有三个升级顺序。当您想通过单一标记方案管理升级订单时，这种方法非常有用：

```
{
   "upgrade_rollout":{
      "default":{
         "patch_order":{
            "@@assign":"last"
         }
      },
      "tags":{
         "devtag":{
            "tag_values":{
               "tag1":{
                  "patch_order":{
                     "@@assign":"first"
                  }
               },
               "tag2":{
                  "patch_order":{
                     "@@assign":"second"
                  }
               },
               "tag3":{
                  "patch_order":{
                     "@@assign":"last"
                  }
               }
            }
         }
      }
   }
}
```