任务：完成通信门 - AWS 规范性指导
第 1 门：创建 T 减日程表2 号门：T-28 提交会议3 号门：T-21 通信4 号门：T-14 检查站会议5 号门：T-7 通信6 号登机口：T-1 要么开会，要么不开会7 号门：T-0 切换会议第 8 号门：Hypercare 期开始第 9 号门：Hypercare 期结束

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

任务：完成通信门

在本任务中，您将使用在中定义的通信门和 T 减时间表来传达每个浪潮任务：定义通信门和日程安排在迁移和投资组合工作流中的状态。

你可以单独移动海浪穿过这些大门，或者如果多个波浪的日程安排相同，你可以成群结队地将它们移动过大门。由于迁移工作流程中的波浪重叠，因此在迁移过程中的任何给定时间，在不同的门口都有多个波浪或成组的波浪是很常见的。下表显示了迁移工作流程中的波浪是如何重叠的，每个波浪计划间隔 1 周。在此示例中，在任何给定时间，迁移工作流中都有 6—7 个波浪处于活动状态，并且每个波浪位于不同的门口。

大门 第 1 波 Wave 2 第 3 波 第 4 波 第 5 波
1 号门：T 减时刻表 3 月 13 日 3 月 20 日 3 月 27 日 4 月 3 日 4 月 10 日
2 号门：T-28 会议 3 月 20 日 3 月 27 日 4 月 3 日 4 月 10 日 4 月 17 日
3 号门：T-21 通信 3 月 27 日 4 月 3 日 4 月 10 日 4 月 17 日 4 月 24 日
4 号门：T-14 会议 4 月 3 日 4 月 10 日 4 月 17 日 4 月 24 日 5 月 1 日
5 号门：T-7 通信 4 月 10 日 4 月 17 日 4 月 24 日 5 月 1 日 5 月 8 日
6 号登机口：T-1 要么开会，要么不开会 4 月 16 日 4 月 23 日 4 月 30 日 5 月 7 日 5 月 14 日
7 号门：切换会议 4 月 17 日 4 月 24 日 5 月 1 日 5 月 8 日 5 月 15 日
第 8 号门：Hypercare 期开始 4 月 18 日 4 月 25 日 5 月 2 日 5 月 9 日 5 月 16 日
第 9 号门：Hypercare 期结束 4 月 22 日 4 月 29 日 5 月 6 日 5 月 13 日 5 月 20 日

此任务由以下通信门组成：

第 1 门：为波浪创建 T 减时间表

在此通信门中执行以下操作：

  1. 创建一个共享存储库，您将在其中存储此浪潮的文档。

  2. 使用您在中创建的 T-minus 计划模板步骤 2：创建 T 减计划模板，输入特定于此波次的日期，然后将 T-minus 计划保存在共享存储库中。

  3. 创建您在迁移手册中为 AWS 大型迁移创建的迁移任务列表的副本，然后将其保存在共享存储库中。当你通过大门时，你可以使用这个任务列表作为清单。

  4. 安排与相应参与者举行的 T-28 承诺会议。有关此会议的更多信息，请参阅第 3 步：定义会议及其节奏。

登机口出口标准

完成以下项目治理活动后，继续进入下一个大门：

  • 您已经为这波浪潮建立了共享存储库。

  • 您已经为该波浪创建了 T 减时间表。

  • 您已经为该浪潮创建了迁移任务列表。

  • 您已经安排了 T-28 承诺会议。

完成以下迁移活动和迁移运行手册中定义的任何其他任务后，继续进入下一个大门：

  • 投资组合团队已经完成了波浪计划。

  • 投资组合团队已经收集了该浪潮的迁移元数据。

2 号门：T-28 提交会议

在这个大门中，迁移团队与应用程序所有者一起审查波浪计划，并要求应用程序所有者承诺波浪计划和转换日期。在此通信门中执行以下操作：

  1. 使用您在中创建的 Wave Workshop 演示文稿第 4 步：准备会议演示文稿，为浪潮自定义此演示文稿，然后将演示文稿保存在共享存储库中。你在这扇大门里使用这个演示文稿然后4 号门：T-14 检查站会议.

  2. 召开 T-28 提交会议，并使用您的演示文稿查看以下内容：

    • 概述波浪计划和迁移过程。

    • 为应用程序所有者提供有关即将采取的措施的详细信息。

    • 确认应用程序所有者已准备好迁移这一浪潮中的每个应用程序。

    • 确认应用程序所有者了解他们需要为其应用程序提供测试计划。测试计划描述了如何验证直接转换是否成功。直接转换后立即进行测试，因此，如果有任何问题，迁移团队可以将应用程序回滚到其原始环境，同时最大限度地减少对业务和应用程序用户的影响。

    • 回顾期望利益相关者在整个浪潮中如何进行协作和沟通。提供共享存储库的位置，利益相关者可以在其中找到与这一浪潮相关的文档。

    • 查看您在中制定的升级计划第 2 步：制定升级计划。

    • 提供提问和回答的机会。

  3. T-28 提交会议结束后，发送您在中创建的 T-28 通信电子邮件。第 3 步：为每个登机口创建标准电子邮件模板自定义电子邮件以获取浪潮信息和收件人，并在此浪潮中添加所有应用程序和服务器。

  4. T-28 提交会议结束后，安排以下与相应参与者的会议：

    • T-14 检查站会议

    • T-1 要么开会，要么不去开会

    • T-0 切换会议

登机口出口标准

完成以下项目治理活动后，继续进入下一个大门：

  • 你主持了 T-28 承诺会议。

  • 您已将共享存储库告知所有主要利益相关者以访问Wave文档，并且所有利益相关者都可以访问该存储库。

  • 根据规定，您已开始暂停迁移工作时间任务：为第 2 阶段安排定期会议。

  • 应用程序所有者已确认可以迁移波浪计划中的应用程序。

  • 所有利益相关者都了解沟通方式，也知道他们需要参加哪些会议。

  • 应用程序所有者了解他们负责的具体操作项目。

  • 您已将 T-28 通信电子邮件发送给所有利益相关者。

  • 您已将会议演示文稿和会议记录保存在共享存储库中，以便所有利益相关者都可以访问。

  • 您已经安排了 T-14 承诺会议。

  • 您已经安排了 T-1 开会或不参加会议。

  • 您已经安排了 T-0 转换会议。

完成以下迁移活动和迁移运行手册中定义的任何其他任务后，继续进入下一个大门：

  • 您已使用在 T-28 提交会议期间所做的任何更改更新了波浪计划。

  • 您已经为浪潮中的应用程序和服务器提交了变更请求 (RFC)，并且变更窗口已安排好了。

  • 了解并确定变更管理流程。

  • 您已提交 RFCs 任何新的基础设施要求，例如转发、路由或代理服务。

  • 您已经更新了迁移任务列表。

3 号门：T-21 通信

沟通团队继续与应用程序所有者和业务部门代表保持联系。邀请这些利益相关者在迁移工作时间进行提问。

  1. 发送您在中创建的 T-21 通信电子邮件。第 3 步：为每个登机口创建标准电子邮件模板自定义电子邮件以获取浪潮信息和收件人，并在此浪潮中添加所有应用程序和服务器。

  2. 与正确的应用程序所有者更新预定的 T-14 检查点会议。如果任何必需的参与者无法参加，请确认是否有候补代表可以根据您的升级计划出席。

登机口出口标准

完成以下项目治理活动后，继续进入下一个大门：

  • 您已将 T-21 通信电子邮件发送给所有利益相关者。

完成以下迁移活动和迁移运行手册中定义的任何其他任务后，继续进入下一个大门：

  • 您已验证源服务器满足复制的最低要求。

  • 您已经开始在浪潮中复制应用程序和服务器。

  • 您已经更新了迁移任务列表。

4 号门：T-14 检查站会议

在这个大门里，你与应用程序所有者举行T-14检查点会议，并评估团队是否有望按计划进行切换。在此通信门中执行以下操作：

  1. 使用您在中准备的 Wave 研讨会演示文稿2 号门：T-28 提交会议，更新 T-14 检查点会议的演示文稿。

  2. 召开 T-14 检查站会议并查看以下内容：

    • 查看此浪潮中正在迁移的应用程序和服务器。

    • 查看剩余的任务和日程安排，确保与会者了解流程中的剩余步骤。

    • 确认所有应用程序所有者（或其代表）都可以参加转换会议。

    • 确认切换完成后，测试计划已准备就绪。

  3. T-14 检查点会议结束后，发送您在中创建的 T-14 通信电子邮件。第 3 步：为每个登机口创建标准电子邮件模板自定义电子邮件以获取浪潮信息和收件人，并在此浪潮中添加所有应用程序和服务器。

  4. 根据参与者的任何变化（例如应用程序所有者指定的替代代表）更新参加 T-1 go 或 no-go 会议和 T-0 转换会议的邀请。

  5. 更新迁移任务列表。

登机口出口标准

完成以下项目治理活动后，继续进入下一个大门：

  • 你主持了 T-14 检查站会议。所有应用程序所有者或其指定代表都出席了会议。如果应用程序所有者没有出席且没有回应，请根据升级计划上报缺勤情况。

  • 您已经完成了本周的迁移工作时间。

  • 您已将 T-14 通信电子邮件发送给所有利益相关者。

  • 您已将会议演示文稿和会议记录保存在共享存储库中，以便所有利益相关者都可以访问。

  • 您已经创建了所有迁移前、迁移和迁移后任务的清单，关闭了所有已完成的任务，并将清单保存在共享存储库中。

完成以下迁移活动和迁移运行手册中定义的任何其他任务后，继续进入下一个大门：

  • 您已经验证了复制的应用程序和服务器的运行状况和状态。您正在对任何问题进行故障排除或已完成故障排除。

  • 应用程序所有者已向迁移团队提供了测试计划。

  • 您已经更新了迁移任务列表。

5 号门：T-7 通信

在这个大门里，沟通团队继续与应用程序所有者和业务部门代表保持联系。您还要为转换活动和会议做准备。

  1. 发送您在中创建的 T-7 通信电子邮件。第 3 步：为每个登机口创建标准电子邮件模板自定义电子邮件以获取浪潮信息和收件人，并在此浪潮中添加所有应用程序和服务器。

  2. 确认所需的参与者可以参加 T-1 go 或 no-go 会议以及 T-0 转换会议。根据需要更新会议邀请以包括候补代表。

登机口出口标准

完成以下项目治理活动后，继续进入下一个大门：

  • 您已将 T-7 通信电子邮件发送给所有利益相关者。

  • 您已确认参加 T-1 go 或 no-go 会议和 T-0 切换会议。所有与会者都接受了会议，或者已经确定了替代代表。

完成以下迁移活动和迁移运行手册中定义的任何其他任务后，继续进入下一个大门：

  • 这一波的所有变更请求均已获得批准。

  • 您已验证目标基础架构已准备好进行切换。

  • 您已经关闭了为验证基础架构而创建的所有测试实例。

  • 您已经验证了直接转换任务列表。

  • 您已经更新了迁移任务列表。

6 号登机口：T-1 要么开会，要么不开会

在此大门中，您可以与所有团队成员一起查看 RACI 矩阵上的迁移前活动清单，以验证浪潮中的应用程序和服务器是否已准备好进行切换。此门在预定切换前 24-48 小时出现。

  1. 在 T-1 go or no-go 会议中，与所有团队成员一起查看 RACI 矩阵上的清单，以验证浪潮中的应用程序和服务器是否已准备好进行切换。

  2. 确认所有必需的参与者都可以参加 T-0 转换会议。

  3. 如果您决定继续迁移 wave (go)，请发送您在中第 3 步：为每个登机口创建标准电子邮件模板创建的 T-1 通信电子邮件。自定义电子邮件以获取浪潮信息和收件人，并在此浪潮中添加所有应用程序和服务器。

  4. 如果您决定不继续迁移浪潮或特定的应用程序和服务器（不行），请向所有利益相关者发送一封电子邮件，告知他们该决定，并提供有关后续步骤或时间表变更的所有可用信息。

登机口出口标准

完成以下项目治理活动后，继续进入下一个大门：

  • 您已确认有可用于 T-0 转换会议的资源，并且所有必需的参与者都可以参加。

  • 您已将会议演示文稿和会议记录保存在共享存储库中，以便所有利益相关者都可以访问。

  • 您已将 T-1 通信电子邮件发送给所有利益相关者。

完成以下迁移活动和迁移运行手册中定义的任何其他任务后，继续进入下一个大门：

  • 在迁移任务列表中，您已确认所有迁移任务均已完成。

7 号门：T-0 切换会议

在这个大门中，您可以在转换会议期间迁移所有服务器和应用程序，然后立即让应用程序所有者测试迁移的应用程序，以确认它们按预期运行。应用程序所有者可以参加整个会议，也可以仅在应用程序需要时出席。

  1. 在直接转换会议之前，发送您在中创建的 T-0 通信电子邮件。第 3 步：为每个登机口创建标准电子邮件模板自定义电子邮件以获取浪潮信息和收件人，并在此浪潮中添加所有应用程序和服务器。

  2. 在 T-0 转换会议中，根据迁移运行手册中的说明迁移浪潮中的服务器和应用程序，这些操作手册是根据针对大型迁移的《迁移手册》中的说明开发的。 AWS

  3. 迁移应用程序或服务器后，使用应用程序所有者制定的测试计划来验证应用程序是否按以下方式运行：

    • 如果应用程序或服务器按预期运行或只有小问题，请将其留在 AWS 环境中并修复所有问题。

    • 如果应用程序或服务器无法运行或存在重大问题，请将其还原。

  4. 完成迁移任务列表中的直接转换活动后，更新任务列表。

  5. 发送您在中创建的直接转换完整通信电子邮件。第 3 步：为每个登机口创建标准电子邮件模板自定义电子邮件以获取浪潮信息和收件人，并在此浪潮中添加所有应用程序和服务器。

登机口出口标准

完成以下项目治理活动后，继续进入下一个大门：

  • 您已经验证浪潮中的每个应用程序或服务器都已成功迁移，或者您已经将其还原。

  • 您已经记录了所有已回滚的应用程序或服务器。对于这些应用程序或服务器，必须更新迁移模式或重新定义目标状态以解决直接转换期间遇到的任何问题。您将把这些应用程序或服务器包含在 future Wave 计划中。

  • 您已向所有利益相关者发送了完整的直接转换通信电子邮件。

完成以下切换活动后，继续前往下一个大门：

  • 您已完成迁移任务列表的 “直接转换任务” 部分中的所有步骤。

第 8 号门：Hypercare 期开始

在这扇大门中，你可以执行以下操作：

  1. 请项目利益相关者查看云中迁移的应用程序和服务器。如果发现任何问题，应将其发送给迁移小组。

  2. 解决在转换期间或超级护理期间发现的任何问题。

  3. 确认云运营团队已准备好接受工作负载。

  4. 更新所有项目管理工具和存储库以反映浪潮的状态。

登机口出口标准

完成以下项目治理活动后，继续进入下一个大门：

  • 所有利益相关者都已审查了迁移的应用程序和服务器。

  • 迁移团队已经解决了在转换期间或超级护理期间发现的任何应用程序或服务器问题。

  • 云运营团队已确认他们已准备好接受迁移的应用程序和服务器。

  • 您已经更新了所有项目管理工具和存储库，以反映波次状态。

第 9 号门：Hypercare 期结束

超级护理期通常持续 1-4 天，在迁移团队解决了迁移的应用程序或服务器的任何问题后结束。在超级护理期结束时，迁移团队与云运营（Cloud Ops）团队会面，以审查迁移的应用程序和服务器。在这个大门里，迁移团队将对迁移工作负载的持续支持转移给云运营团队。Cloud Ops 团队会通知应用程序所有者，超级护理期已经结束，他们现在是任何问题的联系人。或者，您可以在此通信中加入一项调查，并邀请应用程序所有者提供有关迁移和转换过程的反馈。

  1. 将迁移的应用程序和服务器整合到云运营团队的配置管理数据库 (CMDB) 中。

  2. 将任何应用程序信息整合到 Cloud Ops 技术管理支持工具中，例如 ServiceNow。

  3. 发送您为每个登机口创建的 h ypercare 完整通信电子邮件。第 3 步：为每个登机口创建标准电子邮件模板自定义电子邮件以获取波浪信息，并包括有关如何联系云运营团队的说明。

  4. 将过渡通知基础架构支持团队，以便开始停用源服务器和任何支持基础架构。此步骤通常由云运营团队或项目经理执行。

登机口出口标准

当您完成了以下项目治理活动后，此门即告完成：

  • Cloud Ops 已将所有与工作负载相关的信息整合到其 CMDB 中。

  • Cloud Ops 已将所有应用程序信息整合到其技术管理支持工具中。

  • 您已向所有利益相关者发送了 hypercare 完整的沟通电子邮件。

  • 基础设施团队已开始停用任何不再需要的支持基础架构。