本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 波浪规划
在波浪规划中，依赖组是一组具有无法解决的技术和非技术依赖关系的应用程序和基础架构。由于这些依赖关系，依赖关系组中的应用程序和基础架构必须同时迁移或在特定日期迁移。例如，在虚拟机上运行的应用程序和在单独的虚拟机中运行的数据库，在这些虚拟机中存在低延迟要求或高流量和复杂的查询，很可能会一起迁移，而不是在云中运行一个组件，而另一个组件在内部运行。同样，通过具有类似低延迟要求的 API 进行交互的独立应用程序也将同时迁移。
迁移波通常持续 4-8 周，可能包含一个或多个迁移事件。依赖组被组合成波次，因此波浪可以包含一个或多个依赖组。该浪潮还包含迁移所需的其他活动。其中包括 AWS 基础架构设置（例如 landing zone、安全和运营）、迁移工具和迁移活动，例如数据复制、切换规划、测试和迁移后支持。
为了衡量成功和跟踪进展，波浪应与结果和业务驱动因素保持一致。这也会影响波浪持续时间和波浪所包含的依赖组。一波浪潮的完成应反映出一项可衡量的成就。波浪的规划还可以结合其他因素，例如技术指导原则。例如，可以按环境（例如开发、测试、生产）或迁移策略（例如，重新托管浪潮、重新平台浪潮）来定义浪潮。
要制定有效且高度可信的迁移浪潮计划，您必须全面了解应用程序产品组合、相关基础架构（计算、存储、网络）、依赖关系映射和迁移策略。
关于[为应用程序组合建立基准的](baseline-application-portfolio.md)部分描述了四类技术依赖关系。这些依赖关系促成了迁移浪潮的产生和依赖群体的定义。依赖群体将由依赖关系的严重程度决定。此外，还必须考虑非技术依赖性。例如，应用程序发布时间表、维护时段和关键业务日期（例如月底或季度末处理）将影响波浪计划。
确定依赖关系是*软*依赖关系还是*硬*依赖关系。软依赖关系是两个或多个资源之间的关系，或者从一个资源到一个约束的关系，它不依赖于组件的位置。例如，在同一个局域网（或相同基础架构）中运行的两个系统可以分开，方法是将其中一个系统移到云端，而另一个系统则留在内部。另一个例子是可以在维护时段内迁移而不会影响维护活动的系统。
硬依赖关系是两个或多个资产之间的关系，或者从一项资产到约束条件的关系，取决于位置。例如，两个系统在同一个本地网络中运行，并且在很大程度上依赖于低延迟来实现应用程序服务器和数据库服务器之间的通信，这两个系统具有硬依赖性。仅将其中一个系统迁移到云端会导致无法解决的功能或性能问题。同样，非技术原因，例如资源可用性（例如，执行迁移的团队）或操作限制（例如维护时段，两个系统只能在给定的时间窗口内迁移），可能会对这些资产造成严重的依赖。
要制定迁移浪潮计划，请通过分析依赖关系来确定依赖组，最好是来自高度可信的数据来源，例如专业的发现工具，并将这些信息与您的应用程序优先级标准和操作环境相结合。在优先级排名中名列前茅的应用程序应针对您的初始迁移浪潮。根据资源可用性、风险承受能力、业务和技术限制、经验和技能来确定波浪容量（一波可以包含的应用程序数量）。考虑与 AWS 专业服务或 AWS 迁移能力合作伙伴合作，他们可以提供专家在整个过程中为您提供帮助。
优先级标准是将应用程序迁移到云端的顺序的初步指示。但是，依赖组将是将在给定时间移动的应用程序的实际决定因素。这是因为排名为高优先级的应用程序可能与排名中间或底部的应用程序有硬依赖性。
迁移策略还将影响浪潮的构成。例如，需要重构策略的高优先级应用程序可能需要数周或数月的分析、设计、测试和准备工作，很可能会被置于以后的浪潮中。
## 制定波浪计划
迁移一波应用程序的先决条件是应用程序组合数据以及对将在浪潮中迁移的应用程序组的详细应用程序评估。详细的评估应包括浪潮中的应用程序列表、相关的基础架构详细信息、目标设计以及每个应用程序的迁移策略。
建立浪潮所有权和治理是管理和跟踪浪潮工作、项目依赖关系、变更管理、问题和风险的关键。确保建立管理框架来管理计划。
要概述波浪计划，请从默认波浪构造开始。波浪中会发生什么？ 定义初始输入后，波浪就可以开始了。通常，活动将是：
1. 完善切换计划。本活动应概述迁移时必须采取的操作手册和步骤，包括与其他内部和外部团队的协调。
1. 完善回滚计划。如果出现问题，必须采取什么措施才能回滚应用程序？
1. 准备目标基础架构。例如，您可以创建或扩展 landin AWS g zone（安全AWS 账户、网络、基础设施服务、其他支持基础设施）。
1. 测试目标基础架构。
1. 操作迁移工具。例如，安装复制代理并开始数据传输。
1. 执行切换计划和运行手册试运行。对所有参与的团队成员进行分组，并提前查看所有步骤。
1. 监控数据复制和基础架构部署。
1. 确认中基础设施和应用程序的运行准备就绪 AWS。
1. 确认安全准备就绪。
1. 如果适用，请确认合规性和法规要求（例如，迁移前和迁移后的工作负载验证）。
1. 将应用程序迁移到 AWS 并执行上线前测试。
1. 在一段时间（例如 3 天）内提供迁移后支持，届时运营团队和迁移团队将完全可以解决问题并进行优化。
1. 进行迁移后审查。记录吸取的经验教训，并将其融入未来的浪潮中。
1. 通过确认操作移交和获取报告指标来执行波浪结算。
每项活动需要多长时间将取决于范围的复杂性、波浪容量、所涉及的人员和您的独特情况。在可能的情况下，最好使用较小的波浪，因为这样可以减少任何延迟或迁移阻碍因素的影响。与你的队伍一起确定浪潮的默认持续时间。
接下来，继续分析日期，创建由空波组成的初始高级结构（尚未分配应用程序）。考虑以下问题：
+ 迁移计划的总长度是多少？
+ 截止日期是什么时候？
+ 是否有固定的数据中心退出日期？
+ 有搭配合同的终止日期吗？
+ 应用程序和基础架构的更新周期是多少？
+ 应用程序的维护和发布周期是多少？
+ 是否有应避免迁移的日期（例如，发布和维护周期、年底、节假日、月底处理）？
考虑到这些因素，将波浪规划成计划。为了加快迁移过程，我们建议尽可能重叠浪潮。重叠波浪的关键是定义和考虑波浪中会发生什么。通常，部署活动、目标基础架构验证和数据同步将在浪潮的前半段进行。下半部分将侧重于实际的迁移、测试和操作移交。这意味着流程的每一半都涉及不同的团队，并且您可以提高一定的效率。例如，一旦参与目标基础架构准备的团队完成工作，他们就可以开始研究下一波的要求。通常，大多数波浪最好具有相似的长度和结构，以便于采用类似工厂的迁移方法。但是，在波浪规划过程中，可以扩展给定波浪的大小以满足依赖关系或操作要求。
接下来，根据已确定的依赖组，根据波浪可以包含的依赖组数量来确定波浪的最大大小。波浪大小通常由风险偏好（例如，可以容忍多少并行变化）和资源可用性（例如，利用可用资源、技能和预算可以执行多少并行变化）决定。但是，在早期规划期间，不要受资源需求和可用性的限制。在未来的迭代中，包含多个依赖组的波浪可以分解为较小的波浪。
确认给定波次的依赖组后，请查看迁移该浪潮的资源需求。考虑根据资源需求调整波浪大小（其中包含的依赖组数量）。这可能会导致更小或更大的波浪。根据需要迭代波浪计划，直到所有波浪都定义完毕。
## 管理变更
在迁移计划的生命周期中，应用程序和相关基础架构组合将发生变化。长期运行的迁移计划与正常的业务演变和变化并存。应用程序在等待迁移的过程中会不断发展。添加或删除服务器，在本地部署新的基础架构。预计浪潮或依赖群体的范围将需要更改。尤其是在接近迁移日期时，发现以前未知的依赖关系或清单中包含新服务器时，需要进行更改。有时，这可能发生在迁移过程中。
范围变化会影响依赖组和波动。为了应对变化并最大限度地减少影响，建立范围控制机制非常重要。范围变更控制机制要求定义范围的单一真实来源。这可以是管理范围的工具，也可以是迁移计划治理所定义的.csv 文件、电子表格或数据库。您必须识别变化，分析影响，并将变更传达给相关利益相关者，以便他们能够采取行动。因此，将对波浪计划进行迭代。