# 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 确定资源所有者
工作负载的资源必须具有已确定的所有者，以便实现变更控制、故障排除和其他功能。为工作负载、账户、基础设施、平台和应用程序分配所有者。使用集中登记册或附加到资源的元数据等工具记录所有权。组件的商业价值指明了应用于它们的流程和程序。
**期望结果：**
+ 使用元数据或集中登记册确定资源所有者。
+ 团队成员可以确定谁拥有资源。
+ 在可能的情况下，账户只有一个所有者。
**常见反模式：**
+ 未填入 AWS 账户 的备用联系人。
+ 资源缺少用于标识其所属团队的标签。
+ ITSM 队列没有电子邮件映射。
+ 两个团队对一个关键基础设施的所有权重叠。
**建立此最佳实践的好处：**
+ 通过分配所有权，资源的变更控制变得非常简单。
+ 在排查问题时，可以让适合的所有者参与进来。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
定义所有权对于环境中的资源应用场景的意义。所有权表示谁监督资源的变更、谁在排除故障时对资源提供支持或谁负责财务。指定并记录资源所有者，包括姓名、联系信息、组织和团队。
**客户示例**
AnyCompany Retail 将所有权定义为控制资源变更和支持的团队或个人。他们利用 AWS Organizations 来管理其 AWS 账户。使用组收件箱配置备用账户联系人。每个 ITSM 队列映射到一个电子邮件别名。标签确定谁拥有 AWS 资源。对于其他平台和基础设施，使用 Wiki 页面来确定所有权和联系信息。
### 实施步骤
1. 首先定义组织的所有权。所有权意味着谁承担资源的风险、谁控制对资源的变更，或在排除故障时谁为资源提供支持。所有权还意味着资源的财务或管理所有权。
1. 使用 [AWS Organizations](https://aws.amazon.com/organizations/) 管理账户。可以集中管理账户的备用联系人。
1. 使用公司拥有的电子邮件地址和电话号码作为联系信息，这样一来，即使其所属员工离开了公司，也不会影响您的正常访问。例如，为账单、运营和安全性创建单独的电子邮件分发列表，并在各个活跃的 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. 使用 [Amazon Q 企业版](https://aws.amazon.com/q/business/)，这是一款对话助手，使用生成式人工智能来提高员工的工作效率、回答问题并根据企业系统中的信息完成任务。
1. 将 Amazon Q 企业版连接到贵公司的数据来源。Amazon Q 企业版为 40 多个支持的数据来源提供预先构建的连接器，包括 Amazon Simple Storage Service（Amazon S3）、Microsoft SharePoint、Salesforce 和 Atlassian Confluence。有关更多信息，请参阅 [Amazon Q 企业版连接器](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 Account Management - Updating contact information](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact.html)
+ [AWS Organizations - Updating alternative contacts in your organization](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)》
+ [Build private and secure enterprise generative AI apps with Amazon Q Business and AWS IAM Identity Center](https://aws.amazon.com/blogs/machine-learning/build-private-and-secure-enterprise-generative-ai-apps-with-amazon-q-business-and-aws-iam-identity-center/)
+ [Amazon Q Business, now generally available, helps boost workforce productivity with generative AI](https://aws.amazon.com/blogs/aws/amazon-q-business-now-generally-available-helps-boost-workforce-productivity-with-generative-ai/)
+ [AWS 云 Operations & Migrations Blog - Implementing automated and centralized tagging controls with AWS Config and AWS Organizations](https://aws.amazon.com/blogs/mt/implementing-automated-and-centralized-tagging-controls-with-aws-config-and-aws-organizations/)
+ [AWS Security Blog - Extend your pre-commit hooks with AWS CloudFormation Guard](https://aws.amazon.com/blogs/security/extend-your-pre-commit-hooks-with-aws-cloudformation-guard/)
+ [AWS DevOps Blog - Integrating AWS CloudFormation Guard into CI/CD pipelines](https://aws.amazon.com/blogs/devops/integrating-aws-cloudformation-guard/)
**相关讲习会：**
+ [AWS 讲习会 – Tagging](https://catalog.workshops.aws/tagging/)
**相关示例：**
+ [AWS Config 规则 – 带有必需标签和有效值的 Amazon EC2](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 Automation 文档。
+ 在相应的存储库中执行版本控制。
+ 包括适当的资源标记，以便可以轻松识别负责人和文档。
**客户示例**
AnyCompany Retail 对“负责人”的定义是：负责某个应用程序或应用程序组（共享通用架构实践和技术）的流程的团队或个人。最初，这些流程和程序以分步指南的形式记录在文档管理系统中，可在托管应用程序的 AWS 账户 上以及账户中的特定资源组上，使用标签来发现。他们利用 AWS Organizations 来管理其 AWS 账户。随着时间的推移，这些流程会转换为代码，并使用基础设施即代码（例如 CloudFormation 或 AWS Cloud Development Kit (AWS CDK) 模板）定义资源。运营流程成为 AWS Systems Manager 中的自动化文档或 AWS Lambda 函数，这些流程可以作为计划任务启动，用于响应 AWS CloudWatch 警报等事件或 AWS EventBridge 事件，也可以通过 IT 服务管理（ITSM）平台内的请求启动。所有流程都有标签，用于标识负责人。用于自动化和流程的文档，保存在由该流程的代码存储库生成的 Wiki 页面中。
### 实施步骤
1. 记录现有的流程和程序。
1. 查看并保持最新状态。
1. 确定每个流程或程序的负责人。
1. 对流程和程序实施版本控制。
1. 只要可能，对具有相同架构设计的工作负载和环境，共享流程和程序。
1. 建立反馈和改进机制。
1. 定义有关流程审查频率的政策。
1. 定义审核者和审批者流程。
1. 实施问题队列或票证队列，以便提供和跟踪反馈。
1. 在可能时，流程和程序应由变更审批委员会（CAB）预先审批并进行风险分类。
1. 确认需要运行这些流程和程序的人员能够访问和搜索到流程和程序。
1. 使用标签来指示可以在哪里访问工作负载的流程和程序。
1. 使用有意义的错误和事件消息，指明用于解决问题的正确流程或程序。
1. 使用 Wiki 和文档管理，确保可在整个组织内一致地搜索流程和程序。
1. 使用 [Amazon Q 企业版](https://aws.amazon.com/q/business/)，这是一款对话助手，使用生成式人工智能来提高员工的工作效率、回答问题并根据企业系统中的信息完成任务。
1. 将 Amazon Q 企业版连接到贵公司的数据来源。Amazon Q 企业版为 40 多个支持的数据来源提供预先构建的连接器，包括 Amazon S3、Microsoft SharePoint、Salesforce 和 Atlassian Confluence。有关更多信息，请参阅 [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 白皮书 – Best Practices for Tagging AWS Resources](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)
+ [AWS 白皮书 – Organizing Your AWS Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)
+ [AWS 云 Operations and Migrations Blog - Using Amazon Q Business to streamline your operations ](https://aws.amazon.com/blogs/mt/streamline-operations-using-amazon-q-for-business/)
+ [AWS 云 Operations & Migrations Blog - Build a Cloud Automation Practice for Operational Excellence: Best Practices from AWS Managed Services](https://aws.amazon.com/blogs/mt/build-a-cloud-automation-practice-for-operational-excellence-best-practices-from-aws-managed-services/)
+ [AWS 云 Operations & Migrations Blog - Implementing automated and centralized tagging controls with AWS Config and AWS Organizations](https://aws.amazon.com/blogs/mt/implementing-automated-and-centralized-tagging-controls-with-aws-config-and-aws-organizations/)
+ [AWS Security Blog - Extend your pre-commit hooks with AWS CloudFormation Guard](https://aws.amazon.com/blogs/security/extend-your-pre-commit-hooks-with-aws-cloudformation-guard/)
+ [AWS DevOps Blog - Integrating AWS CloudFormation Guard into CI/CD pipelines](https://aws.amazon.com/blogs/devops/integrating-aws-cloudformation-guard/)
**相关讲习会：**
+ [AWS Well-Architected Operational Excellence 讲习会](https://catalog.workshops.aws/well-architected-operational-excellence/en-US/)
+ [AWS 讲习会 – Tagging](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 – 自动化](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS 服务管理连接器](https://aws.amazon.com/service-management-connector/)
# OPS02-BP03 确定对运营活动绩效负责的责任人
了解谁负责对定义的工作负载执行特定活动，以及为什么负责。了解谁负责执行活动，可告知谁来开展活动、验证结果并向活动负责人提供反馈。
**期望结果：**
组织明确定义了在对定义的工作负载执行特定活动以及响应由工作负载生成的事件时，需要承担的相关责任。组织记录了流程的所属责任和实施方法，并让这些信息可供搜索。在发生组织变更时审查和更新责任，并且团队跟踪和衡量缺陷和低效率识别活动的绩效。实施反馈机制来跟踪缺陷和改进，并支持迭代改进。
**常见反模式：**
+ 未记录责任。
+ 脚本呈现碎片化，分布在许多孤立的操作员工作站上。脚本的使用方法只有少数人了解，或将其非正式地称为*团队知识*。
+ 旧的流程需要更新，但没有人知道该流程的负责人是谁，原作者已不在组织中。
+ 无法发现流程和脚本，并且在需要时（例如，在响应意外事件时）无法使用。
**建立此最佳实践的好处：**
+ 了解谁负责执行活动、需要采取行动时要通知谁，以及谁将执行操作、验证结果并向活动负责人提供反馈。
+ 流程和程序可改进运行工作负载的工作。
+ 新的团队成员可以更快地投入工作中。
+ 可以减少用于缓解意外事件的时间。
+ 不同的团队使用相同的流程和程序来一致地执行任务。
+ 团队可以使用可重复的流程来扩展其流程。
+ 在团队之间移交工作负载责任时，标准化的流程和程序有助于减轻移交造成的影响。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
要开始定义责任，请从现有文档开始，例如责任矩阵、流程和程序、职责和责任，以及工具和自动化。审核记录的流程责任，并主持围绕流程责任开展讨论。与团队一起审核，找出文档中的责任和实际流程之间的不一致之处。讨论向该团队的内部客户提供的服务，从而确定团队之间的期望差距。
分析并解决差异。确定改进机会，并寻找经常请求开展的资源密集型活动，这些活动通常是可改进的有力候选方案。探索最佳实践、模式和规范性指南，以便简化和标准化改进。记录改进机会并一直跟踪改进，直至完成。
随着时间的推移，这些程序应该逐步进化为可作为代码运行，从而减少人工干预的需求。例如，程序可以作为 AWS Lambda 函数、CloudFormation 模板或 AWS Systems Manager Automation 文档启动。验证这些程序在相应的存储库中是否受版本控制，并包含适当的资源标记，以便团队能够轻松识别所有者和文档。记录开展活动的责任，然后监控自动化是否成功启动和运行，以及期望结果的实现情况。
**客户示例**
AnyCompany Retail 对“负责人”的定义是：负责某个应用程序或应用程序组（共享通用架构实践和技术）的流程的团队或个人。最初，公司以分步指南的形式将流程和程序记录到文档管理系统中。然后，使用托管应用程序的 AWS 账户 上的标签，以及账户内特定资源组上的标签，让程序可供搜索，并使用 AWS Organizations 管理其 AWS 账户。随着时间的推移，AnyCompany Retail 将这些流程转换为代码，并使用基础设施即代码（通过 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 Best Practices for Tagging AWS Resources](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)
+ [AWS 白皮书 \$1 Organizing Your AWS Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)
+ [AWS 云 Operations & Migrations Blog - Build a Cloud Automation Practice for Operational Excellence: Best Practices from AWS Managed Services](https://aws.amazon.com/blogs/mt/build-a-cloud-automation-practice-for-operational-excellence-best-practices-from-aws-managed-services/)
+ [AWS 讲习会 – Tagging](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. 责任或负责、问责、咨询和知情（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 白皮书 – AWS 云 Adoption Framework: Operations Perspective](https://docs.aws.amazon.com/whitepapers/latest/aws-caf-operations-perspective/aws-caf-operations-perspective.html)
+ [AWS Well-Architected Framework 卓越运营 – 工作负载级别运营模式拓扑](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/operating-model-2-by-2-representations.html)
+ [AWS Prescriptive Guidance - Building your Cloud Operating Model](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-cloud-operating-model/welcome.html)
+ [AWS Prescriptive Guidance - 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 云 Operations & Migrations Blog - Delivering Business Value with Cloud Platform Teams](https://aws.amazon.com/blogs/mt/delivering-business-value-with-cloud-platform-teams/)
+ [AWS 云 Operations & Migrations Blog - Why a Cloud Operating Model?](https://aws.amazon.com/blogs/mt/why-a-cloud-operating-model/)
+ [AWS DevOps Blog - How organizations are modernizing for cloud operations](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 Prescriptive Guidance - Foundation palybook for AWS large migrations: Creating RACI matrices](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-foundation-playbook/team-org.html#raci)
+ 《[Change Management in the Cloud 白皮书](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 预先定义或协商团队间的职责
团队之间具有明确或协商好的协议，规定了团队之间的合作和相互支持方式（例如，响应时间、服务水平目标或服务水平协议）。记录团队间沟通渠道。了解团队工作对业务成果以及其他团队和组织的成果的影响，可以确定其任务的优先顺序，并帮助他们作出适当的响应。
当责任和所有权不确定或未知时，将面临以下风险：没有及时处理必要的活动，以及在处理这些需求时可能出现工作冗余和潜在冲突。
**期望结果：**
+ 商定并记录团队间工作或支持协议。
+ 相互支持或合作的团队有明确的沟通渠道和响应期望。
**常见反模式：**
+ 生产中出现问题，两个单独的团队开始彼此独立地排查问题。他们各自为政，这延长了中断时间。
+ 运营团队需要开发团队提供帮助，但没有商定好响应时间。请求卡滞在积压工作中。
**建立此最佳实践的好处：**
+ 团队知道如何互动和相互支持。
+ 知道响应期望。
+ 明确定义沟通渠道。
**在未建立这种最佳实践的情况下暴露的风险等级：**低
## 实施指导
实施这种最佳实践意味着明确了团队相互合作的方式。正式协议规定了团队如何协同工作或相互支持。记录团队间沟通渠道。
**客户示例**
AnyCompany Retail 的 SRE 团队与其开发团队达成服务水平协议。开发团队在其工单系统中提出请求后，预计可以在十五分钟内得到答复。如果站点发生中断，则 SRE 团队在开发团队的支持下主导调查。
**实施步骤**
1. 与整个组织的利益相关方合作，根据流程和程序在团队之间达成一致。
1. 如果在两个团队之间共享了流程或程序，则编制有关团队如何协同工作的运行手册。
1. 如果团队之间存在依赖关系，请商定请求的响应 SLA。
1. 在知识管理系统中记录责任。
**实施计划的工作量级别：**中。如果团队之间还没有达成一致，则需要努力与组织中的利益相关方达成一致。
## 资源
**相关最佳实践：**
+ [OPS02-BP02 确定流程和程序负责人](ops_ops_model_def_proc_owners.md) – 在团队之间达成协议之前，必须确定流程所有权。
+ [OPS02-BP03 确定对运营活动绩效负责的责任人](ops_ops_model_def_activity_owners.md) – 在团队之间达成协议之前，必须确定运营活动所有权。
**相关文档：**
+ [AWS Executive Insights – 与双披萨团队一起推动创新](https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team/)
+ [AWS 上的 DevOps 简介 – 双披萨团队](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/two-pizza-teams.html)