# 分散型 DevOps
<a name="distributed-devops"></a>

 分散型 DevOps モデルは、[COPE 方法論](cloud-operations-and-platform-enablement.md)に従って、エンジニアリングチーム全体でアプリケーションエンジニアリングオペレーションとインフラストラクチャエンジニアリングオペレーションの責任を分離 (または分散) します。

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

![\[分散型 DevOps モデル図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/operational-excellence-pillar/images/distributed-devops.en.png)


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

 [AWS Organizations](https://aws.amazon.com/organizations/) など、アカウント間で環境を一元管理できるツールまたはサービスを使用します。[AWS Control Tower](https://aws.amazon.com/controltower/features/) などのサービスでは、この管理機能が拡張されています。つまり、アカウントのセットアップに関する設計図 (運用モデルのサポート) を定義し、AWS Organizations を使用して進行中のガバナンスを適用し、新しいアカウントのプロビジョニングを自動化することができます。

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

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

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

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

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

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

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

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