本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 波浪规划
从本质上讲，波浪计划就是迁移计划，它与其他项目规划活动类似。我们建议您使用*迁移浪潮*来创建可管理的群组、降低风险并围绕这些群组组织活动。
要制定有效且高度可信的迁移浪潮计划，您必须全面了解应用程序产品组合、相关基础架构（计算、存储、网络）、依赖关系映射和迁移策略。
除了*业务应用程序*（一种对软件和基础架构组件集合进行分组的形式）之外，您还可以使用其他组级别。*Wav* e 是最高的小组等级。在浪潮中，您可以创建*依赖组*。这种类型的子组可以包含多个应用程序。例如，由于技术依赖性（例如低延迟）或其他因素而需要同时迁移的两个或多个应用程序。然后将该依赖组作为一个整体进行管理。可以将多个依赖组分配给一个波次。接下来，您可以将迁移日期分配给整个浪潮或浪潮中的各个依赖组。迁移日期是指该群组将在当前位置停止并在中处于活动状态的日期和时间 AWS。
迁移浪潮有多种活动。我们建议您分阶段组织浪潮，并为每个阶段设置预期持续时间。以下阶段为例：
+ **设计**：在这个波浪阶段，对浪潮中每项应用的目标设计进行确认和批准。
+ **切**换**计划**：此波阶段包括创建或迭代切换运行手册，以及规划将应用程序切换到所需的所有步骤 AWS （包括回滚场景）。
+ **Pre-migration**：此阶段包括 landing zone 部署活动，例如账户配置、配置、迁移前测试、迁移工具设置和数据复制。
+ **切换**：此阶段是实际迁移发生的时候。在此期间，应用程序将在当前位置停止，最后一次同步数据，执行业务测试并完成迁移。此阶段包括操作移交。
+ **Hypercar** e 或 **Post-migration**：在这个阶段，迁移团队可以在出现问题时为运营提供支持。此外，还可以根据需要进行优化。
+ **浪潮结束**：在此阶段，您将回顾指标和吸取的经验教训，并正式结束浪潮。
迁移浪潮没有预定义的持续时间，这将取决于工作量和复杂程度。我们建议将迁移波保持在 6 到 10 周内。需要更多时间的情况，例如完全重写应用程序组件时，通常最好在迁移浪潮之外处理。
为了衡量成功和跟踪进展，波浪应与结果和业务驱动因素保持一致。这也会影响波浪持续时间和波浪所包含的依赖组。一波浪潮的完成应反映出一项可衡量的成就。
有多种方法可以组织迁移浪潮。下表描述了最常见的波浪组织选项。这些通常是组合在一起的。
|
|
| 波浪组织类型 | 说明 | 优点 | 缺点 |
| --- |--- |--- |--- |
| 按迁移策略或技术堆栈划分 | 将具有通用迁移策略或模式的应用程序分配给浪潮。例如，仅包含重新托管应用程序的浪潮。 | 可以为每个模式或堆栈分配专门的队伍。
活动持续时间均匀。 | 需要对依赖关系进行更多的分析，尤其是对于遵循不同模式的应用程序。 |
| 按业务领域分类 | 为每个业务域创建波浪。例如，订单管理浪潮或付款浪潮。 | 通常在给定域内共享数据。
始终如一的团队参与。 | 由于整个业务领域受到影响，风险增加。 |
| 按技术能力分类 | 对使用一项或多项功能的应用程序进行分组。例如，仅限计算的波浪或计算\+负载平衡波。 | 随着时间的推移，随着技术能力的启用，迁移开始得更快。消除了对完全可操作的着陆区的依赖。 | 在后来的浪潮中创造出一些复杂的局面。 |
| 按环境分类 | Wave 包含一组应用程序的特定环境。例如，开发浪潮或生产浪潮。 | Non-production Waves 受益于执行过程中的灵活性。
降低了生产迁移的风险。 | 需要专注于依赖关系分析，以避免缺少非生产环境中不存在的依赖关系。 |
| 按业务优先级 | 纯粹根据给定的优先级标准创建群组。 | 解决业务成果。 | 通常涉及许多团队；难以协调。 |
关于[为应用程序组合建立基准的](baseline-application-portfolio.md)部分描述了四类技术依赖关系。这些依赖关系促成了迁移浪潮的产生和依赖群体的定义。依赖群体将由依赖关系的严重程度决定。此外，还必须考虑非技术依赖性。例如，应用程序发布时间表、维护时段和关键业务日期（例如月底或季度末处理）可能会影响波浪计划。
确定依赖关系是*软*依赖关系还是*硬*依赖关系。软依赖关系是两个或多个资源之间的关系，或者从一个资源到一个约束的关系，它不依赖于组件的位置。例如，在同一个局域网（或相同基础架构）中运行的两个系统可以分开，方法是将其中一个系统移到云端，而另一个系统则留在内部。硬依赖关系是两个或多个资产之间的关系，或者从一项资产到约束条件的关系，取决于位置。例如，两个系统在同一个本地网络中运行，并且在很大程度上依赖于低延迟来实现应用程序服务器和数据库服务器之间的通信，这两个系统具有硬依赖性。仅将其中一个系统迁移到云端会导致无法解决的功能或性能问题。同样，非技术原因，例如资源可用性（例如执行迁移的团队）或操作限制（例如维护时段，两个系统只能在给定的时间窗口内迁移），可能会对这些资产造成严重的依赖。
要制定迁移浪潮计划，请通过分析依赖关系来确定依赖组，最好是从高度可信的数据来源（例如专业的发现工具）中进行依赖。将这些信息与您的应用程序优先级标准和操作环境相结合。
确定技术依赖关系具有挑战性。需要多个数据点，但没有任何数据源包含所有数据点。例如，尽管您可以从发现工具中获取进程间的通信信息，但很难将它们分为软依赖项和硬依赖项。仅凭网络数据也很难确定延迟容忍度。
以下技术可以帮助您处理确定实际依赖关系的模棱两可之处：
+ 按照 “数据[要求” 部分所述收集所有数据](understanding-complete-assessment-data-requirements.md)，以及根据需要收集您考虑的任何其他数据点。
+ 筛选依赖关系信息（或通信数据），排除共享服务，例如 Active Directory、备份和监控流量。技术共享服务往往会粘合整个范围。
+ 对所有信息进行分类。如果可用，请使用组件之间的网络频率和数据传输量。
+ 与应用程序所有者、架构师和支持团队会面。讨论连接的类型。它们是同步的还是异步的？ 他们知道最低延迟要求吗？ 关键连接有哪些？如果这些连接不可用会怎样？ 你错过了重要的联系吗？ 考虑一下批处理可能会偶尔发生，并且在数据集中缺失。
+ 如果您的发现工具提供了数据图，请寻找能够连接大型应用程序集群的单个应用程序。这些单一的连接点可以帮助将数据分成更小的组。
[AWS Transform](https://docs.aws.amazon.com/transform/latest/userguide/what-is-service.html) 可以帮助您分析依赖关系并执行波浪规划。
## 制定波浪计划
迁移一波应用程序的先决条件是应用程序组合数据以及对将在浪潮中迁移的应用程序组的详细应用程序评估。详细的评估应包括浪潮中的应用程序列表、相关的基础架构详细信息、目标设计以及每个应用程序的迁移策略。
建立浪潮所有权和治理是管理和跟踪浪潮工作、项目依赖关系、变更管理、问题和风险的关键。确保建立管理框架来管理计划。
要概述波浪计划，请从默认波浪构造开始。波浪中会发生什么？ 定义初始输入后，波浪就可以开始了。通常，活动将是：
1. 完善切换计划。本活动应概述迁移时必须采取的操作手册和步骤，包括与其他内部和外部团队的协调。
1. 完善回滚计划。如果出现问题，必须采取什么措施才能回滚应用程序？
1. 准备目标基础架构。例如，您可以创建或扩展 landin AWS g zone（安全AWS 账户、网络、基础设施服务、其他支持基础设施）。
1. 测试目标基础架构。
1. 操作迁移工具。例如，安装复制代理并开始数据传输。
1. 执行切换计划和运行手册试运行。将所有参与的团队成员分组，并提前查看所有步骤。
1. 监控数据复制和基础架构部署。
1. 确认中基础设施和应用程序的运行准备就绪 AWS。
1. 确认安全准备就绪。
1. 如果适用，请确认合规性和法规要求（例如，迁移前和迁移后的工作负载验证）。
1. 将应用程序迁移到 AWS 并执行上线前测试。
1. 在一段时间（例如 3 天）内提供迁移后支持，届时运营团队和迁移团队将完全可以解决问题并进行优化。
1. 进行迁移后审查。记录吸取的经验教训，并将其融入未来的浪潮中。
1. 通过确认操作移交和获取报告指标来执行波浪结算。
每项活动需要多长时间将取决于范围的复杂性、波浪容量、所涉及的人员和您的独特情况。在可能的情况下，最好使用较小的波浪，因为这样可以减少任何延迟或迁移阻碍因素的影响。与你的队伍一起确定浪潮的默认持续时间。
接下来，继续分析日期，创建由空波组成的初始高级结构（尚未分配应用程序）。考虑以下问题：
+ 迁移计划的总长度是多少？
+ 截止日期是什么时候？
+ 是否有固定的数据中心退出日期？
+ 有搭配合同的终止日期吗？
+ 应用程序和基础架构的更新周期是多少？
+ 应用程序的维护和发布周期是多少？
+ 是否有应避免迁移的日期（例如，发布和维护周期、年底、节假日、月底处理）？
考虑到这些因素，将波浪规划成计划。为了加快迁移过程，我们建议尽可能重叠浪潮。重叠波浪的关键是定义和考虑波浪中会发生什么。通常，部署活动、目标基础架构验证和数据同步将在浪潮的前半段进行。下半部分将侧重于实际的迁移、测试和操作移交。这意味着流程的每一半都涉及不同的团队，并且您可以提高一定的效率。例如，一旦参与目标基础架构准备的团队完成工作，他们就可以开始研究下一波的要求。通常，大多数波浪最好具有相似的长度和结构，以便于采用类似工厂的迁移方法。但是，在波浪规划过程中，可以扩展给定波浪的大小以满足依赖关系或操作要求。
接下来，根据已确定的依赖组，根据波浪可以包含的依赖组数量来确定波浪的最大大小。波浪大小通常由风险偏好（例如，可以容忍多少并行变化）和资源可用性（例如，利用可用资源、技能和预算可以执行多少并行变化）决定。但是，在早期规划期间，不要受资源需求和可用性的限制。在未来的迭代中，包含多个依赖组的波浪可以分解为较小的波浪。
确认给定波次的依赖组后，请查看迁移该浪潮的资源需求。考虑根据资源需求调整波浪大小（其中包含的依赖组数量）。这可能会导致更小或更大的波浪。根据需要迭代波浪计划，直到所有波浪都定义完毕。考虑与 AWS 专业服务或 AWS 迁移能力合作伙伴合作，他们可以提供专家在整个过程中为您提供帮助。
## 管理变更
在迁移计划的生命周期中，应用程序和相关基础设施组合将发生变化。 Long-running 迁移计划与正常的业务演变和变化并存。应用程序在等待迁移的过程中会不断发展。添加或删除服务器，在本地部署新的基础架构。预计浪潮或依赖群体的范围将需要更改。尤其是在接近迁移日期时，发现以前未知的依赖关系或清单中包含新服务器时，需要进行更改。有时，这可能发生在迁移过程中。
范围变化会影响依赖组和波动。为了应对变化并最大限度地减少影响，建立范围控制机制非常重要。范围变更控制机制要求定义范围的单一真实来源。它可以是管理范围的工具，也可以是迁移计划治理所定义的.csv 文件、电子表格或数据库。您必须识别变化，分析影响，并将变更传达给相关利益相关者，以便他们能够采取行动。因此，将对波浪计划进行迭代。