ワークロードをリリースする
このフェーズでは、運用環境にワークロードをリリースします。
リソースを Azure にデプロイしました。 次は、移行手順を完了し、今後の変更を他のチームに伝え、最終的な変更の承認を行い、リソースをクリーンアップし、振り返りを行う必要があります。
変更を伝える
移行が影響する可能性のあるすべてのユーザーがプロセスを確実に把握できるように、今後の変更について組織に通知します。 それぞれに専用のユーザーとオペレーターが存在するため、各ワークロードの変更を伝えます。
変更を伝える際に次の質問に答える必要があります。
移行の決定的期日は何ですか?
誰の作業がいつ、どのくらいの期間中断されますか?
準備を整えるために変更前に各ロールでどのような作業を完了する必要がありますか?
機能を確認するために変更後に各ロールでどのような作業を完了する必要がありますか?
質問や課題がある場合、個人は誰に連絡すべきですか?
ビジネス テストの実行
ワークロードのビジネス ユーザーは、新しいソリューションをテストする必要があります。 移行チームはワークロードのテストを容易にし、テスト計画を策定し、テストを自動化できます。
ワークロードをテストするには、変更が最も影響する可能性があるユーザーを特定します。 これらのユーザーに、ビジネス目標、期待される成果、ビジネス プロセスに対する予想される変更を通知します。 ユーザーからフィードバックを受け取り、確実に IT スタッフがフィードバックを理解し、その影響に基づいて優先順位を付けるようにします。 フィードバックでワークロードの変更が要求された場合は、必要なすべてのチームに変更を伝えます。
フィードバックの段階では、移行チームはフィードバックを収集し、結果の技術的なアクションを管理します。 フィードバックとアクションの手順を追跡するためにテスト計画を作成します。
移行を完了する
資産とそのすべての依存関係を運用環境に昇格した後、運用トラフィックを再ルーティングできます。 その後、オンプレミスの資産は古いものになり、使用を停止できます。
ワークロード アーキテクチャに応じて、さまざまなタスクを実行する必要があります。
昇格を開始したことを関係者に伝える。
ステージングされたすべてのリソースが正しく機能していることを確認する。
最近のデータのレプリケーションを行う。
レプリケーション後にリソースをハイドレートする。 負荷分散規則などの他のコンポーネントをステージングする。
移行を妨げないように、ソース サーバーをオフにする。
分離テストを行います。
ユーザーがアプリケーションの新しい場所にアクセスできるように、ネットワーク コンポーネントを更新する。
昇格テストをもう一度行い、ワークロードが期待どおりに動作することを確認する。
利害関係者から最終承認を得る。
昇格が成功したことを必要な関係者に伝える。
移行後のコストの最適化
移行後、ライブ データに基づいてワークロードを最適化し、廃止された資産の使用を停止します。
資産をシャットダウンして使用を停止する場合:
監視を続行する: 確実に運用トラフィックが正しくルーティングされるように、廃止が予定されている資産を監視します。 無効な資産では、ストレージ、ネットワーク、その他のインフラストラクチャ リソースを引き続き使用できます。 これらを有効に戻すと、予期しない問題が発生する可能性があります。 アクティビティを監視し、資産が使用されなくなったことを確かめます。
テストと停止期間を確立する: ユーザーが実行する実際のアクティビティと一致するテスト ケースを実行する非アクティブなテスト期間を特定します。 この期間中に、使用停止のフラグを設定する資産を無効にすることもできます。 メンテナンス期間をスケジュールし、計画をユーザーに通知します。
保有期間を検討する: レプリケーション中にデータを失った場合に備えて、データの一時的なバックアップとして機能するように、少なくとも 30 日間廃止された資産を保持します。 組織のデータ ガバナンス チームには、30 日を超える保有期間を必要とするその他の要件がある場合があります。
振り返りを実施する
移行後に振り返りを行い、うまくいった点、改善できる点、学んだことを確認します。 チームの各メンバーから分析情報を得て、将来の移行に学習したレッスンを適用できるようにします。 プロセスを整理するチーム メンバーを特定します。 また収集したアイデアを追跡して整理する方法を選びます。