任务 5：定义波浪规划流程

波浪规划是大规模迁移的关键里程碑。在波浪计划中，您将相似的应用程序组合在一起，考虑基础架构和应用程序依赖关系（例如共享数据库）、应用程序的优先级、应用程序架构的相似性以及业务功能。然后，您可以与应用程序和基础架构团队一起查看波浪计划，以确认他们在指定的迁移和转换窗口内的可用性。

根据不同 AWS 客户的实际部署情况，以下是波浪规划的一些最佳实践：

• 至少提前 4-5 次规划迁移浪潮。这有助于确保始终有足够的服务器用于迁移工作流。

• 快速失败。您应该从一些低复杂度的应用程序开始，然后将所学知识应用于以后的浪潮。

• 在早期的浪潮（第 1-5 波）中，选择更少的服务器（少于 10 个）、低复杂性的应用程序以及较低的环境（例如开发或测试环境）中的应用程序。随着你的进步，逐渐将更多的复杂性和更多的服务器引入浪潮。

• 波浪规划是一个持续的过程，而不是一次性的任务。不要试图同时计划所有波浪。

• 如果您使用的是投资组合发现工具，并且它具有复杂性评分功能，请在波浪计划中使用它。首先迁移复杂性最低的应用程序。

此任务包括以下步骤：

• 步骤 1：定义移动组流程

• 第 2 步：定义波浪规划选择标准

• 第 3 步：完成波浪规划流程

步骤 1：定义移动组流程

在此步骤中，您将确定所有 application-to-server 依赖关系并定义规则，这些规则将用于确定哪些服务器应作为移动组一起移动。移动组是应在组中一起移动的服务器或应用程序块。这是迁移浪潮的基石，其中每个迁移波都由一个或多个移动组组成，具体取决于每个移动组中的服务器数量。

确定应用程序依赖关系

以下是将相互依赖的应用程序分组到移动组中的关键注意事项：

• 考虑基础架构依赖关系，例如：

  • 一个应用程序可能有多个数据库，而这些数据库可以由其他应用程序共享。

  • 一个应用程序可能依赖于另一个应用程序。

  • 一台服务器可以托管多个应用程序的数据库。

• 考虑业务和运营依赖关系，例如：

  • 由于业务影响或操作日程安排（例如备份或修补），只能在特定的时间段内迁移应用程序。

  • 应用程序所有者只能在一个迁移直接转换窗口中使用，因此所有者的所有应用程序都必须位于同一个移动组中。

您在应用程序研讨会过程中或定义目标状态时确定了基础架构依赖关系。您可以通过自动化或手动流程识别基础架构依赖关系。要自动识别基础架构依赖关系，您可以使用发现工具，例如 Flexera One Cloud 迁移和现代化或 TDS TransitionManager。对于手动流程，请与应用程序和基础架构团队一起验证 CMDB 信息。

您确定了应用程序研讨会流程中的业务和运营依赖关系。

作为构建自己的波浪规划运行手册的起点，我们建议您使用投资组合剧本模板中包含的波浪规划运行手册模板（Microsoft Word 格式）。按如下方式记录迁移的依赖关系：

1. 打开你的浪潮规划操作手册。

2. 在 “应用程序依赖关系” 部分中，记录依赖关系。确定依赖关系的类型（基础架构、业务或运营）、依赖关系以及对依赖关系的简要描述。

3. 保存波浪规划操作手册。

4. 维护波浪计划运行手册中的依赖关系。随着你的进步，你可能会发现新的依赖关系。

下表显示了依赖关系示例。

类型	依赖关系	描述
基础设施	数据库	数据库与其他应用程序共享
基础设施	文件存储	应用程序使用可以解耦的中央文件存储，或者所有关联的应用程序应一起迁移
基础设施	应用程序	该应用程序依赖于一个或多个其他应用程序才能运行，例如提取、转换和加载 (ETL) 作业
业务	业务中断	应用程序的特定且经批准的停机窗口
正常运行	补丁窗口	可能影响迁移切换的计划操作任务（例如修补）

定义移动组规则

在波浪计划运行手册中记录依赖关系后，必须根据这些依赖关系构建移动组规则。这些规则规定了如何将服务器分组到移动组中。使用以下步骤来构建您的规则：

1. 查看您在上一节中定义的依赖关系。

2. 选择影响应用程序在移动组中是否必须一起移动的依赖关系。并非所有依赖关系都要求应用程序一起迁移。例如，在定义移动组时，不应考虑基础架构对 Microsoft Active Directory 的依赖关系，因为它是所有应用程序的共同依赖关系。在迁移任何应用程序之前，您应该在云中构建域控制器。

3. 将需要一起移动应用程序的依赖关系转换为移动组规则。

如果应用程序符合任何规则，则必须将所有关联的服务器放在同一个移动组中，这样它们才能一起迁移。

记录迁移的移动组规则，如下所示：

1. 打开你的浪潮规划操作手册。

2. 在 “移动组规则” 部分，按优先级顺序记录移动组规则。

3. 保存波浪规划操作手册。

4. 遵守波浪规划操作手册中的规则。随着你的进步，你可能会发现新的规则。

下表显示了移动组规则的示例。

规则	移动群组规则
1	具有共享数据库的应用程序必须一起迁移。
2	拥有相同应用程序所有者的应用程序必须一起迁移。
3	具有相同补丁窗口的应用程序必须一起迁移。

第 2 步：定义波浪规划选择标准

建立移动组后，需要将相似的移动组聚集在一起才能形成迁移波。在此步骤中，您将定义用于为每个波浪选择一个或多个移动组的标准。

了解每个移动组的大小对于成功的波浪规划至关重要。目标是调整每波浪潮的规模，使迁移保持敏捷性并保持健康的服务器管道。过大的波浪可能难以适应迁移计划的变化，而波浪太小的波可能无法提供足够的服务器来实现所需的迁移速度。

我们建议您在调整波浪大小时考虑以下标准：

• 第一波较小 — 初始浪潮应该较小，服务器少于 10 个，然后你可以逐渐增加每个浪潮中的服务器数量。这使您可以快速失败，并在吸取的经验教训的基础上再接再厉。例如，先迁移具有 3 台服务器的应用程序，然后再迁移具有 20 台服务器的应用程序。

• 资源-确定迁移团队可以在单波迁移中迁移多少台服务器。标准衡量标准是，由四名架构师组成的迁移团队可以在一周内迁移多达 50 台服务器，以适应重新托管模式。合并移动组，形成不超过迁移团队能力的迁移浪潮。

• 敏捷性 — Waves 必须能够适应迁移计划中的任何变化。如果必须重新安排服务器，则应能够重新安排受影响服务器的整个移动组。

• 存储大小-首先迁移较小的应用程序。例如，先迁移 100 GB 的应用程序，然后再迁移 2 TB 的应用程序。

• 应用程序环境-在较低的环境（例如开发或测试环境）中迁移应用程序，然后再迁移生产环境中的应用程序。

• 应用程序复杂性-首先迁移不太复杂且外部依赖性较少的应用程序。

• 应用程序@@ 的关键性-先迁移非关键应用程序，然后再迁移任务关键型应用程序。

• 用户群-首先迁移用户群较小的应用程序。例如，先迁移具有 10 个用户的应用程序，然后再迁移一个拥有 10,000 个用户的应用程序。

• 网络带宽 — 波浪的大小不应超过网络带宽。有关更多信息，请参阅您的迁移原则，该原则是根据AWS 大型迁移基础手册中的说明定义的。

记录波浪规划的选择标准，如下所示：

1. 打开你的浪潮规划操作手册。

2. 在 Wave 规划选择标准部分，记录您要用于迁移的标准。

3. 保存波浪规划操作手册。

4. 保持波浪规划操作手册中的标准。随着时间的推移，您可能需要调整标准或添加新标准。

下表显示了波浪计划选择标准的示例。

标准	描述
确定最不复杂的应用程序	确定移动组中复杂性分数较高的应用程序。
首先是较低的环境	低级环境（例如开发或测试环境）中的非关键应用程序必须先迁移。生产环境中的关键应用程序（例如产生收入的应用程序）必须最后迁移。
快速失败	在少于 10 台服务器的情况下形成初始浪潮。
迁移团队实力	确定每个迁移团队可以切换多少台服务器。
组合相似的移动组	根据共同点合并移动组。例如，移动组可能共享相同的应用程序所有者、源数据中心或目标 AWS 帐户。
波浪大小	Waves 的服务器总数不应超过 50 台。

步骤退出标准

• 您已经确定了用例的波浪规划标准，并将其记录在波浪规划操作手册中。

第 3 步：完成波浪规划流程

既然您已经定义了如何创建移动组，并确定了用于将移动组合并到迁移波次中的标准，那么您必须定义规划波浪的流程。在此步骤中，您将更新波浪规划操作手册以记录完整的波浪规划流程，并确认您的仪表板工具可供团队用来记录波浪信息。

在此步骤中，我们建议您使用提供的控制面板模板进行波浪规划和迁移，该模板可在投资组合手册模板中找到。该模板旨在为投资组合团队提供帮助，并作为整理数据、帮助分析应用程序组合、识别 application-to-server依赖关系以及最终规划迁移浪潮的起点。您可以根据环境的需要修改此模板。

按如下方式记录波浪规划流程：

1. 打开控制板模板进行波浪规划和迁移。

2. 根据您的用例的需要修改控制面板。例如，您可以添加用于提取服务器清单的工作表，添加新的数据透视表或图表，或者使用VLOOKUP函数导入源信息。

3. 保存仪表板模板。

4. 打开你的浪潮规划操作手册。

5. 在 “第 2 阶段：执行波浪规划” 部分，修改提供的标准流程以满足您的用例需求。

6. 保存波浪规划操作手册。

7. 与团队分享您的浪潮规划操作手册以供审阅。

8. 在波浪规划操作手册中维护流程。此过程可作为标准操作程序，用于规划大规模迁移的浪潮。

任务退出标准

• 您已在波浪规划操作手册中记录了以下内容：

  • 应用程序依赖关系

  • 应用程序移动组规则，按优先级顺序列出

  • 波浪规划选择标准

  • 波浪规划流程