タスク: 通信ゲートの完了

このタスクでは、 で定義した通信ゲートと T-マイナススケジュールを使用してタスク: コミュニケーションゲートとスケジュールの定義、移行とポートフォリオのワークストリームを通過する各ウェーブのステータスを伝えます。

これらのゲートを個別に移動したり、複数のウェーブが同じスケジュールにある場合は、グループ内のゲートを移動したりできます。移行ワークストリームのウェーブオーバーラップのため、移行のどの時点でも、異なるゲートに複数のウェーブまたはウェーブのグループがあるのが一般的です。次の表は、移行ワークストリームで波がどのように重複し、各波が 1 週間間隔でスケジュールされているかを示しています。この例では、移行ワークストリームでいつでも 6～7 個のウェーブがアクティブになり、各ウェーブは異なるゲートに配置されます。

ゲート	ウェーブ 1	ウェーブ 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 go または no-go ミーティング	4 月 16 日	4 月 23 日	4 月 30 日	5 月 7 日	5 月 14 日
ゲート 7: カットオーバー会議	4 月 17 日	4 月 24 日	5 月 1 日	5 月 8 日	5 月 15 日
ゲート 8: ハイパーケア期間の開始	4 月 18 日	4 月 25 日	5 月 2 日	5 月 9 日	5 月 16 日
ゲート 9: ハイパーケア期間の終了	4 月 22 日	4 月 29 日	5 月 6 日	5 月 13 日	5 月 20 日

このタスクは、次の通信ゲートで構成されます。

• ゲート 1: ウェーブの T マイナススケジュールを作成する

• ゲート 2: T-28 コミットミーティング

• ゲート 3: T-21 通信

• ゲート 4: T-14 チェックポイントミーティング

• ゲート 5: T-7 通信

• ゲート 6: T-1 go または no-go ミーティング

• ゲート 7: T-0 カットオーバー会議

• ゲート 8: ハイパーケア期間の開始

• ゲート 9: ハイパーケア期間の終了

ゲート 1: ウェーブの T マイナススケジュールを作成する

この通信ゲートで次の操作を行います。

1. このウェーブのドキュメントを保存する単一の共有リポジトリを作成します。

2. で作成した T-minus スケジュールテンプレートを使用してステップ 2: T-minus スケジュールテンプレートを作成する、このウェーブに固有の日付を入力し、T-minus スケジュールを共有リポジトリに保存します。

3. AWS 「大規模な移行用の移行プレイブック」で作成した移行タスクリストのコピーを作成し、共有リポジトリに保存します。このタスクリストは、ゲートを進める際のチェックリストとして使用します。

4. 適切な参加者との T-28 コミット会議をスケジュールします。この会議の詳細については、「」を参照してくださいステップ 3: 会議とその頻度を定義する。

ゲートの終了条件

次のプロジェクトガバナンスアクティビティが完了したら、次のゲートに進みます。

• ウェーブの共有リポジトリを確立しました。

• ウェーブの T マイナススケジュールを作成しました。

• ウェーブの移行タスクリストを作成しました。

• T-28 コミット会議をスケジュールしました。

次の移行アクティビティと、移行ランブックで定義されているその他のタスクが完了したら、次のゲートに進みます。

• ポートフォリオチームがウェーブプランを完了しました。

• ポートフォリオチームはウェーブの移行メタデータを収集しました。

ゲート 2: T-28 コミットミーティング

このゲートでは、移行チームがアプリケーション所有者とウェーブプランを確認し、ウェーブプランとカットオーバー日をコミットするようアプリケーション所有者に依頼します。この通信ゲートで次の操作を行います。

1. 「」で作成したウェーブワークショッププレゼンテーションを使用してステップ 4: 会議のプレゼンテーションを準備する、ウェーブに合わせてこのプレゼンテーションをカスタマイズし、共有リポジトリにプレゼンテーションを保存します。このプレゼンテーションは、このゲートと で使用しますゲート 4: T-14 チェックポイントミーティング。

2. T-28 コミットミーティングを実施し、プレゼンテーションを使用して以下を確認します。

   • ウェーブプランと移行プロセスの概要を提供します。

   • アプリケーション所有者の今後のアクション項目の詳細を提供します。

   • アプリケーション所有者がこのウェーブの各アプリケーションを移行する準備ができていることを確認します。

   • アプリケーション所有者が、アプリケーションのテストプランを提供する必要があることを理解していることを確認します。テストプランでは、カットオーバーが成功したことを検証する方法について説明します。テストはカットオーバーの直後に行われるため、問題が発生した場合、移行チームはビジネスユーザーやアプリケーションユーザーへの影響を最小限に抑えながらアプリケーションを元の環境にロールバックできます。

   • ステークホルダーが波全体でどのように協力し、コミュニケーションを取ることが期待されているかを確認します。利害関係者がこのウェーブに関連するドキュメントを見つけることができる共有リポジトリの場所を指定します。

   • で作成したエスカレーション計画を確認しますステップ 2: エスカレーション計画を立てる。

   • 質問と回答の機会を提供します。

3. T-28 コミットミーティングの後、「」で作成した T-28 通信 E メールを送信しますステップ 3: ゲートごとに標準の E メールテンプレートを作成する。ウェーブ情報と受信者の E メールをカスタマイズし、このウェーブにすべてのアプリケーションとサーバーを追加します。

4. T-28 コミットミーティングの後、適切な参加者と次のミーティングをスケジュールします。

   • T-14 チェックポイント会議

   • T-1 go または no-go 会議

   • T-0 カットオーバー会議

ゲートの終了条件

次のプロジェクトガバナンスアクティビティが完了したら、次のゲートに進みます。

• T-28 コミットミーティングを実施しました。

• 共有リポジトリについてすべての主要な利害関係者に Wave ドキュメントへのアクセスを知らせ、すべての利害関係者がアクセスできます。

• に従って、移行営業時間の保持を開始しましたタスク: ステージ 2 の定期的な会議をスケジュールする。

• アプリケーション所有者は、ウェーブプラン内のアプリケーションを移行できることを確認しました。

• すべての利害関係者はコミュニケーションのアプローチを理解し、参加する必要がある会議を把握しています。

• アプリケーション所有者は、自分が担当する特定のアクション項目を理解します。

• T-28 通信 E メールをすべての利害関係者に送信しました。

• 会議のプレゼンテーションと会議のメモを共有リポジトリに保存し、すべての利害関係者がアクセスできるようにしました。

• T-14 コミット会議をスケジュールしました。

• T-1 go または no-go 会議をスケジュールしました。

• T-0 カットオーバー会議を予定しました。

次の移行アクティビティと、移行ランブックで定義されているその他のタスクが完了したら、次のゲートに進みます。

• T-28 コミット会議中に行われた変更でウェーブプランを更新しました。

• ウェーブ内のアプリケーションとサーバーの変更リクエスト (RFC) を送信し、変更ウィンドウがスケジュールされています。

• 変更管理プロセスを理解して特定します。

• 転送、ルーティング、プロキシサービスなどの新しいインフラストラクチャ要件について RFCs を送信済みである。

• 移行タスクリストを更新しました。

ゲート 3: T-21 通信

コミュニケーションチームは、アプリケーション所有者やビジネスユニットの担当者との連絡を継続します。これらの利害関係者は、質問の機会を提供するために、移行営業時間に招待されます。

1. で作成した T-21 通信 E メールを送信しますステップ 3: ゲートごとに標準の E メールテンプレートを作成する。ウェーブ情報と受信者の E メールをカスタマイズし、このウェーブにすべてのアプリケーションとサーバーを追加します。

2. 正しいアプリケーション所有者で、スケジュールされた T-14 チェックポイント会議を更新します。必要な参加者が参加できない場合は、エスカレーション計画に従って代替担当者が参加できることを確認します。

ゲートの終了条件

次のプロジェクトガバナンスアクティビティが完了したら、次のゲートに進みます。

• T-21 通信 E メールをすべての利害関係者に送信しました。

次の移行アクティビティと、移行ランブックで定義されているその他のタスクが完了したら、次のゲートに進みます。

• ソースサーバーがレプリケーションの最小要件を満たしていることを確認しました。

• ウェーブでアプリケーションとサーバーのレプリケーションを開始しました。

• 移行タスクリストを更新しました。

ゲート 4: T-14 チェックポイントミーティング

このゲートでは、アプリケーション所有者と T-14 チェックポイントミーティングを行い、チームがスケジュールどおりにカットオーバーする予定があるかどうかを評価します。この通信ゲートで次の操作を行います。

1. 「」で準備したウェーブワークショッププレゼンテーションを使用してゲート 2: T-28 コミットミーティング、T-14 チェックポイントミーティングのプレゼンテーションを更新します。

2. T-14 チェックポイントミーティングを実施し、以下を確認します。

   • このウェーブで移行されるアプリケーションとサーバーを確認します。

   • 残りのタスクとスケジュールを確認して、参加者がプロセスの残りのステップを理解していることを確認します。

   • カットオーバーミーティングですべてのアプリケーション所有者 (またはその代理人) が対応できることを確認します。

   • カットオーバーが完了すると、テストプランの準備が整っていることを確認します。

3. T-14 チェックポイントミーティングの後、「」で作成した T-14 通信 E メールを送信しますステップ 3: ゲートごとに標準の E メールテンプレートを作成する。ウェーブ情報と受信者の E メールをカスタマイズし、このウェーブにすべてのアプリケーションとサーバーを追加します。

4. アプリケーション所有者が指定した代替担当者など、参加者に変更があった場合は、T-1 go または no-go 会議と T-0 カットオーバー会議への招待を更新します。

5. 移行タスクリストを更新します。

ゲートの終了条件

次のプロジェクトガバナンスアクティビティが完了したら、次のゲートに進みます。

• T-14 チェックポイントミーティングを実施しました。すべてのアプリケーション所有者または指定された担当者が出席します。アプリケーション所有者が出席せず、応答しない場合は、エスカレーション計画に従って出席なしをエスカレーションします。

• その週の移行営業時間を設定しました。

• T-14 通信 E メールをすべての利害関係者に送信しました。

• 会議のプレゼンテーションと会議のメモを共有リポジトリに保存し、すべての利害関係者がアクセスできるようにしました。

• 移行前、移行中、移行後のすべてのタスクのチェックリストを作成し、完了したタスクをすべて閉じ、チェックリストを共有リポジトリに保存しました。

次の移行アクティビティと、移行ランブックで定義されているその他のタスクが完了したら、次のゲートに進みます。

• レプリケートされたアプリケーションとサーバーのヘルスとステータスを検証しました。問題をトラブルシューティング中であるか、トラブルシューティングを完了している。

• アプリケーション所有者は、移行チームにテストプランを提供しています。

• 移行タスクリストを更新しました。

ゲート 5: T-7 通信

このゲートでは、コミュニケーションチームはアプリケーション所有者やビジネスユニットの担当者との連絡を継続します。また、カットオーバーアクティビティと会議の準備も行います。

1. で作成した T-7 通信 E メールを送信しますステップ 3: ゲートごとに標準の E メールテンプレートを作成する。ウェーブ情報と受信者の E メールをカスタマイズし、このウェーブにすべてのアプリケーションとサーバーを追加します。

2. 必要な参加者が T-1 go または no-go 会議と T-0 カットオーバー会議に参加できることを確認します。必要に応じて会議の招待状を更新し、代替代理人を含めます。

ゲートの終了条件

次のプロジェクトガバナンスアクティビティが完了したら、次のゲートに進みます。

• T-7 通信 E メールをすべての利害関係者に送信しました。

• T-1 go または no-go 会議と T-0 カットオーバー会議への出席が確認されました。すべての参加者が会議を承諾したか、代替代理人が特定されました。

次の移行アクティビティと、移行ランブックで定義されているその他のタスクが完了したら、次のゲートに進みます。

• このウェーブに対するすべての変更リクエストが承認されました。

• ターゲットインフラストラクチャがカットオーバーの準備が整っていることを検証しました。

• インフラストラクチャを検証するために作成したテストインスタンスをシャットダウンしました。

• カットオーバータスクリストを検証しました。

• 移行タスクリストを更新しました。

ゲート 6: T-1 go または no-go ミーティング

このゲートでは、RACI マトリックスのすべてのチームメンバーと移行前アクティビティのチェックリストを確認して、ウェーブ内のアプリケーションとサーバーがカットオーバーの準備が整っていることを検証します。このゲートは、予定されたカットオーバーの 24～48 時間前に発生します。

1. T-1 go または no-go ミーティングで、RACI マトリックスのすべてのチームメンバーとチェックリストを確認して、ウェーブ内のアプリケーションとサーバーがカットオーバーの準備が整っていることを確認します。

2. 必要なすべての参加者が T-0 カットオーバー会議に参加できることを確認します。

3. ウェーブの移行 (go) に進む場合は、「」で作成した T-1 通信 E メールを送信しますステップ 3: ゲートごとに標準の E メールテンプレートを作成する。ウェーブ情報と受信者の E メールをカスタマイズし、このウェーブにすべてのアプリケーションとサーバーを追加します。

4. ウェーブまたは特定のアプリケーションとサーバーの移行 (no-go) を続行しない場合は、すべての利害関係者に決定を知らせる E メールを送信し、次のステップまたはスケジュールの変更に関する利用可能な情報を提供します。

ゲートの終了条件

次のプロジェクトガバナンスアクティビティが完了したら、次のゲートに進みます。

• T-0 カットオーバー会議でリソースが利用可能であること、および必要なすべての参加者が参加できることを確認しました。

• 会議のプレゼンテーションと会議のメモを共有リポジトリに保存し、すべての利害関係者がアクセスできるようにしました。

• T-1 通信 E メールをすべての利害関係者に送信しました。

次の移行アクティビティと、移行ランブックで定義されているその他のタスクが完了したら、次のゲートに進みます。

• 移行タスクリストで、すべての移行タスクが完了したことを確認しました。

ゲート 7: T-0 カットオーバー会議

このゲートでは、カットオーバー会議中にウェーブ内のすべてのサーバーとアプリケーションを移行し、すぐにアプリケーション所有者が移行したアプリケーションをテストして、期待どおりに動作していることを確認します。アプリケーション所有者は、会議全体に参加するか、アプリケーションに必要な場合にのみ参加できます。

1. カットオーバー会議の前に、「」で作成した T-0 通信 E メールを送信しますステップ 3: ゲートごとに標準の E メールテンプレートを作成する。ウェーブ情報と受信者の E メールをカスタマイズし、このウェーブにすべてのアプリケーションとサーバーを追加します。

2. T-0 カットオーバーミーティングでは、移行ランブックの指示に従ってウェーブ内のサーバーとアプリケーションを移行します。このランブックは、AWS 「大規模な移行のための移行プレイブック」の指示に従って開発しました。

3. アプリケーションまたはサーバーが移行されたら、アプリケーション所有者が作成したテストプランを使用して、アプリケーションが次のように機能していることを確認します。

   • アプリケーションまたはサーバーが想定どおりに機能している場合、または軽微な問題しかない場合は、 AWS 環境内に残して問題を修正します。

   • アプリケーションまたはサーバーが機能していない場合、または重大な問題がある場合は、ロールバックします。

4. 移行タスクリストのカットオーバーアクティビティを完了したら、タスクリストを更新します。

5. 「」で作成したカットオーバー完了通信 E メールを送信しますステップ 3: ゲートごとに標準の E メールテンプレートを作成する。ウェーブ情報と受信者の E メールをカスタマイズし、このウェーブにすべてのアプリケーションとサーバーを追加します。

ゲートの終了条件

次のプロジェクトガバナンスアクティビティが完了したら、次のゲートに進みます。

• ウェーブ内のすべてのアプリケーションまたはサーバーが正常に移行されたことを検証したか、ロールバックしました。

• ロールバックされたアプリケーションまたはサーバーを書き留めました。これらのアプリケーションまたはサーバーでは、移行パターンを更新するか、カットオーバー中に発生した問題に対処するためにターゲット状態を再定義する必要があります。これらのアプリケーションまたはサーバーは、将来のウェーブプランに含めます。

• カットオーバー完了のコミュニケーション E メールをすべての利害関係者に送信しました。

次のカットオーバーアクティビティが完了したら、次のゲートに進みます。

• 移行タスクリストのカットオーバータスクセクションのすべてのステップが完了しました。

ゲート 8: ハイパーケア期間の開始

このゲートでは、次の操作を行います。

1. プロジェクトの関係者に、クラウド内の移行されたアプリケーションとサーバーを確認するよう依頼します。問題が特定された場合は、移行チームに送信する必要があります。

2. カットオーバー中またはハイパーケア期間中に特定された問題に対処します。

3. クラウド運用チームがワークロードを受け入れる準備ができていることを確認します。

4. すべてのプロジェクト管理ツールとリポジトリを更新して、ウェーブのステータスを反映します。

ゲートの終了条件

次のプロジェクトガバナンスアクティビティが完了したら、次のゲートに進みます。

• すべてのステークホルダーが、移行されたアプリケーションとサーバーを確認しました。

• 移行チームは、カットオーバー中またはハイパーケア期間中に特定されたアプリケーションまたはサーバーの問題に対処しました。

• クラウド運用チームは、移行されたアプリケーションとサーバーを受け入れる準備ができていることを確認しました。

• ウェーブステータスを反映するために、すべてのプロジェクト管理ツールとリポジトリを更新しました。

ゲート 9: ハイパーケア期間の終了

ハイパーケア期間は通常 1～4 日間で、移行チームが移行したアプリケーションまたはサーバーに関する問題を解決すると終了します。ハイパーケア期間の終了時に、移行チームはクラウド運用 (Cloud Ops) チームとミーティングを行い、移行されたアプリケーションとサーバーを確認します。このゲートでは、移行チームは移行されたワークロードの継続的なサポートを Cloud Ops チームに転送します。Cloud Ops チームは、ハイパーケア期間が完了したこと、およびそれらが問題に関する連絡窓口になったことをアプリケーション所有者に通知します。必要に応じて、このコミュニケーションにアンケートを含め、アプリケーション所有者を招待して、移行とカットオーバーのプロセスに関するフィードバックを提供できます。

1. 移行したアプリケーションとサーバーをクラウド運用チームの設定管理データベース (CMDB) に組み込みます。

2. ServiceNow などの Cloud Ops 技術管理サポートツールにアプリケーション情報を組み込みます。

3. ステップ 3: ゲートごとに標準の E メールテンプレートを作成する 「」で作成したハイパーケア完了の通信 E メールをゲートごとに送信します。ウェーブ情報の E メールをカスタマイズし、クラウド運用チームに連絡する方法の手順を含めます。

4. ソースサーバーとサポートインフラストラクチャの廃止プロセスを開始するために、インフラストラクチャサポートチームに移行を通知します。このステップは通常、Cloud Ops チームまたはプロジェクトマネージャーによって実行されます。

ゲートの終了条件

このゲートは、次のプロジェクトガバナンスアクティビティを実行すると完了します。

• Cloud Ops は、すべてのワークロード関連情報を CMDB に組み込みました。

• Cloud Ops は、すべてのアプリケーション情報を技術管理サポートツールに組み込みました。

• ハイパーケアに関する完全なコミュニケーション E メールをすべての利害関係者に送信しました。

• インフラストラクチャチームは、不要になったサポートインフラストラクチャの廃止を開始しました。