DevOps チームのトポロジ
IT チームとアプリケーション チーム間の役割、責任、信頼の分散は、大規模なクラウド導入に伴う運用上の変革にとって最も重要です。
IT チームは、管理を維持するよう努めています。 アプリケーションの所有者は、機敏性を最大限に高めようとします。 これら 2 つの目標の間で最終的に確立したバランスは、クラウド運用モデルの成功に大きく影響します。
Conway の法律に従って、チームはコミュニケーション構造に基づいてアーキテクチャを作成します。 この原則を理解することは、自律性と制御の間で必要なバランスを実現するために取り組む際に重要です。 システムを設計する (広く定義されている) 組織は、その組織の通信構造のコピーである設計構造を生成します。
DevOps の観点から、組織は顧客のニーズに迅速に対応できるように最適化する必要があります。 アプリケーションとシステムを所有、設計、実装するチームは、次の特性を持つアーキテクチャで最高レベルの自律性を見つけます。
- 絶え間ない変化をサポートする進化的アーキテクチャ
- 展開可能性
- テスト容易性
コンウェイの解決策は、コンウェイの法則を打ち勝つことです。 組織が特定の構造に従ってサービスと製品を生産し、最適化を検討している場合は、組織の構造を再考する必要があります。 目的のアーキテクチャを実現するために、チームと組織の構造を進化させます。
逆コンウェイ操縦の 
この原則は、DevOps の完全な規範を達成するために、所有するアプリケーション、システム、またはプラットフォームのエンドツーエンドをチームが担当する、意図的に設計された
次の表に、これらのチームの簡単な分類を示します。
| チームの種類 | 定義 |
|---|---|
| アプリケーション ワークロード チーム | これらのチームは、ビジネス ドメインのセグメントの直接的なビジネス成果を促進するアプリケーションを構築します。 Azure ランディング ゾーンのコンテキストでは、これらのチームはアプリケーション ワークロードのエンド ツー エンドのライフサイクルを担当します。 |
| プラットフォーム チーム | これらのチームは、配信を高速化し、アプリケーション ワークロード チームのコグニティブな負荷を軽減するために、説得力のある内部プラットフォームを構築します。 Azure ランディング ゾーンのコンテキストでは、これらのチームは Azure ランディング ゾーンのエンド ツー エンドのライフサイクルを担当します。 |
| イネーブリング チーム | これらのチームは、DevOps などの特殊な機能を使用して他のチームを支援することで、スキルのギャップを克服するのに役立ちます。 |
設計に関する考慮事項
Azure ランディング ゾーンのライフサイクルを設計、構築、プロビジョニング、管理、および維持するためのクロス機能プラットフォーム チームを確立します。 このチームには、中央の IT チーム、セキュリティ、コンプライアンス、ビジネス ユニットのメンバーを含め、幅広い企業を確実に表現できます。 アンチパターンを確実に避けてください。
既存の DevOps 機能を持たないアプリケーションとプラットフォームをサポートする DevOps 関数を提供できる有効化チームを確立するか、ビジネス ケースを確立することを検討します (たとえば、最小限の開発機能を備えたレガシ アプリケーション)。
機敏性が妨げられるため、アプリケーション ワークロード チームを中央の成果物に制限しないでください。 ポリシー駆動型のガバナンスと Azure ロールベースのアクセス制御 (Azure RBAC) を使用して、一貫したベースライン構成を適用し、アプリケーション (部署) チームがイノベーションを行うのに十分な柔軟性を確保しながら、定義済みの一連のテンプレートから引き出すことができるようにすることができます。
アプリケーション チームがアプリケーション リソースのインスタンス化または管理に中央プロセスまたはプロビジョニング パイプラインを使用するように強制しないでください。 アプリケーションの配信に DevOps パイプラインに既に依存している既存のチームは、現在のツールを引き続き使用できます。 Azure Policy を使用することで、組織の標準を適用し、大規模にコンプライアンスを評価し、DevOps プロセスにおけるセキュリティに関する 考慮事項 に対処できます。
DevOps モデルの一括適用では、対応する DevOps チームがすぐに確立されることはありません。
エンジニアリングの機能とリソースへの投資は非常に重要です。
一部のレガシ アプリケーションのアプリケーション チームには、DevOps 戦略に合わせて必要なエンジニアリング リソースがない場合があります。
設計に関する推奨事項
次のセクションでは、チーム トポロジを設計する際に役立つ設計の推奨事項について説明します。
チーム トポロジをクラウド運用モデルに合わせる
チーム トポロジを目的のクラウド運用モデルに合わせて調整してください。
チーム構造から生じる可能性のある問題を完全に理解できるように、運用適合性レビュー
プラットフォーム チームの関数を定義する
次の一覧では、Azure ランディング ゾーンを担当するプラットフォーム チームに推奨される機能のセットを示します。
- アーキテクチャ ガバナンス
- 必要なネットワーク、ID、アクセス管理ポリシーのサブスクリプションのプロビジョニングと委任
- プラットフォームの管理と監視 (包括的)
- コスト管理 (全体的)
- コードとしてのプラットフォーム (テンプレート、スクリプト、およびその他の資産の管理)
- Microsoft Entra テナント内の Microsoft Azure に対する全体的な操作 (サービス プリンシパルの管理、Microsoft Graph API の登録、ロール定義)
- Azure RBAC (包括的)
- セントラル サービスのキー管理 (単純なメール転送プロトコルとドメイン コントローラー)
- ポリシーの管理と適用 (包括的)
- セキュリティの監視と監査 (包括的)
- ネットワーク管理 (包括的)
アプリケーション ワークロード チームの関数を定義する
次の一覧では、アプリケーション ワークロードを担当するアプリケーション チームに推奨される機能のセットを示します。
- DevOps モデルを使用したアプリケーション リソースの作成と管理
- データベース管理
- アプリケーションの移行または変換
- アプリケーションの管理と監視 (アプリケーション リソース)
- Azure RBAC (アプリケーション リソース)
- セキュリティの監視と監査 (アプリケーション リソース)
- シークレットとキーの管理 (アプリケーション キー)
- コスト管理 (アプリケーション リソース)
- ネットワーク管理 (アプリケーション リソース)
チームを有効にする関数を定義する
次の一覧は、他のチームの支援を担当する有効なチームに推奨される機能のセットを示しています。
- 組織全体で適切な専門知識を獲得するのに役立つ水平 (クロス関数) ガイダンスと機能の定義。これにより、ターゲット クラウド運用モデル全体 (DevOps など) との整合性が確保されます。
- 他のチームが必要なレベルの専門知識を得るためのサポート、トレーニング、コーチング
- アプリケーションまたはプラットフォーム チーム用の再利用可能なテンプレートとライブラリの共通セットを確立し、Azure 検証済みモジュール などの InnerSourcing を育成します。
チーム間の対話モードを定義する
チーム間の対話の目標は次のとおりです。
- 自律性を実現する
- 依存関係のブロックを解除する
- 無駄な時間を最小限に抑える
- ボトルネックを回避する
チーム トポロジ では、次の 3 つのチーム対話モードについて説明します。
| 対話モード | 説明 |
|---|---|
| コラボレーション | チームは密接に連携します。 |
| サービスとしての X | Teams は、サードパーティベンダーの操作と同様に、最小限のコラボレーションで他のチームに何かを消費または提供します。 |
| ファシリテーション | チームは、障害を取り除くために別のチームを支援するか、別のチームの支援を受けます。 |