# 组织
团队必须对整个工作负载、他们在其中的角色以及共同的业务目标有一致的理解，以便确立优先事项以实现业务成功。明确优先事项可以让您的工作效益最大化。评估内部和外部客户需求，让包括业务、开发和运营团队在内的关键利益相关方参与进来，以便确定工作重心。评估客户需求将确保您充分了解实现业务成果所需的支持。确保了解组织治理规定的指导原则或义务，以及监管合规性要求和行业标准等可能需要遵循或重视的外部因素。验证您是否具有确定内部治理和外部合规性要求更改的机制。如果未确定要求，请验证您是否已对此决定进行尽职调查。定期审查优先事项，以便在需求发生变化时对其进行更新。
评估业务面临的威胁（例如业务风险和负债以及信息安全威胁），并在风险注册表中维护这些信息。评估风险的影响，在有冲突的利益或替代方法之间作出权衡。例如，新功能的加速上市可能会比成本优化更重要，或者您可以为非关系数据选择关系数据库来简化系统迁移工作，而无需重构。管理益处与风险，以便在确定工作重心时作出明智的决策。有些风险或选择可能在一段时间内可以接受，或许可以降低相关风险，或者允许风险继续存在可能会令人无法接受，在这种情况下，您将采取措施来化解风险。
您的团队必须了解他们在实现业务成果方面所发挥的作用。团队必须了解自己在其他团队获得成功的过程中所扮演的角色、其他团队在他们获得成功的过程中所扮演的角色，并制定共同的目标。了解责任分配、所有权归属、决策制定方式以及决策者，将有助于集中精力并最大限度地发挥团队的优势。团队的需求将由其所支持的客户、所在组织、团队的组成以及工作负载的特征决定。期望单个运营模式能够支持组织中的所有团队及其工作负载是不合理的。
确保每个应用程序、工作负载、平台和基础设施组件都有确定的负责人，并且每个流程和程序都有确定的负责人负责其定义，有负责人负责其性能。
了解每个组件、流程和程序的业务价值，了解为什么要配置这些资源或为什么要执行这些活动，以及为什么要拥有该所有权，这些都有助于确定团队成员的行动。清晰定义团队成员的责任以便他们可以适当地采取行动，并制定相关机制，确定责任和所有权。制定用于请求添加、更改和例外的机制，以免限制创新。在团队之间定义协议，描述团队之间如何开展合作以相互支持以及您的业务成果。
为团队成员提供支持，以便他们可以更有效地采取行动并为您的业务成果提供支持。参与其中的高层领导应设定期望并衡量是否成功。高层领导应是采用最佳实践和组织发展的发起人、倡导者和推动者。允许团队成员在成果面临风险时采取行动以尽可能减少影响，并鼓励他们在认为存在风险时向决策者和利益相关方上报，以便解决问题并避免意外事件。及时、清晰、可行地传达已知风险和计划内事件，以便团队成员可以及时采取适当行动。
鼓励进行试验，以加快学习速度，并使团队成员保持兴趣和参与热情。团队必须增强自己的技能组合，以采用新技术，并随需求和责任的变化继续提供支持。专门安排学习时间，以提供支持并鼓励参与其中。确保团队成员拥有取得成功和进行扩展所需的资源（包括工具和团队成员），以便为您的业务成果提供支持。利用跨组织的多样性来寻求多种独特的见解。利用这种见解提高创新能力、对您的假设提出质疑，并降低确认偏差的风险。在团队内部提升包容性、多样性和可达性有助于获取有益的见解。
如果存在适用于组织的外部法规或合规性要求，则应使用 [AWS 云合规性](https://aws.amazon.com/compliance/?ref=wellarchitected-wp)提供的资源来帮助培训团队，以便他们能够确定优先事项会受到的影响。Well-Architected Framework 强调学习、衡量和改进。它为您提供了一致的方法来评估架构，并实施将随着时间推移而扩展的设计。AWS 提供了 AWS Well-Architected Tool，可协助您在开发之前审查方法，在生产之前审查工作负载状态，以及在生产过程中审查工作负载状态。您可以将工作负载与最新的 AWS 架构最佳实践进行比较，监控整体状态，并深入了解潜在风险。AWS Trusted Advisor 是一种工具，让您可以访问一组核心检查，这些检查会提出优化建议，有助于确定您的优先事项。Business Support 和 Enterprise Support 客户可以访问其他检查，这些检查重点关注安全性、可靠性、性能、成本优化和可持续性，可进一步帮助他们确定优先事项。
AWS 有助于您就 AWS 及其服务对团队进行培训，让他们深入了解自己的选择会如何影响工作负载。使用由 AWS 支持 提供的资源（AWS 知识中心、AWS 讨论论坛和 AWS 支持 中心）和 AWS 文档来培训团队。请通过 AWS 支持 中心联系 AWS 支持，获取与 AWS 问题有关的协助。AWS 还分享了我们通过在 Amazon Builders' Library 中的 AWS 运营学到的最佳实践和模式。您可以通过 AWS Blog 和 The Official AWS Podcast，获得各种其他有用信息。AWSTraining and Certification 提供了一些培训，可以通过自定进度的数字课程，学习 AWS 的基础知识。您还可以报名参加讲师指导培训，进一步培养团队的 AWS 技能。
使用能够跨 AWS Organizations 等账户集中治理环境的工具或服务，协助管理运营模式。AWS Control Tower 等服务扩展了这一管理功能，让您能够定义账户设置的蓝图（支持您的运营模式），使用 AWS Organizations 进行持续治理以及自动预置新账户。托管服务提供商（如 AWS Managed Services、AWS Managed Services 合作伙伴或 AWS 合作伙伴网络中的托管服务提供商）会提供实施云环境的专业知识，并为您的安全性和合规性要求以及业务目标提供支持。将托管服务添加到您的运营模式可以节省您的时间和资源，并让内部团队保持精干，专注于凸显业务优势的战略成果，而不是开发新的技能和功能。
您可能会发现，您需要在某个时间点侧重于一小部分优先事项。长期使用平衡的方法来确保培养所需能力和管理风险。定期审查优先事项，并根据需求变化进行更新。当责任和所有权不确定或未知时，您将面临以下风险：没有及时执行必要的活动，以及在处理这些需求时可能出现工作冗余和潜在冲突。组织文化会直接影响团队成员的工作满意度和保留率。提升团队成员的参与度和能力，取得业务成功。创新必须进行试验，才能将创意转化为成果。应认识到，取得非预期结果也算试验成功，因为这种试验发现了无法实现成功的途径。
**Topics**
+ [组织重点](organization-priorities.md)
+ [运营模式](operating-model.md)
+ [组织文化](organizational-culture.md)
# 组织重点
您的团队需要对整个工作负载、他们在其中的角色以及共同的业务目标有一致的理解，以便设置运营重点以实现业务成功。明确优先事项可以让您的工作效益最大化。定期审查您的运营重点，以便在组织的需求发生变化时对其进行更新。
**Topics**
+ [OPS01-BP01 评估外部客户需求](ops_priorities_ext_cust_needs.md)
+ [OPS01-BP02 评估内部客户需求](ops_priorities_int_cust_needs.md)
+ [OPS01-BP03 评估治理要求](ops_priorities_governance_reqs.md)
+ [OPS01-BP04 评估合规性要求](ops_priorities_compliance_reqs.md)
+ [OPS01-BP05 评估威胁形势](ops_priorities_eval_threat_landscape.md)
+ [OPS01-BP06 在管理益处与风险的同时评估各种权衡因素](ops_priorities_eval_tradeoffs.md)
# OPS01-BP01 评估外部客户需求
让包括业务、开发和运营团队在内的关键利益相关方参与进来，以便确定将工作重心放在哪里来满足外部客户的需求。这可以确保您充分了解实现期望的业务成果所需的运营支持。
**期望结果：**
+ 能够从客户成果出发进行逆向思维。
+ 了解运营实践如何协助您获得业务成果和实现目标。
+ 让所有相关方参与进来。
+ 您已拥有用于捕获外部客户需求的机制。
**常见反模式：**
+ 您决定核心业务时间之外不再提供客户支持，但是您还没有查看历史支持请求数据。您不知道这是否会对客户产生影响。
+ 您正在开发一项新功能，但尚未与客户沟通，不了解客户是否需要；如果需要，以什么形式提供；并且尚未通过试验来验证交付需求和方法。
**建立此最佳实践的好处：**需求得到满足的客户流失的可能性更小。评估和了解外部客户需求将为您提供相关信息，告知您如何通过安排工作的优先级来实现业务价值。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
**了解业务需求：**包括业务、开发和运营团队在内的利益相关方需要有共同的目标和共同的理解，才能实现业务成功。
**审查外部客户的业务目标、需求和优先事项：**让包括业务、开发和运营团队在内的关键利益相关方参与进来，讨论外部客户的目标、需求和优先事项。这可以确保您充分了解实现业务成果和客户成果所需的运营支持。
**建立共识：**建立共识，确定工作负载的业务功能、每个团队在运行工作负载方面的角色，以及这些因素如何支持内部和外部客户共同的业务目标。
## 资源
**相关最佳实践：**
+ [OPS11-BP03 实施反馈环路](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_feedback_loops.html)
# OPS01-BP02 评估内部客户需求
让包括业务、开发和运营团队在内的关键利益相关方参与进来，以便确定怎样将工作重心放在内部客户的需求上。这可以确保您充分了解实现业务成果所需的运营支持。
**期望结果：**
+ 使用这些已明确的优先事项，将改进工作集中部署在能发挥最大影响（例如，培养团队技能、提高工作负载性能、降低成本、自动化运行手册或增强监控）的方面。
+ 随着需求的变化更新优先事项。
**常见反模式：**
+ 您决定更改产品团队的 IP 地址分配（没有与他们商议），以便更轻松地管理网络。您不知道这是否会对您的产品团队产生影响。
+ 您正在采用一种新的开发工具，但尚未与内部客户沟通，不了解他们是否需要，或者是否与他们的现有实践兼容。
+ 您正在实施一个新的监控系统，但尚未与内部客户沟通，不了解他们是否有监控或报告需求需要考虑。
**建立此最佳实践的好处：**评估和了解内部客户需求将为您提供相关信息，告知您通过安排工作的优先级来实现业务价值。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
+ 了解业务需求：包括业务、开发和运营团队在内的利益相关方需要有共同的目标和共同的理解，才能实现业务成功。
+ 审查内部客户的业务目标、需求和优先事项：让包括业务、开发和运营团队在内的关键利益相关方参与进来，讨论内部客户的目标、需求和优先事项。这可以确保您充分了解实现业务成果和客户成果所需的运营支持。
+ 建立共识：建立共识，确定工作负载的业务功能、每个团队在运行工作负载方面的角色，以及这些因素如何支持内部和外部客户共同的业务目标。
## 资源
**相关最佳实践：**
+ [OPS11-BP03 实施反馈环路](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_feedback_loops.html)
# OPS01-BP03 评估治理要求
治理是公司用来实现业务目标的一系列政策、规则或框架。从组织内部生成治理要求。它们会影响您选择的技术类型或影响工作负载运行方式。将组织治理要求纳入工作负载中。合规是证明您已实施治理要求的能力。
**期望结果：**
+ 将治理要求纳入架构设计和工作负载运行中。
+ 您可以提供证据来证明您遵循了治理要求。
+ 定期审查和更新治理要求。
**常见反模式：**
+ 组织要求根账户具有多重身份验证。您未能实施此要求，根账户已泄露。
+ 在设计工作负载时，您选择了未得到 IT 部门批准的实例类型。您无法启动工作负载，必须重新设计。
+ 您需要制定灾难恢复计划。您没有制定灾难恢复计划，且您的工作负载遭受了长时间的中断。
+ 您的团队希望使用新实例，但您的治理要求没有更新，不允许使用新实例。
**建立此最佳实践的好处：**
+ 遵循治理要求，使工作负载与更广泛的组织政策保持一致。
+ 治理要求反映了行业标准和组织的最佳实践。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
与利益相关方和治理组织合作，确定治理要求。将治理要求包括在工作负载中。可以提供证据来证明您遵循了治理要求。
**客户示例**
在 AnyCompany Retail，云运维团队与整个组织内的利益相关方合作制定治理要求。例如，他们禁止对 Amazon EC2 实例进行 SSH 访问。如果团队需要系统访问权限，他们需要使用 AWS Systems Manager Session Manager。随着新服务推出，云运维团队定期更新治理要求。
**实施步骤**
1. 为工作负载确定利益相关方，包括任何集中式团队。
1. 与利益相关方合作确定治理要求。
1. 生成列表之后，按优先顺序列出改进项，并开始将它们实施到工作负载中。
1. 使用诸如 [AWS Config](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/) 之类的服务创建治理即代码，并验证是否遵循了治理要求。
1. 如果您使用 [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)，则可以利用服务控制策略来实施治理要求。
1. 提供用于验证实施的文档。
**实施计划的工作量级别：**中。实施缺失的治理要求可能会导致工作负载返工。
## 资源
**相关最佳实践：**
+ [OPS01-BP04 评估合规性要求](ops_priorities_compliance_reqs.md) – 合规性就像治理，但来自组织外部。
**相关文档：**
+ [AWS Management and Governance Cloud Environment Guide](https://docs.aws.amazon.com/wellarchitected/latest/management-and-governance-guide/management-and-governance-cloud-environment-guide.html)
+ [Best Practices for AWS Organizations Service Control Policies in a Multi-Account Environment](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/)
+ [Governance in the AWS 云: The Right Balance Between Agility and Safety](https://aws.amazon.com/blogs/apn/governance-in-the-aws-cloud-the-right-balance-between-agility-and-safety/)
+ [什么是治理、风险与合规性（GRC）？](https://aws.amazon.com/what-is/grc/)
**相关视频：**
+ [AWS Management and Governance: Configuration, Compliance, and Audit - AWS Online Tech Talks](https://www.youtube.com/watch?v=79ud1ZAaoj0)
+ [AWS re:Inforce 2019: Governance for the Cloud Age (DEM12-R1)](https://www.youtube.com/watch?v=y3WmHnavuN8)
+ [AWS re:Invent 2020: Achieve compliance as code using AWS Config](https://www.youtube.com/watch?v=m8vTwvbzOfw)
+ [AWS re:Invent 2020: Agile governance on AWS GovCloud (US)](https://www.youtube.com/watch?v=hv6B17eriHQ)
**相关示例：**
+ [AWS Config Conformance Pack Samples](https://docs.aws.amazon.com/config/latest/developerguide/conformancepack-sample-templates.html)
**相关服务：**
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Organizations - Service Control Policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)
# OPS01-BP04 评估合规性要求
监管、行业和内部合规性要求是定义组织优先事项的重要驱动因素。您的合规性框架可能会阻止您使用特定技术或地理位置。如果未确定外部合规性框架，则进行尽职调查。生成验证合规性的审计或报告。
如果您宣称自己的产品符合特定的合规性标准，则您必须有内部流程来确保持续合规。合规性标准的示例包括 PCI DSS、FedRAMP 和 HIPAA。适用的合规性标准由各种因素决定，例如解决方案存储或传输的数据类型，以及解决方案支持的地理区域。
**期望结果：**
+ 将监管、行业和内部合规性要求纳入架构选择。
+ 您可以验证合规性并生成审计报告。
**常见反模式：**
+ 部分工作负载属于支付卡行业数据安全标准（PCI-DSS）框架，但工作负载以未加密方式存储信用卡数据。
+ 软件开发人员和架构师不了解组织必须遵循的合规性框架。
+ 年度系统与组织控制（SOC2）类型 II 审核即将开始，您无法验证控制措施是否已到位。
**建立此最佳实践的好处：**
+ 评估和了解适用于工作负载的合规性要求将为您提供相关信息，告知您如何通过安排工作的优先级来实现业务价值。
+ 选择与合规性框架保持一致的适当位置和技术。
+ 设计工作负载以实现可审核性，以便证明您遵守合规性框架。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
实施此最佳实践意味着将合规性要求纳入架构设计过程。团队成员了解所需的合规性框架。您依照框架验证合规性。
**客户示例**
AnyCompany Retail 存储客户的信用卡信息。卡存储团队的开发人员明白他们需要遵守 PCI-DSS 框架。他们已采取措施来确认按照 PCI-DSS 框架安全地存储和访问信用卡信息。他们每年都会与安全团队一起验证合规性。
**实施步骤**
1. 与安全和治理团队合作，确定工作负载必须遵守哪些行业、监管或内部合规性框架。将合规性框架纳入工作负载。
1. 使用 [AWS Compute Optimizer](https://docs.aws.amazon.com/compute-optimizer/latest/ug/what-is-compute-optimizer.html) 和 [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) 之类的服务，验证 AWS 资源的持续合规性。
1. 向团队成员介绍合规性要求，以便他们可以根据要求运行和改进工作负载。架构和技术选择中应包括合规性要求。
1. 根据合规性框架，您可能需要生成审核或合规性报告。与组织合作，尽可能使此过程实现自动化。
1. 使用诸如 [AWS Audit Manager](https://docs.aws.amazon.com/audit-manager/latest/userguide/what-is.html) 之类的服务验证合规性并生成审计报告。
1. 您可以通过 [AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/what-is-aws-artifact.html) 下载 AWS 安全与合规性文档。
**实施计划的工作量级别：**中。实施合规性框架并非易事。生成审核报告或合规性文档带来了额外的复杂性。
## 资源
**相关最佳实践：**
+ [SEC01-BP03 识别和验证控制目标](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_control_objectives.html) – 安全控制目标是整体合规性的重要组成部分。
+ [SEC01-BP06 自动测试和验证管道中的安全控制](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_test_validate_pipeline.html) – 作为管道的一部分，验证安全控制。还可以生成新变更的合规性文档。
+ [SEC07-BP02 定义数据保护控制](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_data_classification_define_protection.html) – 许多合规性框架都基于数据处理和存储策略。
+ [SEC10-BP03 准备取证能力](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_prepare_forensic.html) – 取证能力有时可用于审核合规性。
**相关文档：**
+ [AWS 合规中心](https://aws.amazon.com/financial-services/security-compliance/compliance-center/)
+ [AWS 合规性资源](https://aws.amazon.com/compliance/resources/)
+ [AWS 风险与合规性白皮书](https://docs.aws.amazon.com/whitepapers/latest/aws-risk-and-compliance/welcome.html)
+ [AWS 责任共担模式](https://aws.amazon.com/compliance/shared-responsibility-model/)
+ [按合规性计划提供的范围内 AWS 服务](https://aws.amazon.com/compliance/services-in-scope/)
**相关视频：**
+ [AWS re:Invent 2020: Achieve compliance as code using AWS Compute Optimizer](https://www.youtube.com/watch?v=m8vTwvbzOfw)
+ [AWS re:Invent 2021 - Cloud compliance, assurance, and auditing](https://www.youtube.com/watch?v=pdrYGVgb08Y)
+ [AWS Summit ATL 2022 - Implementing compliance, assurance, and auditing on AWS (COP202)](https://www.youtube.com/watch?v=i7XrWimhqew)
**相关示例：**
+ [AWS 上的 PCI DSS 和 AWS 基础安全最佳实践](https://aws.amazon.com/solutions/partners/compliance-pci-fsbp-remediation/)
**相关服务：**
+ [AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/what-is-aws-artifact.html)
+ [AWS Audit Manager](https://docs.aws.amazon.com/audit-manager/latest/userguide/what-is.html)
+ [AWS Compute Optimizer](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)
# OPS01-BP05 评估威胁形势
评估对业务的威胁（例如竞争、业务风险和负债、运营风险和信息安全威胁），并在风险注册表中维护当前信息。在确定工作重心时，将风险的影响考虑在内。
[Well-Architected Framework](https://aws.amazon.com/architecture/well-architected/) 强调学习、衡量和改进。它为您提供了一致的方法来评估架构，并实施将随着时间推移而扩展的设计。AWS 提供了 [AWS Well-Architected Tool](https://aws.amazon.com/well-architected-tool/)，可协助您在开发之前审查方法，在生产之前审查工作负载状态，以及在生产过程中审查工作负载状态。您可以将其与最新的 AWS 架构最佳实践进行比较，监控工作负载的整体状态，并深入了解潜在风险。
AWS 客户可以使用针对关键任务型工作负载的指导式架构完善的审核，以根据 AWS 最佳实践来[衡量其架构](https://aws.amazon.com/premiumsupport/programs/)。Enterprise Support 客户可以使用[运营审核](https://aws.amazon.com/premiumsupport/programs/)，该审核旨在帮助他们找出云中的运营方法所存在的漏洞。
这些审核需要跨团队参与，可帮助各团队就工作负载形成共识，并理解彼此的团队角色如何助力取得成功。通过审核所确定的需求可以帮助确定优先事项。
[AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/) 是一种工具，让您可以访问一组核心检查，这些检查会提出优化建议，帮助确定优先事项。[Business Support 和 Enterprise Support 客户](https://aws.amazon.com/premiumsupport/plans/)可以访问其他检查，这些检查重点关注安全性、可靠性、性能和成本优化，可进一步帮助他们确定优先事项。
**期望结果：**
+ 您定期审核 Well-Architected 和 Trusted Advisor 输出并采取行动
+ 您了解服务的最新补丁状态
+ 您了解已知威胁的风险和影响，并能采取相应的行动
+ 您能够根据需要实施缓解措施
+ 您能够传达行动和背景
**常见反模式：**
+ 您在产品中使用的是旧版软件库。对于可能会对工作负载产生意外影响的问题，需要对库进行安全更新，而您忽略了这一点。
+ 您的竞争对手刚刚发布了新的产品版本，可以解决许多客户对您产品的投诉。您没有优先解决这些已知问题。
+ 监管机构一直在追查像您这样的不符合法律法规要求的公司。您没有优先处理任何未解决的合规性要求。
**建立此最佳实践的好处：**发现并了解对组织和工作负载的威胁，帮助确定要解决的威胁、需解决的威胁的优先级以及执行操作所需的资源。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
+ **评估威胁形势：**评估对业务的威胁（例如竞争、业务风险和负债、运营风险和信息安全威胁），以便您在确定工作重心时可以将其影响考虑在内。
+ [AWS 最新安全公告](https://aws.amazon.com/security/security-bulletins/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/)
+ **维护威胁模型：**建立并维护威胁模型，确定潜在威胁、计划内和已实施的缓解措施及其优先级。审核威胁酿成意外事件的可能性、从意外事件恢复的成本和预期造成的危害，以及防止这些意外事件发生的成本。根据威胁模型内容的更改修订优先级。
## 资源
**相关最佳实践：**
+ [SEC01-BP07 使用威胁模型识别威胁并确定缓解措施的优先级](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_securely_operate_threat_model.html)
**相关文档：**
+ [AWS 云 合规性](https://aws.amazon.com/compliance/)
+ [AWS 最新安全公告](https://aws.amazon.com/security/security-bulletins/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/)
**相关视频：**
+ [AWS re:Inforce 2023 - A tool to help improve your threat modeling](https://youtu.be/CaYCsmjuiHg?si=e_CXPGqRF4WeBr1u)
# OPS01-BP06 在管理益处与风险的同时评估各种权衡因素
多方利益竞争可能会使确定工作优先级、构建能力和交付符合业务战略的成果变得具有挑战性。例如，您可能需要加快新功能的上市速度，而不是优化 IT 基础设施的成本。这可能导致两个利益相关方之间发生冲突。在这种情况下，应由更高级别的权威机构作出决定，以便解决冲突。需要使用数据来消除决策制定过程中的情感依附。
在战术层面，您可能也面临类似挑战。例如，选择使用关系数据库技术还是非关系数据库技术，可能会对应用程序的运营产生重大影响。了解各种选择的可预测结果非常重要。
AWS 有助于您就 AWS 及其服务对团队进行培训，让他们深入了解自己的选择会如何影响工作负载。使用由 [支持](https://aws.amazon.com/premiumsupport/programs/) 提供的资源（[AWS 知识中心](https://aws.amazon.com/premiumsupport/knowledge-center/)、[AWS 讨论论坛](https://forums.aws.amazon.com/index.jspa)和 [支持 中心](https://console.aws.amazon.com/support/home/)）和 [AWS 文档](https://docs.aws.amazon.com/)来培训团队。如有其他问题，请联系 支持。
AWS 还在 [Amazon Builders' Library 中分享了运营最佳实践和模式。](https://aws.amazon.com/builders-library/)您可以通过 [AWS Blog](https://aws.amazon.com/blogs/) 和 [The Official AWS Podcast](https://aws.amazon.com/podcasts/aws-podcast/)，获得各种其他有用信息。
**期望结果：**您有明确定义的决策治理框架，可以促进云交付组织内各个级别的重要决策。此框架包括风险登记单、有权作出决策的已定义角色，以及针对各级可制定之决策的已定义模型等特色内容。此框架预先定义了冲突解决方式、需要提供的数据以及选项优先级的确定方式，因此，一旦作出决策，您便能立即执行。决策制定框架包括一种标准化方法，用于审核和认真考虑每项决策的益处与风险以了解权衡。这可能包括外部因素，例如遵守法规合规性要求。
**常见反模式：**
+ 您的投资者要求您证明符合支付卡行业数据安全标准（PCI DSS）。您没有在满足他们的要求和继续进行当前的开发工作之间进行权衡，而是在没有证明合规性的情况下继续进行开发工作。投资者出于对平台安全性和投资的担忧停止了对公司的支持。
+ 您决定纳入一个库，这是您的一位开发人员在互联网上找到的库。您尚未评估从未知来源采用此库的风险，也不知道其中是否包含漏洞或恶意代码。
+ 对于迁移，最初的业务理由是实现 60% 的应用程序工作负载的现代化。但由于遇到技术难题，您决定仅实现 20% 的应用程序工作负载的现代化，这导致了长期计划收益的减少；基础设施团队的操作负担加重，需要手动支持遗留系统；并且更加依赖于培养基础设施团队的新技能组合，而团队并未对此变更做好规划。
**建立此最佳实践的好处：**充分调整和支持董事会级别的业务优先事项，了解取得成功的风险，作出明智的决策，并在风险阻碍成功时采取适当行动。了解决策的影响和后果有助于您确定选项的优先级，更快地让各个领导达成共识，从而改进业务成果。确定选择可以带来的益处并了解组织面临的风险，有助于您依据数据而不是轶事来制定决策。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
应由推动关键决策制定要求的管理机构来定义如何管理益处与风险。您需要先了解所涉风险，然后基于决策对组织的益处，制定决策，并确定其优先级。准确的信息对于制定组织决策至关重要。这应基于可靠的测量值，并由常见的成本效益分析行业惯例来定义。要制定这些类型的决策，需要在集权和分权之间取得平衡。始终要进行权衡，并且必须了解每种选择如何影响已定义的战略和期望的业务成果。
### 实施步骤
1. 在整体云治理框架内正式确定效益衡量实践。
1. 平衡决策制定的集权与某些决策的分权。
1. 要明白一点，将繁冗的决策过程强加于每个决策之上，只会拖慢您的决策速度。
1. 将外部因素纳入您的决策制定过程（例如合规性要求）。
1. 为各级决策建立一致认可的决策制定框架，包括谁负责疏解受利益冲突影响的决策。
1. 共同制定不可更改的单向门决策。
1. 允许较低级别的组织领导者制定双向门决策。
1. 了解和管理益处与风险。在决策的益处与涉及的风险之间取得平衡。
1. **确定效益：**根据业务目标、需求和优先事项来确定效益。例如业务案例影响、上市时间、安全性、可靠性、性能和成本等。
1. **确定风险：**根据业务目标、需求和优先事项来确定风险。例如上市时间、安全性、可靠性、性能和成本等。
1. **对照风险评测益处并作出明智决策：**根据包括业务、开发和运营团队在内的关键利益相关方的目标、需求和优先事项，确定益处与风险的影响。对照发生风险的可能性及其影响产生的成本，评估效益的价值。例如，强调上市速度而不是可靠性可能会带来竞争优势。但是如果出现可靠性问题，就可能会导致正常运行时间缩短。
1. 采用程序化方式执行关键决策，以便自动遵守合规性要求。
1. 利用已知的行业框架和能力，如价值流分析和精益生产，衡量当前状态的绩效和业务指标，并定义逐步改进这些指标的迭代过程。
**实施计划的工作量级别：**中高
## 资源
**相关最佳实践：**
+ [OPS01-BP05 评估威胁形势](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_priorities_eval_threat_landscape.html)
**相关文档：**
+ [亚马逊第 1 天文化的要素 \$1 做出高质量、高速的决策](https://aws.amazon.com/executive-insights/content/how-amazon-defines-and-operationalizes-a-day-1-culture/)
+ [云治理](https://aws.amazon.com/cloudops/cloud-governance/)
+ [管理和治理云环境](https://docs.aws.amazon.com/wellarchitected/latest/management-and-governance-guide/management-and-governance-cloud-environment-guide.html?did=wp_card&trk=wp_card)
+ [Governance in the Cloud and in the Digital Age: Parts One & Two](https://aws.amazon.com/blogs/enterprise-strategy/governance-in-the-cloud-and-in-the-digital-age-part-one/)
**相关视频：**
+ [Podcast \$1 Jeff Bezos \$1 On how to make decisions](https://www.youtube.com/watch?v=VFwCGECvq4I)
**相关示例：**
+ [Make informed decisions using data (The DevOps Sagas)](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/oa.bcl.10-make-informed-decisions-using-data.html)
+ [Using development value stream mapping to identify constraints to DevOps outcomes](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-devops-value-stream-mapping/introduction.html)
# 运营模式
在本部分中，我们将提供一种方法来了解您所处的运营模式，如何可视化该模式，以及在团队层面应如何发展以从云服务投资中获得最大价值。通过这样做，您可以增强运营实践，建立敏捷的团队和工作负载，并为业务成果做出积极贡献。
您的团队通常存在于多个组织层中，而这些层具有现有的工作方式。与您的团队一起实现业务成果意味着要了解您的团队在这些层中的位置、您与之互动的团队的位置以及他们的工作方式。此外，团队需要了解自己在其他团队获得成功过程中所扮演的角色、了解其他团队在他们获得成功的过程中所扮演的角色，并设定共同的目标。
这些层构成了组织的整体运营模式。组织如何运作以交付业务成果取决于许多因素，例如类型、行业、地理位置、规模和自主权水平。但是，它可能分为三大类：
+ 集中化
+ 分散式
+ 联合身份
[为成功而组织](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-cloud-operating-model/implement-roadmap.html#organize)中描述了这些组织级别的拓扑。
您的团队和工作负载存在于组织的运营模式中。然而，期望单个运营模式能够支持所有团队及其工作负载是不合理的。因此，您的团队还需要自己的运营模式。这种工作方式是由您的组织、部门、团队的组成以及工作负载本身的特征决定的。
大多数迁移到云的组织都是在企业转型计划中实现该目的的，该计划旨在开启新的工作方式（运营模式），以支持长期战略目标。这段旅程不是一个时间点练习，而是一个需要不断演变和逐步朝着实现战略目标迈进的过程。这使工作负载所有者能够适应不断变化的运营模式，将中断降至最低。
亚马逊经常被用作示例，说明大型组织如何通过助力团队成员与客户保持亲密关系、快速推出创新产品和服务以及利用支持速度和敏捷性的技术架构来实现大规模创新。这要求我们重组团队（现在被称为*双披萨*团队）的组织方式，双披萨团队中嵌入了所有合适的资源（工程、测试、产品和项目管理以及运营），可以端到端地拥有和运行工作负载。
我们建议努力采用这种运营模式，以此作为工作负载团队快速行动并为整体业务成果做出贡献、为客户提供最佳服务的一种行之有效的方法。
想要效仿这一成功的组织可能需要在整个转型过程中调整其运营模式。在组织和团队层面，这都需要考虑、计划和沟通。以下部分提供了一种方法来可视化这些团队级别的运营模式，以及它们如何演变为*谁构建，谁运行*。
# 运营模式 2:2 展示图
这些运营模式 2:2 展示图可帮助您了解您环境中的团队之间的关系。这些图表着重说明成员的职责以及团队之间的关系，但我们也将通过这些示例讨论治理和做出决策。
您的团队可能需要在多个模式的多个部分承担责任，具体取决于他们支持的工作负载。您可能希望打破比所描述的高级规范更专业的规范。当您分离或汇总活动，或叠加团队并提供更具体的细节时，这些模式可能会出现无穷无尽的变化。
您可能发现团队中存在重叠或未被认可的能力，这些能力可以提供额外优势或提高效率。您可能还发现您可以计划解决的组织中未满足的需求。
在评估组织变革时，请检查模式之间的权衡，您的各个团队采用的模式（现在和变革之后），您的团队的关系和职责将如何变化，以及所获得的益处是否抵得过对您的组织产生的影响。
您可以成功使用以下四种运营模式。某些模式更适合于特定使用案例或您的开发中的特定点。其中一些模式可能比在您的环境中使用的模式更具优势。
**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/zh_cn/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/zh_cn/wellarchitected/latest/operational-excellence-pillar/images/devops-msp.en.png)
对于这一变体，我们将治理视为由平台团队集中管理，并使用 AWS Organizations 和 AWS Control Tower 管理账户创建和策略。
此模式需要您修改自身机制，以便使用服务提供商的机制。它不能解决由于团队（包括您的服务提供商）之间的任务转换所造成的瓶颈和延迟，也无法解决由于发现缺陷较晚而存在的潜在返工。
提供商的标准、最佳实践、流程和专业知识将让您受益良多。此外，他们还会不断开发服务产品，您也会从中获益。
将托管服务添加到您的运营模式可以节省您的时间和资源，并使您的内部团队保持精干，专注于凸显业务优势的战略成果，而不是开发新的技能和功能。它还可以让您有时间构建和完善自己的平台功能，而不会减慢云迁移计划的速度。
# 云运维和平台支持（COPE）
这种云运营和平台支持（COPE）模型旨在通过支持应用程序团队为其工作负载执行工程和运营活动，采用 DevOps 文化，建立一种*谁构建，谁运行*的方法。
您的应用程序团队可能负责迁移、采用云或实现工作负载现代化，但现有技能可能无法充分支持云架构和运营。缺乏应用程序团队能力和熟悉度可能会减慢组织的敏捷性并影响业务成果。
要解决这个问题，请利用组织内部现有的运营专业知识来支持应用程序团队的云运营之旅。这可以是一个由专家组成的专门团队，也可以是一个虚拟团队，其参与者是从整个组织中挑选出来的。但是，目标保持不变，即提供运营支持，以增强工作负载团队的能力，使用云优先的自动化原则，消除无差别繁重工作，提供标准化模式并促进自主权。其目标是在云功能方面建立足够的成熟度，降低运营责任的门槛，从而使应用程序团队不再需要额外的支持。
COPE 模型侧重于工作负载级别。如果多个团队同时需要这种方法，如果您将执行为期多年的复杂大规模迁移项目，或者您将构建平台来支持这些计划，请考虑使用云卓越中心（CCoE）。许多人在寻求加快向云的迁移并广泛实现组织转型时都发现了一种成功的机制。
![\[云运维和平台支持（COPE）计划\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/operational-excellence-pillar/images/cope.en.png)
您的平台工程团队构建了一层薄薄的核心共享平台功能，这些功能基于供应用程序团队采用的预定义标准，由 COPE 团队提供。平台工程团队编纂了通过自助机制提供给应用程序团队的企业参考架构和模式。使用诸如 AWS Service Catalog 之类的服务，应用程序团队可以部署经批准的参考架构、模式、服务和配置，这些架构在默认情况下符合集中式治理和安全标准。
平台工程设计团队还为应用程序团队提供一套标准化的服务（例如，开发工具、可观测性工具、备份和恢复工具以及网络）。
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/zh_cn/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/zh_cn/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/zh_cn/wellarchitected/latest/operational-excellence-pillar/images/evolving-ops.en.png)
在评估团队如何支持组织变革时，请检查模式之间的权衡，您的各个团队在模式（随着模式的改变和发展）中的位置，您的团队的关系和职责可能如何变化，以及所获得的益处是否抵得过对您的组织产生的影响。请记住，变化从来都不是线性的。有些模式更适合特定的用例或旅程中的点，其中一些模式可能比环境中的模式更具优势。
# 关系和所有权
您的运营模式定义了团队之间的关系，并为可识别的所有权和责任提供支持。
**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)
# 组织文化
为您的团队成员提供支持，以便他们可以更有效地*采取行动并为您的业务成果提供支持*。
**Topics**
+ [OPS03-BP01 提供高管支持](ops_org_culture_executive_sponsor.md)
+ [OPS03-BP02 赋能团队成员在结果有风险时采取行动](ops_org_culture_team_emp_take_action.md)
+ [OPS03-BP03 鼓励上报](ops_org_culture_team_enc_escalation.md)
+ [OPS03-BP04 沟通及时、清晰、可行](ops_org_culture_effective_comms.md)
+ [OPS03-BP05 鼓励试验](ops_org_culture_team_enc_experiment.md)
+ [OPS03-BP06 鼓励团队成员保持和增强自己的技能组合](ops_org_culture_team_enc_learn.md)
+ [OPS03-BP07 为团队配置适当的资源](ops_org_culture_team_res_appro.md)
# OPS03-BP01 提供高管支持
在最高层面，高层领导作为执行发起人，为组织的成果明确设定期望和方向，包括评估成果成功与否。发起人倡导并推动最佳实践的采用和组织的发展壮大。
**期望结果：**致力于采用、转型和优化云运营的组织，为实现期望结果建立了明确的领导和责任界限。组织了解实现新成果所需的每项能力，并授权职能团队针对相关能力进行培养。领导层要积极确定这一方向、分配所有权、承担责任并界定工作。因此，整个组织中的每个人都能动员起来，受到鼓舞，并积极努力实现预期目标。
**常见反模式：**
+ 工作负载所有者有义务将工作负载迁移到 AWS，但却没有明确的发起人和云运营计划。这就导致团队不能有意识地开展合作，提高业务能力并使之成熟。缺乏运营最佳实践标准会让团队不堪重负（例如操作员疲劳、随时待命和技术债务），从而限制创新能力。
+ 在没有领导层发起人和策略的情况下，就在整个组织范围内设定了采用某种新兴技术的新目标。各团队对目标的理解各不相同，这导致在工作重点、目标为何重要以及如何衡量影响等方面造成了混乱。因此，组织会失去采用该技术的动力。
**建立此最佳实践的好处：**当高管清楚地传达并分享愿景、方向和目标时，团队成员就会知道对他们的期望。当领导者积极参与时，个人和团队就会开始集中精力朝着同一个方向努力，完成既定目标。因此，组织最大限度地提高了获得成功的能力。评估成功时，可以更好地发现成功之路上的障碍，以便通过执行发起人的干预来克服这些障碍。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
+ 在云之旅的每个阶段（迁移、采用或优化），成功都需要最高领导层的积极参与，并指定一名执行发起人。执行发起人能够让团队的思维方式、技能组合和工作方法与既定策略保持一致。
+ **解释*原因*：**阐明并解释愿景和策略背后的原因。
+ **设定期望：**为组织定义和发布目标，包括如何衡量进展和成功。
+ **跟踪目标的实现情况：**定期衡量目标的逐步实现情况（而不仅仅是任务的完成情况）。分享结果，以便在结果面临风险时可以采取适当的行动。
+ **提供实现目标所需的资源：**让人员和团队齐心协力，制定正确的解决方案，实现既定结果。这可以减少乃至消除组织内部的摩擦。
+ **为团队提供支持：**与团队保持互动，以便了解他们的表现以及是否有外部因素影响他们。确定阻碍团队进度的障碍。代表团队采取行动，帮助消除障碍，除去不必要的负担。团队受外部因素影响时，需重新评估目标并适当地调整执行性目标。
+ **推动最佳实践的采用：**认可可量化收益的最佳实践以及创建者和采用者。鼓励进一步采用，实现更大收益。
+ **鼓励团队的发展：**营造持续改进的文化，主动从进步和失败中吸取教训。鼓励个人和组织的成长与发展。利用数据和轶事来发展愿景和策略。
**客户示例**
AnyCompany Retail 正在通过快速重塑客户体验、提高生产力，以及利用生成式人工智能加速增长，来实现业务转型。
### 实施步骤
1. 建立单线程领导层，指派一名主要执行发起人来领导和推动转型。
1. 明确转型的业务成果，分配所有权和责任。赋予主要执行人领导和作出关键决策的权力。
1. 确认转型策略非常明晰，并由执行发起人广泛传达至组织的每一个层级。
1. 为 IT 和云计划明确制定业务目标。
1. 记录关键业务指标，推动 IT 和云转型。
1. 向负责策略各个部分的所有团队和个人持续传达愿景。
1. 制定沟通规划矩阵，明确需要向特定的领导、管理人员和个人贡献者传递哪些信息。指定应传递此信息的人员或团队。
1. 持续可靠地完成沟通计划。
1. 通过定期的面对面活动来设定和管理期望值。
1. 接受有关沟通效果的反馈，并相应地调整沟通和计划。
1. 安排沟通活动，主动了解各个团队提出的挑战，并建立持续的反馈环路，以便在必要时纠正方向。
1. 从领导层的角度积极参与每项计划，以便确认所有受影响的团队是否都了解他们负责实现的成果。
1. 在每次状态会议上，执行发起人都应寻找阻碍因素，检查既定指标、轶事或团队反馈，并衡量实现目标的进展情况。
**实施计划的工作量级别：**中
## 资源
**相关最佳实践：**
+ [OPS03-BP04 沟通及时、清晰、可行](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_effective_comms.html)
+ [OP11-BP01 设置持续改进流程](wellarchitected/latest/operational-excellence-pillar/evolve/learn_share_and_improve/ops_evolve_ops_process_cont_imp.html)
+ [OPS11-BP07 审查运营指标](wellarchitected/latest/operational-excellence-pillar/evolve/learn_share_and_improve/ops_evolve_ops_metrics_review.html)
**相关文档：**
+ [Untangling Your Organisational Hairball: Highly Aligned](https://aws.amazon.com/blogs/enterprise-strategy/untangling-your-organisational-hairball-highly-aligned/)
+ [The Living Transformation: Pragmatically approaching changes](https://aws.amazon.com/blogs/enterprise-strategy/the-living-transformation-pragmatically-approaching-changes/)
+ [Becoming a Future-Ready Enterprise](https://aws.amazon.com/blogs/enterprise-strategy/becoming-a-future-ready-enterprise/)
+ [7 Pitfalls to Avoid When Building a CCOE](https://aws.amazon.com/blogs/enterprise-strategy/7-pitfalls-to-avoid-when-building-a-ccoe/)
+ [Navigating the Cloud: Key Performance Indicators for Success](https://aws.amazon.com/blogs/enterprise-strategy/navigating-the-cloud-key-performance-indicators-for-success/)
**相关视频：**
+ [AWS re:Invent 2023: A leader's guide to generative AI: Using history to shape the future (SEG204)](https://youtu.be/e3snrDsct1o)
**相关示例：**
+ [Prosci: Primary Sponsor's Role & Importance](https://www.prosci.com/blog/primary-sponsors-role-and-importance)
# OPS03-BP02 赋能团队成员在结果有风险时采取行动
由领导层灌输的主人翁文化行为，会让任何员工感到自己有能力代表整个公司行事，超越为其规定的职责和责任范围。员工可以在风险出现时主动识别风险并采取适当行动。这样的文化能够让员工在了解情况的前提下，作出高价值的决策。
例如，亚马逊使用[领导力原则](https://www.amazon.jobs/content/en/our-workplace/leadership-principles)作为准则，推动员工实现在各种情况下前进、解决问题、处理冲突和采取行动等期望行为。
**期望结果：**在领导力的影响下产生了一种新文化，这种文化支持个人和团队作出关键决策，即使在组织的较低层级也是如此（只要决策是用可审计的权限和安全机制定义的）。失败并不可怕，团队会不断学习，改进决策和响应措施，从而应对今后出现的类似情况。如果某个人的行动带来了改进，能让其他团队受益，这些团队就会主动分享从这些行动中获得的知识。领导层衡量运营改进情况，并激励个人和组织采用此类模式。
**常见反模式：**
+ 组织内没有明确的指导或机制来说明在发现风险时该怎么做。例如，当员工发现网络钓鱼攻击时，他们没有向安全团队报告，导致组织中的大部分人遭受攻击。这会造成数据泄露。
+ 客户抱怨服务不可用，主要原因是部署失败。SRE 团队负责部署工具，而他们的长期路线图中包括自动回滚部署。在最近一次的应用程序推广中，一位工程师设计了一种解决方案，可以自动将应用程序回滚到以前的版本。虽然他们的解决方案可以成为 SRE 团队采用的模式，但其他团队并不采用，因为没有流程能跟踪此类改进。组织继续受到部署失败的困扰，这影响了客户，造成了更多负面情绪。
+ 为了保持合规性，信息安全团队会监督一个长期建立的流程，代表连接到 Amazon EC2 Linux 实例的操作员定期轮换共享的 SSH 密钥。信息安全团队需要花几天的时间才能完成密钥的轮换，并且您将无法连接到这些实例。信息安全团队内部和外部的任何人都不建议使用 AWS 上的其他选项来实现相同的结果。
**建立此最佳实践的好处：**通过下放决策权并授权团队决定关键决策，您可以更快地解决问题，并提高成功率。此外，团队开始具有主人翁意识，并意识到失败是可以接受的。实验成为一种文化主流。经理和主管不会觉得他们在工作的各个方面都受到微观管理。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
1. 培养一种会预见失败的文化。
1. 明确规定组织内各职能领域的所有权和责任。
1. 向每个人传达所有权和问责制，让大家都知道谁能帮助他们促进分散决策。
1. 定义单向门决策和双向门决策，让个人了解何时确实需要上报给更高级别的领导。
1. 树立组织意识，让所有员工都有能力在结果面临风险时，从各个层级采取行动。为团队成员提供治理文件、权限级别、工具以及机会，让团队成员练习有效应对所需的技能。
1. 为团队成员提供机会，练习应对各种决策所需的技能。一旦确定了决策级别，就应开展 GameDay 活动，确保所有参与人员都能理解并演示流程。
1. 提供替代的安全环境，以便在其中对流程和程序进行测试和培训。
1. 承认并让团队成员认识到，当结果达到预先定义的风险水平时，他们有权采取行动。
1. 通过为团队成员所支持的工作负载和组件分配权限和访问权限，定义团队成员的行动权限。
1. 让团队能够分享他们的经验教训（运营方面的成功和失败经验教训）。
1. 授权团队挑战现状，并建立一些机制，让团队跟踪和衡量改进情况及其对组织的影响。
**实施计划的工作量级别：**中
## 资源
**相关最佳实践：**
+ [OPS01-BP06 在管理益处与风险的同时评估各种权衡因素](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_priorities_eval_tradeoffs.html)
+ [OPS02-BP05 制定用于确定责任和所有权的机制](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_req_add_chg_exception.html)
**相关文档：**
+ [AWS Blog 文章 \$1 The agile enterprise](https://aws.amazon.com/blogs/enterprise-strategy/the-agile-enterprise/)
+ [AWS Blog 文章 \$1 Measuring success : A paradox and a plan](https://aws.amazon.com/blogs/enterprise-strategy/measuring-success-a-paradox-and-a-plan/)
+ [AWS Blog 文章 \$1 Letting go : Enabling autonomy in teams](https://aws.amazon.com/blogs/enterprise-strategy/letting-go-enabling-autonomy-in-teams/)
+ [Centralize or Decentralize?](https://aws.amazon.com/blogs/enterprise-strategy/centralize-or-decentralize/)
**相关视频：**
+ [re:Invent 2023 \$1 How to not sabotage your transformation (SEG201)](https://www.youtube.com/watch?v=heLvxK5N8Aw)
+ [re:Invent 2021 \$1 Amazon Builders' Library: Operational Excellence at Amazon](https://www.youtube.com/watch?v=7MrD4VSLC_w)
+ [Centralization vs. Decentralization](https://youtu.be/jviFsd4hhfE?si=fjt8avVAYxA9jF01)
**相关示例：**
+ [Using architectural decision records to streamline technical decision-making for a software development project](https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/welcome.html)
# OPS03-BP03 鼓励上报
领导层鼓励团队成员在认为期望结果面临风险和预期标准未得到满足时，将问题和疑虑上报给更高层级的决策者和利益相关方。这是组织文化的一个特点，并在各个层面得到推动。应经常尽早上报，以便能够确定风险，并防止造成意外事件。领导层不会训斥上报问题的个人。
**期望结果：**整个组织中的个人都乐于将问题上报给直属和更高级别的领导层。领导层刻意并有意识地建立期望，让他们的团队可以毫无顾虑地上报任何问题。在组织内部的每个层级，制定上报问题的机制。当员工将问题上报给经理时，他们共同决定问题的影响程度以及是否应该上报。要启动上报程序，员工需要提交一份解决问题的建议工作计划。如果直属管理层没有及时采取行动，而员工强烈认为组织面临的风险需要上报，则组织鼓励员工将问题上报至最高领导层。
**常见反模式：**
+ 在云转型项目状态会议上，执行领导没有提出足够多的探究性问题来发现问题和阻碍因素。大家都报喜不报忧。首席信息官明确表示，她只喜欢听到好消息，因为提出的任何挑战都会让首席执行官认为项目会失败。
+ 您是一名云运营工程师，您注意到应用程序团队并未广泛采用新的知识管理系统。公司花了一年时间并投资了数百万美元，实施这一新的知识管理系统，但人们仍在本地编写运行手册，并在组织云共享上共享这些手册，因此很难找到与支持的工作负载相关的知识。您努力让领导层注意到这一点，因为坚持使用这一系统可以提高运营效率。当您向负责实施知识管理系统的主管提出这个问题时，她斥责了您，因为这会让投资受到质疑。
+ 负责强化计算资源的信息安全团队决定实施一项流程，要求在计算团队发布资源以供使用之前，进行必要的扫描，确保 EC2 实例完全安全。这导致资源的部署时间又延迟了一周，违反了他们的 SLA。计算团队不敢将此事上报给负责云事项的副总裁，因为这会让信息安全副总裁难堪。
**建立此最佳实践的好处：**
对于复杂问题或关键问题，在其对业务产生影响之前就加以解决。减少时间浪费。大幅降低风险。团队在解决问题时会更加积极主动，更加注重结果。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
组织各个层级中的自由上报意愿和能力是一种组织和文化基础，应通过强调培训、领导层沟通、期望设定，以及在整个组织的各个层面部署机制，有意识地加以培养。
### 实施步骤
1. 制定组织的政策、标准和期望。
1. 确保政策、期望和标准得到广泛采纳和理解。
1. 鼓励、培训工作人员，并赋予他们权力，以便在不符合标准时他们会尽早、频繁地上报。
1. 从组织的角度确认，及早和频繁上报是最佳实践。接受上报的内容最终可能证明并无依据，但最好要抓住机会预防意外事件的发生，而不要因为没有上报而错失机会。
1. 建立上报机制（比如 Andon Cord 系统）。
1. 制定成文的程序，规定何时以及如何上报。
1. 确定一系列有各级权力来采取或批准行动的人员，以及每个利益相关方的联系信息。
1. 当上报发生时，应有始有终，直到团队成员认为领导层推动的行动可以充分降低风险，并对结果满意。
1. 上报内容应包括：
1. 情况描述和风险性质
1. 情况的严重性
1. 受影响的人或事
1. 影响有多大
1. 发生影响时的紧迫性
1. 建议的补救措施和减轻影响的计划
1. 保护上报的员工。制定政策来保护团队成员，如果他们上报关于决策者或利益相关方未做出响应的问题，保护他们免遭报复。制定适当的机制，确定是否发生了这种情况并适当响应。
1. 鼓励在组织的所有事项中建立持续改进的反馈环路文化。反馈环路起到向责任人进行小规模上报的作用，即使不需要上报，也能发现改进机会。持续改进的文化促使每个人更加积极主动。
1. 领导层应定期重新强调政策、标准、机制，以及公开上报和持续反馈环路而不受到报复的期望。
**实施计划的工作量级别：**中
## 资源
**相关最佳实践：**
+ [OPS02-BP05 制定用于请求添加、更改和例外的机制](ops_ops_model_req_add_chg_exception.md)
**相关文档：**
+ [How do you foster a culture of continuous improvement and learning from Andon and escalation systems?](https://www.linkedin.com/advice/0/how-do-you-foster-culture-continuous-improvement-7054190310033145857)
+ [The Andon Cord (IT Revolution)](https://itrevolution.com/articles/kata/)
+ [AWS DevOps Guidance \$1 Establish clear escalation paths and encourage constructive disagreement](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/oa.bcl.5-establish-clear-escalation-paths-and-encourage-constructive-disagreement.html)
**相关视频：**
+ [Jeff Bezos on how to make decisions (& increase velocity)](https://www.youtube.com/watch?v=VFwCGECvq4I)
+ [Toyota Product System: Stopping Production, a Button, and an Andon Electric Board](https://youtu.be/TUKpxjAftnk?si=qohtCCX0q78GDzJu)
+ [Andon Cord in LEAN Manufacturing](https://youtu.be/HshopyQk720?si=1XJkpCSqJSpk_zE6)
**相关示例：**
+ [Working with escalation plans in Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/escalation.html)
# OPS03-BP04 沟通及时、清晰、可行
领导层有责任建立强有力的有效沟通，尤其是在组织采用新策略、新技术或新工作方式时。领导者应为所有员工设定期望，让他们为实现公司目标而努力。设计沟通机制，在负责实施由领导层资助和赞助的计划的团队中，树立和保持意识。利用跨组织的多样性，认真倾听多种独特观点。利用这种见解提高创新能力、对您的假设提出质疑，并降低确认偏差的风险。培养团队的包容性、多样性和可达性，以便获得有益的观点。
**期望结果：**组织设计沟通策略来应对变更对组织的影响。团队保持信息畅通，有动力继续相互合作，而不是相互竞争。个人明白自己的职责对于实现既定目标有多么重要。电子邮件只是一种被动的通信机制，因此要合理使用。管理层花时间与个人贡献者沟通，帮助他们了解自己的责任、要完成的任务，以及他们的工作如何为整体使命做出贡献。必要时，领导者在规模较小的场合直接与员工接触，传达信息并核实这些信息是否得到有效传达。由于沟通策略良好，组织的表现达到或超过领导层的期望。领导层鼓励并征求团队内部和团队之间的不同意见。
**常见反模式：**
+ 组织有一个五年计划，要将所有工作负载迁移到 AWS。云业务案例包括对 25% 的工作负载进行现代化改造，以便利用无服务器技术。首席信息官将这一策略传达给直接下属，并希望每位领导者将这一策略传达给经理、总监和个人贡献者，而无需进行任何面对面的沟通。首席信息官退居幕后，期望组织能够执行新策略。
+ 领导层不提供或不使用反馈机制，期望差距变得越来越大，从而导致项目停滞不前。
+ 有人要求您对安全组进行更改，但却没有告诉您详细信息，例如需要进行哪些更改，更改会对所有工作负载产生什么影响，以及何时进行更改等。经理转发了一封来自信息安全副总裁的电子邮件，并添加了“实现此目标”的信息。
+ 迁移策略发生了变化，计划的现代化改造数量从 25% 减少到 10%。这会对运营组织的下游产生影响。下游组织未被告知这一策略变化，因此没有足够的技术能力协助将更多的工作负载直接迁移到 AWS。
**建立此最佳实践的好处：**
+ 组织对新策略或更改后的策略了如指掌，他们会积极采取相应行动，协助彼此实现领导层设定的总体目标和指标。
+ 制定相应机制，用于将已知风险和计划内事件及时通知给团队成员。
+ 新的工作方式（包括人员、组织、流程或技术的变化）以及所需的技能会更有效地为组织所采用，因此组织能更快地实现业务效益。
+ 团队成员可以了解所接收信息的必要背景，从而更有效地开展工作。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
为实施这种最佳实践，必须与整个组织的利益相关方合作，商定沟通标准。向组织公布这些标准。对于任何重大的 IT 过渡，与忽视这一做法的组织相比，一个成熟的规划团队能够更成功地管理更改对员工的影响。规模较大的组织在管理更改时可能更具挑战性，因为要让所有个人贡献者对新策略产生强烈的认同感，这一点至关重要。如果缺乏这样的过渡规划团队，就需要领导层对有效沟通全权负责。在建立过渡规划团队时，指派团队成员与所有组织领导层合作，以便规定和管理各个层级的有效沟通。
**客户示例**
AnyCompany Retail 注册了 AWS Enterprise Support，并依赖其他第三方提供商进行云运营。该公司将聊天和 ChatOps 工具作为运营活动的主要沟通媒介。警报和其他信息会填入特定渠道。当有人必须采取行动时，他们会清楚地说明期望结果，而且在很多情况下，他们会收到一份运行手册或行动手册以供使用。他们借助变更日历来安排生产系统的重大更改。
### 实施步骤
1. 在组织内建立一个核心团队，负责为组织内多个层级的更改制定和启动沟通计划。
1. 建立单线程所有权，以便实现监督。赋予各个团队独立创新的能力，并平衡使用一致的机制，从而实现适当程度的检查和方向性愿景。
1. 与整个组织的利益相关方合作，就沟通标准、实践和计划达成一致。
1. 确认核心沟通团队是否与组织和项目领导层合作，代表领导者向相关人员传达信息。
1. 建立策略沟通机制，通过公告、共享日历、全体员工会议、面对面或一对一的方式管理更改，让团队成员对自己应采取的行动有正确的预期。
1. 提供必要的背景、详细信息和时间（如有可能），以便确定是否有必要采取行动。需要采取行动时，提供所需的行动及其影响。
1. 实施促进战术沟通的工具，例如内部聊天、电子邮件和知识管理。
1. 实施各种机制，以便衡量和确认所有沟通活动是否都取得了期望结果。
1. 建立反馈环路来衡量所有沟通的效果，尤其是当沟通涉及到整个组织对更改的抵触时。
1. 对于所有 AWS 账户，请为账单、安全性和运营创建[备用联系人](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact-alternate.html)。理想情况下，每个联系人都应是电子邮件分发的收件人，而不是特定的个人联系人。
1. 制定上报和逆向上报沟通计划，与内部团队和外部团队（包括 AWS Support 和其他第三方提供商）进行沟通。
1. 在每个转型计划的整个生命周期内，始终如一地启动和执行沟通策略。
1. 优先考虑可重复执行的行动，尽可能安全地实现大规模自动化。
1. 当需要在自动化操作的场景中进行沟通时，沟通目的应该是通知团队、进行审核或作为变更管理流程的一部分。
1. 分析来自警报系统的通信，判断误报或不断生成的警报。删除或更改这些警报，以便在需要人工干预时启动。如果启动了警报，则提供运行手册或行动手册。
1. 您可以使用 [AWS Systems Manager 文档](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-ssm-docs.html)为警报制定行动手册和运行手册。
1. 制定合理的机制，以清晰、可操作的方式提供风险或计划内事件的通知，而且要引起足够的注意，以便适当响应。使用电子邮件列表或聊天频道在计划内事件之前发送通知。
1. [AWS Chatbot](https://docs.aws.amazon.com/chatbot/latest/adminguide/what-is.html) 可用于发送警报并响应组织消息平台中的事件。
1. 提供可访问的信息源，其中包含计划内事件。通知来自同一系统的计划内事件。
1. 发生更改时，可使用 [AWS Systems Manager Change Calendar](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-change-calendar.html) 来创建变更窗口。因而在团队成员可以安全地进行变更时，向他们发送通知。
1. 监控漏洞通知和补丁程序信息，了解外部漏洞以及与工作负载组件相关的潜在风险。向团队成员发送通知，以便他们可以采取行动。
1. 您可以订阅 [AWS 安全公告](https://aws.amazon.com/security/security-bulletins/)，以便接收有关 AWS 漏洞的通知。
1. **寻求不同的意见和观点：**鼓励所有人做出贡献。为代表性不足的群体提供沟通机会。在会议中轮换职责和责任。
1. **扩大职责和责任：**让团队成员有机会尝试他们可能不会担任的角色。他们可以从职责以及与其他团队成员的互动中获得经验和见解，而之前可能并没有机会与这些成员互动。他们还可以将自己的经验和见解赋予新角色，以及就此与新团队成员沟通交流。随着见解不断增多，需要确定新出现的业务机会或新的改进机会。在团队成员之间轮流执行其他人通常执行的日常任务，了解执行这些任务的需求和影响。
1. **提供安全舒适的环境：**制定政策和控制措施，保护组织内团队成员的身心安全。团队成员应该能够彼此敞开心扉，而不是处在会受到报复的担惊受怕之中。当团队成员处于安全舒适的环境中时，才能有更高的参与热情、更高的工作成效。组织越多元化，就越能更好地理解所支持的人，包括客户。当团队成员感到舒服自在、能够畅所欲言并确信自己的意见会被听取时，他们会更愿意分享有价值的洞察（例如营销机会、可访问性需求、尚待开发的细分市场以及环境中未发现的风险）。
1. **鼓励团队成员充分参与：**为员工提供必要的资源，让他们充分参与到所有与工作相关的活动中。团队成员每天都要面对挑战，他们需要掌握应对挑战的技能。这些独特发展的技能可以为组织带来巨大的效益。为团队成员提供必要的后勤保障，让他们的贡献带来更多的效益。
## 资源
**相关最佳实践：**
+ [OPS03-BP01 提供高管支持](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_executive_sponsor.html)
+ [OPS07-BP03 使用运行手册执行程序](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_runbooks.html)
+ [OPS07-BP04 根据行动手册调查问题](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_playbooks.html)
**相关文档：**
+ [AWS Blog 文章 \$1 Accountability and empowerment are key to high-performing agile organizations](https://aws.amazon.com/blogs/enterprise-strategy/two-pizza-teams-are-just-the-start-accountability-and-empowerment-are-key-to-high-performing-agile-organizations-part-2/)
+ [AWS Executive Insights \$1 学会扩大创新规模，而不是增加复杂性 \$1 单线程领导者](https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team/#Single-Threaded_Leaders)
+ [AWS 安全公告](https://aws.amazon.com/security/security-bulletins)
+ [OpenCVE](https://www.opencve.io/welcome)
+ [支持 App in Slack to Manage Support Cases](https://aws.amazon.com/blogs/aws/new-aws-support-app-in-slack-to-manage-support-cases/)
+ [Manage AWS resources in your Slack channels with Amazon Q Developer in chat applications](https://aws.amazon.com/blogs/mt/manage-aws-resources-in-your-slack-channels-with-aws-chatbot/)
**相关服务：**
+ [聊天应用程序中的 Amazon Q 开发者版](https://docs.aws.amazon.com/chatbot/latest/adminguide/what-is.html)
+ [AWS Systems Manager Change Calendar](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-change-calendar.html)
+ [AWS Systems Manager 文档](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-ssm-docs.html)
# OPS03-BP05 鼓励试验
试验是将新想法转化为产品和功能的催化剂。它可以加快学习速度，让团队成员保持兴趣和参与热情。鼓励团队成员经常试验，以便推动创新。即使出现了不希望看到的结果，知道什么不该做也是有价值的。团队成员不会因为试验成功但结果不理想而受到惩罚。
**期望结果：**
+ 组织鼓励试验来促进创新。
+ 将试验当作学习的机会。
**常见反模式：**
+ 想要运行 A/B 测试，但没有运行试验的机制。部署了 UI 更改，但无法对其进行测试。这会造成负面的客户体验。
+ 公司只有一个模拟和生产环境。没有沙盒环境来试验新功能或产品，因此必须在生产环境中进行试验。
**建立此最佳实践的好处：**
+ 试验推动创新。
+ 通过试验，可以更快地对用户的反馈作出反应。
+ 组织培养了一种学习文化。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
试验应以安全的方式进行。利用多个环境来试验，而不危及生产资源。使用 A/B 测试和功能标记来测试试验。让团队成员能够在沙盒环境中进行试验。
**客户示例**
AnyCompany Retail 鼓励试验。团队成员可以每周使用 20% 的工作时间来试验或学习新技术。他们有可以实现创新的沙盒环境。为新功能使用 A/B 测试，用真实的用户反馈进行验证。
**实施步骤**
1. 与整个组织的领导层合作来支持试验。应鼓励团队成员以安全的方式进行试验。
1. 为团队成员提供可以安全进行试验的环境。他们必须能够访问类似于生产的环境。
1. 您可以使用单独的 AWS 账户 来创建用于试验的沙盒环境。[AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) 可用于预置这些账户。
1. 使用功能标记和 A/B 测试安全地试验和收集用户反馈。
1. [AWS AppConfig Feature Flags](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html) 可创建功能标记。
1. 您可以使用 [AWS Lambda 版本](https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html)部署函数的新版本来进行测试版测试。
**实施计划的工作量级别：**高。为团队成员提供试验环境和进行试验的安全方法需要大量投资。可能还需要修改应用程序代码来使用功能标记或支持 A/B 测试。
## 资源
**相关最佳实践：**
+ [OPS11-BP02 在意外事件发生后执行分析](ops_evolve_ops_perform_rca_process.md) – 从意外事件中吸取教训是创新和试验的重要驱动因素。
+ [OPS11-BP03 实施反馈环路](ops_evolve_ops_feedback_loops.md) – 反馈环路是试验的重要组成部分。
**相关文档：**
+ [An Inside Look at the Amazon Culture: Experimentation, Failure, and Customer Obsession](https://aws.amazon.com/blogs/industries/an-inside-look-at-the-amazon-culture-experimentation-failure-and-customer-obsession/)
+ [Best practices for creating and managing sandbox accounts in AWS](https://aws.amazon.com/blogs/mt/best-practices-creating-managing-sandbox-accounts-aws/)
+ [Create a Culture of Experimentation Enabled by the Cloud](https://aws.amazon.com/blogs/enterprise-strategy/create-a-culture-of-experimentation-enabled-by-the-cloud/)
+ [Enabling experimentation and innovation in the cloud at SulAmérica Seguros](https://aws.amazon.com/blogs/mt/enabling-experimentation-and-innovation-in-the-cloud-at-sulamerica-seguros/)
+ [Experiment More, Fail Less](https://aws.amazon.com/blogs/enterprise-strategy/experiment-more-fail-less/)
+ [Organizing Your AWS Environment Using Multiple Accounts - Sandbox OU](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/sandbox-ou.html)
+ [Using AWS AppConfig Feature Flags](https://aws.amazon.com/blogs/mt/using-aws-appconfig-feature-flags/)
**相关视频：**
+ [AWS On Air ft. Amazon CloudWatch Evidently \$1 AWS Events](https://www.youtube.com/watch?v=ydX7lRNKAOo)
+ [AWS On Air San Fran Summit 2022 ft. AWS AppConfig Feature Flags integration with Jira](https://www.youtube.com/watch?v=miAkZPtjqHg)
+ [AWS re:Invent 2022 - A deployment is not a release: Control your launches w/feature flags (BOA305-R)](https://www.youtube.com/watch?v=uouw9QxVrE8)
+ [Programmatically Create an AWS 账户 with AWS Control Tower](https://www.youtube.com/watch?v=LxxQTPdSFgw)
+ [为 AWS Organizations 设置使用最佳实践的多账户 AWS 环境](https://www.youtube.com/watch?v=uOrq8ZUuaAQ)
**相关示例：**
+ [AWS 创新沙盒](https://aws.amazon.com/solutions/implementations/aws-innovation-sandbox/)
+ [End-to-end Personalization 101 for E-Commerce](https://catalog.workshops.aws/personalize-101-ecommerce/en-US/labs/ab-testing)
**相关服务：**
+ [Amazon CloudWatch Evidently](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Evidently.html)
+ [AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html)
+ [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)
# OPS03-BP06 鼓励团队成员保持和增强自己的技能组合
团队必须增强自己的技能组合，以便采用新技术；并随需求和责任的变化继续提供支持，从而支持工作负载。新技术技能的增强通常能提升团队成员满意度并支持创新。支持团队成员获取和维持行业认证，以便验证和认可他们不断增强的技能。进行交叉培训，促进知识转移并降低失去熟练掌握机构知识、经验丰富的团队成员时，产生重大影响的风险。专门安排时间进行学习。
AWS 提供资源，包括 [AWS 入门资源中心](https://aws.amazon.com/getting-started/)、[AWS Blog](https://aws.amazon.com/blogs/)、[AWS 在线技术讲座](https://aws.amazon.com/getting-started/)、[AWS 活动和网络研讨会](https://aws.amazon.com/events/)和 [AWS Well-Architected Lab](https://wellarchitectedlabs.com/)，这些资源提供了培训团队所需的指导、示例和详细演练。
[支持](https://aws.amazon.com/premiumsupport/programs/)（[AWS re:Post](https://repost.aws/)、[支持 中心](https://console.aws.amazon.com/support/home/)）和 [AWS 文档](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)等资源有助于消除技术障碍并改善运营。请通过 支持 中心联系 支持，协助解决问题。
AWS 还在 [Amazon Builders' Library](https://aws.amazon.com/builders-library/) 中分享了我们通过 AWS 运营学到的最佳实践和模式，并通过 [AWS Blog](https://aws.amazon.com/blogs/) 和 [The Official AWS Podcast](https://aws.amazon.com/podcasts/aws-podcast/) 分享了各种其他有用的教育材料。
[AWS 培训 和认证](https://aws.amazon.com/training/)包括通过自定进度的数字课程进行的免费培训，以及按角色或领域制定的学习计划。您还可以报名参加讲师指导培训，进一步支持培养团队的 AWS 技能。
**期望结果：**组织不断评估技能差距，并通过结构化的预算和投资来弥补这些差距。团队鼓励和激励其成员开展提高技能的活动，例如获得领先的行业认证。团队利用午餐学习、沉浸日、黑客马拉松和 GameDay 活动等专门的知识交叉共享计划。组织及时更新知识系统，并使其保持与交叉培训团队成员的相关性，包括新员工入职培训。
**常见反模式：**
+ 在缺乏结构化培训计划和预算的情况下，团队在努力跟上技术发展步伐的过程中会遇到不确定性，从而导致人员流失增加。
+ 在向 AWS 迁移的过程中，组织表现出团队之间存在技能差距和不同的云熟悉度。如果不努力提高技能，团队就会受累于传统且效率低下的云环境管理，并导致操作员不堪重负。这种倦怠感会增加员工的不满情绪。
**建立此最佳实践的好处：**组织有意识地投资于提高团队技能时，这还有助于加速和扩大云的采用和优化。有针对性的学习计划可推动创新，培养团队的运营能力，为处理各种事件做好准备。团队有意识地投资于最佳实践的实施和发展。团队士气高昂，团队成员重视自己对企业的贡献。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
为了采用新技术、推动创新、跟上需求和责任的变化，从而为工作负载提供支持，请持续投资于团队的专业发展。
### 实施步骤
1. **使用结构化的云宣传计划：**[AWS Skills Guild](https://aws.amazon.com/training/teams/aws-skills-guild/) 提供咨询培训，可提高在云技能方面的信心并激发持续学习的文化。
1. **提供教育资源：**专门安排时间，提供培训材料和实验室资源，并支持参加会议和加入专业组织，以便有机会向讲师和同行学习。让初级团队成员有机会接触资深团队成员，并让后者担任导师，或者让初级团队成员跟随资深团队成员工作，接触后者的工作方法和技能。鼓励学习与工作没有直接关系的内容，拓展视野。
1. **鼓励使用专家技术资源：**利用 [AWS re:Post](https://repost.aws/) 之类的资源来访问精选知识和活跃社区。
1. **建立和维护最新的知识库：**使用 Wiki 和运行手册等知识共享平台。使用 [AWS re:Post Private](https://aws.amazon.com/repost-private/) 创建自己的可重复使用的专家知识源，简化协作、提高工作效率并加速员工入职。
1. **团队教育和跨团队参与：**为团队成员的继续教育需求进行规划。为团队成员提供（临时或永久）加入其他团队的机会，以便分享技能和最佳实践，惠及整个组织。
1. **支持获取和维护行业认证：**支持团队成员获取和维护行业认证，以便验证他们所学到的知识并认可他们的成就。
**实施计划的工作量级别：**高
## 资源
**相关最佳实践：**
+ [OPS03-BP01 提供高管支持](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_executive_sponsor.html)
+ [OPS11-BP04 执行知识管理](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html)
**相关文档：**
+ [AWS 白皮书 \$1 Cloud Adoption Framework: People Perspective](https://docs.aws.amazon.com/whitepapers/latest/aws-caf-people-perspective/aws-caf-people-perspective.html)
+ [Investing in continuous learning to grow your organization's future](https://aws.amazon.com/blogs/publicsector/investing-continuous-learning-grow-organizations-future/)
+ [AWS Skills Guild](https://aws.amazon.com/training/teams/aws-skills-guild/)
+ [AWS 培训 和认证](https://aws.amazon.com/training/)
+ [支持](https://aws.amazon.com/premiumsupport/programs/)
+ [AWS re:Post](https://repost.aws/)
+ [AWS 入门资源中心](https://aws.amazon.com/getting-started/)
+ [AWS Blog](https://aws.amazon.com/blogs/)
+ [AWS 云 合规性](https://aws.amazon.com/compliance/)
+ [AWS 文档](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+ [The Official AWS Podcast](https://aws.amazon.com/podcasts/aws-podcast/)。
+ [AWS 在线技术讲座](https://aws.amazon.com/getting-started/)
+ [AWS 活动和网络研讨会](https://aws.amazon.com/events/)
+ [AWS Well-Architected Lab](https://wellarchitectedlabs.com/)
+ [Amazon Builders' Library](https://aws.amazon.com/builders-library/)
**相关视频：**
+ [AWS re:Invent 2023 \$1 Reskilling at the speed of cloud: Turning employees into entrepreneurs](https://www.youtube.com/watch?v=Ax7JqIDIXEY)
+ [WS re:Invent 2023 \$1 Building a culture of curiosity through gamification](https://www.youtube.com/watch?v=EqWvSBAmD3w)
# OPS03-BP07 为团队配置适当的资源
配备适当数量的精通业务的团队成员，并提供工具和资源来支持工作负载需求。团队成员负担过重会增加人为出错的风险。对自动化技术等工具和资源的投资可以提高团队的效率，有助于他们支持更多的工作负载，而不需要具备额外的能力。
**期望结果：**
+ 已根据迁移计划为团队配备了适当的人员，以便获得在 AWS 中操作工作负载所需的技能组合。在迁移项目过程中，随着团队规模不断扩大，他们已经熟练掌握了在迁移应用程序或对应用程序进行现代化改造时，企业计划使用的 AWS 核心技术。
+ 精心调整了人员配备计划，通过利用自动化和工作流程来高效使用资源。哪怕是规模较小的团队，现在也可以代表应用程序开发团队管理更多的基础设施。
+ 随着运营优先事项的不断变化，会主动识别任何资源人员配置方面的限制，以便保护业务计划取得成功。
+ 对报告负担繁重（例如值班疲劳或过度传呼）的运营指标进行审查，以便核实工作人员是否存在不堪重负的情况。
**常见反模式：**
+ 在多年的云迁移计划接近尾声时，员工尚未提高 AWS 技能，这可能会影响对工作负载的支持，并降低员工士气。
+ 整个 IT 组织正在向敏捷工作方式转变。企业正在对产品组合进行优先级排序，并设定需要首先开发的功能指标。敏捷流程并不要求团队为其工作计划分配故事点。因此，无法知道下一个工作量所需的能力水平，也无法知道是否有合适的技能分配给工作。
+ 您正在让 AWS 合作伙伴迁移工作负载，但合作伙伴迁移完项目后，您还没有为团队制定好支持过渡计划。团队难以高效而有效地支持工作负载。
**建立此最佳实践的好处：**组织中有具备适当技能的团队成员来支持工作负载。资源分配可适应优先事项的变化，而不会影响绩效。其结果是，团队能够熟练地支持工作负载，同时最大限度地利用时间专注于为客户创新，这反过来又提高了员工的满意度。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
云迁移的资源规划应在组织层面进行，与迁移计划以及为支持新云环境而实施的理想运营模式保持一致。这应该包括了解为业务和应用程序开发团队部署了哪些云技术。基础设施和运营领导层应该为领导云技术采用的工程师制定技能差距分析、培训和角色定义方面的计划。
### 实施步骤
1. 借助员工生产率等相关的运营指标（例如，支持工作负载的成本或操作员在意外事件期间花费的时间），制定团队成功的成功标准。
1. 制定资源能力规划和检查机制，以便核实在需要时，是否有适当平衡的合格能力，并且这些能力是否可随时间进行调整。
1. 建立机制（例如，每月向团队发送调查问卷），以期了解影响团队的、与工作相关的挑战（如责任增加、技术变化、人员流失或支持的客户增加）。
1. 利用这些机制与团队互动，发现可能导致员工生产率面临挑战的趋势。团队受外部因素影响时，需重新评估目标并适当地调整执行性目标。确定阻碍团队进度的障碍。
1. 定期审查当前预置的资源是否仍然足够，是否需要额外资源，并做出适当调整来支持团队。
**实施计划的工作量级别：**中
## 资源
**相关最佳实践：**
+ [OPS03-BP06 鼓励团队成员保持和增强自己的技能组合](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_team_enc_learn.html)
+ [OPS09-BP03 审查运营指标并确定改进优先顺序](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_operations_health_review_ops_metrics_prioritize_improvement.html)
+ [OPS10-BP01 使用流程来管理事件、意外事件和问题](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_event_incident_problem_process.html)
+ [OPS10-BP07 自动响应事件](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_auto_event_response.html)
**相关文档：**
+ [AWS 云 Adoption Framework: People Perspective](https://docs.aws.amazon.com/whitepapers/latest/aws-caf-people-perspective/aws-caf-people-perspective.html)
+ [Becoming a Future-Ready Enterprise](https://aws.amazon.com/blogs/enterprise-strategy/becoming-a-future-ready-enterprise/)
+ [Prioritize your Employees' Skills to Drive Business Growth](https://aws.amazon.com/executive-insights/content/prioritize-your-employees-skills-to-drive-business-growth/)
+ [高绩效组织 – 亚马逊双披萨团队](https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team/)
+ [How Cloud-Mature Enterprises Succeed](https://aws.amazon.com/blogs/mt/how-cloud-mature-enterprises-succeed/)