適切な計画とガバナンスは、最新化に不可欠です。 この段階では、適用する最新化アプローチとその方法を決定します。 慎重な計画を立てることで、実行中に予算の超過、スコープの拡大、またはサービスの中断が発生する可能性を低くすることができます。
最新化戦略を選択する
ワークロードを最新化することは、現在のビジネス目標、技術標準、クラウド機能に合わせて更新することを意味します。 3 つの主要な戦略 (リプラットフォーム、リファクタリング、再設計) は、複雑さと価値の連続に存在します。 ほとんどの最新化作業では、これらのアプローチを組み合わせて使用します。
重要なのは、目標、タイムライン、使用可能なリソースを考慮して、各コンポーネントの特定のニーズに戦略を合わせすることです。 過剰な最新化の誘惑を避ける。 新しいテクノロジはエキサイティングですが、すべての決定はビジネス価値に根付く必要があります。
| モダン化戦略 | Definition | いつ使用するか | Pros | Cons |
|---|---|---|---|---|
| Replatform | 最小限のコード変更 (IaaS から PaaS) でアプリケーションをクラウド プラットフォームに移動します。 | 必要な中断を最小限に抑え、迅速に勝ちます。 現在のコードは機能しますが、操作の負担は高くなります。 | 高速実装。 メンテナンス作業を削減します。 インフラストラクチャの改善により信頼性が向上します。 | 機能の向上が制限されています。 コア アプリケーションは変更されません。 |
| Refactor | 既存のコードを変更して、機能を維持しながら構造、パフォーマンス、およびクラウドの最適化を改善します。 | 技術的負債が原因で問題が発生したり、コードがクラウドに最適化されていない。 | 保守性、パフォーマンス、およびセキュリティが向上します。 将来の機能強化が容易になります。 | 開発者の多大な労力とテストが必要です。 ユーザーに対する即時の新機能はありません。 |
| Rearchitect | クラウドネイティブ パターン (マイクロサービス、サーバーレス、イベント ドリブン) を使用してアプリケーション アーキテクチャを再設計します。 | 現在のアーキテクチャでは、増加またはクラウドの最適化が制限されています。 | スケーラビリティに関する基本的な問題に対処します。 高度なクラウド サービスを有効にします。 長期的なイノベーションの基盤を築きます。 | 最も複雑で時間がかかります。 初期コストとリスクが高い。 広範なテストと並列操作が必要です。 |
段階的に最新化を計画する
複雑なワークロード全体 (または複数) を一度に最新化しようとすると、リスクが高まります。 作業を論理的なフェーズに分割します。 段階的な価値を提供し、管理可能なチャンクに取り組むことでリスクを軽減し、学習内容に基づいてフェーズ間のコースを調整することができます。
最新化を論理的なフェーズに分割します。 どのように作業を分割するかを決定します。 "正しい方法" は 1 つもありません。アーキテクチャとチーム構造に適した内訳を選択します。 目標は、各フェーズは、圧倒的な複雑さなしで実行してテストするのに十分な小ささですが、価値を提供するのに十分な意味を持つということです。 フェーズを分割する一般的な方法:
除算メソッド Description Example コンポーネントまたはレイヤー別 ワークロード レイヤーまたはワークロード境界に基づいてフェーズを分離する フェーズ 1: データベースの移行、フェーズ 2: アプリケーションのリファクタリング、フェーズ 3: UI の最新化 優先順位と複雑さ 低リスクから高リスクの変更までの作業を整理する フェーズ 1: 重要でないサービス、フェーズ 2: コア ビジネス ロジック、フェーズ 3: 顧客向けの機能 ビジネス機能別 アプリケーションまたは機能の境界に関する構造フェーズ フェーズ 1: ユーザー管理ワークロード、フェーズ 2: 支払処理、フェーズ 3: レポート サービス リスクが低く、価値の高い変更から始めます。 フェーズ 1 では、達成可能で、具体的な勝利を提供するものの、問題が発生してもビジネスを危険にさらさないものを選択します。 たとえば、顧客向けの Web サイトではなく、まずバックエンド サービスまたは内部ツールを最新化します。 証明ポイントとして、最初のフェーズをすばやく (1 か月または 2 か月) 完了することを目指します。 早期の成功により、後続のフェーズに対するチームの信頼と利害関係者のサポートが構築されます。
残りのフェーズを値と依存関係で順序付けます。 最初のフェーズの後、ビジネス価値と技術的依存関係に基づいて後続のフェーズの順序を計画します。 各フェーズにスコープが定義され、重要なコンポーネントのサポート要素が既に最新化または互換性があることを確認するロードマップを作成します。
- 脆弱な領域に対処します。 ワークロードが現在の状態で脆弱な場合は、フェーズ 1 で最新化しても安全に対応できるように、事前の "フェーズ 0" が必要になることがあります (以前の環境で緊急の修正プログラムを適用します)。
- 最初に前提条件に対処します。 ワークロード B の最新化がワークロード A の最新化 (または少なくとも安定) に依存している場合は、まずワークロード A を実行します。
- ビジネス価値とリスクを考慮する: 代わりに、価値の高いリスクの高い部分を 1 つのフェーズで実行し、次のフェーズではリスクの低い部分を行い、チームの負荷とビジネスへのリスクのバランスを取ることにします。
各フェーズの成功条件を定義します。 フェーズごとに、完了して成功したタイミングを決定します。 明確な終了条件を設定することで、フェーズ内のスコープの膨張を防ぐことができます。 成功条件には次のものが含まれます。
成功条件の種類 Examples 技術的な目標 • サービス X は Azure App Service で実行され、20% より多くの負荷を処理します
• データベース Y は、以前のベースラインから 10% 以内にデータ損失とパフォーマンスをゼロにして Azure SQL に移行します品質ゲート • Sev-1レベルのバグは開いていません
• すべての自動テストに合格
• セキュリティ スキャンで重大な脆弱性がゼロタイミングと予算の制約 •予算の3ヶ月以内に、5% 内に完了します
• スケジュールされたメンテナンス期間中にデプロイする結果に基づいて計画を調整します。 フェーズを完了したら、結果と学習した教訓を確認します。 一部の前提条件がオフであったり、一部のタスクが予想よりも簡単または困難であったりする場合があります。 フェーズの追加、組み合わせ、または再調整など、今後のフェーズの計画を適宜調整します。段階的なアプローチは柔軟であることを意図しています。 重要なのは、すべてを一度に試してみることではありません。
最新化ガバナンスの計画
最新化では重要なワークロードに大きな変更が加わることがよくあります。そのため、リスクを管理するには強力なガバナンスが必要です。 モダン化ガバナンスには、変更管理プロセス、凍結、およびスコープの制御が含まれます。
正式な変更承認ワークフローを確立します。 最新化に関連するすべての変更に対して構造化された承認プロセスを定義します。 既存の変更アドバイザリ ボード (CAB) と統合するか、専用のモダン化レビュー ボードを作成します。 変更カテゴリに基づいて承認機関を割り当て、プロジェクト計画の完全なワークフローを文書化します。 詳細については、「変更の 管理」を参照してください。
必要に応じて変更を停止します。 主要なデプロイ イベントの直前と実行中に、それらのワークロードに対するその他の変更を凍結します。 変更の凍結は、リードアップおよびデプロイ中に、それらのワークロードに関連しない他の変更が行われないことを意味します。 環境を安定させることで、動いているターゲットを追う必要がなくなります。 凍結ウィンドウを関連するすべてのチームに伝えます。
スコープ・クリープを回避します。 スコープ・クリープは、システムの近代化における主要な課題です。 評価と承認の手順を実行するには、合意されたモダン化スコープに対する提案された変更が必要です。 ほとんどの要求は、重要でない限り遅延する必要があります。 プロセスで余分な作業を行うために、"no, not now" を形式化します。 現在のモダン化が完了したら、将来のイノベーション プロジェクトにフィードできる、素敵なアイデアのバックログを維持します。 利害関係者は、自分のアイデアが失われていないことを知っている必要があります。
デプロイ戦略を定義する
実行上の重要な決定は、最新化されたコンポーネントを運用環境にロールアウトする方法です。 主な戦略は 2 つあります。 インプレース展開では、既存のセットアップをアップグレードします (家に住んでいる間に家を改装する場合など)。 並列展開では、新しいセットアップを一緒に構築します (新しい家の建設、引っ越しなど)。 各フェーズまたはワークロードの変更レベルとリスク許容度に合った戦略を選択します。 多くの場合、最新化の各フェーズでは異なる戦略が使用される場合があります。 たとえば、フェーズ 1 のインプレース (軽微な変更の場合) とフェーズ 2 の並列 (大規模なデータベースのオーバーホールが含まれる場合) を選択できます。
リスクが低く、元に戻せる変更には、インプレースデプロイを使用します。 インプレース デプロイでは、おそらくメンテナンス期間中に、現在の運用環境に直接変更が導入されます。 この戦略により、インフラストラクチャのオーバーヘッドは最小限に抑えられますが、ダウンタイムのリスクは高くなります。 インプレース デプロイは、変更が小さく分離され、簡単に元に戻すことができる場合にのみ使用します。 たとえば、ソース管理またはバックアップを使用してすばやくロールバックできる、コードのマイナー更新やスキーマの変更などがあります。
複雑な変更やリスクの高い変更には、並列デプロイを使用します。 このモデルでは、古いワークロードが引き続き実行されている間に、最新化されたワークロードの新しい環境を設定します。 データは (レプリケーションまたは移行プロセスを通じて) 同期され、準備ができたら古い環境から新しい環境に切り取ることができます。 ダウンタイムを最小限に抑える必要がある複雑またはリスクの高い変更に使用します。 新しいインフラストラクチャを伴う大規模なデータベース移行または再設計を行う場合は、通常、並列が方法です。 また、ワークロードがミッション クリティカルであり、数分以上のダウンタイムが発生しない場合は、並列 (レプリケーションと迅速なカットオーバー) が必要です。
Strategy Description いつ使用するか Pros Cons その場でのデプロイ 変更を現在の運用環境に直接デプロイする 小さく、取り消し可能な変更と許容可能なメンテナンス期間 重複しないインフラストラクチャ、迅速なデプロイ リスクが高く、ダウンタイムが必要、ロールバック速度が遅い 並列デプロイ 移行中に既存のワークロードと共に新しい環境を実行する 複雑な変更、最小限のダウンタイムを必要とするミッション クリティカルなワークロード より安全なデプロイ、ほぼゼロのダウンタイム、即時フォールバック インフラストラクチャ コストの重複、複雑なデータ同期、使用停止作業
最新化リスクの軽減を計画する
最高の計画とテストでも、すべての変更が完全に行くわけではありません。 モダン化には複雑な変更が伴うことが多く、デプロイによって問題が発生したり、運用環境で予期せず動作したりするリスクが常にあります。 適切に準備されたチームの特徴は、変更やフェーズごとに確実なロールバック計画を持っていることです。
プログレッシブ デプロイ手法を使用します。 プラットフォームで許可されている場合は、カナリア リリースを実施するか、アプリの更新された部分に段階的にトラフィックをシフトします。 たとえば、古いバージョンと並行して新しいバージョンをデプロイし、初めは監視しながらユーザーの5%だけを新しいバージョンに誘導します。 この方法では、ほとんどのユーザーが影響を受けない間に問題をキャッチできます。 メトリックが適切に見える場合は、50%に増やし、次に 100%。 何かが失敗し始める場合は、新しい (ロールバック)% 0 にすばやく戻ります。
すべての大きな変更に対してロールバック プロシージャを作成します。 すべての大きな変更またはフェーズ成果物について、ステップ バイ ステップのロールバック 手順を記述します。 変更を元に戻す各アクション、各ステップの責任者、所要時間を明確に一覧表示します。 ロールバック後に、正常に戻っていることを確認するチェックを含めます。
可能な限りロールバックを自動化します。 自動ロールバック スクリプトまたはコードとしてのインフラストラクチャを使用すると、迅速かつ信頼性の高い復旧を実現できます。 コードとしてのインフラストラクチャ ツール (Terraform、ARM テンプレート、Bicep) を使用して、既知の適切な状態を再デプロイします。 ブルーグリーンまたはカナリアデプロイでは、必要に応じて、本質的に以前のバージョンに"切り替える"ことができます。 ステージングでこれらのメカニズムをテストします。 目標は、スクリプト化されたアクションに対する手動作業 (インシデント発生時の午前 3 時) を減らすことです。 ロールバック手順をデプロイ手順と共に記述すると、ロールバックが簡単になります。
デプロイ中とデプロイ後にスタンバイ状態でサポートを受ける。 可能な限りトラフィックの少ない期間中 (週末または夜間) にデプロイを計画しますが、関連する専門家が利用できることを確認してください。 主要なチーム メンバーが休暇中の場合は、この操作を行わないでください。 デプロイメント直後に、開発者と運用チームがスタンバイしているエクステンデッドサポート（ハイパーケア）期間を設け、問題を早期に発見します。 本番稼働の際には、一部の組織が24〜48時間、ウォールームスタイルでの監視を行います。
利害関係者の承認をセキュリティで保護する
ここまでは技術計画に重点を置いた。 同様に重要なのは、ビジネスと技術の両方のリーダーシップを持つ利害関係者からバイインを受け入れることです。 最新化には多くの場合、多大な投資が必要になるため、説得力のあるケースを提示し、利害関係者の関与を維持する必要があります。
価値提案を各対象ユーザーに合わせて調整します。 利害関係者が異なると、さまざまな結果が考慮されます。 メッセージングをカスタマイズする:
- 技術チームは 、運用効率の優先順位を付けます。メンテナンスの削減、アップタイムの向上、エスカレーションの削減です。
- ビジネス リーダーは 、市場投入までの時間の短縮、カスタマー エクスペリエンスの向上、コスト削減などの成果に重点を置きます。
マイルストーンを含む構造化された計画を文書化します。 明確なロードマップを見れば、利害関係者はより快適です。 前に決定したとおりに計画したフェーズと、それぞれが達成すべき内容を、大まかなタイムラインで示します。 「6週間以内にXコンポーネントを最新化し、20%でパフォーマンスを向上させる」など、早期の勝利を強調します。
最新化の価値を定量化する。 前後のメトリックとターゲットの改善を準備します。 メトリックと一般的な改善範囲 (業界ベンチマークに基づく) の例を次に示します。
Category メトリックの例 一般的な値の範囲 コスト削減 インフラストラクチャ、メンテナンス、ライセンス 年間20~40% の節約 生産性の向上 デプロイの頻度、解決時間 50-80% の改善 リスク軽減 ダウンタイムの回避、セキュリティ インシデント $100K-$ 1M+ コスト回避 Revenue 市場投入までの時間を短縮し、顧客のリテンション期間を短縮 10-25% 収益の加速 プロジェクトのリスクに対処します。 特定の軽減戦略を通じて潜在的な課題を特定し、準備を示します。 一般的なリスクには、データ レプリケーション、パフォーマンスの低下、統合の問題などがあります。 自動ロールバック手順、包括的なテスト プロトコル、専門家によるコンサルテーションの可用性などのソリューションを紹介します。 透過的なリスクディスカッションは、プロジェクトのリーダーシップと計画の徹底に対する利害関係者の信頼を築きます。
定期的な通信周期を維持します。 定義された成功基準に対して進捗状況を報告し、完了した成果物を強調表示し、今後のマイルストーンを伝えます。 最新化プロセス全体を通じてサポートを維持するために、積極的にフィードバックを要求し、懸念事項に対処します。