大規模な移行の管理について

大規模な移行プロジェクトを管理および効果的に管理するには、プロジェクトマネージャーはポートフォリオ、大規模な移行のフェーズ、各ワークストリームの責任について高レベルに理解する必要があります。

大規模な移行のワークストリーム

移行フェーズでは、いつでも、基盤、プロジェクトガバナンス、ポートフォリオ、移行ワークストリームの少なくとも 4 つのワークストリームが同時に運用されています。これらは大規模な移行プロジェクトの中核的なワークストリームであり、プロジェクトには追加のサポートワークストリームがある場合があります。詳細については、「大規模な移行のための Foundation プレイブック」の「大規模な移行のワークストリーム AWS 」を参照してください。

移行パイプラインへのフィード

移行ファクトリーでは、ウェーブプランニングと移行が同時に行われ、継続的に運用されます。ポートフォリオチームはウェーブを計画して移行パイプラインをフィードし、移行チームは移行とワークロードのカットオーバーを実行してパイプラインを完了します。ポートフォリオチームは初期化段階の最後に 5 つのウェーブを準備し、実装段階は移行チームが準備したウェーブの 1 つ以上を移行し始めたときに開始されます。

ウェーブごとに、ポートフォリオのワークストリームは 1～2 週間、移行ワークストリームは通常 3～4 週間実行されます。ポートフォリオワークストリームは移行ワークストリームより 5 ウェーブ先にあるため、ポートフォリオと移行ワークストリームの間には常に 5 ウェーブバッファがあります。実装段階では、ポートフォリオチームと移行チームの両方が引き続きウェーブを処理し、バッファによって移行ワークストリームのサーバーが不足して移行できなくなります。ウェーブスケジュールの例については、「大規模移行ガイド」の「ステージ 2: 大規模移行の実装 AWS 」を参照してください。

ポートフォリオチームはアプリケーションを優先し、論理移動グループのウェーブに割り当てます。ウェーブを計画するとき、ポートフォリオチームは移行の複雑さ、アプリケーションの類似点、アプリケーションとインフラストラクチャの依存関係を考慮します。これにより、アプリケーションとその依存関係全体が確実に移行されます。ウェーブプランニングの詳細については、AWS 「大規模な移行のためのポートフォリオプレイブック」を参照してください。プロジェクトガバナンスでは、アプリケーション、サーバー、アプリケーション所有者など、ウェーブとスプリントに関する情報を管理および追跡します。Confluence サイトのダッシュボード、Microsoft Excel のリスト、またはツールの組み合わせを使用できます。

ハイパーケア期間

カットオーバーが完了すると、移行されたアプリケーションとサーバーはハイパーケア期間に入ります。ハイパーケア期間中、移行チームは、問題に対処するためにクラウド内の移行されたアプリケーションを管理およびモニタリングします。通常、この期間は 1～4 日です。ハイパーケア期間の終了時に、移行チームはアプリケーションの責任をクラウド運用 (Cloud Ops) チームに移します。現時点では、ウェーブは完了したと見なされます。

アジャイルアプローチの確立

アジャイルなアプローチを確立することで、プロジェクトチームは移行中の変化に柔軟に対応し、迅速に適応できます。大規模な移行には、スクラムフレームワークを採用することをお勧めします。AWS 大規模な移行の移行プレイブックでは、スプリントにウェーブを割り当てます。スプリントは、移行チームがそのスプリント内のすべてのウェーブに作業する一定期間です。各スプリントの期間が 2 週間の場合、各ウェーブは少なくとも 2 つのスプリントにまたがります。スプリントは、スプリントの計画や毎日のスタンドアップミーティングの実施、レビュー、遡及などの標準イベントで構成されます。

スプリントの現在のタスクと保留中のタスクで構成されるスプリントバックログを使用して、アクティビティを管理します。このプレイブックでは、進行状況を追跡するためのプロジェクト管理ツールを選択します。Jira や Confluence などのプロジェクトや問題追跡アプリケーションを選択し、カンバンボードやガントチャートなどのタスクを表す視覚的なアプローチを選択することもできます。これらのツールの 1 つ以上でスプリントバックログを追跡することで、プロジェクトの透明性を提供し、各タスクに所有者を割り当て、明確な期限を設定します。