# OPS 2. ビジネスの成果をサポートするために、組織をどのように構築しますか?
チームはビジネスの成果を達成するうえでの役割を理解する必要があります。チームは他のチームの成功におけるそれぞれの役割、自分たちのチームの成功における他のチームの役割を理解し、目標を共有する必要があります。責任、所有権、意思決定方法、意思決定を行う権限を持つユーザーを理解することは、労力を集中的に投入し、チームの利点を最大化するのに役立ちます。
**Topics**
+ [OPS02-BP01 リソースには特定の所有者が存在する](ops_ops_model_def_resource_owners.md)
+ [OPS02-BP02 プロセスと手順に特定の所有者が存在する](ops_ops_model_def_proc_owners.md)
+ [OPS02-BP03 パフォーマンスに責任を持つ所有者が運用アクティビティに存在する](ops_ops_model_def_activity_owners.md)
+ [OPS02-BP04 責任と所有権を管理するためのメカニズムが存在する](ops_ops_model_def_responsibilities_ownership.md)
+ [OPS02-BP05 追加、変更、除外をリクエストするメカニズムが存在する](ops_ops_model_req_add_chg_exception.md)
+ [OPS02-BP06 チーム間の責任は事前定義済みまたは交渉済みである](ops_ops_model_def_neg_team_agreements.md)
# OPS02-BP01 リソースには特定の所有者が存在する
ワークロードのリソースには、変更管理、トラブルシューティング、その他機能を受け持つ、特定できる所有者が必要です。所有者は、ワークロード、アカウント、インフラストラクチャ、プラットフォーム、アプリケーションに割り当てられます。所有権は、一元登録などのツール、またはリソースに添付されたメタデータを使用して記録されます。コンポーネントのビジネス価値で、それらに適用されるプロセスと手順が決まります。
**期待される成果:**
+ リソースに、メタデータまたは一元登録を使用して特定できる所有者がいます。
+ チームメンバーが、リソースを誰が所有しているかを特定できます。
+ アカウントの所有者は、可能な限り 1 人です。
**一般的なアンチパターン:**
+ AWS アカウントのその他の連絡先が入力されていない。
+ リソースに、それを所有するチームを特定するタグがない。
+ E メールマッピングのない ITSM キューがある。
+ インフラストラクチャの重要な部分で 2 つのチームの所有権が重複している。
**このベストプラクティスを活用するメリット:**
+ リソースの変更管理は、所有権が割り当てられていて、わかりやすくなっています。
+ トラブルシューティングが発生した場合に、適切な所有者を関与させることができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
環境内のリソースユースケースにおける所有権の意味を定義します。所有権とは、リソースの変更を監督する人、トラブルシューティング中にリソースをサポートする人、または財務的な責任者を意味することもあります。名前、連絡先情報、組織、チームなどでリソースの所有者を指定し、記録します。
**お客様事例**
AnyCompany Retail は、所有権を、リソースの変更とサポートを担当するチームまたは個人と定義しています。同社は AWS Organizations を活用して AWS アカウントを管理しています。予備のアカウント連絡先は、グループ受信箱を使用して設定されています。各 ITSM キューは、E メールエイリアスにマッピングされています。タグによって、誰が AWS リソースを所有しているかを特定できます。その他のプラットフォームやインフラストラクチャについては、所有権と連絡先情報を特定できる wiki ページがあります。
### 実装手順
1. 組織における所有権を定義することから始めます。所有権は、リソースのリスクに対して責任を持つ人、リソースの変更を担当する人、またはトラブルシューティング時にリソースをサポートする人などを意味します。また、リソースの財務的または管理的な所有権を意味することもあります。
1. [AWS Organizations](https://aws.amazon.com/organizations/) を使用してアカウントを管理します。アカウントのその他の連絡先を一元管理できます。
1. 会社の E メールアドレスや電話番号を連絡先として使用することで、その E メールアドレスや電話番号の持ち主が組織から離れた場合でも、連絡先にアクセスすることができます。例えば、請求、オペレーション、セキュリティ用に別々の E メール配信リストを作成し、アクティブな AWS アカウントごとに請求、セキュリティ、オペレーションの連絡先として設定します。誰かが休暇を取っていたり、担当が変わったり、会社を辞めたりした場合でも、複数の人が AWS の通知を受け取り、対応できるようになります。
1. アカウントが [AWS Organizations](https://aws.amazon.com/organizations/) で管理されていない場合、代替のアカウント連絡先があれば、必要に応じて AWS が適切な担当者と連絡を取ることができます。アカウントの代替連絡先は、個人ではなくグループを指定して設定してください。
1. タグを使用して AWS のリソースの所有者を特定します。所有者と連絡先情報の両方を、別々のタグで指定できます。
1. [AWS Config](https://aws.amazon.com/config/) ルールを使用して、リソースに必須の所有権タグをつけるように強制できます。
1. 組織においてタグ付け戦略を策定する方法に関する詳細なガイダンスについては、「[AWS のタグ付けのベストプラクティス (ホワイトペーパー)](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)」を参照してください。
1. 生成 AI を活用する会話型アシスタント、[Amazon Q Business](https://aws.amazon.com/q/business/) を使用して、従業員の生産性を高め、質問に回答し、エンタープライズシステムの情報に基づいてタスクを完了します。
1. Amazon Q Business を会社のデータソースに接続します。Amazon Q Business には、Amazon Simple Storage Service (Amazon S3)、Microsoft SharePoint、Salesforce、Atlassian Confluence など、40 を超えるサポート対象のデータソースへの事前構築済みのコネクタが用意されています。詳細については、「[Amazon Q Business のコネクタ](https://aws.amazon.com/q/business/connectors/)」を参照してください。
1. その他のリソース、プラットフォーム、インフラストラクチャについては、所有権を特定するドキュメントを作成します。このドキュメントはチームメンバーが誰でも利用できるようにします。
**実装計画に必要な工数レベル:** 低。アカウントの連絡先情報およびタグを利用して、AWS リソースの所有権を割り当てます。その他のリソースについては、wiki の表などシンプルなものを使用して所有権と連絡先情報を記録するか、ITSM ツールを使用して所有権をマッピングします。
## リソース
**関連するベストプラクティス:**
+ [OPS02-BP02 プロセスと手順には特定の所有者が存在する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_proc_owners.html)
+ [OPS02-BP04 責任と所有権を管理するためのメカニズムが存在する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_responsibilities_ownership.html)
**関連ドキュメント:**
+ [AWS アカウント管理 - 連絡先情報の更新](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact.html)
+ [AWS Organizations - 組織の代替連絡先の更新](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_update_contacts.html)
+ [AWS のタグ付けのベストプラクティス (ホワイトペーパー)](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)
+ [Amazon Q Business と AWS IAM Identity Center を利用して、プライベートでセキュアなエンタープライズ生成 AI アプリケーションを開発する](https://aws.amazon.com/blogs/machine-learning/build-private-and-secure-enterprise-generative-ai-apps-with-amazon-q-business-and-aws-iam-identity-center/)
+ [生成 AI を使用して従業員の生産性向上を支援する Amazon Q Business の一般提供開始](https://aws.amazon.com/blogs/aws/amazon-q-business-now-generally-available-helps-boost-workforce-productivity-with-generative-ai/)
+ [AWS クラウド運用および移行ブログ - AWS Config と AWS Organizations で自動かつ一元的なタグ付けコントロールを実装する](https://aws.amazon.com/blogs/mt/implementing-automated-and-centralized-tagging-controls-with-aws-config-and-aws-organizations/)
+ [AWS セキュリティブログ - AWS CloudFormation Guard で pre-commit フックを拡張する](https://aws.amazon.com/blogs/security/extend-your-pre-commit-hooks-with-aws-cloudformation-guard/)
+ [AWS DevOps ブログ - AWS CloudFormation Guard を CI/CD パイプラインに統合する](https://aws.amazon.com/blogs/devops/integrating-aws-cloudformation-guard/)
**関連するワークショップ:**
+ [AWS Workshop - タグ付け](https://catalog.workshops.aws/tagging/)
**関連する例:**
+ [AWS Config ルール - Amazon EC2 with required tags and valid values](https://github.com/awslabs/aws-config-rules/blob/master/python/ec2_require_tags_with_valid_values.py)
**関連サービス:**
+ [AWS Config ルール - required-tags](https://docs.aws.amazon.com/config/latest/developerguide/required-tags.html)
+ [AWS Organizations](https://aws.amazon.com/organizations/)
# OPS02-BP02 プロセスと手順に特定の所有者が存在する
個々のプロセスと手順の定義を誰が所有しているか、特定のプロセスと手順が使用されている理由、およびその所有権が存在する理由を理解します。特定のプロセスと手順が使用される理由を理解することで、改善の機会を見極めることができます。
**期待される成果:** 組織において、運用タスクのための一連のプロセスと手順が明確に定義され、維持されています。プロセスと手順は一元的に保管され、チームメンバーが利用できます。プロセスと手順は、所有権が明確に割り当てられ、頻繁に更新されます。可能な場合は、スクリプト、テンプレート、オートメーションドキュメントがコードとして実装されます。
**一般的なアンチパターン:**
+ プロセスが文書化されていない。断片化されたスクリプトが、隔離されたオペレーターワークステーションに存在している場合がある。
+ スクリプトの使用方法に関する知識が一部の個人によって保持されているか、チームの知識として非公式に共有されている。
+ レガシープロセスの更新が必要であるのに、更新の所有権が不明であり、当初の作成者が既に組織を離れている。
+ プロセスとスクリプトが検出可能になっていないため、必要なとき (インシデントへの対応時など) にすぐに利用できない。
**このベストプラクティスを活用するメリット:**
+ プロセスと手順が整備されていると、ワークロードの運用努力の効果が上がります。
+ 新しいチームメンバーがより早く成果を出せるようになります。
+ インシデントを軽減するための時間が短縮されます。
+ さまざまなチームメンバー (やチーム) が同じプロセスと手順を一貫した方法で使用できます。
+ 繰り返し使用可能なプロセスを持つことで、チームがプロセスをスケールすることができます。
+ プロセスと手順が標準化されているため、チーム間でワークロードの責任を移転することの影響を軽減できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ プロセスと手順に対し、その定義に責任を持つ所有者が指定されています。
+ ワークロードのサポートにおいて実施される運用アクティビティを特定します。これらのアクティビティを検出可能な場所に文書化します。
+ アクティビティの仕様に責任を有する個人またはチームを一意に特定します。当該個人またはチームは、適切なアクセス許可、アクセス、およびツールを持つ適切なスキルのあるチームメンバーが正常に実行できるようにする責任があります。そのアクティビティの実行に問題がある場合、アクティビティの改善に必要となる詳細なフィードバックを提供する責任はそのチームメンバーにあります。
+ AWS Systems Manager などのサービス、ドキュメント、AWS Lambda を通じて、アクティビティアーティファクトのメタデータの所有権をキャプチャします。タグまたはリソースグループを使用してリソースの所有権をキャプチャし、所有権と連絡先情報を指定します。AWS Organizations を使用してタグ付けポリシーを作成し、所有権と連絡先情報をキャプチャします。
+ 時間が経つにつれて、これらの手順はコードとして実行できるように進化し、人的介入の必要が減るはずです。
+ 例えば、AWS Lambda 関数、CloudFormation テンプレート、AWS Systems Manager オートメーションのドキュメントを検討します。
+ 適切なリポジトリでバージョン管理を行います。
+ 所有者と文書を簡単に識別できるように、適切なリソースタグを付けてください。
**お客様事例**
AnyCompany Retail では、所有権を 1 つまたは (共通のアーキテクチャプラクティスとテクノロジーを共有する) 複数のアプリケーションのプロセスを所有するチームまたは個人と定義しています。最初にプロセスと手順をステップバイステップガイドとしてドキュメント管理システムに文書化し、アプリケーションをホストする AWS アカウントと、アカウント内の特定のリソースグループのタグを使用して手順を検出可能にしています。同社は AWS Organizations を活用して AWS アカウントを管理しています。時間の経過に伴い、これらのプロセスはコードに変換され、リソースは Infrastructure as Code (CloudFormation または AWS Cloud Development Kit (AWS CDK) テンプレートなど) を使用して定義されます。運用プロセスは AWS Systems Manager または AWS Lambda 関数でオートメーションドキュメントとなります。これらの関数は、スケジュールされたタスクとして、AWSCloudWatch アラームや AWS EventBridge イベントなどのイベントに応じて開始する場合や、IT サービス管理 (ITSM) プラットフォーム内の要求に応じて開始する場合があります。すべてのプロセスには、所有者を識別するタグが付いています。オートメーションとプロセスのドキュメントは、プロセスのコードリポジトリによって生成された Wiki ページ内で管理されます。
### 実装手順
1. 既存のプロセスと手順を文書化します。
1. レビューを行い、最新の状態に保ちます。
1. 各プロセスまたは手順の所有者を特定します。
1. それらをバージョン管理下に置きます。
1. 可能な場合は、アーキテクチャ設計を共有するワークロードや環境全体でプロセスと手順を共有します。
1. フィードバックと改善のためのメカニズムを確立します。
1. プロセスをレビューする頻度に関するポリシーを定義します。
1. レビュー担当者と承認者用のプロセスを定義します。
1. フィードバックを提供し、追跡するための問題やチケットキューを実装します。
1. プロセスと手順は、可能な限り、変更承認委員会 (CAB) による事前承認とリスク分類を受ける必要があります。
1. プロセスと手順は、それらを実行するユーザーがアクセスおよび検出できることを確認します。
1. タグを使用して、ワークロードのプロセスと手順にアクセスできる場所を示します。
1. 有意義なエラーやイベントのメッセージを活用して、問題に対処するための適切なプロセスまたは手順を示します。
1. Wiki とドキュメント管理を使用して、プロセスと手順を組織全体で一貫して検索できるようにします。
1. 生成 AI を活用する会話型アシスタント、[Amazon Q Business](https://aws.amazon.com/q/business/) を使用して、従業員の生産性を高め、質問に回答し、エンタープライズシステムの情報に基づいてタスクを完了します。
1. Amazon Q Business を会社のデータソースに接続します。Amazon Q Business には、Amazon S3、Microsoft SharePoint、Salesforce、Atlassian Confluence など、40 を超えるサポート対象のデータソースへの事前構築済みのコネクタが用意されています。詳細については、「[Amazon Q のコネクタ](https://aws.amazon.com/q/business/connectors/)」を参照してください。
1. 必要に応じて自動化します。
1. サービスやテクノロジーが API を提供している場合は、オートメーションを開発する必要があります。
1. プロセスに関する指導を十分に行います。これらのプロセスを自動化するためのユーザーストーリーと要件を作成します。
1. プロセスと手順の使用状況を適切に評価し、問題を提起するか、チケットを作成して反復的な改善に役立てます。
**実装計画に必要な工数レベル:** 中
## リソース
**関連するベストプラクティス:**
+ [OPS02-BP01 リソースには特定の所有者が存在する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_resource_owners.html)
+ [OPS02-BP04 責任と所有権を管理するためのメカニズムが存在する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_responsibilities_ownership.html)
+ [OPS11-BP04 ナレッジ管理を実施する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html)
**関連ドキュメント:**
+ [AWS ホワイトペーパー - AWS での DevOps の概要](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/automation.html)
+ [AWS ホワイトペーパー - AWS リソースのタグ付けのベストプラクティス](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)
+ [AWS ホワイトペーパー - 複数のアカウントで AWS 環境を構成する](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)
+ [AWS クラウド オペレーションと移行ブログ - Using Amazon Q Business to streamline your operations](https://aws.amazon.com/blogs/mt/streamline-operations-using-amazon-q-for-business/)
+ [AWS クラウド運用および移行ブログ - クラウドオートメーションプラクティスを構築して運用上の優秀性を実現する: AWS Managed Services 提供のベストプラクティス](https://aws.amazon.com/blogs/mt/build-a-cloud-automation-practice-for-operational-excellence-best-practices-from-aws-managed-services/)
+ [AWS クラウド運用および移行ブログ - AWS Config と AWS Organizations で自動かつ一元的なタグ付けコントロールを実装する](https://aws.amazon.com/blogs/mt/implementing-automated-and-centralized-tagging-controls-with-aws-config-and-aws-organizations/)
+ [AWS セキュリティブログ - AWS CloudFormation Guard で pre-commit フックを拡張する](https://aws.amazon.com/blogs/security/extend-your-pre-commit-hooks-with-aws-cloudformation-guard/)
+ [AWS DevOps ブログ - AWS CloudFormation Guard を CI/CD パイプラインに統合する](https://aws.amazon.com/blogs/devops/integrating-aws-cloudformation-guard/)
**関連するワークショップ:**
+ [AWS Well-Architected 運用上の優秀性ワークショップ](https://catalog.workshops.aws/well-architected-operational-excellence/en-US/)
+ [AWS Workshop - タグ付け](https://catalog.workshops.aws/tagging/)
**関連動画:**
+ [How to automate IT Operations on AWS](https://www.youtube.com/watch?v=GuWj_mlyTug)
+ [AWS re:Invent 2020 - Automate anything with AWS Systems Manager](https://www.youtube.com/watch?v=AaI2xkW85yE)
+ [AWS re:Inforce 2022 - Automating patch management and compliance using AWS (NIS306)](https://www.youtube.com/watch?v=gL3baXQJvc0)
+ [サポートs You - Diving Deep into AWS Systems Manager](https://www.youtube.com/watch?v=xHNLNTa2xGU)
**関連サービス:**
+ [AWS Systems Manager - Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Service Management Connector](https://aws.amazon.com/service-management-connector/)
# OPS02-BP03 パフォーマンスに責任を持つ所有者が運用アクティビティに存在する
定義されたワークロードに対して特定のアクティビティを実行する責任を持つ者と、その責任が存在する理由を理解します。運用アクティビティを実行することに責任を負うのが誰かを理解すると、アクティビティを実行する人物、結果を検証する人物、アクティビティの所有者にフィードバックを提供する人物を把握できます。
**期待される成果:**
組織において、定義されたワークロードで特定のアクティビティを実行し、そのワークロードによって生成されたイベントに対応する責任が明確に定義されています。組織は、プロセスの所有権と履行を文書化し、この情報を検出可能にしています。組織で変更があった場合は責任を見直して更新し、チームは欠点や非効率を特定するアクティビティのパフォーマンスを追跡して測定します。フィードバックメカニズムを実装して、欠点や改善を追跡し、反復的な改善をサポートします。
**一般的なアンチパターン:**
+ 責任を文書化しない。
+ 断片化されたスクリプトが、隔離されたオペレーターワークステーションに存在している。一部の個人だけがスクリプトの使用方法を知っている、またはチームの知識として非公式に参照している。
+ レガシープロセスの更新が必要であるのに、プロセスの所有者が誰かを誰も把握しておらず、当初の作成者が既に組織を離れている。
+ プロセスとスクリプトが検出可能になっていないため、必要な際 (インシデントへの対応時など) にすぐに利用できない。
**このベストプラクティスを活用するメリット:**
+ アクティビティを実行する責任を持つのは誰か、アクションが必要なときに誰に通知すべきか、アクションを実行し、結果を検証してアクティビティの所有者にフィードバックを提供するのは誰かを理解できます。
+ プロセスと手順が整備されていると、ワークロードの運用努力の効果が上がります。
+ 新しいチームメンバーがより早く成果を出せるようになります。
+ インシデントを軽減するための時間を短縮できます。
+ さまざまなチームが同じプロセスと手順を使用して、一貫した方法でタスクを実行できます。
+ 繰り返し使用可能なプロセスを持つことで、チームがプロセスをスケールすることができます。
+ プロセスと手順が標準化されているため、チーム間でワークロードの責任を移転することによる影響を軽減できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
責任の定義を始めるには、まず責任マトリックス、プロセスと手順、ロールと責任、ツールとオートメーションなどの既存のドキュメントから始めます。文書化されたプロセスについて責任をレビューし、ディスカッションを設けます。複数のチームとレビューして、文書化されている責任とプロセスの間の不一致を特定します。提供されるサービスについてそのチームの内部顧客と話し合い、チーム間での期待事項のギャップを特定します。
相違点を分析して対処します。改善の機会を特定し、頻繁にリクエストされ、リソースを大量に消費するアクティビティを探します。こうしたアクティビティは、一般的に有力な改善候補と考えられます。改善を簡素化し標準化するためのベストプラクティス、パターン、規範ガイダンスを調べます。改善の機会を記録し、改善が完了するまで追跡します。
経時的に、これらの手順をコードとして実行できるよう変換し、人的介入の必要性を減らします。例えば、AWS Lambda 関数、CloudFormation テンプレート、または AWS Systems Manager Automation ドキュメントとして手順を開始できます。これらの手順が適切なリポジトリでバージョン管理されていることを確認し、チームが所有者とドキュメントを簡単に特定できるように適切なリソースタグを付けます。アクティビティの実行責任を文書化し、オートメーションの正常な起動と稼働、期待される成果のパフォーマンスをモニタリングします。
**お客様事例**
AnyCompany Retail では所有権を、1 つのアプリケーションまたは共通のアーキテクチャプラクティスとテクノロジーを共有する複数のアプリケーションのプロセスを所有するチームまたは個人と定義しています。同社は、最初にプロセスと手順をステップバイステップガイドとしてドキュメント管理システムに文書化しています。アプリケーションをホストする AWS アカウントと、アカウント内の特定のリソースグループのタグを使用して手順を検出可能にし、AWS Organizations を使用して AWS アカウントを管理しています。時間の経過に伴って、AnyCompany Retail はこれらのプロセスをコードに変換し、Infrastructure as Code を使用して (CloudFormation または AWS Cloud Development Kit (AWS CDK) テンプレートなどのサービスを通じて) リソースを定義します。運用プロセスは AWS Systems Manager または AWS Lambda 関数でオートメーションドキュメントとなります。これらの関数は、スケジュールされたタスクとして、Amazon CloudWatch アラームや Amazon EventBridge イベントなどのイベントへの応答として、または IT サービス管理 (ITSM) プラットフォーム内のリクエストによって起動できます。すべてのプロセスには、誰が所有者かを示すタグが付いています。チームは、プロセスのコードリポジトリによって生成された Wiki ページ内で、オートメーションとプロセスのドキュメントを管理しています。
### 実装手順
1. 既存のプロセスと手順を文書化します。
1. レビューを行い、最新の状態であることを確認します。
1. 各プロセスまたは手順に所有者がいることを確認します。
1. 手順をバージョン管理下に置きます。
1. 可能な場合は、アーキテクチャ設計を共有するワークロードや環境全体でプロセスと手順を共有します。
1. フィードバックと改善のためのメカニズムを確立します。
1. プロセスをレビューする頻度に関するポリシーを定義します。
1. レビュー担当者と承認者用のプロセスを定義します。
1. フィードバックを提供して追跡するための問題やチケットキューを実装します。
1. プロセスと手順は、可能な限り、変更承認委員会 (CAB) による事前承認とリスク分類を受けます。
1. プロセスと手順を実行する必要がある人が、これにアクセスでき、検出できるようにします。
1. タグを使用して、ワークロードのプロセスと手順にアクセスできる場所を示します。
1. 有意義なエラーやイベントのメッセージを活用して、問題に対処するための適切なプロセスや手順を示します。
1. Wiki またはドキュメント管理を使用して、プロセスと手順を組織全体で一貫して検索できるようにします。
1. 適切である場合は自動化します。
1. サービスやテクノロジーが API を提供している場合は、オートメーションを開発します。
1. プロセスが十分に理解されていることを確認し、これらのプロセスを自動化するためのユーザーストーリーと要件を作成します。
1. プロセスと手順の適切な使用を評価し、問題を追跡して反復的な改善に役立てます。
**実装計画に必要な工数レベル:** 中
## リソース
**関連するベストプラクティス:**
+ [OPS02-BP01 リソースには特定の所有者が存在する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_resource_owners.html)
+ [OPS02-BP02 プロセスと手順に特定の所有者が存在する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_resource_owners.html)
+ [OPS02-BP04 責任と所有権を管理するためのメカニズムが存在する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_responsibilities_ownership.html)
+ [OPS02-BP05 責任と所有権を特定するためのメカニズムが存在する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_find_owner.html)
+ [OPS11-BP04 ナレッジ管理を実施する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html)
**関連ドキュメント:**
+ [AWS ホワイトペーパー \$1 AWS での DevOps の概要](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/automation.html)
+ [AWS ホワイトペーパー \$1 AWS リソースのタグ付けのベストプラクティス](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)
+ [AWS ホワイトペーパー \$1 複数のアカウントで AWS 環境を構成する](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)
+ [AWS クラウド運用および移行ブログ \$1 クラウドオートメーションプラクティスを構築して運用上の優秀性を実現する: AWS Managed Services 提供のベストプラクティス](https://aws.amazon.com/blogs/mt/build-a-cloud-automation-practice-for-operational-excellence-best-practices-from-aws-managed-services/)
+ [AWS Workshop - タグ付け](https://catalog.workshops.aws/tagging/)
+ [AWS Service Management Connector](https://aws.amazon.com/service-management-connector/)
**関連動画:**
+ [AWS Knowledge Center Live \$1 Tagging AWS Resources](https://www.youtube.com/watch?v=MX9DaAQS15I)
+ [AWS re:Invent 2020 \$1 Automate anything with AWS Systems Manager](https://www.youtube.com/watch?v=AaI2xkW85yE)
+ [AWS re:Inforce 2022 \$1 Automating patch management and compliance using AWS (NIS306)](https://www.youtube.com/watch?v=gL3baXQJvc0)
+ [サポートs You \$1 Diving Deep into AWS Systems Manager](https://www.youtube.com/watch?v=xHNLNTa2xGU)
# OPS02-BP04 責任と所有権を管理するためのメカニズムが存在する
自分の役割の責任と、ビジネスの成果に自分がどのように貢献するかを理解することで、タスクの優先順位付けと役割が重要である理由を知ることができます。これにより、チームメンバーはニーズを認識し、適切に対応できます。チームメンバーが各自の役割を把握していると、所有権を確立し、改善の機会を特定できるとともに、影響を与える方法や適切な変更を行う方法を理解できます。
責任の所有者が明確に定められていない場合もあります。このような場合は、このギャップを解消するメカニズムを構築します。所有権の割り当て権限を持つ個人への明確なエスカレーションパスを設定するか、ニーズに対処するための計画を立てます。
**望ましい結果:** 組織内のチームには、リソース、実行するアクション、プロセス、手順との関係性を含む、明確に定義された責任があります。これらの責任は、チームの責任と目標、および他のチームの責任と一致しています。エスカレーションパスを一貫性のある検出可能な方法で文書化し、決定内容を責任マトリクス、チーム定義、Wiki ページなどのドキュメントアーティファクトに反映させます。
**一般的なアンチパターン:**
+ チームの責任が不明瞭、または明確に定義されていない。
+ チームが役割と責任を一致させていない。
+ チームが目標や目的と責任を一致させていないため、成功の測定が難しい。
+ チームメンバーの責任が、チームや広範の組織と一致しない。
+ チームが責任を最新の状態に保っていないため、チームが実行するタスクとの整合性が取れていない。
+ 責任決定のためのエスカレーションパスが定義されていない、または不明瞭である。
+ エスカレーションパスに、適時の対応を保証するシングルスレッド (専任) の所有者がいない。
+ 役割、責任、エスカレーションパスが検出可能でないため、必要なとき (インシデントへの対応時など) にすぐには利用できない。
**このベストプラクティスを活用するメリット:**
+ 責任者または所有者が誰かを理解することで、適切なチームまたはチームメンバーに連絡して、リクエストをしたり、タスクを移行したりすることができる。
+ 不作為やニーズへの未対応というリスクを低減するために、責任や所有権の割り当て権限を持つ個人を特定できる。
+ 責任範囲が明確に定義されている場合、チームメンバーの自主性と所有権が高まる。
+ 責任を理解することで、決定すべき事項、実行すべきアクション、および適切な所有者に引き渡すべきアクティビティが明確になる。
+ 何がチームの責任範囲外かをしっかりと理解しているため、放棄された責任を特定しやすくなり、明確化のためにエスカレーションできるようになる。
+ チームの混乱や緊張を防ぎ、チームがワークロードとリソースをより適切に管理できるようになる。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
チームメンバーの役割と責任を特定し、チームメンバーが自らの役割に対する期待事項を理解していることを確認します。この情報を検出可能にして、組織のメンバーが、特定のニーズについて連絡する必要があるチームまたは個人を特定できるようにします。組織が AWS での移行とモダナイズの機会活用を目指す中で、役割と責任も変わる可能性があります。チームとそのメンバーにそれぞれの責任を認識させ、こうした変化の中で各自のタスクを遂行できるように適切にトレーニングを行います。
責任と所有権を特定するためのエスカレーションを受ける役割またはチームを決定します。このチームは、決定を下すためにさまざまなステークホルダーと連携できます。ただし、意思決定プロセスの管理責任はこのチームが負います。
組織のメンバーが所有権と責任を知り、特定するために、メンバーがアクセス可能なメカニズムを提供します。こうしたメカニズムによって、特定のニーズについて誰に連絡すべきかがわかります。
**お客様事例**
AnyCompany Retail は最近、リフトアンドシフトアプローチによって、オンプレミス環境から AWS のランディングゾーンへのワークロードの移行を完了しました。同社は、運用レビューを実施して、一般的な運用タスクをどのように達成するかを検討し、既存の責任マトリックスに新しい環境での運用が反映されていることを確認しました。オンプレミスから AWS に移行したことで、ハードウェアと物理インフラストラクチャに関連するインフラストラクチャチームの責任が軽減されました。この変化により、ワークロードの運用モデルを発展させる新たな機会があることも明らかになりました。
責任の大半の特定、対処、文書化を行うと同時に、見落とされた責任や、運用体制の発展に伴って変更が必要となる可能性のある責任についてのエスカレーションパスも定義しました。ワークロード全体にわたる標準化と効率向上のための新たな機会を探るには、AWS Systems Manager などの運用ツールや、AWS Security Hub CSPM および Amazon GuardDuty などのセキュリティツールへのアクセスを提供します。AnyCompany Retail では、最初に取り組むべき改善点に基づいて、責任と戦略の見直しをまとめました。同社は、新しい働き方や技術パターンの導入に合わせて、責任マトリックスを更新しています。
### 実装手順
1. 既存のドキュメントから始めます。一般的なソースドキュメントには以下が含まれます。
1. 責任または実行責任者 (responsible)、説明責任者 (accountable)、相談先 (consulted)、報告先 (informed) (RACI) のマトリクス
1. チーム定義または Wiki ページ
1. サービスの定義とサービス内容
1. 役割または職務内容
1. 文書化された責任をレビューし、ディスカッションを設けます。
1. チームとレビューを行って、文書化された責任と、チームが通常遂行している責任との間の不一致を特定します。
1. 内部顧客が提供している可能性のあるサービスについて話し合い、チーム間での期待事項のギャップを特定します。
1. 相違点を分析して対処します。
1. 改善の機会を特定します。
1. 頻繁に発生し、リソースを大量に消費するリクエストを特定します。通常、こうしたリクエストは改善の対象となる有力候補です。
1. ベストプラクティスを参照して、パターンを理解し、規範ガイダンスに従い、改善を簡素化および標準化します。
1. 改善の機会を記録し、完了まで追跡します。
1. チームが責任の割り当てを管理および追跡する責任を負っていない場合、その責任を担うチームメンバーを指定します。
1. チームが責任の明確化を求めるためのプロセスを定義します。
1. プロセスを見直し、明確で使いやすいことを確認します。
1. 必ず誰かがエスカレーションに責任を持ち、完了まで追跡するようにします。
1. 効果を測定するための運用メトリクスを設定します。
1. フィードバックメカニズムを作成して、チームが改善の機会を強調できるようにします。
1. 定期的なレビューのメカニズムを導入します。
1. 検出とアクセスが可能な場所にドキュメントを保管します。
1. Wiki またはドキュメントポータルが一般的です。
**実装計画に必要な工数レベル:** 中
## リソース
**関連するベストプラクティス:**
+ [OPS01-BP06 トレードオフを評価する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_priorities_eval_tradeoffs.html)
+ [OPS03-BP02 チームメンバーに、結果にリスクがあるときにアクションを実行する権限が付与されている](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_team_emp_take_action.html)
+ [OPS03-BP03 エスカレーションが推奨されている](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_team_enc_escalation.html)
+ [OPS03-BP07 チームに適正なリソースを提供する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_team_res_appro.html)
+ [OPS09-BP01 メトリクスを使用して業務目標と KPI を測定する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_operations_health_measure_ops_goals_kpis.html)
+ [OPS09-BP03 運用メトリクスのレビューと改善の優先順位付け](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_operations_health_review_ops_metrics_prioritize_improvement.html)
+ [OPS11-BP01 継続的改善のプロセスを用意する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_process_cont_imp.html)
**関連ドキュメント:**
+ [AWS ホワイトペーパー - AWS での DevOps の概要](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/automation.html)
+ [AWS Whitepaper - AWS クラウド Adoption Framework: Operations Perspective](https://docs.aws.amazon.com/whitepapers/latest/aws-caf-operations-perspective/aws-caf-operations-perspective.html)
+ [AWS Well-Architected フレームワーク運用上の優秀性 - ワークロードレベルの運用モデルトポロジ](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/operating-model-2-by-2-representations.html)
+ [AWS 規範的ガイダンス - Building your Cloud Operating Model](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-cloud-operating-model/welcome.html)
+ [AWS 規範的ガイダンス - Create a RACI or RASCI matrix for a cloud operating model](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/create-a-raci-or-rasci-matrix-for-a-cloud-operating-model.html)
+ [AWS クラウド運用および移行ブログ - クラウドプラットフォームチームを編成してビジネス価値を提供する](https://aws.amazon.com/blogs/mt/delivering-business-value-with-cloud-platform-teams/)
+ [AWS クラウド運用および移行ブログ - クラウド運用モデルを導入すべき理由](https://aws.amazon.com/blogs/mt/why-a-cloud-operating-model/)
+ [AWS DevOps ブログ - 組織のクラウドオペレーションをいかにモダナイズするか](https://aws.amazon.com/blogs/devops/how-organizations-are-modernizing-for-cloud-operations/)
**関連動画:**
+ [AWS Summit Online - Cloud Operating Models for Accelerated Transformation](https://www.youtube.com/watch?v=ksJ5_UdYIag)
+ [AWS re:Invent 2023 - Future-proofing cloud security: A new operating model](https://www.youtube.com/watch?v=GFcKCz1VO2I)
# OPS02-BP05 追加、変更、除外をリクエストするメカニズムが存在する
プロセス、手順、およびリソースの所有者にリクエストを送信できます。リクエストには、追加、変更、除外などがあります。このようなリクエストは変更管理プロセスを通ります。利点とリスクを評価した後、実行可能で適切であると判断されたリクエストを、十分な情報に基づいて承認します。
**期待される成果:**
+ 割り当てられた所有権に基づいて、プロセス、手順、リソースの変更をリクエストできます。
+ 変更は、メリットとリスクを検討して、熟考の上で行われます。
**一般的なアンチパターン:**
+ アプリケーションをデプロイする方法を更新しなければならないが、オペレーションチームからデプロイプロセスの変更をリクエストする方法がない。
+ ディザスタリカバリ計画を更新しなければならないが、変更のリクエスト先になる特定できる所有者がいない。
**このベストプラクティスを活用するメリット:**
+ プロセス、手順、リソースを、要件の変更に合わせて進化させることができます。
+ 所有者は十分な情報に基づいて変更時期を決定できます。
+ 変更は熟考の上で行われます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
このベストプラクティスを実装するには、プロセス、手順、リソースに対する変更のリクエストが可能である必要があります。変更管理プロセスは簡単なものでかまいません。変更管理プロセスを文書化します。
**お客様事例**
AnyCompany Retail は責任割り当て (RACI) マトリックスを使用して、プロセス、手順、リソースの変更を所有しているのが誰かを特定しています。文書化された変更管理プロセスは、簡単で従いやすいものです。RACI マトリックスとこのプロセスを使用して、誰でも変更リクエストを送信できます。
**実装手順**
1. ワークロードのプロセス、手順、リソースと、それぞれの所有者を特定します。ナレッジマネジメントシステムにそれらを記録します。
1. [OPS02-BP01 リソースには特定の所有者が存在する](ops_ops_model_def_resource_owners.md)、[OPS02-BP02 プロセスと手順に特定の所有者が存在する](ops_ops_model_def_proc_owners.md) または [OPS02-BP03 パフォーマンスに責任を持つ所有者が運用アクティビティに存在する](ops_ops_model_def_activity_owners.md) を実装していない場合は、まずそれらから始めます。
1. 組織の関係者と協力して、変更管理プロセスを作成します。このプロセスは、リソース、プロセス、手順の追加、変更、除外を対象とします。
1. [AWS Systems Manager Change Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/change-manager.html) は、ワークロードリソースの変更管理プラットフォームとして使用できます。
1. ナレッジマネジメントシステムに、変更管理プロセスを記録します。
**実装計画に必要な工数レベル:** 中 変更管理プロセスの作成では、組織全体の複数の関係者と協調する必要があります。
## リソース
**関連するベストプラクティス:**
+ [OPS02-BP01 リソースには特定の所有者が存在する](ops_ops_model_def_resource_owners.md) - 変更管理プロセスを構築する前に、リソースに特定された所有者が必要です。
+ [OPS02-BP02 プロセスと手順に特定の所有者が存在する](ops_ops_model_def_proc_owners.md) - 変更管理プロセスを構築する前に、プロセスに特定された所有者が必要です。
+ [OPS02-BP03 パフォーマンスに責任を持つ所有者が運用アクティビティに存在する](ops_ops_model_def_activity_owners.md) - 変更管理プロセスを構築する前に、オペレーションアクティビティに特定された所有者が必要です。
**関連ドキュメント:**
+ [AWS 規範的ガイダンス - AWS 大規模な移行のための基盤プレイブック: RACI 行列の作成](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-foundation-playbook/team-org.html#raci)
+ [Change Management in the Cloud Whitepaper](https://docs.aws.amazon.com/whitepapers/latest/change-management-in-the-cloud/change-management-in-the-cloud.html)
**関連サービス:**
+ [AWS Systems Manager Change Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/change-manager.html)
# OPS02-BP06 チーム間の責任は事前定義済みまたは交渉済みである
チーム間には、チームがどのように連携し、互いにサポートするかを説明する、定義済みまたは交渉済みの契約があります (応答時間、サービスレベル目標、サービスレベルアグリーメントなど)。チーム間コミュニケーションチャネルが文書化されています。チームの仕事がビジネスの成果に及ぼす影響、および他のチームや組織の成果を理解することで、タスクの優先順位付けを知り、適切に対応できるようになります。
責任と所有権が未定義または不明な場合、必要な活動をタイムリーに処理できず、これらのニーズへの対応が重複し、競合する可能性のある作業が生じるリスクがあります。
**期待される成果:**
+ チーム間の作業またはサポートに関する契約が、合意され文書化されます。
+ 相互にサポートまたは協力するチームに、コミュニケーションチャネルおよび応答時間目標が定められます。
**一般的なアンチパターン:**
+ 本稼働環境で問題が発生し、2 つの個別のチームが別個にトラブルシューティングを開始した。このサイロ化された作業のために停止時間が長くなった。
+ オペレーションチームが開発チームの支援を必要としているが、応答時間の合意がない。リクエストが後回しにされる。
**このベストプラクティスを活用するメリット:**
+ チームが相互にやり取りおよびサポートする方法を理解します。
+ 応答性の目標が周知されます。
+ コミュニケーションチャネルが明確に定義されます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
このベストプラクティスを実装すると、チームが協力し合う方法についてあいまいさがなくなります。正式に合意を結ぶことで、チームの協力方法や互いにサポートする方法を体系化できます。チーム間コミュニケーションチャネルが文書化されます。
**お客様事例**
AnyCompany Retail の SRE チームは、開発チームとサービスレベルアグリーメントを結んでいます。開発チームがチケットシステムでリクエストを行う際に、15 分以内の応答を期待できます。サイトが停止した場合は、SRE チームが開発チームのサポートを受けながら調査を主導します。
**実装手順**
1. 組織全体の関係者と協力して、プロセスと手順に基づき、チーム間の契約を策定します。
1. プロセスまたは手順が 2 つのチームで共有されている場合は、チームの協力方法に関するランブックを作成します。
1. チーム間に依存関係がある場合は、リクエストについての応答 SLA を結びます。
1. 責任の所在をナレッジマネジメントシステムに文書化します。
**実装計画に必要な工数レベル: 中** チーム間に既存の契約がない場合、組織全体の関係者が合意に至るまでに工数がかかる場合があります。
## リソース
**関連するベストプラクティス:**
+ [OPS02-BP02 プロセスと手順に特定の所有者が存在する](ops_ops_model_def_proc_owners.md) - チーム間で契約を設定する前に、プロセスの所有権を特定する必要があります。
+ [OPS02-BP03 パフォーマンスに責任を持つ所有者が運用アクティビティに存在する](ops_ops_model_def_activity_owners.md) - チーム間で契約を設定する前に、運用アクティビティの所有権を特定する必要があります。
**関連ドキュメント:**
+ [AWS Executive Insights - ピザ 2 枚チームでイノベーションを促進する](https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team/)
+ [AWS での DevOps の概要 - 2 枚のピザチーム](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/two-pizza-teams.html)