本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
升级推出政策
AWS Organizations 升级推出策略允许您集中管理和错开组织中多个 AWS 资源和帐户的自动升级。通过这些策略,您可以定义资源接受升级的顺序,从而确保更改在进入生产之前在不太重要的环境中得到验证。
在当今复杂的云环境中,管理大量资源和账户的升级可能具有挑战性。升级推出政策通过提供实施升级的系统方法来应对这一挑战。通过使用这些政策,您可以使升级过程与组织的变更管理实践保持一致,从而降低风险并提高运营效率。
升级推出策略利用的分层结构 AWS Organizations 将策略应用于整个组织或特定组织单位 (OUs)。这种集成允许您大规模管理升级,无需手动协调或自定义自动化脚本。
主要功能和优势
升级推出策略为管理升级提供了全面的功能,同时为跨多个账户和环境管理资源的组织提供了显著的优势。下表概述了主要功能及其相关优势:
| 功能 | 描述 | 主要优势 |
|---|---|---|
| 升级订购系统 | 三层系统(第一层、第二层、最后一层),定时可配置 | • 在预生产环境中测试升级 |
| • 最大限度地降低生产工作负载的风险 | ||
| 基于策略的管理 | 通过以下方式进行集中控制 AWS Organizations | • 一站式管理多个账户 |
| • 减少管理开销 | ||
| 资源目标定位 | 基于标签和基于 OU 的定位选项 | • 瞄准特定的资源组 |
| • 大规模应用政策 | ||
| 自动调度 | 适用于现有的维护窗口 | • 消除手动协调 |
| • 保持一致的升级模式 | ||
| 服务集成 | 与 AWS 服务升级机制配合使用 | • 通过 Amazon 监控事件 EventBridge |
| 合规控制 | 策略继承和强制执行 | • 强制执行组织标准 |
| • 满足合规要求 |
有关策略继承的更多信息,请参阅了解管理策略继承。
什么是升级推出政策?
升级推出策略是一组规则,用于确定如何以及何时将自动升级应用于您的 AWS 资源。这些策略允许您为资源指定不同的升级顺序,通常与您的开发、测试和生产环境保持一致。通过这样做,您可以确保首先将升级应用于不太重要的系统,从而使您能够在任何问题影响生产工作负载之前发现并解决这些问题。
这些策略支持三个升级订单:第一个、第二个和最后一个。这些命令创建了一种分阶段的升级方法,指定为 “第一” 的资源最初接受升级,然后在等待期后获得 “第二”,在另一个等待期之后最后是 “最后”。这种错开的方法使您有时间在升级进入更关键的系统之前在每个阶段对其进行验证。
升级推出政策对于具有复杂的多账户结构或具有严格变更管理要求的组织特别有价值。它们在维护 up-to-date系统和最大限度地降低与升级相关的关键服务中断风险之间取得了平衡。
升级推出政策的工作原理
升级推出策略可与您的现有 AWS 基础架构和流程无缝集成。当您创建升级推出策略并将其附加到组织单位时,该策略将应用于该组织单位内的所有账户。然后,您可以使用资源标签或补丁单来指定应按哪个顺序升级哪些资源。
当支持的 AWS 服务发布升级时,它会参考升级推出政策,以确定资源应按何种顺序接收升级。该服务首先在配置的维护时段内将升级应用于标记为 “第一” 的资源。在服务特定的等待期(通常为一周左右)之后,标记为 “第二” 的资源将有资格进行升级。最后,经过另一个等待期,标记为 “Last” 的资源将获得升级。
此过程可确保以可控、可预测的方式在整个组织中应用升级。它允许您在每个阶段监控升级的影响,并在更改到达最关键的环境之前根据需要采取纠正措施。此过程的自动化性质减少了管理升级的运营开销,同时仍为您提供维护 AWS 资源稳定性和安全性所需的控制和可见性。
术语
以下是您在使用升级推出策略时应了解的关键术语:
| 租期 | 定义 |
|---|---|
| 活跃日期 | amVu 在 “描述待处理的维护操作” API 中变为可见并可供应用程序使用的日期。 |
| amVu(自动次要版本升级) | 数据库引擎次要版本的自动升级过程。 |
| 有效策略 | 在考虑所有继承和直接关联的策略后,适用于账户或资源的最后一组规则。 |
| 维护窗口 | 可以对资源应用自动升级的重复时间段。升级推出策略在这些配置的维护时段内起作用。 |
| 组织部门(OU) | 组织中 AWS 账户的容器。可以在 OU 级别附加升级推出政策,以影响其中的所有账户。 |
| 补丁顺序 | 资源获得升级的顺序(第一个、第二个、最后一个)。 |
| 政策目标 | 升级推出政策的适用范围,可以是整个组织 OUs、特定账户或个人账户。 |
| 资源标签 | 键值对,可用于确定哪些资源应遵循策略中的特定升级顺序。 |
| 日程安排窗口 | 特定补丁顺序的资源获得升级的时间范围。 |
| 特定于服务的等待期 | 升级不同升级顺序的资源之间的指定时间间隔。此期限因 AWS 服务和升级类型而异。 |
| 升级订单 | 一种指定,用于确定资源何时获得相对于其他资源的升级。可以设置为 “第一个”、“第二个” 或 “最后一个”。 |
| 升级推出政策 | 用于管理跨资源的升级计划的 AWS Organizations 策略类型。 |
升级推出策略的用例
不同规模和行业的组织可以从升级推出政策中受益。以下虚拟场景演示了常见的升级管理难题以及升级推出策略如何提供有效的解决方案。这些示例基于典型的客户体验,但经过简化以突出关键优势和实施模式。
许多组织面临着类似的挑战:他们需要将资源 up-to-date保留在最新版本上,同时最大限度地降低生产环境的风险。如果没有基于策略的集中式方法,团队通常会诉诸手动流程或复杂的自动化脚本。以下示例演示了两个不同的组织如何使用升级推出策略来解决类似的难题:
用例示例:全球金融服务公司
一家金融服务公司在多个账户中运营着数百个 Aurora PostgreSQL 数据库。 AWS 在制定升级推出政策之前,他们的 DevOps 团队每月花几天时间手动协调数据库升级,确保更改在进入生产系统之前在开发环境中进行测试。通过实施升级推出政策,他们:
-
使用升级顺序标记为 “First” 的开发数据库
-
已将 QA 数据库分配到升级顺序 “第二”
-
将生产数据库指定为升级顺序 “Last”
-
将升级协调时间从几天缩短到几分钟
-
首先在较低的环境中自动验证更改
-
保持对变更管理要求的合规性
示例用例:物联网设备平台提供商
一家物联网公司每天使用多个 Amazon RDS 数据库处理数百万个设备事件。他们需要确保自动次要版本升级不会中断其生产服务。使用升级推出策略,他们:
-
制定了适用于其组织结构的政策
-
已将金丝雀环境配置为先接收升级
-
在早期升级环境中设置监控
-
在产品升级之前,有时间检测和响应任何问题
-
用简单的策略取代了复杂的自定义升级自动化
-
保持其生产工作负载的高可用性,同时保持数据库版本的最新状态
支持的 AWS 服务
升级推出策略与以下 AWS 服务集成,同时支持自动次要版本升级:
| 服务名称 | 用途 |
|---|---|
| Amazon Aurora PostgreSQL 兼容版 | 自动次要版本升级 |
| Amazon Aurora MySQL 兼容版 | 自动次要版本升级 |
| 适用于 PostgreSQL 的亚马逊关系数据库服务 | 自动次要版本升级 |
| 适用于 SQL Server 的 Amazon Relational Database Service | 自动次要版本升级 |
| 适用于 Oracle 的亚马逊 Relational Database S | 自动次要版本升级 |
| 适用于 MariaDB 的亚马逊关系数据库服务 | 自动次要版本升级 |
| 适用于 MySQL 的亚马逊关系数据库服务 | 自动次要版本升级 |
| 适用于 Db2 的亚马逊关系数据库服务 | 自动次要版本升级 |
先决条件
以下是在中管理升级推出策略所需的先决条件和必需权限: AWS Organizations
-
AWS Organizations 管理账户或委派管理员访问权限
-
支持的服务(目前为 Amazon Aurora 和亚马逊关系数据库服务数据库引擎)中的资源
-
管理升级推出策略的正确 IAM 权限
后续步骤
要开始使用升级推出策略,请执行以下操作:
-
查看升级推出政策入门以了解如何创建和管理策略
-
探索如何使用升级推出策略的最佳实践实施升级推出政策
-
明白 升级推出策略语法和示例