一般的なクラウド運用モデルを確認して比較する

[アーティクル]
03/22/2023

運用モデルは、サポートする対象のビジネスに特定かつ固有であり、それらの現在の要件と制約に基づいています。しかし、運用モデルは スノーフレークではありません。顧客の運用モデルには、いくつかの一般的なパターンがあります。この記事では、最も一般的な 4 つのパターンについて説明します。

運用モデルの比較

次の図は、最も複雑でない (非集中型) から最も複雑 (グローバルな運用) までの複雑さのスコープに基づいて、一般的な運用モデルをマップしています。次の表は、他のいくつかの属性の相対値に基づいて、同じ運用モデルを比較したものです。

運用モデルの複雑さの程度を示す図。

優先事項またはスコープ

クラウド運用モデルは、主に次の 2 つの要素によって推進されます。

戦略上の優先事項または動機
管理するポートフォリオのスコープ

	非集中型の運用 (ops)	集中型の運用 (ops)	エンタープライズ型の運用 (ops)	分散型の運用 (ops)
戦略上の優先事項または動機	イノベーション	コントロール	民主化	統合
ポートフォリオのスコープ	ワークロード	ランディングゾーン	クラウドプラットフォーム	完全なポートフォリオ
ワークロード環境	複雑度が高い	複雑度が低い	複雑度が中程度	複雑度が中程度または可変
ランディングゾーン	該当なし	複雑度が高い	複雑度が中程度から低い	複雑度が低い
基本ユーティリティ	該当なし	該当なし、または少ないサポート	集中化された、より多くのサポート	最も多いサポート
クラウド基盤	該当なし	該当なし	ハイブリッド、プロバイダー固有、または地域の基盤	分散型と同期

戦略上の優先事項または動機：各運用モデルは、一般的なクラウド導入の戦略的動機に対応します。しかし、一部の運用モデルでは、特定の動機が簡素化されています。
ポートフォリオのスコープ: ポートフォリオのスコープは、特定の運用モデルデザインがサポートする最大のスコープを示しています。たとえば、集中型の運用は、少数のランディングゾーン向けに設計されています。しかし、運用モデルの決定によって、組織の運用上のリスクが生じ得る可能性があります。運用上のリスクは、大規模で複雑なポートフォリオを管理しようとするときに生じます。これらのポートフォリオでは、多くのランディングゾーンが必要だったり、ランディングゾーンの設計にさまざまな複雑さが伴ったりする場合があります。

重要

クラウドの導入は、多くの場合、現在の運用モデルを見直すきっかけとなり、一般的な 1 つの運用モデルから別のどれかに切り替えることにつながることがあります。しかし、クラウドの導入が唯一のきっかけなのではありません。ビジネス上の優先順位とクラウドの導入の範囲によって、ポートフォリオをどのようにサポートする必要があるかが変化する可能性があります。また、最も適切に調整された運用モデルでも、他の変更が生じ得る可能性があります。取締役会またはその他の役員会が 5 年から 10 年の事業計画を策定するとき、それらの計画には多くの場合、運用モデルを調整する (明示的または暗黙的な) 要件が盛り込まれています。運用モデルは、指針となる意思決定のためのよい参考となります。これらのモデルは、要件や制約に合わせて変更されたり、カスタマイズが必要になったりする場合もあります。

責任の整合

多くのチームと個人が、さまざまな機能のサポートを担当します。しかし、それぞれの一般的な運用モデルでは、決定の結果に対する最終的な責任が、1 つのチームまたは 1 人の個人に割り当てられます。このアプローチは、運用モデルの資金調達方法と、各機能にどのレベルのサポートを提供するかに影響します。

	非集中型の運用	集中型の運用	エンタープライズ型の運用	分散型の運用
ビジネスの整合	ワークロードチーム	中央のクラウド戦略	CCoE	可変 - 幅広いクラウド戦略チームを編成?
クラウド運用	ワークロードチーム	中央 IT	CCoE	ポートフォリオ解析に基づき - ビジネスアラインメントとビジネスコミットメントを参照してください
クラウドガバナンス	ワークロードチーム	中央 IT	CCoE	複数レイヤーのガバナンス
クラウドのセキュリティ	ワークロードチーム	セキュリティオペレーションセンター (SOC)	CCoE + SOC	混合 - 「セキュリティ戦略を定義する」を参照
クラウドの自動化と DevOps	ワークロードチーム	中央 IT または該当なし	CCoE	ポートフォリオ解析に基づき - ビジネスアラインメントとビジネスコミットメントを参照してください

Azure での運用モデル実装の加速

運用モデルの定義に関するページで説明しているように、クラウド導入フレームワークの各手法によって、運用モデルを開発するための構造化されたパスが提供されます。これらの手法は、クラウド運用モデルの導入におけるギャップに由来する阻害要因を克服するのに役立つ場合があります。

次の表は、運用モデルの実装を加速させる方法の概要を示しています。

	非集中型の運用	集中型の運用	エンタープライズ型の運用	分散型の運用
開始ポイント	Azure Well-Architected Framework (WAF)	Azure ランディングゾーン: 小規模から始めるオプション	Azure ランディングゾーン: CAF エンタープライズ規模	ビジネスの整合
イテレーション	ワークロードに重点を置くと、チームは WAF 内で反復することができます。	小規模から始めるオプションでは、各手法で追加の反復が必要ですが、それはクラウド導入の取り組みが成熟するにつれて実行できます。	参照実装に示されているように、今後の反復では通常、小規模な構成の追加に重点を置きます。	Azure ランディングゾーンの実装オプションを確認し、運用のベースラインに最も合ったオプションを使用して開始します。そのオプションの設計原則に定義された反復パスに従います。

分散型運用

運用は常に複雑です。運用のスコープを 1 つのワークロードまたは少数のワークロードの集合に制限すると、複雑さをコントロールできます。一般的な運用モデルのうち最も複雑さが少ないのは非集中型の運用です。この形式の運用では、すべてのワークロードが専任のワークロードチームによって個別に運用されます。

優先事項: チームは、複数のワークロードの間での集中管理または標準化よりも、イノベーションを評価します。
明らかな利点:: 設計、構築、運用を完全にコントロールするワークロードとビジネスのチームを配置することによって、イノベーションの速度を最大化します。
明らかに不利な点: 次のものが減少: ワークロード間の標準化、共有サービスによるスケールメリット、一貫したガバナンスの集中化したコンプライアンスの取り組み。
リスク: このアプローチでは、ワークロードのポートフォリオを管理する際にリスクが生じます。ワークロードチームは、中央 IT 機能に特化した専任のチームを持っている場合があります。この運用モデルは、一部の組織 (特にサードパーティのコンプライアンス要件に従う必要がある企業) からリスクの高いオプションと見なされています。
ガイダンス: 非集中型の運用は、ワークロードレベルの意思決定に限定されます。 Microsoft Azure Well-Architected Framework は、そのスコープ内で行われる意思決定をサポートします。クラウド導入フレームワーク内のプロセスとガイダンスによって、非集中型の運用では必要とされないオーバーヘッドが追加される可能性があります。

非集中型の運用の利点

コスト管理: 運用コストを 1 つの部署に簡単に対応付けることができます。ワークロード固有の運用により、より優れたワークロードの最適化がサポートされます。
責務: 通常、この形式の運用は、オーバーヘッドを最小限にするために自動化に大きく依存しています。責務は、リリース管理のための DevOps とパイプラインにフォーカスしたものになる傾向があります。この種の運用により、開発中のより迅速なデプロイとフィードバックサイクルの短縮がサポートされます。
標準化: ソースコードとデプロイパイプラインを使用して、リリースごとに環境を標準化します。
運用のサポート: 運用に影響を与える意思決定は、そのワークロードのニーズにのみ関係するため、運用上の意思決定が簡略化されます。運用のスコープが狭いことから、DevOps コミュニティのメンバーは、運用のサポートが最も純粋な形式の運用であると主張しています。
専門知識: DevOps チームと開発チームは、このアプローチによって最も権限を与えられ、市場の変化の促進に対して経験する抵抗が最も少なくなります。
ランディングゾーンの設計: 特定の運用上の利点はありません。
基本ユーティリティ: 特定の運用上の利点はありません。
職務の分離: 特定の運用上の利点はありません。

非集中型の運用の不利な点

コスト管理: 企業コストを計算しづらくなります。集中化したガバナンスチームが存在しないので、統一されたコスト制御や最適化を実装することが難しくなります。大規模な場合、このモデルはコストが高くなる可能性があります。デプロイされた資産と人員の割り当てが各ワークロードで重複している可能性があるためです。
責務: 集中化したサポートが存在しないことは、ガバナンス、セキュリティ、運用、変更管理についてワークロードチームが全面的に責務を負うことを意味します。それらのタスクがコードレビューおよびリリースパイプラインで自動化されていない場合、サポートを受けられないことは問題です。
標準化: ワークロードのポートフォリオ全体の標準化が一定せず、一貫性がありません。
運用のサポート: 多くの場合でスケールメリットはありませんが、複数のワークロードにわたってベストプラクティスがもたらされます。
専門知識: チームメンバーは、アプリケーションの設計と構成におけるガバナンス、セキュリティ、運用、変更管理について、賢明で倫理的な意思決定を行い、より大きな責務を果たします。必要な専門知識を強化するために Microsoft Azure Well-Architected Review と Azure Well-Architected Framework を頻繁に検討してください。
ランディングゾーンの設計: ランディングゾーンはワークロード固有ではなく、このアプローチでは考慮されません。
基本ユーティリティ: ワークロード間で共有される基本サービスは、(あるとしても) 少数であるため、スケールメリットは低下します。
職務の分離: DevOps チームと開発チームに対する要件が高く、それらのチームでの昇格された特権の使用回数が増加します。職務の分離が必要な場合は、このアプローチで運用するために、DevOps の成熟度に多額の投資が必要になる可能性があります。

集中型の運用

安定した状態の環境では、個々のワークロードのアーキテクチャや個別の運用要件を重視する必要はないかもしれません。集中型の運用は、主に安定した状態のワークロードで構成されるテクノロジ環境の標準です。安定した運用状態の例としては、商用市販の成果物 (COTS) であるアプリケーションや、リリースの頻度が低い、定着しているカスタムアプリケーションなどがあります。変化率が通常の更新プログラムとパッチで決まる場合、運用の集中化は、ポートフォリオを管理するための効果的な方法である可能性があります。

優先事項: 優先事項はイノベーションよりも中央制御であり、最新のクラウド運用へのカルチャの変化よりも既存の運用プロセスを評価します。
明らかな利点: 集中化により、スケールメリット、最高レベルのコントロール、標準化された運用、クラウド環境での最適な動作が実現します。これらの環境では、クラウド運用を既存の運用やプロセスに統合するための特定の構成が必要です。集中化は、中程度のアーキテクチャの複雑さとコンプライアンス要件を持つ、数百のワークロードからなるポートフォリオで最も有利です。
明らかに不利な点: 大規模なワークロードのポートフォリオの需要に合わせてスケーリングすることで、運用ワークロードに関する運用上の意思決定を下す集中化されたチームに、大きな負担がかかる場合があります。 VM、アプリケーション、またはデータソースの数が 1,000 を超える規模まで技術資産が増大すると予想される場合、それが 18 か月から 24 か月以内であれば、エンタープライズ型モデルの使用を検討できます。
リスク: このアプローチにより、集中化が少数のサブスクリプション (多くの場合、1 つの運用サブスクリプション) に制限されます。クラウド導入作業の後半でリファクタリングを行う場合は、重大なリスクが伴い、導入計画を妨げるおそれがあります。やり直しを避けるために、セグメント化、環境の境界、ID ツール、その他の基本要素に注意してください。
ガイダンス: "小規模から始めて拡張する" という開発速度に整合した Azure ランディングゾーンの実装オプションを使用すると、妥当な開始点になります。これらのオプションを使用して、導入作業を加速できます。しかし、成功させるには、受け入れ可能なリスク許容範囲内での早期導入の取り組みをガイドする明確なポリシーを確立します。統制と管理の手法は、並行して運用を成熟させるプロセスを作成するのに役立ちます。それらの手順に従うことは、運用が成熟するにつれてより高いリスクを許容する前に完了する必要があるステージゲートとして機能します。

集中型の運用の利点

コスト管理: 複数のワークロード間で共有サービスを集中化することで、スケールメリットが生じ、重複するタスクが排除されます。中央のチームは、エンタープライズ規模のサイズ調整と規模の最適化により、コスト削減を迅速に実装できます。
責務: 専門知識と標準化を中央に集中させることにより、安定性の向上、運用のパフォーマンス向上、変更に関連した障害の最小化につながる可能性があります。このアプローチにより、ワークロードにフォーカスしたチームに対する広範なスキル育成の負担が軽減されます。
標準化:: 一般的に、運用の標準化とコストが最も少ないのは集中型モデルです。これは、重複するシステムやタスクが少ないためです。
運用のサポート: 複雑さを軽減し、運用を集中化することで、小規模な IT チームによる運用のサポートが容易になります。
専門知識: サポートチームの集中化により、セキュリティ、リスク、ガバナンス、運用の専門家が、ビジネス上の重要な意思決定を推進できるようになります。
ランディングゾーンの設計: 中央 IT 部門は、ランディングゾーンとサブスクリプションの数を最小限に抑えることによって、複雑さを軽減します。ランディングゾーンの設計は、前のデータセンターの設計を模倣する傾向があるため、移行時間が短縮されます。導入が進むにつれて、共有リソースを別のサブスクリプションまたはプラットフォームの基盤に移す場合があります。
基本ユーティリティ: 既存のデータセンターの設計をクラウドに取り込むことにより、オンプレミスのツールと運用を模倣した基本的な共有サービスが得られます。オンプレミス運用が主要な運用モデルである場合、これは利点となる可能性がありますが、いくつかの不利な点に注意してください。オンプレミス運用によって移行時間が短縮され、スケールメリットを活用し、オンプレミスとクラウドでホストされるワークロード間で一貫した運用プロセスをサポートできるようになります。このアプローチにより、短期間の複雑さと労力が軽減され、小規模なチームが学習曲線を抑えながらクラウド運用をサポートできるようになります。
職務の分離: 集中型の運用では、職務の分離は明確です。中央 IT 部門が運用環境のコントロールを維持し、他のチームからの昇格されたアクセス許可の必要性が軽減されます。このアプローチでは、昇格された特権を持つアカウントの数を制限することで、違反を減らします。

集中型の運用の不利な点

コスト管理: 中央のチームは、ワークロードレベルで影響のある最適化を実現するワークロードアーキテクチャを必ずしも理解しているとは限りません。このような理解不足により、適切に調整されたワークロード運用によるコスト削減の量が制限されます。ワークロードアーキテクチャを完全に理解していないことで、集中化されたコスト最適化に影響が及ぶ可能性があり、適切に設計されたワークロードのパフォーマンス、規模、またはその他の柱に影響します。注目度の高いワークロードに企業全体のコスト変更を適用する前に、中央の IT チームが Microsoft Azure Well-Architected レビューを理解し、完了する必要があります。
責務: 運用環境のサポートとアクセスを集中化すると、運用上の大きな負担が少数の人員にかかり、各個人の負担が高まる可能性があります。これらの個人にかかる負担が原因で、デプロイされたワークロードの詳細なレビューを実行し、セキュリティガバナンスとコンプライアンスに関する詳細な要件に準拠していることを確認することが必要になります。
標準化: 中央 IT のアプローチでは、中央の IT スタッフを直線的に増員することなく標準化を拡張することは困難です。
運用のサポート: このアプローチで最も不利な点は、イノベーションを評価する大幅な規模と変化に関連しています。
専門知識: この種類の環境では、開発者と DevOps の専門家が過小評価されたり、制約を受けすぎたりする可能性があります。
ランディングゾーンの設計: データセンターの設計は、前述のアプローチの制約に基づいていますが、それらはクラウドに必ずしも当てはまるわけではありません。このアプローチに従うと、環境のセグメント化を再考し、イノベーションのチャンスを広げる機会が減少します。また、ランディングゾーンのセグメント化が欠如していることで、侵害の可能性や、ガバナンスおよびコンプライアンス順守の複雑さが増し、クラウド導入過程で導入の阻害要因が生じる可能性があります。上記のリスクのセクションを参照してください。
基本ユーティリティ: デジタル変革の過程で、クラウドが主要な運用モデルになる可能性があります。オンプレミスの運用向けに構築された中央のツールによって、運用を最新化する機会と運用効率を向上する機会が減少します。導入プロセスの早い段階で運用を最新化しないことを選択することも、1 つの選択肢です。最新化は、クラウド導入過程でプラットフォーム基盤サブスクリプションを作成することによって実現できることもあります。その取り組みは、事前に計画されていない、複雑でコストと時間がかかるものになる可能性があります。
職務の分離: 一般的に、集中型の運用は 2 つのパスのうちいずれかに従い、どちらもイノベーションを妨げる可能性があります。
- オプション 1: 中央 IT 部門の外部のチームは、運用環境を模倣した開発環境への制限付きアクセスを許可されます。このオプションは実験の妨げになります。
- オプション 2: チームは、サポートされていない環境で開発とテストを行います。このオプションは、デプロイプロセスの妨げになり、デプロイ後の統合テストが遅れます。

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

エンタープライズ型の運用は、すべてのクラウド運用に推奨されるターゲットの状態です。エンタープライズ型の運用では、意思決定と責務を簡素化して、コントロールの必要性とイノベーションのバランスを取ります。中央 IT 部門は、ワークロードチームをサポートする、より効率的なクラウドのセンターオブエクセレンスつまり CCoE チームによって置き換えられます。 CCoE チームはワークロードチームの行動をコントロールしたり制限したりするのではなく、意思決定の責任を持たせます。ワークロードチームには、適切に定義されたガードレールの範囲内でイノベーションを推進するために、より多くの権限と責務が与えられます。

優先事項: 技術に関する意思決定の民主化を優先させます。技術に関する意思決定の民主化によって、以前は中央 IT 部門が担っていた責務がワークロードチームに移行されます。この優先事項の変化を実現するために、意思決定は、人間が実行するレビュープロセスに依存することが少なくなります。このアプローチでは、クラウドネイティブツールを使用した自動レビュー、ガバナンス、適用をサポートします。
明らかな利点: 環境のセグメント化と職務の分離によって、コントロールとイノベーションのバランスを取ることができます。集中型の運用では、コンプライアンスの強化や安定した状態の運用を必要とするワークロードや、より大きなセキュリティリスクを表すワークロードを維持できます。逆に、このアプローチでは、より高度なイノベーションを必要とするワークロードと環境については、集中管理の削減をサポートします。より大きなポートフォリオでは、コントロールとイノベーションのバランスを取るのに苦労する場合があります。この柔軟性により、運用上の問題を削減しながら数千のワークロードに簡単に拡張できます。
明らかに不利な点: オンプレミスで機能したものが、エンタープライズ型のクラウド運用では適切に機能しない可能性があります。運用に対するこのアプローチでは、多くの面で変更が必要になります。多くの場合、制御権と責務におけるカルチャの変化が最大の課題です。カルチャの変化に続く運用の変化は、実装、成熟、安定化に時間と献身的な努力を要します。アーキテクチャの変化は安定したワークロードで必要になることがありますが、ツールの変化は、カルチャ、運用、アーキテクチャの変化を強化およびサポートするために必要です。これらの変化には、主要なクラウドプロバイダーに対するコミットメントが必要になる場合があります。これらの変更の前に行われる導入作業には、一般的なリファクタリング作業を超える大幅な修正が必要になる場合があります。
リスク: このアプローチでは、変更戦略に対する役員のコミットメントが必要です。また、学習曲線を克服し、必要な変化を実現するために、技術チームからのコミットメントも必要です。長期的な利点を実現するには、ビジネス、CCoEおよび中央 IT、ワークロードの各チーム間の長期的な連携が必要です。
ガイダンス: Azure ランディングゾーンのオプションは、 エンタープライズ規模として定義されています。これらのオプションには、Azure のクラウドネイティブツールを使用して技術的な変更を実現する方法を示す参照実装が用意されています。エンタープライズ規模のアプローチでは、それらの実装を最大限に活用するために必要な運用とカルチャの変化についてチームをガイドします。その同じアプローチによって、参照アーキテクチャを調整し、導入戦略とコンプライアンスの制約に合わせて環境を構成できる場合があります。エンタープライズ規模の実装が完了したら、統制と管理の手法をプロセスの定義に役立てることができます。これらのプロセスでは、運用ニーズに合わせてコンプライアンスと運用の機能を拡張することができます。

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

コスト管理: 中央のチームはポートフォリオ間の最適化を行い、より高度なワークロードの最適化については個々のワークロードチームに責任を持たせます。ワークロードにフォーカスしたチームは、意思決定を行う権限を与えられ、それらの意思決定がコストにマイナスの影響を及ぼす場合が明確化されています。中央のチームとワークロードチームは、コストに関する意思決定について、適切なレベルで責任を共有します。
責務: 中央のチームは、クラウドネイティブツールを使用してガードレールを定義、適用、自動化します。ワークロードチームの作業は、CCoE の自動化とプラクティスによって促進されます。ワークロードチームは、イノベーションを推進し、それらのガードレール内で意思決定を行うための権限を与えられます。
標準化: 集中化したガードレールと基本サービスによって、すべての環境にわたって一貫性が実現されます。
運用のサポート: 集中型の運用のサポートを必要とするワークロードは、安定した状態のコントロールを持つ環境に分割されます。職務のセグメント化と分離によって権限を与えられたワークロードチームが、独自の専用環境で運用サポートの責任を負います。自動化されたクラウドネイティブツールを使用して、集中化した運用サポートにより、すべての環境の最小限の運用ベースラインを保証します。
専門知識：セキュリティ、リスク、ガバナンス、運用などのコアサービスの集中化により、集中管理された適切な専門知識が確保されます。明確なプロセスとガードレールによって、ワークロードチームがより詳細な意思決定を行えるよう教育し、権限を与えます。これらの意思決定により、テクノロジーの規模に応じて直線的にスタッフを増やすことなく、集中化したエキスパートの影響力が増大します。
ランディングゾーンの設計: ランディングゾーンの設計では、明確なセキュリティ、ガバナンス、および責任の境界を作成して、ポートフォリオのニーズを複製します。これらの境界は、クラウドでワークロードを運用するために必要です。セグメント化のプラクティスは、前のデータセンターの設計によって作成された制約に似ているとは言えません。エンタープライズ型の運用では、ランディングゾーンの設計はあまり複雑ではないため、迅速なスケーリングが可能になり、セルフサービスの需要に対する障壁を低減することができます。
基本ユーティリティ: 基本ユーティリティは、プラットフォーム基盤と呼ばれる個別の集中管理されるサブスクリプションでホストされます。その後、中央のツールをユーティリティサービスとして各ランディングゾーンにパイプでつなぎます。ランディングゾーンから基本ユーティリティを分離すると、一貫性とスケールメリットが最大化されます。また、これらのユーティリティでは、集中管理される責務とワークロードレベルの責務が明確に区別されます。
職務の分離: 基本ユーティリティとランディングゾーンとの間の職務の分離が明確になることは、この運用アプローチの最大の利点の 1 つです。クラウドネイティブのツールとプロセスは、中央のチームとワークロードチームの間で、アクセスと適切なコントロールのバランスをサポートします。このアプローチは、個別のランディングゾーンと、ランディングゾーンセグメントでホストされているワークロードの要件に基づきます。

エンタープライズ型の運用の不利な点

コスト管理: 中央のチームは、ランディングゾーン内で運用の変更を行うために、ワークロードチームにより大きく依存します。この変化によって、予算超過が発生するリスクが生じ、実際の支出規模の適正化が遅れる可能性があります。予想外のコストを発生させないように、コスト管理プロセス、明確な予算、自動制御、定期的なレビューを事前に用意しておく必要があります。
責務: エンタープライズ運用では、必要なカルチャと運用上の要件が大きくなります。これらの要件により、中央チームとワークロードチームの間の責務と責任が明確になります。
従来の変更管理プロセスまたは変更諮問委員会 (cabs) は、この運用モデルで必要とされるペースとバランスを維持しないことがあります。これらのプロセスは、クラウドの導入を安全に拡張するプロセスと手順の自動化に反映されます。
変化に対するコミットメントの欠如は、まず責務の交渉と整合に現れます。責務の変化に対する整合ができないということは、短期間のクラウド導入の取り組みで中央 IT の運用モデルが必要になる可能性があることを示しています。
標準化: 集中管理されたガードレールまたは自動化への投資の欠如によって標準化のリスクが生じ、これは手動のレビュープロセスでは克服しにくいものです。ランディングゾーン内のワークロードと共有サービスの間の運用上の依存関係によって、リスクが高くなります。これらのリスクは、基本ユーティリティのアップグレードサイクルまたは将来のバージョンでの標準化から拡大したものです。プラットフォーム基盤のリビジョン中は、サポートされているすべてのランディングゾーンとそれらがホストするワークロードについて、改善または自動化されたテストが必要です。
運用のサポート: 影響が少ないか重要度の低いワークロードの場合は、自動化および集中化された運用によって提供される運用ベースラインで十分かもしれません。しかし、複雑なまたは重要度の高いワークロードに対しては、ワークロードチームやその他の形式での専任の運用が必要になる場合があります。その場合、これにより運用の予算が変化することがあり、そのため各部署は、それらの形式の高度な運用に対して運用経費を提供する必要があります。中央の IT 部門のみに運用コストの責任を持たせる必要がある場合、エンタープライズ型の運用を実装するのが困難になることがあります。
専門知識: 中央 IT チームのメンバーは、以前は手動プロセスを通じて提供されていた中央コントロールの自動化に関する専門知識を獲得することが必要な場合があります。また、それらのチームは、環境を定義するためにコードとしてのインフラストラクチャの手法のスキルを身に付けると共に、分岐、マージ、デプロイのパイプラインについて理解しなければならない場合もあります。少なくともプラットフォーム自動化チームは、クラウドのセンターオブエクセレンスまたは中央の運用チームによる意思決定を理解するために、意思決定スキルが必要になる場合があります。ワークロードチームは、意思決定を管理するコントロールとプロセスに関連した追加の知識を獲得することが必要な場合もあります。
ランディングゾーンの設計: ランディングゾーンの設計は基本ユーティリティに依存します。ワークロードチームは、設計の内容と、含めることが禁止されている内容を理解している必要があります。これを理解することは、作業の重複、エラー、または競合を回避するのに役立ちます。柔軟性を得るために、ランディングゾーンの設計に例外プロセスを考慮に入れる必要があります。
基本ユーティリティ: 基本ユーティリティの集中化には時間がかかります。これらのユーティリティでは、最終的にオプションが検討され、さまざまな導入計画に合わせて拡張できるソリューションが開発されます。初期の導入作業に遅延が発生する可能性があります。プロセスの後半で作業が加速し阻害要因が回避されるため、長期的には遅延が相殺されることがあります。
職務の分離: 職務の明確な分離を保証するには、成熟した ID 管理プロセスが必要です。ユーザー、グループ、オンボードおよびオフボード活動の適切な整合に関連する追加のメンテナンスが発生する場合があります。昇格された特権での Just-In-Time アクセスに対応するために、新しいプロセスの採用が必要になる場合があります。

分散型の運用

既存の運用モデルが細分化されすぎていて組織全体を新しい運用モデルに移行できない可能性があります。それ以外に、グローバルな運用やさまざまなコンプライアンス要件によって、特定の部署に変化を起こすことが妨げられることがあります。このケースでは、分散型の運用アプローチが必要になる場合があります。このアプローチは、これまでに説明した運用モデルを 1 つ以上統合する必要であるため、はるかに複雑です。

お勧めしませんが、一部の組織ではこの運用アプローチが必要になる場合があります。このアプローチは主に、全く異なる部署が緩やかに集まった組織や、顧客セグメントの多様なベース、またはリージョンの運用を行う組織に関係します。

優先事項: 複数の既存の運用モデルの統合。
組織全体を前述のいずれかの運用モデルに移行することに重点を置いた移行状態。
組織が大きすぎるか、複雑すぎるために 1 つの運用モデルに整合できない場合の、長期的な運用アプローチ。
明らかな利点: 各部署の共通の運用モデル要素の統合。このアプローチより、運用の単位を階層にグループ化し、一貫性のある反復可能なプロセスを使用して運用を成熟させるのに役立つ手段が創出されます。
明らかに不利な点: 複数の運用モデル間での一貫性と標準化を長期にわたって維持することは困難です。この運用アプローチを利用するには、ポートフォリオについて、およびテクノロジポートフォリオのさまざまなセグメントがどのように運用されるかについて深く理解している必要があります。
リスク: 主要な運用モデルへのコミットメントがないと、チーム間で混乱が生じる可能性があります。この運用モデルは、1 つの運用モデルに整合させる方法がない場合に使用してください。
ガイダンス: ビジネスアラインメントに関する記事に記載されている方法を使用する、ポートフォリオの詳細なレビューから開始します。ポートフォリオを状態の運用モデル (非集中型、集中型、またはエンタープライズ型) でグループ化してみてください。
運用モデルのグループ化を反映した管理グループ階層を作成します。この配置には、リージョンや部署についての他の編成パターン、あるいは最も一般的でないバケットから最も一般的なバケットまでワークロードクラスターをマップするその他の基準が含まれます。
ワークロードと運用モデルの整合性を評価し、最初に最も関連性の高い運用モデルクラスターを見つけます。ノードと管理グループ階層におけるすべてのワークロードに対して、その運用モデルにマップされているガイダンスに従います。
統制と管理の手法を使用して、階層のさまざまなポイントで必要とされる運用管理のプラクティスを含む、共通する企業ポリシーを見つけます。共通の Azure ポリシーを適用して、共有されている企業ポリシーを自動化します。
Azure ポリシーをさまざまなデプロイでテストする際に、管理グループ階層の上位に移動することを試みます。これらのポリシーは多くのワークロードに適用でき、共通点や明らかな運用ニーズが見つかる場合もあります。
時間が経つにつれて、このアプローチは、さまざまな運用モデル間でスケーリングするモデルを定義するのに役立つようになる場合があります。また、このアプローチでは、一連の共通するポリシーと手順を通じてチームを統合する場合もあります。

このアプローチの利点と不利な点は、意図的に空白にしています。ポートフォリオのビジネスへの整合を完了した後、利点と不利な点については、上記の主要な運用モデルのセクションを参照してください。

次のステップ

運用モデルに関連した用語について説明します。運用モデルが企業計画という、より大きなテーマにどのように適合するかが、用語によって理解しやすくなります。

運用モデルの用語

ランディングゾーンによってクラウド導入環境の基礎構成要素が提供されるしくみについて説明します。

ランディングゾーンとは