分散 DevOps

分散 DevOps モデルは、 COPE方法論に従って、エンジニアリングチーム間でアプリケーションエンジニアリングオペレーションとインフラストラクチャエンジニアリングオペレーションの責任を分離 (または分散) します。

アプリケーションエンジニアは、ワークロードのエンジニアリングと運用の両方を担当します。同様に、インフラストラクチャエンジニアは、アプリケーションチームをサポートするために使用するプラットフォームのエンジニアリングと運用の両方を実行します。

分散 DevOps

この例では、ガバナンスを組織内の他の場所で一元化されたものとして扱います。標準はアプリケーションチームおよびプラットフォームチームに分散、提供、または共有されます。

AWS Organizations など、アカウント間で環境を一元管理できるツールまたはサービスを使用します。などのサービスは、アカウントのセットアップのブループリント (運用モデルのサポート) の定義、 を使用した継続的なガバナンスの適用、新しいアカウントのプロビジョニングの自動化を支援することで AWS Organizations、この管理機能AWS Control Towerを拡張します。

「自分で構築して実行する」とは、アプリケーションチームがフルスタック、ツールチェーン、およびプラットフォームの責任を負うという意味ではありません。

プラットフォームエンジニアリングチームは、標準化された一連のサービス (開発ツール、モニタリングツール、バックアップおよび復旧ツール、ネットワークなど) をアプリケーションチームに提供します。プラットフォームチームは、承認されたクラウドプロバイダーサービス、同じ特定の設定、またはその両方へのアクセスをアプリケーションチームに提供することもできます。

Service Catalog など、承認されたサービスと設定をデプロイするためのセルフサービス機能を提供するメカニズムは、ガバナンスを適用しながらフルフィルメントリクエストの遅延を制限するのに役立ちます。

プラットフォームチームはフルスタックの可視性を確保します。それにより、アプリケーションチームはアプリケーションコンポーネントに関する問題と、アプリケーションが消費するサービスやインフラストラクチャコンポーネントとを区別できます。プラットフォームチームは、これらのサービスの設定に関する支援や、アプリケーションチームの運用改善に関するガイダンスを提供することもできます。

前に説明したように、アプリケーションチームが、アクティビティやアプリケーションのイノベーションをサポートする標準の追加、変更、例外をリクエストするメカニズムが存在することが不可欠です。

分散 DevOps モデルは、アプリケーションチームに強力なフィードバックループを提供します。 Day-to-dayワークロードのオペレーションは、直接のやり取りを通じて、またはサポートや機能リクエストを通じて間接的に、顧客との接触を増やします。このような可視性の向上により、アプリケーションチームはより迅速に問題に対処できるようになります。より深いつながりと密接な関係により、顧客ニーズに対するインサイトが得られ、より迅速なイノベーションが可能になります。

これらはすべて、アプリケーションチームをサポートするプラットフォームチームにも当てはまります。プラットフォームチームは、これらのアプリケーションチームを顧客とみなす必要があるためです。

採用された標準は使用前に承認され、本番環境への投入に必要なレビューの量が減る場合があります。プラットフォームチームによって提供される、サポートおよびテスト済みの標準を使用すると、これらのサービスに関する問題の頻度を減らすことができます。標準を採用することで、アプリケーションチームはワークロードの差別化に焦点を当てることができます。