クラウド管理におけるビジネス コミットメント
ビジネス コミットメントは、許容可能な運用コストで運用管理のレベルを定義するために役立ちます。 ビジネス コミットメントを定義するには、優先順位のバランスを取る必要があります。 この記事では、データ ポイントを評価する方法と、そのバランスを見つけるための計算について説明します。
ビジネスの安定性に関連するコミットメントを設定することで、ビジネス上の意思決定の正当性を示すことができます。 安定性コミットメントには、サービス レベル アグリーメント (SLA) や特定のレベルの技術的回復性を含めることができます。 ほとんどのワークロードでは、ベースライン レベルのクラウド管理で十分です。 その他のワークロードでは、ベースライン レベルと比較して、クラウド管理のコストが 2 ～ 4 倍になる可能性があります。 ビジネスの中断による潜在的な影響を考えると、このコストは正当であると言えます。
このシリーズの前の記事は、さまざまなワークロードに対する中断の分類と影響を理解するために役立ちます。 この記事は、結果の計算に役立ちます。
次の図は、回復性の増加よりも早くコストが上昇する分岐点が、クラウド管理の各レベルに存在することを示しています。 これは、ビジネス上の意思決定とビジネス コミットメントを詳細に行う必要があることを意味します。
適切なコミットメントを決定する
クラウド運用チームとクラウド戦略チームは、クラウド運用チームが直接提供する管理レベルに合わせて、ポートフォリオ内の各ワークロードを調整する必要があります。
ビジネスでのコミットメントを確立する際には、次のような点の調整方法を決定します。
- IT 運用の前提条件
- 管理責任
- クラウド テナント
- ソフト コスト要因
- 投資収益率 (ROI) 損失回避
- 管理レベルの検証
以下のセクションでは、意思決定に役立てていただけるよう、これらの点について詳しく説明します。
IT 運用の前提条件を決定する
Azure 管理ツールの概要は、「Azure 管理ガイド」に示されています。 企業でのコミットメントを設定する前に、IT 部門では、管理対象のすべてのワークロードに適用する許容可能な標準レベルの管理ベースラインを決定する必要があります。 IT ポートフォリオ内の管理対象ワークロードごとに、CPU コア数、ディスク容量、その他の資産関連の可変要素に基づいて標準管理コストを計算できます。 IT 部門では、アーキテクチャに基づいて、ワークロードごとに複合サービス レベル目標 (SLO) を見積もることもできます。
開始時の複合 SLO に対して IT 運用チームが使用するアップタイムは、既定の 99.9% 以上であることが少なくありません。 ログ記録とストレージのニーズが最小限のソリューションの場合は特に、平均的なワークロードに基づいて管理コストを標準化できます。 最初の話し合いの出発点として、重要度が中程度のワークロードをいくつか示し、そのコストの平均をとることができます。
ヒント
運用管理ワークブックを使用してクラウド管理を計画する場合は、IT 運用の前提条件を反映して運用管理フィールドを更新する必要があります。 運用管理フィールドには、コミットメント レベル、複合 SLO、月額料金などが含まれます。 月額料金は、追加する運用管理ツールの月単位のコストを表します。
運用管理ベースラインはあくまでも開始点であり、以下のような点についてもベースラインを検証する必要があります。
責任モデルを選択する
従来のオンプレミス環境では、環境の管理コストは IT 運用の埋没コストであると受け取られます。 埋没コストとは、取り戻すことのできない費用を指します。 クラウドでの管理は、予算に直接影響する、目的に基づいた意思決定です。 クラウドにデプロイする各ワークロードに、各管理機能のコストを直接割り当てることができます。 このアプローチでは、さらに詳細な制御が可能になります。 ただし、クラウド運用チームとクラウド戦略チームは、まずそれぞれの責任について合意する必要があります。
企業における継続的な管理機能の一部が、サービス プロバイダーにアウトソーシングされる場合もあります。 サービス プロバイダーで Azure Lighthouse を使用すると、顧客企業での詳細な制御が可能になります。 たとえば、リソースへのアクセス権を付与し、サービス プロバイダーが実行するアクションをより詳細に把握することができます。
クラウド環境を管理するには、さまざまなモデルを実装できます。
責任委任モデル: IT 運用では、責任の委任と呼ばれるアプローチを使用できます。 この方法では、一元管理が不要であるため、運用管理のオーバーヘッドを回避できます。 クラウドのセンター オブ エクセレンス (CCoE) モデルでは、プラットフォームの運用とプラットフォームのオートメーションにより、一元化された IT 運用チームとは無関係に、業務主導の運用チームが使用できるセルフサービス管理ツールが提供されます。
このアプローチにより、業務の利害関係者は管理関連の予算を完全に制御できます。 CCoE チームは、最小限のガードレール セットが適切に実装されていることも確認できます。 IT 部門は、企業の賢明な意思決定を支援する仲介者およびガイドとして機能します。 事業運営側は、依存しているワークロードの日常業務を監督します。
責任一元化モデル: コンプライアンス要件や技術的な複雑さが存在し、共有サービス モデルを運用している場合、企業には一元的 IT チーム モデルが必要になることがあります。 一元的 IT モデルでは、IT が運用管理の責任を果たします。
環境設計、管理制御、ガバナンス ツールを一元的に管理および制御することで、管理上のコミットメントがビジネスの利害関係者によって行われる状況を回避できます。 その一方で、クラウド アプローチのコストとアーキテクチャが可視化されることにより、一元的 IT 部門は各ワークロードのコストと管理レベルをに簡単に伝達できます。
混合モデル: 管理責任に対する混合モデルの中核は、分類です。 オンプレミスからクラウドへの移行過程にある企業では、しばらくの間、オンプレミス優先の運用モデルが必要になる場合があります。 厳格なコンプライアンス要件が存在する企業や、IT アウトソーシング ベンダーとの長期契約に依存している企業には、一元型の運用モデルが必要になる可能性があります。
混合モデルのアプローチによってバランスの実現が可能になります。 このアプローチで、一元的 IT チームは、ミッション クリティカルなすべてのワークロード、または機密情報を含むすべてのワークロードのための、一元化された運用モデルを提供します。 チームは、委任された責任をサポートするクラウド環境に、その他のすべてのワークロード分類を配置します。 責任一元化アプローチは一般的な運用モデルとして使用できますが、個々の企業は必要レベルのサポートと機密性に基づいて、特化した運用モデルを柔軟に採用できます。
次に、ワークロードの日常的な運用管理を誰が担当するかを検討します。 責任のアプローチは、コミットメントに影響します。
クラウド テナントを管理する
通常、資産は単一のテナント内に存在する方が管理が容易になります。 ただし、複数のテナントを維持する必要が生じることもあります。 マルチテナントの Azure 環境が必要になる理由については、Azure Lighthouse による管理操作一元化に関する記事を参照してください。
ソフト コスト要因を考慮する
次のセクションでは、さまざまなレベルの管理プロセスとツールに関連する相対的な収益を決定するアプローチの要点を説明します。 分析されたワークロードごとに、業務の中断時に予測される影響に対する管理コストを測定できます。 より広範な管理アプローチに投資する必要があるかどうかを判断するには、次の方法を使用します。
数値を計算する前に、ソフト コスト要因を考慮してください。 ソフト コスト要因は収益を生み出しますが、損益計算書に見られる直接的なハード コストの節約からその収益を測定することは困難です。 ソフト コスト要因は、財政的に堅実なレベルを上回るレベルで管理に投資する必要性を示している可能性があります。
ソフト コスト要因には次のようなものがあります。
ボードまたは CEO による毎日のワークロードの使用状況。
他の場所よりも収益に与える影響が大きい上位 x% の顧客によるワークロードの使用。
従業員満足度に対する影響。
コミットメントを行うために、次に評価する必要があるデータ ポイントは、ソフト コスト要因のリストです。 この段階ではソフト コスト要因を文書化する必要はありませんが、ビジネス関係者には、ソフト コスト要因の重要性と、以下の計算から除外することを知らせておきます。
損失回避の ROI を計算する
クラウド運用を担当する IT チームが運用管理コストの相対的な収益を計算する場合、前述の前提条件を完了し、すべてのワークロードに対して最低限の管理レベルを想定する必要があります。
企業が次に行うべきコミットメントは、ベースライン管理オファリングに関連するコストを受け入れることです。 企業がクラウド運用の最低基準を満たすためにベースライン オファリングに投資することに同意するかどうかを決定します。
そのレベルの管理に企業が同意しない場合は、事業を継続できるようにソリューションを構築する必要があります。 このソリューションが他のワークロードのクラウド運用に重大な影響を与えないことを確認してください。
これとは逆に、標準的な管理レベルよりも高いレベルが必要になる場合があります。 次のセクションでは、そのような投資と、これに関連する損失回避という形でのリターンを検証します。
管理レベルを引き上げる
マネージド ソリューションでは、管理ベースラインに加えて、いくつかの設計原則とテンプレート ソリューションを適用できます。 信頼性と回復力に関する設計原則を加えると、その運用コストがワークロードに追加されます。 このような追加のコミットメントについては、IT 部門と経営陣の同意を得る必要があるため、より多くの原則を実装することでどのような損失を回避できる可能性があるのか理解しておく必要があります。
以下のセクションでは、損失と、管理への投資の増加との違いをよりよく理解するために役立つ数式を示しています。 管理の強化に必要なコストの計算方法の詳細については、ワークロードのオートメーションとプラットフォームのオートメーションに関する記事を参照してください。
ヒント
運用管理ワークブックを使用してクラウド管理を計画する場合は、毎回の話し合いを反映して運用管理のフィールドを更新してください。 これらの変更により、ROI の計算式と以下の各フィールドが更新されます。
停止時間を見積もる
複合 SLO は、ワークロード内の各資産のデプロイに基づく SLA です。 複合 SLO フィールドは、ワークブックで Est. Outage というラベルが付けられた推定停止時間を制御します。 ブックを使用せずに年間の推定停止時間を計算するには、次の式を適用します。
推定停止時間 = (1 - 複合 SLO のパーセンテージ) × 1 年間の時間数
ブックでは、既定値の "8,760 時間/年" を使用します。
標準的な損失の影響
"標準的な損失の影響" は、推定停止時間の予測が正確であると仮定した場合の、停止による財務上の影響を予測した値です。 標準的な損失の影響は、ワークブックでは Standard Impact と示されます。 ブックを使用せずにこの予測を計算するには、次の式を適用します。
標準的な影響 = 99.9% の稼働時間での推定停止時間 × 時間と価値の影響
この値は、ビジネス上の利害関係者がより高いレベルの管理に投資する場合の、コストのベースラインとして機能します。
複合 SLO の影響
"複合 SLO の影響" は、SLA で保証される稼働時間の変更に基づいて、更新された財務上の影響を示します。 この計算を使用すると、両方のオプションについて、予想される財務的な影響を比較できます。 複合 SLO の影響は、ワークブックでは Commitment level impact と示されます。 スプレッドシートを使用せずにこの予測される影響を計算するには、次の式を適用します。
複合 SLO の影響 = 推定停止時間 × 時間と価値の影響
この値は、変更されたコミットメント レベルと新しい複合 SLO によって回避できる可能性のある損失を表します。
比較基準
比較基準フィールドでは、標準的な影響と複合 SLO の影響を評価して、年間 ROI フィールドの収益額を決定します。
損失回避に対する利益
ワークロードの管理コストが潜在的損失を上回る場合は、提案されているクラウド管理への投資が有益ではない可能性があります。 損失の回避と利益を比較するには、Annual ROI というラベルが付いた列をご覧ください。 この列をご自分で計算するには、次の式を使用します。
損失回避に対する利益 = (比較基準 - (月額料金 × 12)) ÷ (月額料金 × 12)
考慮すべき他のソフトコスト要因がない場合は、この比較を使用すると、クラウド運用、回復力、信頼性、またはその他の領域にさらに投資する必要があるかどうかを迅速に判断できます。
コミットメントを検証する
プロセスのこの時点で、企業は責任の一元化、責任の委任、Azure テナントなどのコミットメントを行い、コミットメントのレベルを決定できます。 各コミットメントを検証して文書化することで、クラウド運用チーム、クラウド戦略チーム、ビジネス上の利害関係者がこれらのコミットメントに沿ってワークロードを管理しているかどうかを確認できます。
次のステップ
コミットメントを行った後、担当の運用チームがワークロードを構成できます。 開始するには、インベントリと可視性に対するさまざまなアプローチを評価します。