# 運用モデルの 2 x 2 表示
これらの運用モデルの 2 x 2 表示は、環境内でのチーム間の関係を理解するのに役立つ図です。これらの図では、誰が何をするかということと、チーム間の関係に重点を置いていますが、これらの例に沿ったガバナンスと意思決定についても説明します。
チームはサポートするワークロードに応じて、複数のモデルの複数の部分を担当する場合があります。説明されている高レベルの分野よりも、さらに専門的な分野に分割したい場合があります。アクティビティを分離または集計したり、チームをオーバーレイしてより具体的な詳細を提供したりすると、これらのモデルで無限のバリエーションが生じる可能性があります。
チーム間で機能が重複する、または認識されていない機能があり、それらがさらなる利点をもたらしたり、効率化につながったりする可能性があることに気づくことがあります。また、組織内で満たされていないニーズを見つけ、それに取り組むことができる可能性もあります。
組織の変化を評価する際は、モデル間のトレードオフ、個々のチームがモデル内で存在する場所 (現在および変更後)、チームの関係と責任がどのように変化するか、およびメリットが組織への影響に見合っているかどうかを調べます。
次の 4 つの各運用モデルを使用して成功を実現することができます。一部のモデルは、特定のユースケースや、開発における特定のポイントに適しています。これらのモデルによっては、現在の環境で使用しているモデルよりも利点が大きい場合があります。
**Topics**
+ [完全に分離された運用モデル](fully-separated-operating-model.md)
+ [クラウドマネージドサービスプロバイダーを使用する DevOps](devops-with-cloud-managed-service-provider.md)
+ [クラウドオペレーションおよびプラットフォームイネーブルメント (COPE)](cloud-operations-and-platform-enablement.md)
+ [分散型 DevOps](distributed-devops.md)
+ [非集中型 DevOps](decentralized-devops.md)
+ [運用モデルの進化](evolving-your-ops-model.md)
# 完全に分離された運用モデル
次の図では、縦軸にアプリケーションとプラットフォームが設定されています。アプリケーションとは、ビジネス成果を提供するワークロードを指し、カスタム開発または購入したソフトウェアであると考えます。プラットフォームとは、物理および仮想インフラストラクチャと、ワークロードをサポートするその他のソフトウェアを指します。
横軸には、エンジニアリングとオペレーションが設定されています。エンジニアリングとは、アプリケーションやインフラストラクチャの開発、構築、テストを指します。オペレーションとは、アプリケーションとインフラストラクチャのデプロイ、更新、および継続的なサポートのことです。
![\[従来のモデル図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/operational-excellence-pillar/images/full-seperate.png)
従来、組織は ITIL などのフレームワークや ISO などの標準を採用し、それらを基準に運用活動を形成し、トポロジが完全に分離されることがよくありました。このモデルでは、各クアドラントのアクティビティは個別のチームによって実行されます。作業は、作業リクエスト、キュー、チケットなどのメカニズムを介して、または IT サービス管理 (ITSM) システムを使用してチーム間で渡されます。
チームへの、またはチーム間でのタスクを移行すると、複雑性が増し、ボトルネックや遅延が生じてしまいます。リクエストは、優先順位が高くなるまで遅延することがあります。遅れて特定された不具合は大幅な再処理が必要になる可能性があり、同じチームとその機能を再び通過する必要が生じます。エンジニアリングチームによるアクションを必要とするインシデントがある場合、引き渡しのアクティビティによって対応が遅れてしまいます。
業務チーム、開発チーム、オペレーションチームが、実行されているアクティビティや機能を中心に編成されている場合には、調整不良のリスクが高くなります。これでは、チームはビジネス成果の達成に集中するのではなく、特定の責任に集中することになってしまいます。チームは専門的、物理的、あるいは論理的に細かく分けられて隔離されることがあり、コミュニケーションや共同作業の妨げになる場合があります。
# クラウドマネージドサービスプロバイダーを使用する DevOps
クラウドマネージド型サービスプロバイダーを使用する DevOps モデルでは、アプリケーションチームは「自分で構築して実行」方法論を採用します。しかし、専用のプラットフォームエンジニアリングおよび運用チームをサポートするための既存のスキルやチームメンバーが存在しない場合があります。また、そのための時間と労力の投資ができないことも考えられます。
あるいは、ビジネス差別化につながる機能の開発をプラットフォームチームに集中させ、差別化につながらない日常業務は外部に委託したいという場合もあります。
[AWS Managed Services](https://aws.amazon.com/managed-services/) などのマネージドサービスプロバイダ、または [AWS Partner Network](https://aws.amazon.com/partners/find/results/?keyword=Managed+Service+Provider) のプロバイダは、クラウド環境の実装に関する知見を提供し、セキュリティとコンプライアンスの要件、ビジネスの目標をサポートしています。
![\[クラウドマネージドサービスプロバイダーを使用する DevOps\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/operational-excellence-pillar/images/devops-msp.en.png)
このバリエーションでは、ガバナンスはプラットフォームチームによって一元管理されます。アカウント作成とポリシーは AWS Organizations および AWS Control Tower が管理します。
このモデルでは、サービスプロバイダーの仕組みに合わせるように組織を変更する必要があります。これは、サービスプロバイダーを含むチーム間のタスクの移行によって生じるボトルネックや遅延、または不具合の特定の遅れに関連する潜在的な再作業には対応していません。
プロバイダの標準、ベストプラクティス、プロセス、専門知識を活用できます。また、サービス提供の継続的な開発によるメリットも得られます。
運用モデルにマネージドサービスを追加すると、時間とリソースを節約できます。また、社内チームは新しいスキルや能力の開発に注力するのではなく、人員を増加せずにビジネス差別化につながる戦略的成果に集中できます。さらに、クラウド移行プログラムを遅らせることなく、独自のプラットフォーム機能を構築して成熟させる時間を確保することもできます。
# クラウドオペレーションおよびプラットフォームイネーブルメント (COPE)
クラウドオペレーションおよびプラットフォームイネーブルメント (COPE) モデルは、アプリケーションチームがワークロードのエンジニアリングとオペレーション活動を実行して DevOps 文化を醸成できるように支援することで、「自分で構築して実行」方法論を確立することを目標とします。
しかし、アプリケーションチームは、移行、クラウド採用、ワークロードモダナイゼーションを任されていても、クラウドアーキテクチャやクラウドオペレーションを十分にサポートする既存スキルがない場合があります。アプリケーションチームの能力と知識が不足していると、組織の俊敏性が低下し、ビジネス成果に影響を与える可能性があります。
この懸念に対処するには、組織内の既存の運用上の専門知識を活用して、アプリケーションチームがクラウドオペレーションに移行する取り組みをサポートします。これは、専門家の専属チームにすることも、組織全体から選ばれた人材で構成される仮想的なチームにすることもできます。ただし、目標は変わりません。つまり、クラウドファーストの自動化の原則に基づいて、画一的で負荷の高い作業を排除し、標準化されたパターンを提供し、自律性を促進することで、ワークロードチームの能力を向上する運用サポートを提供します。目的は、クラウド機能全体で十分な成熟度を高め、オペレーション上の責任の障壁を低くして、アプリケーションチームがサポートを必要としないようにすることです。
COPE モデルはワークロードレベルに焦点を当てています。このアプローチが複数のチームで同時に必要な場合、複雑で大規模な複数年にわたる移行プロジェクトを実行している場合、またはこれらのイニシアチブをサポートするプラットフォームを構築する場合は、Cloud Center of Excellence (CCoE) を検討してください。これは、クラウドへの移行を加速し、組織を広く変革しようとする多くの企業で成功した仕組みです。
![\[クラウドオペレーションおよびプラットフォームイネーブルメント (COPE) 図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/operational-excellence-pillar/images/cope.en.png)
プラットフォームエンジニアリングチームは、中心的な共有プラットフォーム機能のシンレイヤーを構築します。これは、アプリケーションチームが採用する事前定義された標準に基づいており、COPE チームによって提供されます。プラットフォームエンジニアリングチームはエンタープライズリファレンスアーキテクチャ、およびセルフサービスメカニズムを介してアプリケーションチームに提供されるパターンをコード化します。AWS Service Catalog などのサービスを使用することで、アプリケーションチームは承認済のリファレンスアーキテクチャ、パターン、サービス、構成などをデプロイできます。これらは一元化されたガバナンスおよびセキュリティ標準に既定で遵守します。
また、プラットフォームエンジニアリングチームは、標準化された一連のサービス (開発ツール、オブザーバビリティツール、バックアップおよび復旧ツール、ネットワークなど) をアプリケーションチームに提供します。
COPE チームは、標準化されたサービスを管理、サポートし、リファレンスアーキテクチャとパターンに基づいてクラウドプレゼンスを確立するアプリケーションチームを支援します。COPE チームはアプリケーションチームと協力して、ベースラインオペレーションを確立します。このプロセス中、アプリケーションチームは、時間の経過とともにシステムやリソースに対して徐々により多くの責任を担います。COPE チームはプラットフォームエンジニアリングチームと協力しながら継続的な改善を進め、アプリケーションチームの支持者として活動します。
アプリケーションチームは、環境、CI/CD パイプライン、変更管理、オブザーバビリティおよびモニタリング、インシデント/イベント管理プロセスのセットアップにおいて COPE チームからの支援を得ます。COPE チームはアプリケーションチームによるこれらの運用アクティビティに参加しますが、時間の経過とともにアプリケーションチームに所有権を移すため、ゆるやかにフェードアウトします。
アプリケーションチームは、COPE チームのスキルとこれまでに組織で得た学びから恩恵を受けることができます。つまり、一元化されたガバナンスを通じたガードレールで守られることになります。アプリケーションチームは社内に存在する過去の成功の上に構築され、採用した組織標準の継続的な更新による恩恵を得ます。オブザーバビリティおよびモニタリングを介してワークロードの運用に関する優れたインサイトを得ることができ、ワークロードに対して行った変更の影響をより深く理解できます。
COPE チームは運用アクティビティをサポートするために必要なアクセスを保持し、複数のアプリケーションチームにまたがったエンタープライズレベルの運用ビューと重大インシデント管理サポートを提供します。また COPE チームは画一的な負荷の大きい作業に分類されるアクティビティに対する責任を保持します。COPE チームは、大規模に対応できる標準化されたサポートソリューションを通じてこの責任を果たします。さらに、アプリケーションチームがアプリケーションの差別化に集中できるように、一般的なプログラミングや自動化された運用アクティビティの管理を引き続き行います。
各チームがもたらす組織の標準、ベストプラクティス、プロセス、専門知識による恩恵を受けることができます。新しいチームがクラウドを採用したりモダナイゼーションを行ったりする際に、これらの成功パターンを繰り返せるようなメカニズムを確立します。このモデルでは、COPE チームによるアプリケーションチームの確立、知識とアーティファクトの継承を支援する能力を重視しています。アプリケーションチームによる広範囲の独立性の取得の失敗リスクに対処するために、アプリケーションチームの運用負荷を低減します。プラットフォームエンジニアリング、COPE、アプリケーションチーム間の関係を確立し、進化と革新をさらに進めるためのフィードバックループを作り出します。
組織全体の標準を定義しながらプラットフォームエンジニアリングと COPE チームを確立することで、クラウドの採用を促進し、モダナイゼーションプロセスをサポートできます。アプリケーションチームに対する COPE チームによる追加のサポートをコンサルタントやパートナーとして位置づけることで、アプリケーションチームはワークロードレベルの障壁を取り除き、より迅速にクラウド機能のメリットを採用できるようになります。
# 分散型 DevOps
分散型 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 モデルは、アプリケーションチームに強力なフィードバックループを提供します。ワークロードの日々の運用は、直接的なやり取り、またはサポートや機能のリクエストを介した間接的なやりとりを通じて顧客との接点を増やします。このような可視性の向上により、アプリケーションチームはより迅速に問題に対処できるようになります。より深いつながりと密接な関係により、顧客ニーズに対するインサイトが得られ、より迅速なイノベーションが可能になります。
これらはすべて、アプリケーションチームをサポートするプラットフォームチームにも当てはまります。プラットフォームチームは、これらのアプリケーションチームを顧客とみなす必要があるためです。
採用された標準は使用前に承認され、本番環境への投入に必要なレビューの量が減る場合があります。プラットフォームチームによって提供される、サポートおよびテスト済みの標準を使用すると、これらのサービスに関する問題の頻度を減らすことができます。標準を採用することで、アプリケーションチームはワークロードの差別化に焦点を当てることができます。
# 非集中型 DevOps
分散型 DevOps モデルは、「自分で構築して実行」方法論のバリエーションです。オペレーションは主にワークロードチームの責任下にあります。
アプリケーションエンジニアは、ワークロードのエンジニアリングとオペレーションの両方を担当します。同様に、インフラストラクチャエンジニアは、アプリケーションチームをサポートするために使用するプラットフォームのエンジニアリングとオペレーションの両方を実行します。
![\[分散型 DevOps 図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/operational-excellence-pillar/images/decentralized-devops.en.png)
この例では、ガバナンスは一元管理されていないものとして扱います。標準はプラットフォームチームによってアプリケーションチームに分散、提供、または共有されますが、アプリケーションチームはワークロードに対応するために新しいプラットフォーム機能を自由に設計および運用できます。
このモデルでは、アプリケーションチームに対する制約が少なくなりますが、責任は大幅に増加します。追加のプラットフォーム機能をサポートするためには、追加のスキルや、場合によってはチームメンバーの増員が必要になります。スキルセットが適切でなく、不具合が早期に発見されない場合、大幅な再作業のリスクが高まります。
アプリケーションチームに特に委任されていないポリシーを適用する必要があります。[AWS Organizations](https://aws.amazon.com/organizations/) など、アカウント間で環境を一元管理できるツールまたはサービスを使用します。[AWS Control Tower](https://aws.amazon.com/controltower/features/) などのサービスでは、この管理機能が拡張されています。つまり、アカウントのセットアップに関する設計図 (運用モデルのサポート) を定義し、AWS Organizations を使用して進行中のガバナンスを適用し、新しいアカウントのプロビジョニングを自動化することができます。
アプリケーションチームが標準への追加や変更をリクエストするためのメカニズムを持つことは有益です。他のアプリケーションチームに利益をもたらす新しい標準にチームが貢献できます。プラットフォームチームは、これらの追加機能の直接サポートを提供することが、ビジネス成果につながる効果的なサポートであると判断する可能性があります。
このモデルでは、高度なスキルやチームメンバーなどの要件を用いてイノベーションに対する制約を回避します。チーム間のタスクの移行によって生成されるボトルネックや遅延の多くに対処しながら、チームと顧客との間の効果的な関係の発展を促進します。
# 運用モデルの進化
ここで示したモデルは、ツーピザチームの原則に合致し、ワークロードレベルで徐々に自律性の向上に向かうようになります。従来のアプローチから (ツーピザチームモデルへの継続的な進化の基盤としての) 分散型 DevOps への移行は時間がかかる可能性が高く、多くの機能にわたって成熟度を高める必要があることを理解することが重要です。したがって、チームと組織がエンタープライズトランスフォーメーションジャーニーを進める中でモデルを移行する方法の例を下記に示しました。変更やモデルごとに、より自律的でありながら組織的に整合性のあるチームへと進化しています。
![\[クラウド運用モデルのオンプレミスから自動化されたバリューストリームとプロセスへの進化図\]](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/operational-excellence-pillar/images/evolving-ops.en.png)
チームがどのように組織の変化をサポートできるか評価する際は、モデルごとのトレードオフ、個々のチームがモデル内で存在する場所 (移行や変更中も)、チームの関係と責任がどのように変化するか、およびメリットが組織への影響に見合っているかどうかを調べます。変更は決して線形ではないことにご注意ください。一部のモデルは、特定のユースケースやジャーニー中の特定ポイントに適しています。また、これらのモデルの中には、貴社の環境で他のモデルよりも利点が存在する場合もあります。