クラウド管理におけるビジネス コミットメント

  • [アーティクル]

"ビジネス コミットメント" の定義は、優先順位のバランスを取ることの実習です。 この目標は、適切なレベルの運用管理を、許容できる運用コストで調整することです。 このバランスを見つけるには、この記事で説明したいくつかのデータ ポイントと計算が必要です。

コストと回復性のバランスを取る

技術的な回復性やその他のサービス レベル アグリーメント (SLA) の影響によるビジネスの安定性に対するコミットメントは、業務上の正当な理由です。 環境内のほとんどのワークロードには、クラウド管理のベースライン レベルで十分です。 それ以外の場合は、業務の中断による影響を受ける可能性があるため、2 倍から 4 倍のコスト増加は容易に妥当と判断できます。

このシリーズの前の記事は、さまざまなワークロードに対する中断の分類と影響を理解するために役立ちます。 この記事は、結果の計算に役立ちます。 前の図に示すように、クラウド管理の各レベルには、回復性の増加よりも早くコストが上昇する転換点があります。 そのような転換点は、詳細な業務上の意思決定とビジネス コミットメントを促します。

ビジネスに対する適切なコミットメントを判断する

クラウド運用チームとクラウド戦略チームは、ポートフォリオ内の各ワークロードについて、クラウド運用チームが直接提供する管理レベルに合わせて調整する必要があります。

ビジネスでのコミットメントを確立する際に、調整すべきいくつかの重要な側面があります。

  • IT 運用の前提条件。
  • 管理責任。
  • クラウド テナント。
  • ソフト コスト要因。
  • 損失回避の ROI。
  • 管理レベルの検証。

この記事の残りの部分では、決定プロセスの助けとなるようこれらの各側面を詳しく説明します。

IT 運用の前提条件

Azure 管理ガイドでは、Azure で使用できる管理ツールの概要について説明しています。 ビジネスに対するコミットメントに達する前に、IT 部門では、管理対象のすべてのワークロードに適用される、許容できる標準レベルの管理ベースラインを決定する必要があります。 IT 部門は、CPU コアの数、ディスク領域、およびその他の資産関連の変数の数に基づいて、IT ポートフォリオ内の管理対象の各ワークロードに対する標準の管理コストを計算します。 また、IT 部門は、アーキテクチャに基づいて各ワークロードの複合 SLA も見積もります。

ヒント

多くの場合、IT 運用チームは、最初の複合 SLA に対して既定の 99.9% 以上のアップタイムを使用します。 また、ログ記録とストレージのニーズを最小限に抑えたソリューションの場合は特に、平均ワークロードに基づいて管理コストを正規化することもあります。 重要度が中程度のいくつかのワークロードのコストを平均して、最初の会話の開始点とすることができます。

ヒント

運用管理ブックを使用してクラウド管理の計画を立てている場合は、これらの前提条件を反映するように運用管理フィールドを更新する必要があります。 これらのフィールドには、Commitment level (コミットメント レベル)、Composite SLA (複合 SLA)、Monthly cost (月額料金) などがあります。 月額料金は、追加された運用管理ツールのコストを月単位で表します。

運用管理ベースラインは、次の各セクションでの検証の最初の開始点として使用できます。

管理責任

従来のオンプレミス環境では、通常、環境の管理コストは IT 運用が所有する埋没コストと見なされます。 クラウドでは、管理とは予算に直接影響する、目的を持った意思決定を意味します。 各管理機能のコストは、クラウドにデプロイされた各ワークロードが直接的な原因で発生することがあります。 このアプローチではより高度な制御が可能ですが、クラウド運用チームとクラウド戦略チームが責任範囲について最初に合意する必要が生じます。

また、組織では、一部の継続的な管理機能をサービス プロバイダーに外部委託することもできます。 これらのサービス プロバイダーは、Azure Lighthouse を使用して組織がリソースへのアクセスを許可する際の精度と制御を強化し、サービス プロバイダーが実行するアクションの可視性を高めることができます。

  • 委任された責任: 運用管理のオーバーヘッドを一元化して想定する必要がないため、多くの組織の IT 運用では新しいアプローチを検討しています。 一般的なアプローチの 1 つは "委任された責任" と呼ばれます。 クラウドのセンター オブ エクセレンス モデルでは、プラットフォームの運用とプラットフォームのオートメーションにより、一元化された IT 運用チームとは無関係に、業務主導の運用チームが使用できるセルフサービス管理ツールが提供されます。 このアプローチにより、業務の利害関係者は管理関連の予算を完全に制御できます。 また、これにより、クラウドのセンター オブ エクセレンス (CCoE) チームは、最小限のガードレール セットが適切に実装されていることを確実にすることもできます。 このモデルでは、IT 部門は、企業の賢明な意思決定を支援する仲介者およびガイドとして機能します。 事業運営側は、依存するワークロードの日常業務を監督します。

  • 一元化された責任: コンプライアンス要件、技術的な複雑さ、および一部の共有サービス モデルでは、"中央 IT チーム" モデルが必要になる場合があります。 このモデルでは、IT が引き続き運用管理の責任を負います。 環境設計、管理制御、ガバナンス ツールを一元的に管理および制御することができ、これにより、経営陣のコミットメントの際のビジネスの利害関係者の役割が制限されます。 しかし、クラウドのアプローチのコストとアーキテクチャの可視性によって、各ワークロードのコストと管理レベルは一元化された IT 部門から簡単に伝達されます。

  • 混合モデル: 分類は、管理責任に対する "混合モデル" の中核です。 オンプレミスからクラウドへの変換の最中である企業では、しばらくの間、オンプレミス優先の運用モデルが必要になる場合があります。 コンプライアンス要件が厳密であったり、IT アウトソーシング ベンダーとの長期契約に依存したりしている企業では、一元化された運用モデルが必要になる場合があります。

    制約に関係なく、現代のビジネスは革新する必要があります。 中央 IT、中央集中型責任モデルの中で急速な技術革新を進める必要がある場合は、混合モデル アプローチでバランスを取れる可能性があります。 このアプローチでは、中央 IT チームは、ミッション クリティカルなすべてのワークロード、または機密情報を含むすべてのワークロードのための、一元化された運用モデルを提供します。 同時に、他のすべてのワークロード分類は、委任される責任に合わせて設計されたクラウド環境に配置される場合があります。 一元化された責任のアプローチは、一般的な運用モデルとして役立ちます。 これにより企業は、必要なレベルのサポートと機密度に基づいて、特殊化された運用モデルを柔軟に採用することができます。

最初のステップは、次のコミットメントを形成する責任のアプローチにコミットすることです。

このワークロードの日常業務の管理を担当するのはどの組織か。

クラウド テナント

ほとんどの企業で、すべての資産が 1 つのテナントに存在していれば、管理はより簡単になります。 ただし、組織によっては、複数のテナントを管理しなければならない場合があります。 ビジネスにマルチテナントの Azure 環境が必要になる理由については、Azure Lighthouse による管理操作一元化に関する記事を参照してください。

このワークロードは、他のすべてのワークロードと共に 1 つの Azure テナントに存在することになるのか?

ソフト コスト要因

次のセクションでは、管理プロセスとツールのレベルに関連する相対的な収益に対するアプローチについて概説します。 このセクションの最後に、分析された各ワークロードは、ビジネス中断の予測影響を基準とした管理コストを測定します。 このアプローチを使うと、より高度な管理アプローチへの投資が必要かどうかを比較的簡単に理解できます。

試算する前に、ソフト コスト要因を確認することが重要です。 ソフト コスト要因は収益を生み出しますが、その収益を損益計算書に見られる直接的なハード コストの節約から測定することは困難です。 ソフト コスト要因は、財政的に堅実なものよりも高いレベルの管理に投資する必要性を示す可能性があるため、重要なものです。

ソフト コスト要因の例を次に示します。

  • ボードまたは CEO による毎日のワークロードの使用状況。
  • 他の場所よりも収益に与える影響が大きい上位 x% の顧客によるワークロードの使用。
  • 従業員満足度に対する影響。

コミットメントするために必要な次のデータ ポイントは、ソフト コスト要因の一覧です。 これらの要因をこの段階で文書化する必要はありませんが、ビジネスの利害関係者は、これらの要因の重要性を認識し、次の計算から必ず除外する必要があります。

損失回避の ROI を計算する

運用管理コストの相対的収益を計算するときは、クラウド運用を担当する IT チームが上記の前提条件を完了し、すべてのワークロードの最小レベルの管理を想定する必要があります。

次に行うコミットメントは、企業による、ベースラインで管理されるオファリングに関連するコストの承諾です。

クラウド運用の最低限の基準を満たすために、企業はベースライン オファリングに投資することに同意するか?

企業がそのレベルの管理に同意しない場合は、他のワークロードのクラウド運用に実質的な影響を与えずに業務を進めることができるソリューションを考案する必要があります。

企業が標準の管理レベル以上のものを必要とする場合は、このセクションの残りの部分が、(損失回避の形での) その投資および関連する収益の検証に役立ちます。

管理レベルの増加: 設計原則とサービス カタログ

マネージド ソリューションには、管理ベースラインに加えて適用できるいくつかの設計原則とテンプレート ソリューションがあります。 信頼性と回復性のための設計原則はそれぞれ、ワークロードに対する運用コストを増加させます。 IT 部門と企業がこのような追加のコミットメントに同意するためには、その投資の増加によって回避される可能性のある損失について理解しておくことが重要です。

次の計算では、損失と管理への投資の増加との差について理解を深めるための数式について説明します。 管理の増加コストの計算に関するガイダンスについては、ワークロードのオートメーションとプラットフォームのオートメーションに関する記事を参照してください。

ヒント

運用管理ブックを使用してクラウド管理を計画している場合は、各メッセージ交換が反映されるように運用管理のフィールドを更新してください。 これらのフィールドには、Commitment level (コミットメント レベル)、Composite SLA (複合 SLA)、Monthly cost (月額料金) などがあります。 月額料金は、追加された運用管理ツールの月額コストを表します。 これらのフィールドを更新すると、ROI の式と次の各フィールドが更新されます。

推定停止時間 (年間の時間)

複合 SLA は、ワークロード内の各資産のデプロイに基づくサービス レベル アグリーメントです。 このフィールドによって、"推定停止時間" (ブックのラベルは Est.Outage) が変わります。 ブックを使用せずに年間の推定停止時間を計算するには、次の式を適用します。

推定停止時間 = (1 - 複合 SLA のパーセンテージ) × 1 年間の時間数

ブックでは、既定値の "8,760 時間/年" を使用します。

標準的な損失の影響

"標準的な損失の影響" (ブックのラベルは Standard Impact) は、"推定停止時間" の予測が正確であると仮定した場合の、停止による財務上の影響を予測します。 ブックを使用せずにこの予測を計算するには、次の式を適用します。

標準的な影響 = 99.9% の稼働時間での推定停止時間 × 時間と価値の影響

これは、ビジネスの利害関係者がより高いレベルの管理に投資することを選択した場合の、コストのベースラインとして機能します。

複合 SLA の影響

"複合 SLA の影響" (ブックのラベルは Commitment level impact) は、SLA で保証される稼働時間の変更に基づいて、更新された財務上の影響を示します。 この計算により、両方のオプションの予想される財務的な影響を比較できます。 スプレッドシートを使用せずにこの予測される影響を計算するには、次の式を適用します。

複合 SLA の影響 = 推定停止時間 × 時間と価値の影響

この値は、変更されたコミットメント レベルと新しい複合 SLA によって回避される可能性のある損失を表します。

比較基準

"比較基準" は、標準的な影響と複合 SLA の影響を評価して、収益の列に最も適したものを決定します。

損失回避に対する利益

ワークロードの管理コストが潜在的損失を上回る場合は、提案されているクラウド管理への投資が有益ではない可能性があります。 Return on Loss Avoidance (損失回避に対する利益) を比較するには、Annual ROI**** (年間 ROI) というラベルが付いた列をご覧ください。 この列をご自分で計算するには、次の式を使用します。

損失回避に対する利益 = (比較基準 - (月額料金 × 12)) ÷ (月額料金 × 12))

考慮すべきその他のソフト コスト要因がない限り、この比較によって、クラウド運用、回復性、信頼性、またはその他の領域に対してさらに投資すべきかどうかをすぐに示すことができます。

コミットメントを検証する

プロセスのこの時点までに、一元化または委任された責任、Azure テナント、コミットメントのレベルについてコミットメントが行われました。 クラウド運用チーム、クラウド戦略チーム、およびビジネスの利害関係者が、ワークロードを管理するためにこのコミットメントに合わせて連携していることを確認するために、各コミットメントを検証し、文書化する必要があります。

次のステップ

コミットメントが行われると、担当の運用チームは、対象となるワークロードの構成を開始できます。 開始するには、インベントリと可視性に対するさまざまなアプローチを評価します。

インベントリと可視性のオプション