運用管理プロセスを確立する

企業が Azure でワークロードの運用を開始したら、次のステップは、運用管理および適合性のプロセスを確立することです。 このプロセスでは、これらのワークロードに対する運用状態を列挙、実装、繰り返し確認して、最適化します。

運用適合性レビューのプロセスにより、ワークロードのポートフォリオ全体が、パフォーマンス、信頼性、コストに対するビジネス コミットメントを確実に満たすことができます。 このプロセスでは、中央 IT、クラウドのセンター オブ エクセレンス、ワークロード チームの取り組みを合わせ、大規模なオペレーショナル エクセレンスを実現します。

運用適合性レビューのコア プロセスを確立する

運用環境でワークロードを実行することが原因で発生する問題と、それらの問題を修復および解決する方法を完全に理解するために、運用適合性レビューのプロセスを作成します。 この記事では、企業がこの目標を達成するために使用できる高レベルの運用適合性レビューのプロセスの概要について説明します。

Microsoft での運用適合性

当初から、Microsoft の多くのチームが Azure プラットフォームの開発に携わってきました。 このような規模と複雑さのプロジェクトで、品質と一貫性を確保することは困難です。 基本的な非機能要件を定期的に列挙して実装するには、堅牢なプロセスが必要です。

Microsoft が実施するプロセスが、この記事で概要を説明するプロセスの基礎を形成しています。

ロールと運用モデルを理解する

運用管理は、企業全体にわたって複数のロールが関係する広範な規範です。 組織の運用モデルによっては、これらのロールは、一元化および分散化された運用チームの間での多数の引き渡しが行われるマトリックス化された環境で動作する可能性があります。

• 中央 IT/CCoE: この一元化されたテクノロジ機能は、テクノロジ ポートフォリオ内のすべてのテクノロジ資産の構成、運用、ガバナンス、セキュリティを担当します。
• クラウド運用: 一元化されたテクノロジ組織内の機能です。この運用機能により、テクノロジ ポートフォリオの正常性と運用が管理されます。 プロセスが円滑に実行されるように、プロセス内の隣接する各ロールに必要なツールが与えられるように、このプロセスの予想されるものに対して後続ロールのそれぞれが責任を負うように手配するのがその役割です。
• クラウド戦略: さまざまなワークロードの運用要件を維持するためにコミットメントを識別し、優先順位を付けることができるように、ビジネスに関する知識を提供します。 また、軽減コストをビジネスへの影響と比較し、修復に関する最終的な決定を下します。
• ワークロード チーム: オンプレミスかクラウド内かにかかわらず、特定のサポート アプリケーション、サービス、インフラストラクチャにマップされる個々のワークロードの開発と運用に対する責任を負います。 このロールには、ワークロード アーキテクチャに関する深い知識が必要です。

各組織の運用モデルは、上記のロールの説明責任と日常的なアクティビティを決定します。

• 一元化された運用: 中央 IT は、運用に対する全面的な説明責任を保持します。 ワークロードの所有者は、運用と構成への入力がある場合がありますが、運用環境の変更にアクセスすることはできません。 運用適合性を向上させるために運用の変更を行うことができるのは、中央 IT およびクラウド運用だけです。
• 分散化された運用: ワークロード チームは通常、成熟した CI/CD パイプラインと DevOps 自動化を通じて、運用に対する全面的な説明責任を負います。 このモデルでは、構成、運用、ガバナンス、セキュリティに対する中央のサポートはありません。 この運用に対するアプローチは、クラウド導入フレームワークの対象範囲外です。 この運用モデルには、運用ガイダンスの Azure Well-Architected Framework が表示されます。
• エンタープライズ運用: クラウドのセンター オブ エクセレンスは、運用に対する責任を負います。 クラウド運用チームとワークロード チームはそれぞれ、運用適合性の特定の側面に対する責任を共有します。

レビューの目的

運用適合性は、信頼性、パフォーマンス、コストといういくつかのメトリックを使用して、ポートフォリオ全体で評価されます。 これらのプロパティをまとめると、ポートフォリオ内のすべての資産に関する正常性と適合性を迅速に評価できます。 これらのメトリックは、3 つの運用管理の昇格で評価されます。

• 運用ベースライン (または拡張ベースライン): 機能に関係なく、デプロイされているすべての資産で運用適合性を評価します。 この運用に対する幅広い視野を持つことで広範囲にわたる変更や大きな影響を実現できますが、個々のワークロードのアーキテクチャでの可視性の欠如によって制限されます。 クラウドにデプロイされているすべてのリソースは、クラウド運用からの通常のサポートを備えた運用ベースラインの対象である必要があります。 環境によっては、強化されたベースラインのニーズを満たすために、より高いレベルの運用サポートが必要になる場合があります。
• プラットフォーム運用: 一元化されたテクノロジ プラットフォームの運用適合性を評価します。 この運用のビューは、プラットフォームのアーキテクチャと、ソリューションに対する変更が運用適合性にどのように影響するかを考慮しているため、より洗練されています。 中央テクノロジ プラットフォームを変更すると、サポートされているワークロードに対してダウンストリームの影響が広範囲に及ぶ可能性があります。 ミッション クリティカルなすべてのプラットフォームは、中央 IT チームから専用のサポートを受ける必要があります。
• ワークロード運用: 個々のワークロードの運用適合性を評価します。 この運用のビューはより洗練されており、運用適合性を改善するためにワークロードのアーキテクチャに変更を加える必要がある場合に考慮する必要があります。 ワークロード運用は、Azure Well-Architected Framework の原則に準拠している必要があります。 アクティブな DevOps サイクルを持つミッション クリティカルなすべてのワークロードは、ワークロード チームから専用のサポートを受ける必要があります。

運用適合性レビューの目的は、すべてのレベルで運用適合性を定期的に評価することです。 その後、特定された改善点を適切なレベルで適用して、ポートフォリオ全体の管理に必要な変更を通知することができます。

運用適合性レビューのプロセス

企業のポートフォリオのパフォーマンスと継続性の維持において重要なのは、運用適合性レビューのプロセスを実装することです。

概要レベルでは、プロセスには 2 つのフェーズがあります。 前提条件フェーズでは、要件が確立されて、サポート サービスにマップされます。 このフェーズは頻繁に行われません。おそらく、年 1 回や、新しい業務の導入時です。 前提条件フェーズの出力は、フロー フェーズで使用されます。 フロー フェーズは、毎月のように、さらに頻繁に発生します。

前提条件フェーズ

このフェーズのステップでは、ポートフォリオとミッション クリティカルなワークロードの定期的なレビューを実施するための要件をキャプチャします。

1. 重要なビジネス業務を識別する。 合意されたビジネス コミットメントに基づいて、企業のミッション クリティカルなビジネス操作を識別します。 ビジネス操作は、すべてのサポート サービス機能から独立しています。 つまり、ビジネス操作は、ビジネスで実行する必要があり、IT サービスのセットによってサポートされる、実際のアクティビティを表します。

   "ミッション クリティカル" (または "ビジネス クリティカル") という用語は、操作が妨げられた場合のビジネスに対する重大な影響を示します。 たとえば、オンライン小売業には、"客がショッピング カートに商品を追加できるようにする" や "クレジット カードの支払いを処理する" といったビジネス操作が存在する場合があります。これらの操作のいずれかが失敗した場合、顧客は取引を完了できず、企業は販売の実現に失敗します。

2. 業務をサービスにマップする。 重要なビジネス操作を、それらをサポートする IT サービス (ベースライン、プラットフォーム、ワークロードの操作) にマップします。 また、重要なビジネス機能をサポートするために必要なテクノロジ プラットフォームまたはワークロードを識別して、操作やサービスを担当チームにマップする必要もあります。

3. サービスの依存関係を分析する。 ほとんどのビジネス操作では、複数のサポート ワークロードとテクノロジ プラットフォームの間のオーケストレーションが必要です。 サポート資産の各セット間の依存関係と、これらのサービスを介したミッション クリティカルなトランザクションのフローについて理解しておくことが重要です。

   オンプレミスのサービスと Azure サービスの間の依存関係についても考慮してください。 ショッピング カートの例では、在庫管理サービスがオンプレミスでホスティングされていて、実際の倉庫から従業員によって入力されたデータを取り込む場合があります。 一方で、Azure Storage などの Azure サービスや、Azure Cosmos DB などのデータベースにオフプレミスでデータを格納する場合もあります。

これらのアクティビティからの出力は、運用管理に対するスコアカード メトリックのセットです。 スコアカードは、信頼性、パフォーマンス、コストなどの基準を測定します。 スコアカードのメトリックは、サービスで満たすことを期待する運用基準を表します。

スコアカードは、ビジネス所有者、クラウド運用、ワークロード チームの間の意味のあるディスカッションを容易にするために簡単な用語で表す必要があります。 たとえば、信頼性に関するスコアカードのメトリックは、合意された SLA の達成に基づいて色分けされている場合があります。 緑色は定義された SLA を満たしていること、黄色は定義された基準を満たしていないが計画的な修復をアクティブに実装していること、赤色は定義された基準を満たしておらず計画もアクションもないことを意味します。

これらのメトリックがビジネス コミットメントを直接反映する必要があることを強調することが重要です。

サービス レビュー フェーズ

サービス レビュー フェーズは、運用適合性レビューの中核です。 以下のステップが関係します。

1. サービス メトリックを測定する。 スコアカードのメトリックを使用して、運用管理の各レベルでパフォーマンスを監視することにより、サービスにおいてビジネス コミットメントを確実に満たせるようにします。 インベントリおよび可視性のサービスが運用ベースライン内であることは不可欠です。 ビジネス コミットメントに関してリソースのセットを監視できない場合、対応するスコアカードのメトリックは赤色であると見なします。 この場合、修復のための最初のステップは、適切なサービス監視を実装することです。 たとえば、企業が 99.99% の可用性でのサービス運用を期待しているのに、可用性を測定するための運用テレメトリが配置されていない場合は、要件が満たされていないと想定します。

2. 修復を計画する。 メトリックが許容されるしきい値を下回っているビジネス コミットメントごとに、必要な修復を完了するための適切な運用チームを決定します。 このチームは、サービスを修復して、運用を許容されるレベルまで引き上げるためのコストの計算を担当します。 この問題の修復のコストが、そのサービスに割り当てられた予算を超えている場合、中央 IT または CCoE はクラウド戦略チームと確認して、追加の投資を評価する必要があります。

3. 修復を実装する。 クラウド運用チームまたはワークロード チームは、修復計画の承認後、それを実装します。 スコアカードのメトリックを評価するたびに、実装の状態を報告します。

このプロセスは、繰り返し実行されます。 中央 IT または CCoE チームは、プロセスを管理し、クラウド戦略チームに進行状況を報告する責任があります。 このチームは、定期的にミーティングを行って、既存の修復プロジェクトを検討し、新しいワークロードの基礎レビューを開始し、企業の全体的なスコアカードを追跡する必要があります。 また、このチームには、修復チーム (クラウド運用またはワークロード運用) がスケジュールに遅れた場合やメトリックを満たせない場合にその責任を追求する権限も与える必要があります。

レビュー ミーティング

運用適合性を定期的にレビューすることをお勧めします。 中央 IT または CCoE およびクラウド運用チームは、レビューに参加する必要があります。 クラウド戦略チームとワークロード運用チームは、参加することをお勧めしますが、任意です。 頻度の例として、コア チームは、計画に合わせて毎月ミーティングを行い、さまざまな運用チームに説明責任を課す場合があります。 四半期ごとに、クラウド戦略チームとすべてのワークロード チームは、状態とメトリックを理解するために参加できます。

プロセスとミーティングの詳細は、特定のニーズに合わせて調整します。 以下の考慮事項から始めることをお勧めします。

• 一元化された運用: ワークロード チームがプロセスに積極的に参加することはほとんどありませんが、表示できるようにレポートに含める必要があります。
• 分散化された運用: クラウド運用チームは、技術プラットフォームの運用を改善するために使用するベスト プラクティスをワークロード チームと共有する必要があります。 ワークロード チームは、それぞれのワークロードへの変更を共有して、技術プラットフォームと運用ベースラインに適用できる改善点を識別する必要があります。

推奨リソース

• Azure Automanage。 Azure Automanage では、運用ベースライン全体の運用適合性が自動的に監視され、ポートフォリオ全体のさまざまな修復戦略の適用が自動化されます。
• Azure Advisor。 Azure Advisor では、リソースを最適化するのに役立つ、使用状況と構成に基づいてパーソナライズされたレコメンデーションが提供されます。 既定では、このツールは、運用ベースラインを改善するために、サブスクリプション全体でレコメンデーションを提供します。 また、技術プラットフォームや個々のワークロードに対する改善点を識別するために、よりきめ細かく使用できます。
• Microsoft Azure Well-Architected Framework: ワークロード運用を改善したり、分散化された操作をガイドしたりするためのガイダンスです。