翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

プロセスの視点

プロセスは一貫性をもたらしますが、各プロジェクトが一意であるため、進化し、変更の影響を受けやすくなります。プロセスを繰り返し実行すると、障害発生時、学習時、導入時、反復時に大きなメリットをもたらす可能性のある改善のギャップと余地を特定できます。これらの変更は、プロジェクトとビジネスが将来活用できる新しいアイデアやイノベーションにつながる可能性があり、品質とチームの自信をもたらす成長の促進要因となります。

移行プロセスは、以前にリンクされていない可能性のあるテクノロジーや境界を越えるため、複雑になる可能性があります。この視点は、大規模な移行の特定の要件に関するプロセスとガイダンスを提供します。

大規模な移行の準備

以下のセクションでは、移行ジャーニーを明確な方向性で開始し、成功に不可欠なステークホルダーからの賛同を得るために必要な基本原則の概要を説明します。

ビジネスドライバーを定義し、タイムライン、範囲、戦略を伝える

大規模な移行に近づくと AWS、サーバーを移行する方法が多数あることがすぐにわかります。例えば、次の操作を実行できます。

正しい移行パスを決定するには、ビジネスドライバーから逆算することが重要です。最終的な目標がビジネスの俊敏性の向上である場合は、2 番目の 2 つのパターンを優先できます。これには、より多くのレベルの変換が含まれます。年末までにデータセンターを退避することを目標とする場合は、リホストの速度によってワークロードをリホストすることを選択できます。

大規模な移行には、通常、次のような幅広い利害関係者が関係します。

移行のビジネス推進要因を特定し、移行プログラムのメンバーがアクセスできるプロジェクト憲章など、そのリストをドキュメントに含めることが重要です。さらに、目標とするビジネス成果に密接に一致する主要業績評価指標 (KPIs) を作成します。

たとえば、ある顧客が、データセンターを退避するという目標ビジネス成果を達成するために、12 か月以内に 2,000 台のサーバーを移行したいと考えています。ただし、セキュリティチームはこの目標に向けて調整されていませんでした。その結果、データセンターの閉鎖日を逃したが、アプリケーションをさらにモダナイズするか、最初にリホストしてタイムリーなデータセンターの閉鎖を可能にし、アプリケーションをモダナイズするかについて、数か月にわたる技術的な議論が行われました AWS。

ブロッカーの削除に役立つ明確なエスカレーションパスを定義する

大規模なクラウド移行プログラムには、通常、幅広い利害関係者が参加します。結局のところ、数十年にわたってオンプレミスでホストされているアプリケーションが変更される可能性があります。各利害関係者が競合する優先順位を持つことが一般的です。

すべての優先順位が価値をもたらす可能性がありますが、プログラムは予算の量が制限され、目標成果が定義されます。さまざまなステークホルダーを管理し、目標とするビジネス成果に焦点を当てるのは難しい場合があります。この課題は、移行の対象となる数百または数千のアプリケーションに乗算すると複雑になります。さらに、ステークホルダーは、他の優先事項を持つさまざまなリーダーシップチームに報告する可能性があります。これを念頭に置いて、目標とするビジネス成果を明確に文書化するとともに、明確なエスカレーションマトリックスを定義してブロッカーを排除することが重要です。これにより、かなりの時間を節約し、さまざまなチームを共通の目標に合わせることができます。

この例の 1 つは、12 か月以内にプライマリデータセンターを退避することを目標とする金融サービス会社です。明確なマンデートやエスカレーションパスがなかったため、時間と予算の制約に関係なく、ステークホルダーが希望する移行パスを作成しました。CIO へのエスカレーション後、明確な義務が設定され、必要な決定をリクエストするためのメカニズムが提供されました。

不要な変更を最小限に抑える

変化は良好ですが、変化が多いほどリスクが高くなります。大規模な移行のビジネスケースが承認されると、特定の日付までにデータセンターを退避するなど、このイニシアチブを推進するビジネス成果がターゲットになる可能性が高くなります。技術者が AWS サービスを最大限に活用するためにすべてを書き換えることは一般的ですが、これはビジネス目標ではないかもしれません。

ある顧客は、会社のウェブスケールインフラストラクチャ全体を 2 年間移行することに重点を置いていました AWS。アプリケーションチームがアプリケーションを書き換えて数か月を費やすことを防ぐためのメカニズムとして、2 週間のルールを作成しました。2 週間のルールを使用することで、顧客は何百ものアプリケーションを複数年にわたって移動する必要があったとき、一貫した頻度で長期的な移行を維持できました。詳細については、ブログ記事「The Two-week Rule: Refactor Your Applications for the Cloud in 10 Days」を参照してください。

ビジネス成果と一致しない変更は最小限に抑えることをお勧めします。代わりに、将来のプロジェクトでこれらの追加変更を管理するメカニズムを構築します。

end-to-endプロセスを早期に文書化する

大規模な移行プログラムの初期段階で、移行プロセス全体と所有権の割り当てを文書化します。このドキュメントは、移行の実行方法とその役割と責任についてすべての利害関係者を教育するために重要です。このドキュメントは、問題が発生する可能性のある場所を理解し、移行の進行中にプロセスの更新と反復を提供するのに役立ちます。

移行プロジェクトの開発中に、既存のプロセスを理解し、統合ポイントと依存関係が明確に文書化されていることを確認します。変更リクエスト、サービスリクエスト、ベンダーサポート、ネットワークとファイアウォールのサポートなど、外部プロセス所有者とのエンゲージメントが必要な場所を含めます。プロセスを理解したら、責任、説明責任、相談、情報 (RACI) マトリックスに所有権を文書化して、さまざまなアクティビティを追跡することをお勧めします。プロセスを確定するには、移行の各ステップに関連するタイムラインを特定してカウントダウン計画を確立します。カウントダウンプランは通常、ワークロード移行のカットオーバー日時から逆算して機能します。

このドキュメントアプローチは、1 年未満で AWS 正常に に移行し、4 つのデータセンターを終了した多国籍のホームアプライアンス企業にとってうまく機能しました。6 つの異なる組織チームと複数のサードパーティーが関係していたため、管理オーバーヘッドが発生し、意思決定がback-and-forthし、実装が遅れました。 AWS プロフェッショナルサービスチームは、顧客とそのサードパーティーと協力して、移行アクティビティの主要なプロセスを特定し、それぞれの所有者に文書化しました。結果の RACI マトリックスは、関係するすべてのチームによって共有され、合意されました。RACI マトリックスとエスカレーションマトリックスを使用して、お客様は遅延を発生させていたブロック要因と問題を軽減しました。その後、データセンターを事前に終了できました。

RACI とエスカレーションマトリックスを使用する別の例では、保険会社は 4 か月以内にデータセンターを出ることができました。お客様は責任共有モデルを理解して実装し、詳細な RACI マトリックスに従って、移行中の各プロセスとアクティビティの進行状況を追跡しました。その結果、実装の最初の 12 週間で 350 を超えるサーバーを移行できました。

標準の移行パターンとアーティファクトを文書化する

これを、実装用の Cookie カッターの作成と考えてください。再利用可能なリファレンス、ドキュメント、ランブック、パターンがスケーリングの鍵です。これらのジャーナルには、将来の移行プロジェクトが再利用して回避できる経験、学習、落とし穴、問題、ソリューションが記されており、移行を大幅に加速します。パターンとアーティファクトは、プロセスを改善し、将来のプロジェクトを導くのに役立つ投資でもあります。

たとえば、ある顧客が、3 つの異なる SI AWS パートナーによってアプリケーションが移行される 1 年間の移行を実行していました。初期段階では、各 AWS パートナーは独自の標準、ランブック、アーティファクトを使用していました。これにより、同じ情報がさまざまな方法で顧客チームに提示される可能性があるため、顧客チームに多くのストレスがかかりました。このような初期の苦労の後、顧客は移行で使用するすべてのドキュメントとアーティファクトの一元的な所有権を確立し、推奨される変更を送信するプロセスを確立しました。これらのアセットには以下が含まれます。

さらに、これらのドキュメントと標準への変更は毎週すべてのチームに送信され、各パートナーは変更の受信と準拠を確認する必要がありました。これにより、移行プロジェクトのコミュニケーションと一貫性が大幅に向上し、別のビジネスユニットで別の大規模な移行作業が開始されると、そのチームは既存のプロセスとドキュメントを採用でき、成功が大幅に加速しました。

移行メタデータとステータスの信頼できる単一のソースを確立する

大規模な移行を計画する場合、さまざまなチームを連携させ、データ駆動型の意思決定を可能にするには、信頼できる情報源を確立することが重要です。このジャーニーを開始すると、設定管理データベース (CMDB)、アプリケーションパフォーマンスモニタリングツール、インベントリリストなど、使用できる多数のデータソースが見つかる場合があります。

または、データソースが少なく、必要なデータをキャプチャするメカニズムを作成する必要があります。例えば、検出ツールを使用して技術情報を明らかにし、IT リーダーを調査してビジネス情報を取得する必要がある場合があります。

移行に使用できる 1 つのデータセットにさまざまなデータソースを集約することが重要です。その後、単一の信頼できるソースを使用して、実装中の移行を追跡できます。たとえば、移行されたサーバーを追跡できます。

提供されたデータセットを使用した移行の計画に重点を置いて、 AWS すべてのワークロードを に移行したいと考えている金融サービスの顧客。このデータセットにはビジネス重要度や依存関係情報などの重要なギャップがあったため、プログラムは検出演習を開始しました。

別の例では、同じ業界の企業が、サーバーインフラストラクチャインベントリout-of-date理解に基づいて移行ウェーブの実装に移行しました。データが正しくなかったため、すぐに移行数が減少し始めました。この場合、アプリケーション所有者は理解されなかったため、テスターを間に合うように見つけることができませんでした。さらに、データはアプリケーションチームが完了した廃止と一致していないため、サーバーはビジネス目的で使用されずに実行されていました。

大規模な移行の実行

ビジネス成果を確立し、ステークホルダーに戦略を伝えたら、大規模な移行の範囲を持続可能な移行イベントや波に取り込む方法の計画に進むことができます。次の例は、ウェーブプランを作成するための主要なガイダンスを提供します。

安定したフローを確保するために、移行ウェーブを事前に計画する

移行の計画は、プログラムの最も重要なフェーズの 1 つです。「計画に失敗した場合、失敗する予定」と書かれています。移行ウェーブを事前に計画しておくと、チームが移行状況に対してより積極的になるにつれて、プロジェクトが迅速に流れるようになります。これにより、プロジェクトのスケーリングが容易になり、プロジェクトの需要が増加し、複雑になるにつれて意思決定と予測が向上します。前もって計画することで、チームが変化に適応する能力も向上します。

例えば、ある大規模な金融サービスの顧客がデータセンターの出口プログラムに取り組んでいました。当初、お客様は移行ウェーブを順番に計画し、1 つのウェーブを完了してから次のウェーブの計画を開始します。このアプローチにより、準備時間が短縮されました。利害関係者がアプリケーションが移行されていることを知らされても AWS、移行を開始する前にいくつかのステップを実行する必要がありました。これにより、プログラムに大幅な遅延が発生しました。顧客がこれを認識した後、移行ウェーブが数か月前に計画された、包括的で未来に焦点を当てた移行計画ストリームを実装しました。これにより、アプリケーションチームは、 AWS パートナーへの通知、ライセンス分析などの移行前アクティビティを実行するのに十分な通知が提供されました。その後、プログラムの重要なパスからこれらのタスクを削除できます。

ウェーブ実装とウェーブ計画を個別のプロセスとチームとして維持する

ウェーブプランニングチームとウェーブ実装チームが別々の場合、2 つのプロセスは並行して機能します。通信と調整では、十分なサーバーやアプリケーションが期待速度を達成する準備ができていないため、移行が遅くなるのを回避できます。例えば、移行チームは毎週 30 台のサーバーを移行する必要があるかもしれませんが、現在のウェーブでは 10 台のサーバーしか準備ができていません。この課題は、多くの場合、以下が原因で発生します。

事前にウェーブを計画し、準備とウェーブ実装の開始の間にバッファを作成することが重要です。また、ウェーブプランニングチームと移行チームが連携して適切なデータを収集し、再作業を避けることも重要です。

大きな成果を得るために小規模から始める

小規模から始めて、その後のウェーブごとに移行速度を上げることを計画します。初期ウェーブは、10 台未満の単一の小さなアプリケーションである必要があります。後続のウェーブにアプリケーションとサーバーを追加し、移行速度を最大限に向上させます。複雑性やリスクの低いアプリケーションを優先し、スケジュールに従って速度を上げることで、チームは連携して作業し、プロセスを学習する時間を確保できます。さらに、チームはウェーブごとにプロセスの改善を特定して実装できるため、後のウェーブの速度を大幅に向上させることができます。

あるお客様は、年間 1,300 台を超えるサーバーを移行していました。パイロット移行といくつかの小さなウェーブから始めることで、移行チームは後の移行を改善する複数の方法を特定できました。例えば、以前に新しいデータセンターネットワークセグメントを特定しました。プロセスの早い段階でファイアウォールチームと協力して、移行ツールとの通信を可能にするファイアウォールルールを設定しました。これにより、将来の波での不要な遅延を防ぐことができます。さらに、チームは、各ウェーブで検出プロセスとカットオーバープロセスをさらに自動化するスクリプトを開発することができました。小規模から始めることで、チームは初期のプロセス改善に集中し、自信が大幅に高まりました。

カットオーバーウィンドウの数を最小限に抑える

大規模な移行には、スケールを推進するための統制のとれたアプローチが必要です。一部の領域で柔軟性が高すぎることは、大規模な移行にはアンチパターンです。毎週のカットオーバーウィンドウの数を制限することで、カットオーバーアクティビティに費やされる時間が高くなります。

たとえば、カットオーバーウィンドウの柔軟性が高すぎる場合、それぞれ 5 台のサーバーで 20 回のカットオーバーが発生する可能性があります。代わりに、それぞれ 50 台のサーバーで 2 つのカットオーバーを行うことができます。各カットオーバーの時間と労力は似ているため、カットオーバーが少なくて大きいほど、スケジューリングの運用上の負担が軽減され、不要な遅延が制限されます。

ある大規模なテクノロジー企業が、契約の有効期限が切れる前にいくつかのリースデータセンターから移行しようとしていました。有効期限が切れると、費用がかかり、短期間の更新期間が発生します。移行の早い段階で、アプリケーションチームは、カットオーバーのわずか数日前に何らかの理由で移行をオプトアウトするなど、過去 1 分間の移行スケジュールを指示することができました。これにより、プロジェクトの初期段階で多数の遅延が発生しました。多くの場合、顧客は過去 1 分間に他のアプリケーションチームと交渉して入力する必要がありました。顧客は最終的に計画の規律を高めましたが、この初期のミスにより、移行チームに継続的なストレスが生じました。スケジュール全体の遅延により、一部のアプリケーションがデータセンターから間に合わなくなりました。

フェイルファスト、エクスペリエンスの適用、反復

すべての移行には、最初は落とし穴があります。早期失敗は、チームが学習し、ボトルネックを理解し、学んだ教訓をより大きな波に適用するのに役立ちます。移行の最初の数波は、次の理由で遅くなることが予想されます。

問題は一般的であり、最初の数波中に予期されます。一部のチームは新しいことを試して失敗することを好まない可能性があるため、これを理解し、組織全体に伝えることが重要です。失敗すると、チームを失望させ、将来の移行の妨げになる可能性があります。最初の問題がジョブの一部であることを全員が理解し、全員が失敗するように促すことが、移行を成功させるための鍵となります。

ある会社では、24～36 か月で 10,000 台を超えるサーバーを移行する予定です。この目標を達成するには、1 か月あたり約 300 台のサーバーを移行する必要がありました。ただし、1 日目から 300 台のサーバーを移行したわけではありません。最初のいくつかの波は波を学習することでした。これにより、チームは物事がどのように機能し、誰が何を行う権限を持っているかを理解できます。また、CMDB や CyberArk との統合など、プロセスを改善する統合も特定しました。学習ウェーブを使用して失敗、改善、失敗し直し、プロセスと自動化を改善しました。6 か月後、毎週 120 を超えるサーバーを移行できました。

遡及的情報を忘れないでください。

これはアジャイルプロセスの重要な部分です。チームがコミュニケーション、調整、学習、同意、前進する場所です。最も基本的なレベルでの遡及的調査は、振り返って、何が起こったのかを議論し、何がうまくいき、何を改善する必要があるのかを判断することです。その後、それらの議論に基づいて改善を構築できます。遡及的思考は、教訓を学ぶという概念に形式やプロセスを巻き付けます。大規模な移行を成功させるには、プロセス、ツール、チームが常に進化し、改善する必要があるため、遡及性は重要です。遡及的分析はその中で重要な役割を果たします。

従来の教訓学習セッションはプログラムが終了するまで行われないため、多くの場合、これらの教訓は次の移行ウェーブの開始時にレビューされません。大規模な移行では、学んだ教訓を次のウェーブに適用し、ウェーブ計画プロセスの重要な部分とする必要があります。

ある顧客については、カットオーバーから学んだ教訓について議論し、文書化するために、毎週の遡及調査が行われました。これらのセッションでは、プロセスの観点や自動化から合理化の範囲がある領域を発見しました。これにより、特定のアクティビティ、所有者、自動化スクリプトを含むカウントダウンスケジュールを実装し、カットオーバー中のサードパーティーツールの検証や Amazon CloudWatch エージェントのインストールなど、手動タスクを最小限に抑えました。

別の大規模なテクノロジー企業では、以前の移行ウェーブの問題を特定するために、チームと定期的な遡及調査を実施しました。これにより、プロセス、スクリプト、自動化が改善され、プログラム全体で平均移行時間が 40% 短縮されました。

その他の考慮事項

多くの分野を大規模な移行プログラムに組み込む必要があります。以下のセクションでは、考慮すべき他の項目について説明します。

移動中にクリーンアップする

コストが予想の 10 倍で、移行に使用されるリソースがシャットダウンされてクリーンアップされるまでプロジェクトが完了していない場合、移行は成功とは見なされません。このクリーンアップは、移行後のアクティビティの一部である必要があります。これにより、使用されていないリソースやサービスが環境に残ってコストが増加することがなくなります。移行後のクリーンアップは、環境を公開する脅威や脆弱性を防ぐための優れたセキュリティプラクティスでもあります。

への移行の主な成果 AWS クラウド は、コスト削減とセキュリティの 2 つです。未使用のリソースを残すと、クラウドへの移行というビジネス目的が損なわれる可能性があります。クリーンアップされない最も一般的なリソースは次のとおりです。

不正なクリーンアッププラクティスの一例では、SI AWS パートナーは移行が成功した後にレプリケーションエージェントを削除しませんでした。 AWS 監査では、すでに移行されていたレプリケーションサーバーと EBS ボリュームのコストは毎月 20,000 USD (USD) であることがわかりました。この問題を軽減するために、 AWS Professional Services は、古いサーバーがまだレプリケートされているときに SI AWS パートナーに通知する自動監査プロセスを作成しました。その後、SI AWS パートナーは未使用の古いインスタンスに対してアクションを実行できます。

今後の移行では、移行後のハイパーケア期間として 48 時間を定義し、プラットフォームのスムーズな導入を保証するプロセスを採用しました。次に、お客様のインフラストラクチャチームがオンプレミスサーバーに対して廃止リクエストを送信しました。廃止リクエストが承認されると、それぞれのウェーブのサーバーがアプリケーション移行サービスコンソールから削除されることが通知されました。

追加の変換のために複数のフェーズを実装する

大規模な移行を実行するときは、データセンターの閉鎖やインフラストラクチャの変革など、中心的な目標に集中し続けることが重要です。小規模な移行では、スコープクリープの影響は最小限に抑えられます。ただし、数日の追加作業に数千のサーバーを掛けると、プログラムにかなりの時間がかかる可能性があります。さらに、追加の変更により、サポートチームのドキュメント、プロセス、トレーニングの更新が必要になる場合もあります。

潜在的なスコープクリープを克服するために、移行に多段階アプローチを実装できます。例えば、データセンターを退避することが目標である場合、フェーズ 1 には、ワークロードをできるだけ AWS 速くリホストすることのみが含まれる場合があります。ワークロードがリホストされると、フェーズ 2 はターゲットのビジネス成果を危険にさらすことなく、変革的なアクティビティを実装できます。

たとえば、ある顧客が 12 か月以内にデータセンターを出る予定でした。ただし、移行には、新しいアプリケーションパフォーマンスモニタリングツールのロールアウトやオペレーティングシステムのアップグレードなど、他の変換アクティビティが含まれていました。1,000 台以上のサーバーが移行対象であったため、これらのアクティビティにより移行が大幅に遅れました。さらに、このアプローチでは、新しいツールの使用に関するトレーニングが必要でした。顧客は後で、リホストに重点を置いた複数フェーズのアプローチを実装することを決定しました。これにより、移行速度が向上し、データセンターの閉鎖日を満たさないリスクが軽減されました。