一般的な運用モデル

完了

このユニットでは、一般的な運用モデルを検討し、Tailwind Traders のストーリーに最も適しているものを確認します。 また、クラウド導入計画に最適な運用モデルを評価およびマップする方法についても学びます。 この情報は、最も適切な Azure ランディング ゾーンを選択してクラウド環境の構築を開始するのに役立ちます。

一般的な運用モデル

クラウド導入の取り組み全体で次の 4 つの運用モデルが見られます。 これらの一般的な運用モデルを調べることで、環境の設計と構成について説明できます。 初期デプロイを迅速化するために、それぞれの運用モデルは 1 つ以上の Azure ランディング ゾーンにマップされます。

Diagram that shows four common operating models: decentralized, centralized, enterprise, and distributed.

以下の特徴は、一般的な運用モデルの 1 つに合わせるために役立ちます。

戦略的な優先度: クラウドを導入する場合、イノベーション、統制 (最適化された運用)、民主化 (自主性)、統合のすべてが重要な戦略的優先事項です。 経営層の利害関係者に説明するときに、次の 3 年から 5 年間で会社にとって最も重要な要因になるものはどれでしょうか?

組織: 人の組織は、運用に関する一部の決定を左右します。 小規模な IT チームがすべてのポートフォリオをカバーしていますか? 個別のチームがセキュリティ、ガバナンス、運用などの機能に特化されていますか? チームは個別のワークロードを中心に編成されていますか? 監査人または他のコンプライアンス機関によってレビューされる、厳格な第三者のコンプライアンス基準によって拘束されますか?

ポートフォリオのスコープ: ポートフォリオのサイズと、運用でどこに重点を置くかも、各運用モデルの重要な考慮事項です。 大規模で複雑な、マルチクラウドのワークロード ポートフォリオを管理しますか? 1 つのクラウド プラットフォームでポートフォリオをサポートできますか? すべてのワークロードが 1 つの運用環境サブスクリプションで稼働する必要がありますか? 集中サポートのないワークロード固有の運用に重点を置きますか? これらの用語の詳細については、ポートフォリオ階層に関する記事をご覧ください。

責任 (義務の分離):テクノロジに関しては、どこかで問題が発生する可能性は常にあります。 したがって、100% のアップタイム SLA にサインアップするチームはまれです。 問題が発生したり、期待どおりに事が運ばない場合に、電話に出るのは誰の責任ですか? 停止を最小限に抑えるための予防的な修正は誰の責任ですか? クラウドの経済性と執行中の予算の責任者は誰ですか? 責任および関連するアクセス要件は、環境設計に関する一部の決定を左右します。

標準化: ネットワーク、ID、セキュリティなどの基本ユーティリティを標準化すると、目に見える費用削減効果が生まれ、さまざまな作業に割かれる人的リソースを削減できます。 ユーティリティまたは共有リソースの標準化はどれくらい重要ですか?

運用の優先度: 運用の最新化において、運用サポートのプライマリ形式として運用チームがクラウドファーストのサービスを選択するのは一般的なことです。 あるいは、既存のオンプレミス ツールがチームで必要とするプライマリの運用ツールである場合は、クラウドを拡張またはセカンダリの運用モデルにすることができます。 将来を見据えて、運用とサポートのツールをクラウドファーストの視点で見ることを望みますか? 既存のツールを継続使用してクラウドに拡張しますか? パブリックとプライベートのクラウドの運用をシームレスに融合できる統合型の運用アプローチを探していますか?

プラットフォーム開発の速度:ワークロードには、直接的なワークロード環境を作り出す独自の資産が必要です。 資産を直接的にサポートするもの以外にも、さまざまな度合いの先行投資があります。 ワークロード全体で共有される基本ユーティリティ (ネットワークや ID など) に割きたい労力はどれくらいですか? 複数のランディング ゾーン間でこれらのユーティリティを共有する、集中型のクラウド基盤に先行投資する労力はどれくらいが適切ですか?

分散型運用

最も複雑度の低い運用モデルは、完全な非集中型のモデルです。 このモデルでは、個別のワークロードに重点を置き、集中型の運用には極力依存しないようにします。 このモデルはバイモーダル IT または非集中型 IT とも呼ばれます。

Illustration that shows individual workloads and dependent assets in decentralized operations.

戦略的な優先順位: 組織が非集中型を使用するのは、"統制よりもイノベーション" を優先する場合が多いです。 このモデルは、スタートアップ組織では一般的ですが、大規模な組織でも増加傾向にあります。

組織: 他の 3 つの運用モデルとは対照的に、チームはワークロードまたはビジネス プロセスを中心に編成されます。

ポートフォリオのスコープ: ポートフォリオのスコープもワークロード レベルに分離されます。 組織が全面的に非集中化されていると、ポートフォリオ配置の管理に組織が多くの時間を費やす可能性は低くなります。

責任 (義務の分離):ワークロード チームは、運用、ガバナンス、セキュリティに関する決定について全面的に責任を負います。 非集中型の運用には共有責任モデルはありません。

標準化: ベスト プラクティスとデプロイの自動化 (継続的インテグレーションまたは継続的配布パイプライン) は、ワークロード間である程度の標準化を行うために不可欠です。 集中型の機能がないと、標準化はおそらく長続きしないでしょう。

運用の優先度: 非集中型の運用チームでは、サービスとしてのソフトウェア (SaaS) またはサービスとしてのプラットフォーム (PaaS) ツールを使用してクラウドファーストの運用を優先し、運用を自動化することが多くなります。

プラットフォーム開発の速度: 非集中型の運用では、デプロイ スクリプトをワークロード間で共有できますが、ワークロード間で共有される集中リソースはほとんどないか、皆無です。

クラウド導入フレームワークにおける非集中型の運用について、長所、短所、特徴をさらに比較します

集中型の運用

集中型モデルは、IT で最も一般的な運用モデルです。 このモデルでは、集中型の運用のみによって管理される、統制された運用環境に大きく重点を置きます。 集中型の運用では、基本ユーティリティが組み込まれた、比較的少数のランディング ゾーンに重点を置きます。

Illustration of centralized operations with landing zones and embedded utilities.

非運用環境の管理は、組織によって異なります。 しかし、集中型の運用モデルでは、非運用環境であっても、ガバナンスとセキュリティの要件によって制約を受ける可能性が高くなります。

戦略的な優先度:ビジネスにおける統制と安定性がイノベーションよりも重要である場合、このモデルが最も採用されやすい傾向があります。 大規模な組織や安定した組織は、多くの場合、集中型の運用を使用します。 このモデルは、サードパーティのコンプライアンス要件から環境に関する決定が導かれる場合に一般的です。

組織:チームはまず、機能またはプロセスを中心に編成されます。 小規模な組織では、中央の IT 部門が、セキュリティ、ガバナンス、運用、インフラストラクチャに重点を置くチーム メンバーの拠点です。 組織の規模が大きくなると、これらの機能は、個々の機能に特化したチームに分離される場合があります。

ポートフォリオのスコープ:集中型の運用チームでは、1 つのランディング ゾーンまたは少数のランディング ゾーンに重点を置く傾向があります。 これらのランディング ゾーン内で、組織は基本ユーティリティをデプロイして、各ランディング ゾーン内のワークロードの組み合わせをサポートします。 この運用モデルでは、組織が堅牢なクラウド基盤とマルチクラウド ポートフォリオをサポートするときに、スケールが課題になる傾向があります。

責任 (義務の分離): この運用モデルでは、通常、中央の IT チームまたは中央の運用部門チームが、運用環境内のすべての資産に関して責任を負います。 義務の分離は環境の分離に重点を置く傾向があり、これによって、ワークロード固有のチームが運用環境の資産とやり取りすることを防ぎます。

標準化:ワークロード全体の標準化が高水準になる可能性が高くなります。 ただし、ポートフォリオが大きくなり、複数のランディング ゾーンまたは複数のクラウド プラットフォームにまたがるようになると、標準化が機能しなくなり、環境への大幅な変更が必要になる場合があります。

運用の優先順位: 組織は、クラウド運用モデルをセカンダリ運用モデルと見なす場合、一般的に集中型の運用を使用します。 既存のオンプレミスまたはプライベート クラウドの運用がプライマリのモデルであるため、これらの組織では、既存の運用ツールを継続使用し、最新のクラウドファースト運用ツールをプライマリとして使用することを制限する傾向があります。

プラットフォーム開発の速度: 集中型の運用チームでは、通常、一般的なユーティリティに対処するために、小規模から始めるアプローチを必要とします。 時間の経過と共に、チームは最適な組み合わせのソリューションを環境に構築することに重点を置くようになります。

クラウド導入フレームワークにおける集中型の運用について、長所、短所、特徴をさらに比較します

エンタープライズ型の運用

エンタープライズ モデルは、データセンター全体または大規模なポートフォリオをクラウドに移行するお客様に適しています。 エンタープライズ型の運用では、基本ユーティリティがプラットフォーム基盤に集中した、比較的多数のランディング ゾーンに重点を置きます。

Illustration of enterprise operations with landing zones and foundational utilities.

戦略的な優先順位: このエンタープライズ運用モデルでは、一部のランディング ゾーンにおけるイノベーションのニーズと、その他のゾーンにおけるより厳格な統制のニーズのバランスをとるために、決定の民主化と責務の委譲に重点を置きます。 これは、市場の変化に対応するためにイノベーションを促進しつつ、既存の利害を保護する必要がある大規模組織向けの戦略的な優先度です。

組織: エンタープライズ型の運用では、各ワークロード チームの構築および運用機能を強化します。 ワークロード チームは、ガバナンス、セキュリティ、運用などの機能別に整理されます。 クラウドのセンター オブ エクセレンス (CCoE) チームは、ワークロードとサポートのチームを統合して、アクティビティを調整し、クラウド基盤全体で運用の卓越性を保証します。

ポートフォリオのスコープ:エンタープライズ型の運用のスコープでは、基本ユーティリティが集中化され、すべてのランディング ゾーンから利用できることを保証するために、クラウド基盤全体に重点を置きます。 ランディング ゾーンと専用のワークロード環境を、必要なすべての依存関係を提供するクラウド基盤を使用して、セルフサービスの容量にデプロイできるようになります。

責任 (義務の分離): CCoE チームの責務は、必要な集中型のリソースを管理し、ポートフォリオ全体を可視化することです。 その後は、集中運用チームまたはワークロード固有の運用チームが、個別のワークロードの日々のサポートに責任を負います。

標準化:標準化は、この運用モデルで最も高水準になります。 集中型のクラウド基盤により、すべてのランディング ゾーン設計の領域の構成で一貫性が保証されます。 健全なベスト プラクティスでは、すべてのワークロードの自動デプロイが好まれます。 この自動化により、ワークロードと資産レベルでさらに標準化を行うことができます。

運用の優先度:エンタープライズ型の運用モデルでは、クラウドファーストの運用アプローチが要求されます。 クラウドにおける集中型の運用を維持するためには、ファーストパーティのクラウドベースのツールが不可欠です。 このタイプのモデルが効果を発揮するには、プライマリの運用モデルとしてクラウドに目を向ける必要があります。 組織は、既存のオンプレミス運用をセカンダリの運用と見なし、長期的な移行計画に含める必要があります。

プラットフォーム開発の速度: 急拡大するワークロードのポートフォリオ全体でガバナンス、セキュリティ、運用の集中化を促進するために、エンタープライズ型の運用チームでは、導入前にエンタープライズ型のソリューションを実装することが必要になります。

クラウド導入フレームワークにおけるエンタープライズ型の運用について、長所、短所、特徴をさらに比較します

分散型の運用

分散型のモデルは、最も複雑な運用形式です。 他のモデルを組み合わせます。

Diagram that shows the integration of operating models in distributed operations.

企業は通常、急速な買収によって拡大するときにこのアプローチを採用し、結果的に、前の 3 つの運用モデルが分散した状態で混在します。 企業は、この状態を長く存続させることはできます。 しかし、冗長性を最小限に抑え、より効率的な運用を促進するために、より複雑度の低いモデルの 1 つに移行する計画の策定を検討する必要があります。

戦略的な優先順位: 組織が、イノベーションや統制よりも、買収した事業部門の統合を優先する場合にこのモデルを使用します。 これは多くの場合、より効率的な運用モデルに将来移行するために必要な一時的またはブリッジ戦略です。 このモデルは、組織が自主性を維持したいと考え、プライベート エクイティや持ち株会社でよく見られるように、短期的な出口戦略を検討している場合に存続する傾向があります。

組織: この運用モデルでは、組織の集中型の構造を維持することが課題となります。 組織の周辺で運用の可視性と認識を育むために、組織では、プロセスの早い段階で CCoE 仮想チームを立ち上げることが賢明です。

ポートフォリオのスコープ:分散型の運用では、複雑なポートフォリオに重点を置きます。 時間の経過と共に、その重点をポートフォリオのより細部のレベルに絞り込むことができます。

責任 (義務の分離):責任は事業部門によって異なります。 中央視点からの義務の分離は達成が困難です。

標準化: 分散型の運用モデルにおける標準化に向けた最初のステップは、ポートフォリオ全体のデジタル資産を明確に把握することです。 データドリブンのアプローチにより、集中型またはエンタープライズ型の運用モデルに傾きがちなポートフォリオに見られる共通性の特定を開始します。

運用の優先度:このモデルにおける運用の優先度はデータが中心です。 統合運用のために設計されたツールを使用してデータを集中化すると、移行中に、また成熟度向上の取り組みの中で、CCoE チームが、さまざまな事業部門に指導と助言を提供できるようになります。 運用の優先度を一律に強制する前に、適切なツールとベースラインを確保するために、ワークロード運用のポートフォリオを評価します。

プラットフォーム開発の速度: ワークロード運用のポートフォリオの評価では、小規模から始めるか、またはエンタープライズ規模のアプローチに適合する、許容可能なプラットフォーム開発速度を特定する必要があります。 方向性を決定する最優先のデータ ポイントは、ポートフォリオ全体で最も一般的な運用管理アプローチに依存します。

クラウド導入フレームワークにおける分散型の運用について、長所、短所、特徴をさらに比較します

自分の知識をチェックする

1.

次の答えのうち、Tailwind Traders の運用モデルの説明として最も正しいものはどれですか?

2.

顧客のストーリーには、小売イノベーション チームからのソリューションをリリースするための制御されたプロセスがあります。 そのプロセスが改善され、制御されたランディング ゾーンでチームが自らのワークロードを管理できるようになった場合、新しい配置を最もよく説明するのはどの運用モデルですか?

3.

小売イノベーション チームは、Tailwind Traders に買収される前は全面的にワークロードに重点を置いていました。 わかっていることから判断して、買収前にそのチームでどのような運用を行っていたかの説明として最も正しいのはどの運用モデルですか?