クラウドの最新化は、ビジネス ニーズをより適切に満たすために、既存のクラウドベースのワークロードを改善する手法です。 新しい機能を追加することなく、ワークロードをクラウドのベスト プラクティスに合わせます。 このフレームワークは、組織がすべてのワークロード チームで最新化を計画および実行するためのエンド ツー エンドガイドを提供します。
組織の最新化を定義する
最新化の成功は、組織の準備から始まります。 この段階では、モダン化が会社にとって何を意味するのかを誰もが理解できるようになります。 また、チームに必要なスキルがあるかどうかを評価し、最初に最新化するアプリケーションを特定する必要があります。
最新化の共通の定義を確立します。 クラウドの最新化により、新しい機能を構築することなく、既存のワークロードの動作が向上します。 一般的な最新化アクティビティには、再プラットフォーム化 (新しいホスティング環境へのコンポーネントの移動)、リファクタリング (コードの最適化または再構築)、クラウド内での再設計 (システムの構造の再設計) などがあります。 最新化では、新しい新機能や、新しい機能の完全な書き換えが除外されます。
最新化の定義を伝えます。 この定義を関連するすべてのチームや利害関係者と共有します。 プロジェクト マネージャー、エンジニア、製品所有者、およびエグゼクティブが理解し、同意していることを確認します。 統一された理解は、ミスアラインメントを防ぎます。
チーム間で責任を共有する。 最新化には、開発チーム、運用チーム、セキュリティ チーム、アーキテクチャ チーム間のコラボレーションが必要です。 各チームは、最新化の成功にさまざまな専門知識を提供します。 定期的なコミュニケーションと共同意思決定プロセスを確立します。 統合の問題や要件を満たさなくなるサイロ化された作業を避けます。 チーム間の調整を維持しながら、明確なロールを割り当てます。
モダン化の準備とスキルを評価する
モダン化のスキルを評価します。 最新化に着手する前に、チームが正常に最新化するために必要なスキルとツールを持っているかどうかを評価します。 評価する主な領域は次のとおりです。
スキル領域 評価に関する質問 クラウド サービスの知識 エンジニアは、最新化時に使用する可能性のある関連する Azure サービスに精通していますか? DevOps と CI/CD 成熟した継続的インテグレーション/継続的デリバリー パイプラインを導入していますか? コードとしてのインフラストラクチャを使用してテストとデプロイを自動化できますか? 最新のアーキテクチャ パターン チームは、リファクタリングまたは再設計の一部となる可能性があるマイクロサービス、コンテナー化、およびその他の最新のクラウドネイティブの概念を理解していますか? 監視と自動化 最新化後のより高度なクラウド運用をサポートするには、監視、ログ記録、自動化のツールで十分ですか? スキルのギャップを特定し、それらを埋める計画を作成します。 既存のスタッフ (Azure 認定資格、クラウド アーキテクチャ ワークショップ) をトレーニングしたり、特定の専門知識を持つ新規採用/請負業者を導入したりすることもできます。 多くの場合、スキルは特定のテクノロジよりも重要です。 適切なトレーニングを受けたチームは、チームがオンザフライで学習するよりもスムーズに最新化を実行します。
必要に応じて外部の専門知識を活用します。 チームに重要な領域での経験がない場合は、Microsoft または Microsoft パートナーを呼び込む必要があります。 外部の専門家は、最新化戦略を検証し、適切なツールを推奨し、現実的なタイムラインを確立するのに役立ちます。
最新化するワークロードに優先順位を付ける
すべてのワークロードを最新化する必要があるわけではありません。 構造化されたアプローチを使用して、最初に最新化するワークロードを決定します。 重要なのは、ビジネス価値を技術的リスクと比較し、アクションを強制する緊急のトリガーを特定することです。
ビジネス価値を評価する。 候補となるワークロードの一覧を作成し、それぞれの重要度をビジネスに評価します。 ビジネス価値には、高/中/低のランク付けまたは数値スコアを使用できます。 ワークロードが収益、顧客満足度、または運用にとって重要であるほど、ビジネス価値スコアが高くなります。
ビジネス価値カテゴリ Examples 収益または重要業務 販売トランザクションを処理するシステム、または主要なビジネス機能をサポートするシステム (ダウンタイムは、直接失われたお金を意味します) カスタマー エクスペリエンス 顧客またはクライアントが直接やり取りするシステム (パフォーマンスと信頼性が満足度に影響を与える) コンプライアンスまたは規制 厳格な規制またはセキュリティ要件の対象となるシステム (更新に失敗すると、法的リスクが発生する可能性があります) 広範な内部依存関係 従業員やその他のシステムによって広く使用されているプラットフォーム (低速または不安定な場合は、組織全体の生産性を下げる) 技術的なリスクを評価します。 個別に、各システムの技術的な状態を評価します。 基本的に、モダン化が必要な量を把握します。 技術的なリスク/ニーズを、ワークロードごとに高、中、または低としてランク付けします。 高い技術的リスクまたは負債の兆候は次のとおりです。
技術的なリスク カテゴリ Examples 技術的負債 回避策、古いフレームワーク、変更が難しいアーキテクチャを含むレガシ コード 古いテクノロジ サポート終了に近いオペレーティング システムまたはデータベース、非推奨のプログラミング言語 高いメンテナンス作業 頻繁な手動介入、サポート コストの増加、複雑なトラブルシューティング プロセス パフォーマンスと信頼性の問題 慢性的なダウンタイム、応答時間の遅さ、負荷の急増に対処できない スケーラビリティの制限 成長に大きな手直しを必要とするアーキテクチャ、手動スケーリング プロセス 緊急の最新化のトリガーを特定します。 一部のイベントは、最初に一覧の先頭になかった場合でも、ワークロードの優先度を突然変更する可能性があります。 最新化を緊急にするための次のトリガーを監視します。
トリガー カテゴリ Examples セキュリティの脆弱性 レガシ コンポーネント、古い暗号化プロトコル、またはコンプライアンス違反で新しく検出されたセキュリティ ホール サポート終了期限 12 か月以内にベンダーのサポートを失うプラットフォームまたはソフトウェア、古いセキュリティ パッチ ビジネスの成長需要 システム容量、新しい市場参入要件、または統合ニーズを超える顧客の急速な成長 システムの信頼性に関する問題 停止の繰り返し、慢性的なパフォーマンスの問題、またはメンテナンス コストのエスカレート ワークロードに優先順位を付けます。 ビジネス価値と技術的なリスク評価を単純な優先順位マトリックスに組み合わせます。
ビジネス バリュー 技術的リスク モダン化の優先順位 Action High High 最高優先順位 今すぐモダン化を開始します。 投資収益率が高い High Low Monitor 特定のビジネス上の利点がない限り、最新化を遅らせる Low High Case-by-case 明確な利点がない限り、すぐに最新化しない Low Low 何もしない ここでの最新化作業は、リソースを適切に使用することはできません。
最新化の方法を理解する
実行に進む前に、自分と個々のワークロード チームが、クラウドでの最新化のアプローチとベスト プラクティスを理解していることを確認します。
Azure Well-Architected Framework を使用して改善の機会を見つける。. Well-Architected Framework (WAF) は、信頼性、セキュリティ、コストの最適化、オペレーショナル エクセレンス、パフォーマンス効率の 5 つの柱にわたるベスト プラクティスのセットです。 ワークロードの Well-Architected レビュー を実施すると、ベスト プラクティスに従っていない箇所が強調表示されます。 これらのギャップにより、モダン化のための to-do リストが効果的に生成されます。 ギャップの数が多いほど、そのワークロードを最新化する必要性が高くなります。 この方法で、WAF は修正対象のデータドリブン ロードマップを提供します。
ワークロード チームが最新化の意思決定を行えるようにします。 各アプリケーションを日常的に所有および実行するチームは、多くの場合、その問題点と、どのような変更が役立つかについて、最も深い洞察を得ることができます。 システムを最新化する方法を決定するには、これらのチームを関与させるのが賢明です。 ビジネス コンテキスト ("2 倍のトラフィックを処理するにはこのシステムが必要です" または "メンテナンス コストを 30%削減する必要があります" ) を提供し、ソリューションを提案します。 おそらく、特定のサービスをスワップアウトできることや、コードのどの部分が最悪であるかを知っているかもしれません。 予算、タイムライン、全体的なアーキテクチャ標準の境界内で技術的な選択を行うために、これらのチームに意思決定権限を提供します。 定期的なチェックインを確立して、より広範な組織の目標に合った計画を立ててください。