DevOps チーム トポロジ

IT チームとアプリケーション チーム間での役割、責任、信頼の分担は、大規模なクラウド導入で必要となる運用の変革において最も重要です。

IT チームは、制御を維持することを目指しています。 アプリケーションの所有者は、機敏性を最大限に高めようとしています。 これら 2 つの目標の間で最終的に確立されるバランスは、クラウド運用モデルの成功に大きく影響します。

コンウェイの法則に従って、チームはコミュニケーション構造に基づくアーキテクチャを作成します。 自律性と制御の間で必要なバランスの実現に取り組んでいるので、この原則を理解することは重要です。 (広義の) システムを設計するあらゆる組織は、その組織のコミュニケーション構造のコピーである設計構造を作り出します。

DevOps の観点から、組織は顧客のニーズに迅速に対応できるように最適化する必要があります。 アプリケーションとシステムを所有、設計、実装するチームは、次の特性を持つアーキテクチャで最高レベルの自律性を見つけます。

• 継続的な変更をサポートする進化的なアーキテクチャ
• デプロイ容易性
• Testability

コンウェイの解決策は、コンウェイの法則より戦略で勝ることです。 組織が特定の構造に従ってサービスや製品を生産し、最適化を目指している場合は、組織構造を再考する必要があります。 目的のアーキテクチャを実現するために、チームと組織構造を進化させます。

この原則により、チーム トポロジが意図的に設計されます。このトポロジでは、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 検証済みモジュールなどのインナーソーシングの促進。

チーム間のインタラクション モードを定義する

チーム間のインタラクションの目標は次のとおりです。

• 自律性を実現する
• 依存関係のブロックを解除する
• 無駄な時間を最小限に抑える
• ボトルネックを回避する

チーム トポロジでは、次の 3 つのチーム インタラクション モードの概要を示します。