# 卓越运营
卓越运营（OE）是一项承诺，即正确地构建软件，同时持续提供卓越的客户体验。卓越运营支柱包含组织团队、设计工作负载、大规模运营工作负载和随时间推移改进工作负载的最佳实践。有关具体实施的说明性指导，请参阅《[卓越运营支柱白皮书](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html)》。
**Topics**
+ [组织](a-organization.md)
+ [准备](a-prepare.md)
+ [操作](a-operate.md)
+ [改进](a-evolve.md)
# 组织
**Topics**
+ [OPS 1. 您如何确定自己的优先事项？](ops-01.md)
+ [OPS 2. 如何构建组织结构来为业务成果提供支持？](ops-02.md)
+ [OPS 3. 组织文化如何为业务成果提供支持？](ops-03.md)
# OPS 1. 您如何确定自己的优先事项？
每个人都应该了解自己在实现业务成功方面所发挥的作用。制定共同的目标，以便为资源设定优先事项。这可以让您的工作效益最大化。
**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)
# 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)
# OPS 3. 组织文化如何为业务成果提供支持？
为团队成员提供支持，以便他们可以更有效地采取行动并为您的业务成果提供支持。
**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/)
# 准备
**Topics**
+ [OPS 4. 如何在工作负载中实现可观测性？](ops-04.md)
+ [OPS 5. 如何减少缺陷、简化修复和改进生产流程？](ops-05.md)
+ [OPS 6. 如何缓解部署风险？](ops-06.md)
+ [OPS 7. 如何知道您已经准备好支持某种工作负载？](ops-07.md)
# OPS 4. 如何在工作负载中实现可观测性？
在工作负载中实现可观测性，以便您可以了解其状态并根据业务要求作出数据驱动型决策。
**Topics**
+ [OPS04-BP01 确定关键绩效指标](ops_observability_identify_kpis.md)
+ [OPS04-BP02 实施应用程序遥测](ops_observability_application_telemetry.md)
+ [OPS04-BP03 实施用户体验遥测](ops_observability_customer_telemetry.md)
+ [OPS04-BP04 实施依赖项遥测](ops_observability_dependency_telemetry.md)
+ [OPS04-BP05 实施分布式跟踪](ops_observability_dist_trace.md)
# OPS04-BP01 确定关键绩效指标
要在工作负载中实现可观测性，首先要了解其状态，并根据业务要求做出数据驱动型决策。确保监控活动与业务目标相一致的最有效方法之一是，定义和监控关键绩效指标（KPI）。
**期望结果：**与业务目标紧密协调的高效可观测性实践，确保监控工作始终为切实的业务成果服务。
**常见反模式：**
+ 不明确的 KPI：在没有明确 KPI 的情况下工作可能会导致监控过多或过少内容，从而缺少重要信号。
+ 静态 KPI：不会随着工作负载或业务目标的发展变化而重新审视或完善 KPI。
+ 不一致：重点关注与业务成果不直接相关或难以与现实问题关联的技术指标。
**建立此最佳实践的好处：**
+ 易于发现问题：业务 KPI 通常比技术指标能够更清楚地揭示问题。与筛查众多技术指标相比，深入研究业务 KPI 有助于更有效地查明问题。
+ 业务协调：确保监控活动直接支持业务目标。
+ 效率：将监控资源和注意力优先放在重要的指标上。
+ 积极主动：在问题对业务产生更广泛影响之前发现问题并加以解决。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
要有效地定义工作负载 KPI，请执行以下操作：
1. **从业务成果开始：**在深入研究指标之前，请先了解期望的业务成果。是销售额增加、用户参与度提高还是响应时间更短？
1. **将技术指标与业务目标相关联：**并非所有技术指标都会对业务成果产生直接影响。确定那些确实会产生直接影响的指标，但使用业务 KPI 来发现问题通常更为简单。
1. **使用 [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)：**使用 CloudWatch 来定义和监控代表 KPI 的指标。
1. **定期审查和更新 KPI：**随着工作负载和业务的发展，请保持 KPI 的相关性。
1. **让利益相关方参与其中：**让技术和业务团队参与定义和审查 KPI。
**实施计划的工作量级别：**中
## 资源
**相关最佳实践：**
+ [OPS04-BP02 实施应用程序遥测](ops_observability_application_telemetry.md)
+ [OPS04-BP03 实施用户体验遥测](ops_observability_customer_telemetry.md)
+ [OPS04-BP04 实施依赖项遥测](ops_observability_dependency_telemetry.md)
+ [OPS04-BP05 实施分布式跟踪](ops_observability_dist_trace.md)
**相关文档：**
+ [AWS Observability Best Practices](https://aws-observability.github.io/observability-best-practices/)
+ 《[Amazon CloudWatch 用户指南](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)》
+ [AWS Observability Skill Builder Course](https://explore.skillbuilder.aws/learn/course/external/view/elearning/14688/aws-observability)
**相关视频：**
+ [Developing an observability strategy](https://www.youtube.com/watch?v=Ub3ATriFapQ)
**相关示例：**
+ [One Observability 讲习会](https://catalog.workshops.aws/observability/en-US)
# OPS04-BP02 实施应用程序遥测
应用程序遥测是实现工作负载可观测性的基础。发射遥测数据至关重要，它可以提供切实可行的洞察，便于了解应用程序的状态以及技术和业务成果的实现情况。从故障排除到衡量新功能的影响或确保与业务关键绩效指标（KPI）保持一致，应用程序遥测可为构建、操作和改进工作负载的方式提供指导。
指标、日志和跟踪数据构成了可观测性的三个主要支柱。它们用作诊断工具来描述应用程序状态。随着时间的推移，还可协助创建基准和识别异常情况。但是，为了确保监控活动与业务目标协调一致，定义和监控 KPI 至关重要。与只考虑纯粹的技术指标相比，业务 KPI 通常有助于更轻松地发现问题。
真实用户监控（RUM）和综合事务等其他遥测类型，是对这些主要数据来源的补充。RUM 有助于了解实时用户交互，而综合事务则模拟潜在的用户行为，有助于提前发现瓶颈，以防真实用户遇到瓶颈。
**期望结果：**获得有关工作负载性能的切实可行的洞察。这些洞察有助于主动作出性能优化决策，提高工作负载稳定性，简化 CI/CD 流程，并有效地利用资源。
**常见反模式：**
+ **可观测性不完整：**忽略将可观测性纳入工作负载的每一层，造成盲点，从而掩盖重要的系统性能和行为洞察。
+ **支离破碎的数据视图：**当数据分散在多个工具和系统中时，要全面了解工作负载的运行状况和性能，会非常困难。
+ **用户报告的问题：**这表明缺乏通过遥测和业务 KPI 监控来主动发现问题的功能。
**建立此最佳实践的好处：**
+ **明智的决策：**借助从遥测和业务 KPI 中获得的洞察，可以作出以数据驱动型决策。
+ **提高运营效率：**数据驱动的资源利用率可提高成本效益。
+ **增强工作负载稳定性：**更快地检测和解决问题，延长正常运行时间。
+ **简化 CI/CD 流程：**从遥测数据获得的洞察有助于完善流程和可靠地交付代码。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
要为工作负载实现应用程序遥测，请使用 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 和 [AWS X-Ray](https://aws.amazon.com/xray/) 等 AWS 服务。Amazon CloudWatch 提供了一套全面的监控工具，可观察 AWS 和本地环境中的资源和应用程序。该服务会收集、跟踪和分析指标，整合和监控日志数据，并对资源的变化做出响应，从而增进对工作负载运行方式的了解。同时，利用 AWS X-Ray，还可以跟踪、分析和调试应用程序，深入了解工作负载的行为。借助服务地图、延迟分布和跟踪时间表等功能，AWS X-Ray 可让您深入了解工作负载的性能和影响工作负载性能的瓶颈。
### 实施步骤
1. **确定要收集哪些数据：**确定有助于深入了解工作负载运行状况、性能和行为的基本指标、日志和跟踪数据。
1. **部署 [CloudWatch 代理](https://aws.amazon.com/cloudwatch/)：**CloudWatch 代理在从工作负载及其底层基础设施中获取系统和应用程序指标和日志方面发挥重要作用。CloudWatch 代理还可用于收集 OpenTelemetry 或 X-Ray 跟踪数据，并将其发送到 X-Ray。
1. **对日志和指标实施异常检测：**使用 [CloudWatch Logs 异常检测功能](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/LogsAnomalyDetection.html)和 [CloudWatch Metrics 异常检测功能](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)来自动识别应用程序操作中的异常活动。这些工具使用机器学习算法来检测异常情况并发出警报，从而增强了监控能力，加快了对潜在中断或安全威胁的响应速度。设置这些功能可主动管理应用程序的运行状况和安全性。
1. **保护敏感日志数据：**使用 [Amazon CloudWatch Logs 数据保护](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/mask-sensitive-log-data.html)来掩蔽日志中的敏感信息。此功能会在访问敏感数据之前自动检测和掩蔽敏感数据，有助于维护隐私和合规性。实施数据掩蔽，以期安全地处理和保护个人身份信息（PII）等敏感详细信息。
1. **定义和监控业务 KPI：**建立与[业务结果](https://aws-observability.github.io/observability-best-practices/guides/operational/business/monitoring-for-business-outcomes/)一致的[自定义指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)。
1. **使用 AWS X-Ray 检测应用程序：**除了部署 CloudWatch 代理之外，还必须[对应用程序进行检测](https://docs.aws.amazon.com/xray/latest/devguide/xray-instrumenting-your-app.html)，以便发出跟踪数据。此过程可让您进一步了解工作负载的行为和性能。
1. **标准化整个应用程序中的数据收集：**标准化整个应用程序中的数据收集实践。统一性有助于关联和分析数据，从而全面了解应用程序的行为。
1. **实现跨账户可观测性：**借助 [Amazon CloudWatch 跨账户可观测性](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html)，提高对多个 AWS 账户 的监控效率。利用该功能，可以将不同账户中的指标、日志和警报整合到一个视图中，从而简化管理，并提高对整个组织的 AWS 环境中已发现问题的响应速度。
1. **分析数据并据此采取行动：**数据收集和标准化完成后，使用 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/features/) 进行指标和日志分析，并使用 [AWS X-Ray](https://aws.amazon.com/xray/features/) 进行跟踪分析。此类分析可得出有关工作负载运行状况、性能和行为的重要洞察，从而指导决策过程。
**实施计划的工作量级别：**高
## 资源
**相关最佳实践：**
+ [OPS04-BP01 定义工作负载 KPI](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_identify_kpis.html)
+ [OPS04-BP03 实施用户活动遥测](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_customer_telemetry.html)
+ [OPS04-BP04 实施依赖项遥测](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_dependency_telemetry.html)
+ [OPS04-BP05 实施事务可追溯性](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_dist_trace.html)
**相关文档：**
+ [AWS Observability Best Practices](https://aws-observability.github.io/observability-best-practices/)
+ 《[Amazon CloudWatch 用户指南](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)》
+ [AWS X-Ray 开发人员指南](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [检测分布式系统的运营可见性](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility)
+ [AWS Observability Skill Builder Course](https://explore.skillbuilder.aws/learn/course/external/view/elearning/14688/aws-observability)
+ [Amazon CloudWatch 的新功能](https://aws.amazon.com/about-aws/whats-new/management-and-governance/?whats-new-content.sort-by=item.additionalFields.postDateTime&whats-new-content.sort-order=desc&awsf.whats-new-products=general-products%23amazon-cloudwatch)
+ [AWS X-Ray 的新功能](https://aws.amazon.com/about-aws/whats-new/developer-tools/?whats-new-content.sort-by=item.additionalFields.postDateTime&whats-new-content.sort-order=desc&awsf.whats-new-products=general-products%23aws-x-ray)
**相关视频：**
+ [AWS re:Invent 2022 - Observability best practices at Amazon](https://youtu.be/zZPzXEBW4P8)
+ [AWS re:Invent 2022 - Developing an observability strategy](https://youtu.be/Ub3ATriFapQ)
**相关示例：**
+ [One Observability 讲习会](https://catalog.workshops.aws/observability)
+ [AWS 解决方案库：使用 Amazon CloudWatch 进行应用程序监控](https://aws.amazon.com/solutions/implementations/application-monitoring-with-cloudwatch)
# OPS04-BP03 实施用户体验遥测
深入了解客户体验以及与应用程序的交互至关重要。真实用户监控（RUM）和综合事务是实现此目的的强大工具。RUM 提供有关真实用户交互的数据，从未经筛选的视角反映用户满意度，而综合事务可模拟用户交互，有助于在潜在问题影响真实用户之前就发现这些问题。
**期望结果：**全面了解客户体验，主动检测问题，优化用户交互，从而提供无缝的数字体验。
**常见反模式：**
+ 应用程序没有真实用户监控（RUM）功能：
+ 问题检测延误：如果没有 RUM，可能要等到用户抱怨时，才会意识到性能瓶颈或问题。这种被动应对的方法可能会导致客户不满。
+ 缺乏对用户体验的了解：不使用 RUM 意味着无法掌握揭示真实用户如何与应用程序交互的关键数据，从而限制优化用户体验的能力。
+ 应用程序没有综合事务功能：
+ 错过边缘案例：综合事务有助于测试普通用户可能不经常使用、但对某些业务职能至关重要的路径和功能。没有综合事务，这些路径可能会出现故障并被忽视。
+ 在未使用应用程序时检查问题：定期的综合测试可以模拟真实用户未积极与应用程序交互时的情况，确保系统始终正常运行。
**建立此最佳实践的好处：**
+ 主动检测问题：在潜在问题影响真实用户之前，发现并解决这些问题。
+ 优化用户体验：来自 RUM 的持续反馈有助于完善和增强整体用户体验。
+ 获得有关设备和浏览器性能的洞察：了解应用程序在各种设备和浏览器上的表现，从而实现进一步优化。
+ 经过验证的业务工作流程：定期的综合事务可确保核心功能和关键路径始终可以使用且高效。
+ 增强应用程序性能：利用从真实用户数据中收集的洞察，提高应用程序的响应能力和可靠性。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
为利用 RUM 和综合事务进行用户活动遥测，AWS 提供了 [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) 和 [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) 等服务。指标、日志和跟踪数据，再加上用户活动数据，可让您全面了解应用程序的运行状态和用户体验。
### 实施步骤
1. **部署 Amazon CloudWatch RUM：**将应用程序与 CloudWatch RUM 集成，收集、分析和呈现真实的用户数据。
1. 使用 [CloudWatch RUM JavaScript 库](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)，将 RUM 与应用程序集成。
1. 设置控制面板，以可视化形式呈现和监控真实的用户数据。
1. **配置 CloudWatch Synthetics：**创建金丝雀或脚本化例程，模拟用户与应用程序的交互。
1. 定义关键应用程序工作流程和路径。
1. 使用 [CloudWatch Synthetics 脚本](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)设计金丝雀，模拟这些路径的用户交互。
1. 安排和监控金丝雀按指定的间隔运行，确保进行一致的性能检查。
1. **分析数据并据此采取行动：**利用来自 RUM 和综合事务的数据来获取洞察，并在检测到异常时采取纠正措施。使用 CloudWatch 控制面板和警报及时了解情况。
**实施计划的工作量级别：**中
## 资源
**相关最佳实践：**
+ [OPS04-BP01 确定关键绩效指标](ops_observability_identify_kpis.md)
+ [OPS04-BP02 实施应用程序遥测](ops_observability_application_telemetry.md)
+ [OPS04-BP04 实施依赖项遥测](ops_observability_dependency_telemetry.md)
+ [OPS04-BP05 实施分布式跟踪](ops_observability_dist_trace.md)
**相关文档：**
+ 《[Amazon CloudWatch RUM 指南](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)》
+ 《[Amazon CloudWatch Synthetics 指南](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)》
**相关视频：**
+ [Optimize applications through end user insights with Amazon CloudWatch RUM](https://www.youtube.com/watch?v=NMaeujY9A9Y)
+ [AWS on Air ft. Real-User Monitoring for Amazon CloudWatch](https://www.youtube.com/watch?v=r6wFtozsiVE)
**相关示例：**
+ [One Observability 讲习会](https://catalog.workshops.aws/observability/en-US/intro)
+ [适用于 Amazon CloudWatch RUM Web 客户端的 Git 存储库](https://github.com/aws-observability/aws-rum-web)
+ [Using Amazon CloudWatch Synthetics to measure page load time](https://github.com/aws-samples/amazon-cloudwatch-synthetics-page-performance)
# OPS04-BP04 实施依赖项遥测
要想监控工作负载所依赖的外部服务和组件的运行状况及性能，依赖项遥测必不可少。依赖项遥测提供有关与 DNS、数据库或第三方 API 等依赖项相关的可访问性、超时及其他关键事件的宝贵洞察。对应用程序进行检测，发布有关这些依赖项的指标、日志和跟踪数据时，能更清楚地了解可能影响工作负载的潜在瓶颈、性能问题或故障。
**期望结果：**确保工作负载所依赖的依赖项按预期执行，让您能够主动解决问题并确保最佳的工作负载性能。
**常见反模式：**
+ **忽略外部依赖项：**仅关注内部应用程序指标，而忽略与外部依赖项相关的指标。
+ **缺乏主动监控：**等待问题出现，而不是持续监控依赖项运行状况和性能。
+ **孤立监控：**使用多种不同的监控工具，这可能会导致依赖项运行状况视图支离破碎且不一致。
**建立此最佳实践的好处：**
+ **提高工作负载可靠性：**通过确保外部依赖项始终可用且性能出色来实现。
+ **更快地检测和解决问题：**在依赖项问题影响工作负载之前，主动发现和解决这些问题。
+ **全面视图：**全面了解影响工作负载运行状况的内部和外部组件。
+ **增强工作负载可扩展性：**通过了解外部依赖项的可扩展性限制和性能特征来实现。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
从确定工作负载所依赖的服务、基础设施和流程开始，实施依赖项遥测。量化这些依赖项按预期运行时的良好状况，然后确定将需要哪些数据来衡量这些状况。利用这些信息，可以创建控制面板和警报，为运营团队提供有关这些依赖项状态的洞察。当依赖项无法按需交付时，使用 AWS 工具来发现和量化影响。不断重新审视策略，考虑优先事项、目标和所获洞察的变化。
### 实施步骤
要有效地实现依赖项遥测，请执行以下操作：
1. **确定外部依赖项：**与利益相关方合作，查明工作负载所依赖的外部依赖项。外部依赖项可包括外部数据库、第三方 API、通往其他环境的网络连接路由以及 DNS 服务等内容。实现有效的依赖项遥测的第一步是全面了解这些依赖项是什么。
1. **制定监控策略：**一旦清楚地了解了外部依赖项，就可以针对它们构建一个量身定制的监控策略。这包括了解每个依赖项的重要程度、其预期行为以及任何相关的服务水平协议或目标（SLA 或 SLT）。设置主动警报，在出现状态变化或性能偏差时发出通知。
1. **使用[网络监控](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Network-Monitoring-Sections.html)：**使用[网络检测仪](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-InternetMonitor.html)和[网络监视器](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/what-is-network-monitor.html)，全面了解全球互联网和网络状况。这些工具有助于了解并应对影响外部依赖项的中断、破坏或性能下降。
1. **随时了解 [AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health/) 的最新信息：**AWS Health 是有关 AWS 云资源运行状况的权威信息来源。使用 AWS Health 可视化并接收有关任何当前服务事件和即将发生的更改（例如计划的生命周期事件）的通知，以便您可以采取措施来减轻影响。
1. 通过 [AWS 用户通知服务](https://docs.aws.amazon.com/notifications/latest/userguide/what-is-service.html) 创建要发送到电子邮件和聊天渠道且[契合目标的 AWS Health 事件通知](https://docs.aws.amazon.com/health/latest/ug/user-notifications.html)，并通过 Amazon EventBridge 或 [AWS Health API](https://docs.aws.amazon.com/health/latest/APIReference/Welcome.html) 以编程方式与[监控和警报工具](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html)集成。
1. 通过与您可能已经通过 Amazon EventBridge 或 AWS Health API 使用的变更管理或 ITSM 工具（如 [Jira](https://docs.aws.amazon.com/smc/latest/ag/cloud-sys-health.html) 或 [ServiceNow](https://docs.aws.amazon.com/smc/latest/ag/sn-aws-health.html)）集成，规划和跟踪需要采取行动的运行状况事件的进度。
1. 如果您使用 AWS Organizations，请启用 [organization view for AWS Health](https://docs.aws.amazon.com/health/latest/ug/aggregate-events.html) 以跨账户聚合 AWS Health 事件。
1. **使用 [AWS X-Ray](https://aws.amazon.com/xray/) 检测应用程序：**AWS X-Ray 让您能够深入了解应用程序及其底层依赖项的运行情况。通过从头到尾跟踪请求，可以找出应用程序所依赖的外部服务或组件中的瓶颈或故障。
1. **使用 [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/)：**这项服务由机器学习驱动，可发现操作问题，预测何时可能出现严重问题，并建议可采取的具体行动。其可贵之处在于，可以让您深入了解依赖项，并确保这些依赖项不会成为操作问题的根源。
1. **定期监控：**持续监控与外部依赖项相关的指标和日志。针对意外行为或性能下降设置警报。
1. **更改后进行验证：**每当任何外部依赖项有更新或更改时，都应验证其性能，并检查它们是否符合应用程序的要求。
**实施计划的工作量级别：**中
## 资源
**相关最佳实践：**
+ [OPS04-BP01 定义工作负载 KPI](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_identify_kpis.html)
+ [OPS04-BP02 实施应用程序遥测](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_application_telemetry.html)
+ [OPS04-BP03 实施用户活动遥测](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_customer_telemetry.html)
+ [OPS04-BP05 实施事务可追溯性](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_dist_trace.html)
+ [OP08-BP04 创建可操作的警报](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_workload_observability_create_alerts.html)
**相关文档：**
+ 《[Amazon Personal Health Dashboard User Guide](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html)》
+ 《[AWS Internet Monitor User Guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-InternetMonitor.html)》
+ [AWS X-Ray 开发人员指南](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ 《[AWS DevOps Guru User Guide](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)》
**相关视频：**
+ [Visibility into how internet issues impact app performance](https://www.youtube.com/watch?v=Kuc_SG_aBgQ)
+ [Introduction to Amazon DevOps Guru](https://www.youtube.com/watch?v=2uA8q-8mTZY)
+ [Manage resource lifecycle events at scale with AWS Health](https://www.youtube.com/watch?v=VoLLNL5j9NA)
**相关示例：**
+ [AWS Health Aware](https://github.com/aws-samples/aws-health-aware/)
+ [Using Tag-Based Filtering to Manage AWS Health Monitoring and Alerting at Scale](https://aws.amazon.com/blogs/mt/using-tag-based-filtering-to-manage-health-monitoring-and-alerting-at-scale/)
# OPS04-BP05 实施分布式跟踪
分布式跟踪提供了一种方法，可在请求遍历分布式系统的各个组件时对请求进行监控和可视化。通过从多个来源捕获跟踪数据并在一个统一视图中对其进行分析，团队可以更好地了解请求是如何流动的、哪里存在瓶颈以及优化工作的重点。
**期望结果：**全面了解流经分布式系统的请求，从而精确调试、优化性能和改善用户体验。
**常见反模式：**
+ 检测不一致：并非分布式系统中的所有服务都经过跟踪检测。
+ 忽略延迟：只关注错误，而不考虑延迟或性能逐渐下降的情况。
**建立此最佳实践的好处：**
+ 全面了解系统：以可视化方式呈现请求从进入到退出的整个路径。
+ 增强调试功能：快速发现出现故障或性能问题的地方。
+ 改善用户体验：监控并根据实际用户数据进行优化，确保系统满足现实需求。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
首先确定工作负载中所有需要检测的元素。将所有组件都考虑在内后，利用 AWS X-Ray 和 OpenTelemetry 之类的工具收集跟踪数据，以便使用 X-Ray 和 Amazon CloudWatch ServiceLens Map 等工具进行分析。定期与开发人员一起进行审查，并使用 Amazon DevOps Guru、X-Ray Analytics 和 X-Ray Insights 等工具来补充这些讨论，以便挖掘更深层次的信息。根据跟踪数据确立警报，以便在结果面临风险时，按照工作负载监控计划中定义的流程发出通知。
### 实施步骤
要有效地实施分布式跟踪，请执行以下操作：
1. **采用 [AWS X-Ray](https://aws.amazon.com/xray/)：**将 X-Ray 集成到应用程序中，以便深入了解其行为和性能并查明瓶颈。利用 X-Ray Insights 自动分析跟踪数据。
1. **检测服务：**验证从 [AWS Lambda](https://aws.amazon.com/lambda/) 函数到 [EC2 实例](https://aws.amazon.com/ec2/)的每项服务是否发送了跟踪数据。检测的服务越多，端到端视图就越清晰。
1. **整合 [CloudWatch 真实用户监控](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)和[综合监控](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)：**将真实用户监控（RUM）和综合监控与 X-Ray 集成。这可捕捉实际的用户体验并模拟用户交互，从而发现潜在问题。
1. **使用 [CloudWatch 代理](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)：**该代理可发送来自 X-Ray 或 OpenTelemetry 的跟踪数据，从而增强所获得洞察的深度。
1. **使用 [Amazon DevOps Guru：](https://aws.amazon.com/devops-guru/)**DevOps Guru 使用来自 X-Ray、CloudWatch、AWS Config 和 AWS CloudTrail 的数据来提供切实可行的建议。
1. **分析跟踪数据：**定期审查跟踪数据，识别可能影响应用程序性能的模式、异常或瓶颈。
1. **设置警报：**在 [CloudWatch](https://aws.amazon.com/cloudwatch/) 中配置针对异常模式或延迟时间过长的警报，从而主动解决问题。
1. **持续改进：**在添加或修改服务时，重新审视跟踪策略，以便捕获所有相关数据点。
**实施计划的工作量级别：**中
## 资源
**相关最佳实践：**
+ [OPS04-BP01 确定关键绩效指标](ops_observability_identify_kpis.md)
+ [OPS04-BP02 实施应用程序遥测](ops_observability_application_telemetry.md)
+ [OPS04-BP03 实施用户体验遥测](ops_observability_customer_telemetry.md)
+ [OPS04-BP04 实施依赖项遥测](ops_observability_dependency_telemetry.md)
**相关文档：**
+ 《[AWS X-Ray 开发人员指南](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)》
+ 《[Amazon CloudWatch 代理用户指南](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)》
+ 《[Amazon DevOps Guru User Guide](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)》
**相关视频：**
+ [Use AWS X-Ray Insights](https://www.youtube.com/watch?v=tl8OWHl6jxw)
+ [AWS on Air ft. Observability: Amazon CloudWatch and AWS X-Ray](https://www.youtube.com/watch?v=qBDBnPkZ-KI)
**相关示例：**
+ [ Instrumenting your application for AWS X-Ray](https://aws.amazon.com/xray/latest/devguide/xray-instrumenting-your-app.html)
# OPS 5. 如何减少缺陷、简化修复和改进生产流程？
采用的方法需能够改进将更改应用于生产环境的流程，激活重构、快速质量反馈和错误修复。这些方法可以加快有益更改进入生产环境的速度、减少产生的问题，并能够快速识别和修复通过部署活动引入的问题。
**Topics**
+ [OPS05-BP01 使用版本控制](ops_dev_integ_version_control.md)
+ [OPS05-BP02 测试并验证更改](ops_dev_integ_test_val_chg.md)
+ [OPS05-BP03 使用配置管理系统](ops_dev_integ_conf_mgmt_sys.md)
+ [OPS05-BP04 使用构建和部署管理系统](ops_dev_integ_build_mgmt_sys.md)
+ [OPS05-BP05 执行补丁管理](ops_dev_integ_patch_mgmt.md)
+ [OPS05-BP06 共享设计标准](ops_dev_integ_share_design_stds.md)
+ [OPS05-BP07 实施提高代码质量的实践](ops_dev_integ_code_quality.md)
+ [OPS05-BP08 使用多个环境](ops_dev_integ_multi_env.md)
+ [OPS05-BP09 频繁进行可逆的小规模更改](ops_dev_integ_freq_sm_rev_chg.md)
+ [OPS05-BP10 完全自动化集成和部署](ops_dev_integ_auto_integ_deploy.md)
# OPS05-BP01 使用版本控制
使用版本控制来跟踪更改和发布。
许多 AWS 服务都提供版本控制功能。使用 [Git](https://aws.amazon.com/devops/source-control/git/) 等修订或[源代码控制](https://aws.amazon.com/devops/source-control/)系统来管理代码和其它构件，例如基础设施的版本受控的 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 模板。
**期望结果：**团队协作编写代码。合并后，代码将保持一致，并且不会丢失任何更改。通过正确的版本控制，可以很容易纠正错误。
**常见反模式：**
+ 您一直在工作站上开发和存储代码。工作站上发生了不可恢复的存储故障，代码丢失了。
+ 用更改内容覆盖现有代码后，重新启动应用程序，但其无法运行。您无法撤销所做更改。
+ 您对报告文件执行了写入锁定，而其他人需要对此文件进行编辑。他们与您联系要求停止写入锁定，以便他们可以完成自己的任务。
+ 研究团队一直在进行详细的分析，以便对未来的工作进行规划。有人不小心把购物单保存在最终报告上了。您无法撤销更改，不得不重新创建报告。
**建立此最佳实践的好处：**借助版本控制功能，可以轻松地恢复到已知的良好状态和以前的版本，并降低资产丢失的风险。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
在版本受控的存储库中维护资产。这让您能够跟踪更改、部署新版本、检测对现有版本的更改，以及恢复到以前的版本（例如在发生故障时回滚到已知的良好状态）。将配置管理系统的版本控制功能集成到程序中。
## 资源
**相关最佳实践：**
+ [OPS05-BP04 使用构建和部署管理系统](ops_dev_integ_build_mgmt_sys.md)
**相关视频：**
+ [AWS re:Invent 2023 - How Lockheed Martin builds software faster, powered by DevSecOps ](https://www.youtube.com/watch?v=Q1OSyxYkl5w)
+ [AWS re:Invent 2023 - How GitHub operationalizes AI for team collaboration and productivity ](https://www.youtube.com/watch?v=cOVvGaiusOI)
# OPS05-BP02 测试并验证更改
部署的每一项更改都必须经过测试，避免在生产中出现错误。此最佳实践的重点是测试从版本控制到构件构建的更改。除应用程序代码更改外，测试还应该包括基础设施、配置、安全控制和操作程序。测试有多种形式，从单元测试到软件组件分析（SCA）等等。在软件集成和交付过程中，尽早进行测试可进一步确保构件质量。
组织必须为所有的软件构件制定测试标准。自动化测试可以减少工作量，并避免人工测试的错误。但有些情况下，可能必须进行手动测试。开发人员必须能够访问自动化测试结果，以便创建反馈环路，提高软件质量。
**期望结果：**软件更改在交付前经过测试。开发人员可以访问测试结果和验证结果。组织制定了适用于所有软件更改的测试标准。
**常见反模式：**
+ 在没有进行任何测试的情况下部署一项新软件更改。它无法在生产环境中运行，从而导致中断。
+ 使用 AWS CloudFormation 部署新安全组，而没有在预生产环境中进行测试。这些安全组导致客户无法访问应用程序。
+ 修改了一个方法，但没有进行单元测试。该软件在部署到生产环境中后无法运行。
**建立此最佳实践的好处：**降低了软件部署更改的失败率。软件质量得到改进。开发人员提高了对其代码可行性的认识。可以放心地推出安全策略，支持组织实现合规性。可以提前测试自动扩缩策略更新等基础设施更改，从而满足流量需求。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
作为持续集成实践的一部分，对从应用程序代码到基础设施的所有更改都进行测试。将公布测试结果，以便开发人员快速提供反馈。组织制定了测试标准，所有更改都必须通过该标准。
利用 Amazon Q 开发者版的生成式人工智能的强大功能，提高开发人员的生产力和代码质量。Amazon Q 开发者版包括生成代码建议（基于大型语言模型）、制作单元测试（包括边界条件），以及通过检测和修复安全漏洞来增强代码安全性。
**客户示例**
作为持续集成管道的一部分，AnyCompany Retail 对所有软件构件进行几种类型的测试。他们实行测试驱动型开发，因此所有软件都要进行单元测试。构件构建完毕后，他们会立即运行端到端测试。第一轮测试完成后，他们会运行静态应用程序安全扫描，寻找已知漏洞。在每个测试关口通过时，开发人员都会收到消息。所有测试均完成后，软件构件就会存储在构件库中。
### 实施步骤
1. 与组织中的利益相关方合作，为软件构件制定测试标准。所有构件均应通过哪些标准测试？ 测试范围内是否必须包含合规性或治理要求？ 是否需要进行代码质量测试？ 测试完成后，需要通知谁？
1. [AWS 部署管道参考架构](https://pipelines.devops.aws.dev/)包含一个权威的测试类型列表，可作为集成管道的一部分对软件构件执行这些测试。
1. 根据软件测试标准，利用必要的测试来检测应用程序。每组测试应在 10 分钟内完成。测试应该作为集成管道的一部分运行。
1. 使用 [Amazon Q 开发者版](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/what-is.html)，这是一款生成式人工智能工具，可以帮助创建单元测试案例（包括边界条件）、使用代码和注释生成函数以及实现已知算法。
1. 使用 [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) 来测试应用程序代码是否存在缺陷。
1. 使用 [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) 对软件构件执行测试。
1. [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) 可以将软件测试编排到管道中。
## 资源
**相关最佳实践：**
+ [OPS05-BP01 使用版本控制](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_version_control.html)
+ [OPS05-BP06 共享设计标准](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_share_design_stds.html)
+ [OPS05-BP07 实施提高代码质量的实践](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_code_quality.html)
+ [OPS05-BP10 完全自动化集成和部署](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_auto_integ_deploy.html)
**相关文档：**
+ [采用测试驱动型开发方法](https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-cdk-typescript-iac/development-best-practices.html)
+ [Accelerate your Software Development Lifecycle with Amazon Q](https://aws.amazon.com/blogs/devops/accelerate-your-software-development-lifecycle-with-amazon-q/)
+ [Amazon Q Developer, now generally available, includes previews of new capabilities to reimagine developer experience](https://aws.amazon.com/blogs/aws/amazon-q-developer-now-generally-available-includes-new-capabilities-to-reimagine-developer-experience/)
+ [The Ultimate Cheat Sheet for Using Amazon Q Developer in Your IDE](https://community.aws/content/2eYoqeFRqaVnk900emsknDfzhfW/the-ultimate-cheat-sheet-for-using-amazon-q-developer-in-your-ide)
+ [Shift-Left Workload, leveraging AI for Test Creation](https://community.aws/content/2gBZtC94gPzaCQRnt4P0rIYWuBx/shift-left-workload-leveraging-ai-for-test-creation)
+ [Amazon Q 开发人员中心](https://aws.amazon.com/developer/generative-ai/amazon-q/)
+ [10 ways to build applications faster with Amazon CodeWhisperer](https://aws.amazon.com/blogs/devops/10-ways-to-build-applications-faster-with-amazon-codewhisperer/)
+ [Looking beyond code coverage with Amazon CodeWhisperer](https://aws.amazon.com/blogs/devops/looking-beyond-code-coverage-with-amazon-codewhisperer/)
+ [Best Practices for Prompt Engineering with Amazon CodeWhisperer](https://aws.amazon.com/blogs/devops/best-practices-for-prompt-engineering-with-amazon-codewhisperer/)
+ [Automated AWS CloudFormation Testing Pipeline with TaskCat and CodePipeline](https://aws.amazon.com/blogs/devops/automated-cloudformation-testing-pipeline-with-taskcat-and-codepipeline/)
+ [Building end-to-end AWS DevSecOps CI/CD pipeline with open source SCA, SAST, and DAST tools](https://aws.amazon.com/blogs/devops/building-end-to-end-aws-devsecops-ci-cd-pipeline-with-open-source-sca-sast-and-dast-tools/)
+ [Getting started with testing serverless applications](https://aws.amazon.com/blogs/compute/getting-started-with-testing-serverless-applications/)
+ [My CI/CD pipeline is my release captain](https://aws.amazon.com/builders-library/cicd-pipeline/)
+ 《[在 AWS 上练习持续集成和持续交付白皮书](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/welcome.html)》
**相关视频：**
+ [Implement an API with Amazon Q Developer Agent for Software Development](https://www.youtube.com/watch?v=U4XEvJUvff4)
+ [Installing, Configuring, & Using Amazon Q Developer with JetBrains IDEs (How-to)](https://www.youtube.com/watch?v=-iQfIhTA4J0)
+ [Mastering the art of Amazon CodeWhisperer - YouTube playlist](https://www.youtube.com/playlist?list=PLDqi6CuDzubxzL-yIqgQb9UbbceYdKhpK)
+ [AWS re:Invent 2020: Testable infrastructure: Integration testing on AWS](https://www.youtube.com/watch?v=KJC380Juo2w)
+ [AWS Summit ANZ 2021 - Driving a test-first strategy with CDK and test driven development](https://www.youtube.com/watch?v=1R7G_wcyd3s)
+ [Testing Your Infrastructure as Code with AWS CDK](https://www.youtube.com/watch?v=fWtuwGSoSOU)
**相关资源：**
+ [AWS Deployment Pipeline Reference Architecture - Application](https://pipelines.devops.aws.dev/application-pipeline/index.html)
+ [AWS Kubernetes DevSecOps 管道](https://github.com/aws-samples/devsecops-cicd-containers)
+ [Run unit tests for a Node.js application from GitHub by using AWS CodeBuild](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/run-unit-tests-for-a-node-js-application-from-github-by-using-aws-codebuild.html)
+ [Use Serverspec for test-driven development of infrastructure code](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/use-serverspec-for-test-driven-development-of-infrastructure-code.html)
**相关服务：**
+ [Amazon Q 开发者版](https://aws.amazon.com/q/developer/)
+ [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html)
+ [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
# OPS05-BP03 使用配置管理系统
使用配置管理系统来实现和跟踪配置更改。这些系统可以减少手动过程引起的错误，并减少部署更改的工作量。
静态配置管理在初始化资源时设置值，这些值预计在资源的生命周期内会保持一致。动态配置管理在初始化时设置值，这些值在资源的生命周期内可能或预计会发生变化。例如，可以设置功能切换，通过配置更改来激活代码中的功能，或者在意外事件发生期间更改日志详细信息级别。
配置应在已知且一致的状态下部署。应该使用自动化检查功能来持续监控跨环境和区域的资源配置。这些控制措施应定义为自动化代码和管理，从而确保在各个环境中始终如一地应用规则。配置更改应通过商定的更改控制程序进行更新，并一致地应用，从而遵守版本控制。应用程序配置应独立于应用程序和基础设施代码进行管理。这可实现在多个环境中进行一致的部署。配置更改不会导致重建或重新部署应用程序。
**期望结果：**可以作为持续集成、持续交付（CI/CD）管道的一部分进行配置、验证和部署。通过监控来验证配置是否正确。这样可以最大限度地减少对终端用户和客户的任何影响。
**常见反模式：**
+ 手动更新整个实例集中的 Web 服务器配置，由于更新错误，许多服务器变得没有响应。
+ 手动更新应用程序服务器实例集需要花费很长时间。在更改过程中，如果配置不一致会导致意外行为发生。
+ 有人更新了安全组，Web 服务器变得无法访问。如果不知道进行了哪些更改，就需要花费大量时间来调查问题，导致恢复时间延长。
+ 未经验证即通过 CI/CD 将预生产配置推送到生产环境中。让用户和客户接触到不正确的数据和服务。
**建立此最佳实践的好处：**采用配置管理系统可以减少更改及对其进行跟踪的工作量，还可以降低手动程序导致错误的频率。配置管理系统为治理、合规性和监管要求提供了保障。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
配置管理系统用于跟踪和实施对应用程序和环境配置的更改。配置管理系统还用于减少手动流程导致的错误，让配置更改可重复且可审核，并减少工作量。
在 AWS 上，可以使用 [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) 持续监控[跨账户和区域](https://docs.aws.amazon.com/config/latest/developerguide/aggregate-data.html)的 AWS 资源配置。这有助于跟踪其配置历史记录，了解配置更改会如何影响其他资源，并使用 [AWS Config 规则](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) 和 [AWS Config 合规包](https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html)根据预期或期望的配置对其进行审查。
对于在 Amazon EC2 实例、AWS Lambda、容器、移动应用程序或 IoT 设备上运行的应用程序中的动态配置，可以使用 [AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html) 在各环境中对其进行配置、验证、部署和监控。
### 实施步骤
1. 确定配置负责人。
1. 让配置负责人了解任何合规性、治理或监管需求。
1. 确定配置项和可交付成果。
1. 配置项是受 CI/CD 管道内的部署影响的所有应用程序和环境配置。
1. 可交付成果包括成功标准、验证和要监控的内容。
1. 根据业务要求和交付管道，选择配置管理工具。
1. 考虑使用加权部署，例如用于重大配置更改的金丝雀部署，以便尽可能减少错误配置的影响。
1. 将配置管理集成到 CI/CD 管道中。
1. 验证推送的所有更改。
## 资源
**相关最佳实践：**
+ [OPS06-BP01 针对不成功的更改制定计划](ops_mit_deploy_risks_plan_for_unsucessful_changes.md)
+ [OPS06-BP02 测试部署](ops_mit_deploy_risks_test_val_chg.md)
+ [OPS06-BP03 采用安全部署策略](ops_mit_deploy_risks_deploy_mgmt_sys.md)
+ [OPS06-BP04 自动测试和回滚](ops_mit_deploy_risks_auto_testing_and_rollback.md)
**相关文档：**
+ [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)
+ [AWS 登录区加速器](https://aws.amazon.com/solutions/implementations/landing-zone-accelerator-on-aws/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [什么是 AWS Config？](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)
+ [AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html)
+ [什么是 AWS CloudFormation？](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [AWS 开发人员工具](https://aws.amazon.com/products/developer-tools/)
+ [AWS CodeBuild](https://aws.amazon.com/codebuild/)
+ [AWS CodePipeline](https://aws.amazon.com/codepipeline/)
+ [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)
**相关视频：**
+ [AWS re:Invent 2022 - Proactive governance and compliance for AWS workloads](https://youtu.be/PpUnH9Y52X0?si=82wff87KHXcc6nbT)
+ [AWS re:Invent 2020: Achieve compliance as code using AWS Config](https://youtu.be/m8vTwvbzOfw?si=my4DP0FLq1zwKjho)
+ [Manage and Deploy Application Configurations with AWS AppConfig](https://youtu.be/ztIxMY3IIu0?si=ovYGsxWOBysyQrg0)
# OPS05-BP04 使用构建和部署管理系统
使用构建和部署管理系统。这些系统可以减少手动过程引起的错误，并减少部署更改的工作量。
在 AWS 中，您可以使用 [AWS 开发人员工具](https://aws.amazon.com/products/developer-tools/)（例如 [AWS CodeBuild](https://aws.amazon.com/codebuild/)、[AWS CodePipeline](https://aws.amazon.com/codepipeline/) 和 [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)）等服务，来构建持续集成/持续部署（CI/CD）管道。
**期望结果：**构建和部署管理系统支持组织的持续集成/持续交付（CI/CD）系统，该系统提供使用正确配置自动进行安全部署的功能。
**常见反模式：**
+ 在开发系统上编译代码后，将可执行文件复制到生产系统中，但它无法启动。本地日志文件显示这是因为缺少依赖项所致。
+ 成功在开发环境中构建了具有新功能的应用程序，并将代码送交质量检查（QA）。由于缺少静态资产，它没有通过质量检查。
+ 星期五，经过大量的努力，成功地在开发环境中手动构建了应用程序，包括新编码的功能。星期一，无法重复支持成功构建应用程序的步骤。
+ 执行为新版本创建的测试。花费了接下来一周的时间来设置测试环境，并执行所有现有的集成测试，然后执行性能测试。新代码产生了难以接受的性能影响，因此必须重新开发并测试。
**建立此最佳实践的好处：**制定相应机制来管理活动的构建和部署。这样，可以减少执行重复任务的工作量，让团队成员腾出时间专注于高价值的创造性任务，还可以减少手动程序导致的错误。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
构建和部署管理系统用于跟踪和实施变更，减少手动流程导致的错误，并减少安全部署所需的工作量。将集成和部署管道完全自动化，从代码签入到构建、测试、部署和验证都包含在内。这可以缩短准备时间，降低成本，鼓励更频繁地进行更改，减少工作量并增进协作。
### 实施步骤
![\[图中显示了使用 AWS CodePipeline 和相关服务的 CI/CD 管道\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/deployment-pipeline-tooling.png)
1. 使用版本控制系统来存储和管理资产（例如文档、源代码和二进制文件）。
1. 使用 CodeBuild 来编译源代码，运行单元测试，并生成可供部署的构件。
1. 使用 CodeDeploy 作为部署服务，可以自动将应用程序部署到 [Amazon EC2](https://aws.amazon.com/ec2/) 实例、本地实例、[无服务器 AWS Lambda 函数](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)或 [Amazon ECS](https://aws.amazon.com/ecs/)。
1. 监控部署。
## 资源
**相关最佳实践：**
+ [OPS06-BP04 自动测试和回滚](ops_mit_deploy_risks_auto_testing_and_rollback.md)
**相关文档：**
+ [AWS 开发人员工具](https://aws.amazon.com/products/developer-tools/)
+ [什么是 AWS CodeBuild ？](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [AWS CodeBuild](https://aws.amazon.com/codebuild/)
+ [什么是 AWS CodeDeploy ？](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
**相关视频：**
+ [AWS re:Invent 2022 - AWS Well-Architected best practices for DevOps on AWS](https://youtu.be/hfXokRAyorA)
# OPS05-BP05 执行补丁管理
执行补丁管理以便实现功能、解决问题并保持监管合规性。实现自动补丁管理，减少手动流程导致的错误，进行扩展，并减少修补工作量。
补丁和漏洞管理是益处与风险管理活动的一部分。最好是具有不可变的基础设施并在经验证的已知良好状态下部署工作负载。如果该方法不可行，那就只能进行修补。
[AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health/) 是有关计划的生命周期事件以及其它影响 AWS 云 资源运行状况而需采取措施的事件的权威信息来源。您应该知道即将进行的更改和应执行的更新。计划的重大生命周期事件至少提前六个月发送。
[Amazon EC2 Image Builder](https://aws.amazon.com/image-builder/) 提供了更新机器映像的管道。作为补丁管理的一部分，可以考虑使用 [AMI 映像管道](https://docs.aws.amazon.com/imagebuilder/latest/userguide/start-build-image-pipeline.html)的[亚马逊机器映像（AMI）](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html )或带有 [Docker 映像管道](https://docs.aws.amazon.com/imagebuilder/latest/userguide/start-build-container-pipeline.html)的容器映像，而 AWS Lambda 提供适用于[自定义运行时和其他库](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html)的模式用来消除漏洞。
应使用 [Amazon EC2 Image Builder](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) 管理适用于 Linux 或 Windows Server 映像的[亚马逊机器映像（AMI）](https://aws.amazon.com/image-builder/)的更新。可以结合使用 [Amazon Elastic Container Registry（Amazon ECR）](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html)和现有管道来管理 Amazon ECS 映像和 Amazon EKS 映像。Lambda 包含[版本管理功能](https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html)。
在未事先在安全环境中测试的情况下，不应对生产系统执行修补操作。仅当补丁支持运营或业务成果时，才应该应用补丁。在 AWS 上，可以使用 [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) 自动完成托管系统的修补过程，并使用 [Systems Manager 维护时段](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html)安排活动。
**期望结果：**AMI 和容器映像经过修补、处于最新状态，随时可以启动。可以跟踪所有已部署映像的状态，并了解补丁合规性。可以报告当前状态，并制定流程来满足合规性需求。
**常见反模式：**
+ 您接到任务，需要在两个小时内应用所有新的安全补丁，但由于应用程序与补丁不兼容，导致了多次停机。
+ 没有安装补丁的库会引发意外后果，这是因为未知方会利用其中的漏洞来访问工作负载。
+ 在未通知开发人员的情况下自动修补开发人员环境。收到来自开发人员的多起投诉，称他们的环境不能按预期运行。
+ 尚未修补持久性实例上的现有商用软件。遇到软件问题并与供应商联系时，他们告知已不再为该版本提供支持，您必须安装特定级别的补丁才能获得帮助。
+ 您使用的加密软件最近发布了新补丁，对性能进行了重大改进。未安装补丁的系统仍然存在性能问题，恰恰是因为没有安装补丁造成的。
+ 您收到通知，告知存在零日漏洞，需要紧急修复，而您不得不手动为所有环境打补丁。
+ 您不知道维护资源所需的关键操作，例如强制版本更新，因为您未查看即将发生的计划生命周期事件和其它信息。您错失了计划和执行的关键时间，导致团队发生紧急变化，并可能造成影响或意外停机。
**建立此最佳实践的好处：**通过建立补丁管理流程，包括修补标准以及在环境中分发补丁的方法，可以进行扩展和报告补丁级别。这为安全补丁提供了保障，并确保清楚地了解已知修复的状态。这会促进采用所需特性和功能、快速解决问题并保持监管合规性。实施补丁管理系统和自动化，可减少部署补丁的工作量，并减少手动流程导致的错误。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
修补系统以便纠正问题、获得所需的特性或功能、符合监管政策并满足供应商支持需求。在不可变系统中，使用适当的补丁集进行部署，以便实现所需结果。自动执行补丁管理机制以便缩短修补时间、避免手动流程导致的错误，并减少修补工作量。
### 实施步骤
对于 Amazon EC2 Image Builder：
1. 使用 Amazon EC2 Image Builder，指定管道详细信息：
1. 创建映像管道并为其命名
1. 定义管道计划和时区
1. 配置任何依赖项
1. 选择方案：
1. 选择现有方案或创建新方案
1. 选择映像类型
1. 为方案命名并确定其版本
1. 选择基础映像
1. 添加构建组件并添加到目标注册表
1. 可选 – 定义基础设施配置。
1. 可选 – 定义配置设置。
1. 查看设置。
1. 定期检查方案，保持方案正常发挥作用。
对于 Systems Manager Patch Manager：
1. 创建补丁基准。
1. 选择补丁操作方法。
1. 启用合规性报告和扫描。
## 资源
**相关最佳实践：**
+ [OPS06-BP04 自动测试和回滚](ops_mit_deploy_risks_auto_testing_and_rollback.md)
**相关文档：**
+ [What is Amazon EC2 Image Builder](https://docs.aws.amazon.com/imagebuilder/latest/userguide/what-is-image-builder.html)
+ [Create an image pipeline using the Amazon EC2 Image Builder](https://docs.aws.amazon.com/imagebuilder/latest/userguide/start-build-image-pipeline.html)
+ [Create a container image pipeline](https://docs.aws.amazon.com/imagebuilder/latest/userguide/start-build-container-pipeline.html)
+ [AWS Systems Manager Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)
+ [使用 Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-console.html)
+ [使用补丁合规性报告](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-compliance-reports.html)
+ [AWS 开发人员工具](https://aws.amazon.com/products/developer-tools)
**相关视频：**
+ [CI/CD for Serverless Applications on AWS](https://www.youtube.com/watch?v=tEpx5VaW4WE)
+ [Design with Ops in Mind](https://youtu.be/uh19jfW7hw4)
**相关示例：**
+ [AWS Systems Manager Patch Manager 教程](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-tutorials.html)
# OPS05-BP06 共享设计标准
在不同团队间共享最佳实践，以便提高认识并最大程度地实现开发工作的效益。随着架构的发展，记录最佳实践并使其保持最新。如果在组织中强制实施了共享标准，则必须制定相应的机制来请求对标准进行添加、更改和例外处理。如果没有这样的机制，标准将成为创新的约束。
**期望结果：**在组织中的不同团队间共享设计标准。随着最佳实践的发展，记录标准并使其保持最新。
**常见反模式：**
+ 两个开发团队各自创建了一个用户身份验证服务。对于用户来说，他们想要访问系统的每一部分，都必须使用一套单独的凭据。
+ 每个团队管理他们自己的基础设施。新的合规性要求迫使您更改基础设施，各个团队以不同的方式实施更改。
**建立此最佳实践的好处：**使用共享标准支持最佳实践的采用，并充分实现开发工作的效益。记录和更新设计标准，让组织可以了解最新的最佳实践以及安全和合规性要求。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
在不同团队间共享现有的最佳实践、设计标准、检查清单、操作程序、指南和监管要求。建立针对设计标准的更改、添加和例外请求程序，以便支持改进和创新。让团队了解已发布的内容。随着新最佳实践的出现，制定一种机制来让设计标准保持最新。
**客户示例**
AnyCompany Retail 拥有负责创建软件架构模式的跨职能架构团队。此团队构建具有内置合规性和治理的架构。采用这些共享标准的团队可以从内置合规性和治理中受益。他们可以在设计标准的基础上快速构建。架构团队每季度召开一次会议，评估架构模式，如有必要，更新架构模式。
### 实施步骤
1. 组建一个跨职能团队，负责开发和更新设计标准。此团队应与整个组织的利益相关方合作，制定设计标准、操作程序、检查清单、指南和治理要求。记录设计标准并在组织内共享。
1. [AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html) 可用于使用基础设施即代码创建代表设计标准的产品组合。可以在不同账户间共享产品组合。
1. 随着新最佳实践的确定，制定一种机制来让设计标准保持最新。
1. 如果集中执行设计标准，则制定一个流程来请求更改、更新和豁免。
**实施计划的工作量级别：**中。制定一个流程来创建和共享设计标准，就可以与整个组织的利益相关方进行协调与合作。
## 资源
**相关最佳实践：**
+ [OPS01-BP03 评估治理要求](ops_priorities_governance_reqs.md) – 治理要求会影响设计标准。
+ [OPS01-BP04 评估合规性要求](ops_priorities_compliance_reqs.md) – 在创建设计标准时，合规性是一项至关重要的输入。
+ [OPS07-BP02 确保以一致的方式对运营准备情况进行审查](ops_ready_to_support_const_orr.md) – 运营准备检查清单是一种在设计工作负载时实施设计标准的机制。
+ [OPS11-BP01 设置持续改进流程](ops_evolve_ops_process_cont_imp.md) – 更新设计标准是持续改进的一部分。
+ [OPS11-BP04 执行知识管理](ops_evolve_ops_knowledge_management.md) – 在知识管理实践过程中，记录和共享设计标准。
**相关文档：**
+ [Automate AWS Backups with AWS Service Catalog](https://aws.amazon.com/blogs/mt/automate-aws-backups-with-aws-service-catalog/)
+ [AWS Service Catalog Account Factory-Enhanced](https://aws.amazon.com/blogs/mt/aws-service-catalog-account-factory-enhanced/)
+ [How Expedia Group built Database as a Service (DBaaS) offering using AWS Service Catalog](https://aws.amazon.com/blogs/mt/how-expedia-group-built-database-as-a-service-dbaas-offering-using-aws-service-catalog/)
+ [Maintain visibility over the use of cloud architecture patterns](https://aws.amazon.com/blogs/architecture/maintain-visibility-over-the-use-of-cloud-architecture-patterns/)
+ [Simplify sharing your AWS Service Catalog portfolios in an AWS Organizations setup](https://aws.amazon.com/blogs/mt/simplify-sharing-your-aws-service-catalog-portfolios-in-an-aws-organizations-setup/)
**相关视频：**
+ [AWS Service Catalog – Getting Started](https://www.youtube.com/watch?v=A9kKy6WhqVA)
+ [AWS re:Invent 2020: Manage your AWS Service Catalog portfolios like an expert](https://www.youtube.com/watch?v=lVfXkWHAtR8)
**相关示例：**
+ [AWS Service Catalog Reference Architecture](https://github.com/aws-samples/aws-service-catalog-reference-architectures)
+ [AWS Service Catalog 讲习会](https://catalog.us-east-1.prod.workshops.aws/workshops/d40750d7-a330-49be-9945-cde864610de9/en-US)
**相关服务：**
+ [AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html)
# OPS05-BP07 实施提高代码质量的实践
实施能够提高代码质量并尽可能减少缺陷的最佳实践。一些示例包括测试驱动型开发、代码审查、标准采用和结对编程。将这些实践合并到持续集成和交付流程中。
**期望结果：**组织使用代码审查或结对编程等最佳实践来提高代码质量。在软件开发生命周期内，开发人员和操作人员采用代码质量最佳实践。
**常见反模式：**
+ 在没有进行代码审查的情况下将代码提交到应用程序的主分支。更改会自动部署到生产环境并导致中断。
+ 开发新应用程序，而不进行任何单元测试、端到端测试或集成测试。在部署之前无法测试应用程序。
+ 团队在生产中进行手动更改来解决缺陷问题。更改没有经过测试或代码审查，也不会通过持续集成和交付流程得到捕获或记录。
**建立此最佳实践的好处：**通过采用提高代码质量的实践，能够帮助最大限度地减少引入生产中的问题。代码质量最佳实践包括结对编程、代码审查和实施人工智能生产力工具等。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
实施提高代码质量的实践，以便在部署代码之前尽可能减少缺陷。使用测试驱动型开发、代码审查和结对编程等实践来提高开发的质量。
利用 Amazon Q 开发者版的生成式人工智能的强大功能，提高开发人员的生产力和代码质量。Amazon Q 开发者版包括生成代码建议（基于大型语言模型）、制作单元测试（包括边界条件），以及通过检测和修复安全漏洞来增强代码安全性。
**客户示例**
AnyCompany Retail 采用几种实践来提高代码质量。他们采用了测试驱动型开发作为编写应用程序的标准。对于一些新功能，他们让开发人员在冲刺阶段结对编程。在集成和部署之前，由高级开发人员对每个拉取请求进行代码审查。
### 实施步骤
1. 在持续集成和交付流程中采用测试驱动型开发、代码审查和结对编程等代码质量实践。使用这些技术来提高软件质量。
1. 使用 [Amazon Q 开发者版](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/what-is.html)，这是一款生成式人工智能工具，可以帮助创建单元测试案例（包括边界条件）、使用代码和注释生成函数、实现已知算法、检测代码中的安全策略违规行为和漏洞、检测机密、扫描基础设施即代码（IaC）、记录代码以及更快地学习第三方代码库。
1. [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) 可以使用机器学习为 Java 和 Python 代码提供编程建议。
**实施计划的工作量级别：**中。实施此最佳实践有很多方法，但获得组织采用可能并非易事。
## 资源
**相关最佳实践：**
+ [OPS05-BP02 测试并验证更改](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_test_val_chg.html)
+ [OPS05-BP06 共享设计标准](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_share_design_stds.html)
**相关文档：**
+ [采用测试驱动型开发方法](https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-cdk-typescript-iac/development-best-practices.html)
+ [Accelerate your Software Development Lifecycle with Amazon Q](https://aws.amazon.com/blogs/devops/accelerate-your-software-development-lifecycle-with-amazon-q/)
+ [Amazon Q Developer, now generally available, includes previews of new capabilities to reimagine developer experience](https://aws.amazon.com/blogs/aws/amazon-q-developer-now-generally-available-includes-new-capabilities-to-reimagine-developer-experience/)
+ [The Ultimate Cheat Sheet for Using Amazon Q Developer in Your IDE](https://community.aws/content/2eYoqeFRqaVnk900emsknDfzhfW/the-ultimate-cheat-sheet-for-using-amazon-q-developer-in-your-ide)
+ [Shift-Left Workload, leveraging AI for Test Creation](https://community.aws/content/2gBZtC94gPzaCQRnt4P0rIYWuBx/shift-left-workload-leveraging-ai-for-test-creation)
+ [Amazon Q 开发人员中心](https://aws.amazon.com/developer/generative-ai/amazon-q/)
+ [10 ways to build applications faster with Amazon CodeWhisperer](https://aws.amazon.com/blogs/devops/10-ways-to-build-applications-faster-with-amazon-codewhisperer/)
+ [Looking beyond code coverage with Amazon CodeWhisperer](https://aws.amazon.com/blogs/devops/looking-beyond-code-coverage-with-amazon-codewhisperer/)
+ [Best Practices for Prompt Engineering with Amazon CodeWhisperer](https://aws.amazon.com/blogs/devops/best-practices-for-prompt-engineering-with-amazon-codewhisperer/)
+ 《[Agile Software Guide](https://martinfowler.com/agile.html)》
+ [My CI/CD pipeline is my release captain](https://aws.amazon.com/builders-library/cicd-pipeline/)
+ [Automate code reviews with Amazon CodeGuru Reviewer](https://aws.amazon.com/blogs/devops/automate-code-reviews-with-amazon-codeguru-reviewer/)
+ [采用测试驱动型开发方法](https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-cdk-typescript-iac/development-best-practices.html)
+ [How DevFactory builds better applications with Amazon CodeGuru](https://aws.amazon.com/blogs/machine-learning/how-devfactory-builds-better-applications-with-amazon-codeguru/)
+ [On Pair Programming](https://martinfowler.com/articles/on-pair-programming.html)
+ [RENGA Inc. automates code reviews with Amazon CodeGuru](https://aws.amazon.com/blogs/machine-learning/renga-inc-automates-code-reviews-with-amazon-codeguru/)
+ [The Art of Agile Development: Test-Driven Development](http://www.jamesshore.com/v2/books/aoad1/test_driven_development)
+ [Why code reviews matter (and actually save time\$1)](https://www.atlassian.com/agile/software-development/code-reviews)
**相关视频：**
+ [Implement an API with Amazon Q Developer Agent for Software Development](https://www.youtube.com/watch?v=U4XEvJUvff4)
+ [Installing, Configuring, & Using Amazon Q Developer with JetBrains IDEs (How-to)](https://www.youtube.com/watch?v=-iQfIhTA4J0)
+ [Mastering the art of Amazon CodeWhisperer - YouTube playlist](https://www.youtube.com/playlist?list=PLDqi6CuDzubxzL-yIqgQb9UbbceYdKhpK)
+ [AWS re:Invent 2020: Continuous improvement of code quality with Amazon CodeGuru](https://www.youtube.com/watch?v=iX1i35H1OVw)
+ [AWS Summit ANZ 2021 - Driving a test-first strategy with CDK and test driven development](https://www.youtube.com/watch?v=1R7G_wcyd3s)
**相关服务：**
+ [Amazon Q 开发者版](https://aws.amazon.com/q/developer/)
+ [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html)
+ [Amazon CodeGuru Profiler](https://docs.aws.amazon.com/codeguru/latest/profiler-ug/what-is-codeguru-profiler.html)
# OPS05-BP08 使用多个环境
使用多个环境来试验、开发和测试工作负载。当环境接近于生产环境时，逐步加强控制，确保工作负载在部署后能够按预期运行。
**期望结果：**您有多个环境，这些环境均反映合规性和治理需求。在通往生产的道路上，可以通过环境来测试和推广代码。
1. 组织可通过建立登录区来实现这一目标，登录区可提供治理、控制、账户自动化、联网、安全性和运营可观测性。通过使用多个环境来管理这些登录区功能。一个常见的例子是沙盒组织，用于开发和测试对基于 [AWS Control Tower](https://aws.amazon.com/controltower/) 的登录区的更改，其中包括 [AWS IAM Identity Center](https://aws.amazon.com/iam/identity-center/) 和 [service control policies (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) 等策略。所有这些因素都会对登录区内 AWS 账户的访问和操作产生重大影响。
1. 除了这些服务外，您的团队还可通过 AWS 和 AWS 合作伙伴发布的解决方案，或作为组织内部开发的自定义解决方案，来扩展登录区的功能。AWS 发布的解决方案示例包括 [AWS Control Tower 的自定义选项（CfCT）](https://aws.amazon.com/solutions/implementations/customizations-for-aws-control-tower/)和 [AWS Control Tower Account Factory for Terraform (AFT)](https://docs.aws.amazon.com/controltower/latest/userguide/aft-overview.html)。
1. 您的组织对登录区的测试、推广代码和策略变更采用相同的原则，贯穿通往生产之路的各个环境。该策略为您的应用程序和工作负载团队提供了一个稳定且安全的登录区环境。
**常见反模式：**
+ 您正在共享开发环境中执行开发，另一位开发人员将覆盖您的代码更改。
+ 对共享开发环境严苛的安全控制导致您无法试验新的服务和功能。
+ 对生产系统执行负载测试，导致用户停机。
+ 生产中发生了严重错误，导致数据丢失。在生产环境中，尝试重新创建导致数据丢失的条件，以便能够确定它是如何发生的，并防止它再次发生。为了防止在测试期间再次丢失数据，您被迫采取措施，导致用户无法使用应用程序。
+ 您正在运行多租户服务，无法支持客户对专用环境的请求。
+ 您可能并不总是进行测试，但在需要测试时，您在生产环境中进行。
+ 您认为单一环境的简单性比更改在环境中的影响范围更加重要。
+ 您升级了一项关键的登录区功能，但此项更改会削弱您的团队为新项目或现有工作负载销售账户的能力。
+ 您对 AWS 账户应用了新的控制，但此项更改会影响工作负载团队在其 AWS 账户内部署更改的能力。
**建立此最佳实践的好处：**当您部署多个环境时，可以为多个同时进行的开发、测试和生产环境提供支持，而不会在开发人员或用户社区间造成冲突。对于诸如登录区之类的复杂功能，它可以显著降低变更风险，简化改进过程，并降低对环境进行关键更新的风险。使用登录区的组织自然会因其 AWS 环境中的多个账户而受益，包括账户结构、治理、网络和安全配置。随着时间推移，组织不断成长，登录区可以不断发展，以保护和组织您的工作负载和资源。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
使用多个环境，为开发人员提供控制机制最少的沙盒环境，协助进行试验。提供单独的开发环境来协助并行工作，并提高开发的敏捷性。在接近生产的环境中实施更严格的控制，让开发人员能够创新。使用基础设施即代码和配置管理系统来部署与生产环境中的控制机制配置一致的环境，确保系统在部署后按照预期运行。关闭不使用的环境，以免空闲资源（例如，晚上和周末的开发系统）产生费用。在负载测试时部署与生产等效的环境，以改善有效结果。
诸如平台工程、网络和安全运营等团队通常在组织层面管理可满足不同要求的功能。单靠分离账户不足以为实验、开发和测试提供和维护单独的环境。在此类情况下，请创建单独的 AWS Organizations 实例。
## 资源
**相关文档：**
+ [AWS 实例调度器](https://aws.amazon.com/solutions/implementations/instance-scheduler-on-aws/)
+ [什么是 AWS CloudFormation ？](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [ Organizing Your AWS Environment Using Multiple Accounts - Multiple organizations - Test changes to your overall AWS environment ](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/multiple-organizations.html#test-changes-to-your-overall-aws-environment)
+ [AWS Control Tower Guide ](https://catalog.workshops.aws/control-tower)
# OPS05-BP09 频繁进行可逆的小规模更改
频繁进行可逆的小规模更改可以减少更改的范围和影响。当与变更管理系统、配置管理系统以及构建和交付系统结合使用时，频繁进行可逆的小规模更改可以减少更改的范围和影响。这样可以提高故障排除工作的效率、加快修复速度，并支持回滚更改。
**常见反模式：**
+ 每季度部署一个新版本的应用程序，这会存在一个变更窗口，意味着核心服务将关闭。
+ 经常更改数据库架构，而不跟踪管理系统中的更改。
+ 执行手动就地更新，覆盖现有安装和配置，并且没有明确的回滚计划。
**建立此最佳实践的好处：**通过频繁部署小更改，可以加快开发速度。更改很小时，更易于确定是否会带来意外后果，并且更容易撤回。更改可逆时，由于简化了恢复过程，因此实施更改的风险更小。更改过程的风险降低，更改失败的影响也减小。
**在未建立这种最佳实践的情况下暴露的风险等级：**低
## 实施指导
频繁进行可逆的小规模更改可以减小更改的范围和影响。这可以简化故障排除、加快修复速度，并支持回滚更改。这还可以加快实现业务价值。
## 资源
**相关最佳实践：**
+ [OPS05-BP03 使用配置管理系统](ops_dev_integ_conf_mgmt_sys.md)
+ [OPS05-BP04 使用构建和部署管理系统](ops_dev_integ_build_mgmt_sys.md)
+ [OPS06-BP04 自动测试和回滚](ops_mit_deploy_risks_auto_testing_and_rollback.md)
**相关文档：**
+ [在 AWS 上实施微服务](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)
+ [Microservices - Observability](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/observability.html)
# OPS05-BP10 完全自动化集成和部署
实现自动构建、部署和测试工作负载。这可以减少手动流程导致的错误，并减少部署更改的工作量。
使用[资源标签](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)和 [AWS Resource Groups](https://docs.aws.amazon.com/ARG/latest/APIReference/Welcome.html)，按照一致的[标记策略](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/)应用元数据，以标识资源。标记资源，以便进行整理、成本核算、访问控制并有针对性地自动执行运营活动。
**期望结果：**开发人员使用工具来交付代码并推广到生产环境。开发人员无需登录 AWS 管理控制台 即可提供更新。对更改和配置进行全面的审计跟踪记录，可满足治理和合规性需求。流程是可重复的，并且可跨团队实现标准化。开发人员可以腾出时间专注于开发和代码推送，从而提高工作效率。
**常见反模式：**
+ 星期五，您完成了为功能分支编写新代码的工作。星期一，在运行代码质量测试脚本和各单元测试脚本后，您将代码签入计划发行的下一版本中。
+ 您接到任务，需要为重要问题编写修复代码，该问题在生产中影响了大量客户。对修复代码进行测试后，您提交代码并通过电子邮件发送变更管理，请求批准，以便将其部署到生产环境中。
+ 作为开发人员，您可以登录 AWS 管理控制台，使用非标准方法和系统创建新的开发环境。
**建立此最佳实践的好处：**通过实施自动化的构建和部署管理系统，可以减少手动流程导致的错误，并减少部署更改的工作量，有助于团队成员专注于实现业务价值。推广到生产环境后，交付速度也随之提高。
**在未建立这种最佳实践的情况下暴露的风险等级：**低
## 实施指导
使用构建和部署管理系统来跟踪并实施更改，以便减少手动流程引起的错误，并减少工作量。将集成和部署管道完全自动化，从代码签入到构建、测试、部署和验证都包含在内。这可以缩短准备时间，鼓励更频繁地进行更改，减少工作量，提高面市速度，提升生产力，并增进代码在推广到生产环境时的安全性。
## 资源
**相关最佳实践：**
+ [OPS05-BP03 使用配置管理系统](ops_dev_integ_conf_mgmt_sys.md)
+ [OPS05-BP04 使用构建和部署管理系统](ops_dev_integ_build_mgmt_sys.md)
**相关文档：**
+ [什么是 AWS CodeBuild ？](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [什么是 AWS CodeDeploy ？](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
**相关视频：**
+ [AWS re:Invent 2022 - AWS Well-Architected best practices for DevOps on AWS](https://youtu.be/hfXokRAyorA)
# OPS 6. 如何缓解部署风险？
采用的方法需能够提供快速质量反馈，并在更改没有达到预期结果时实现快速恢复。使用这些实践可以减轻因部署更改而产生的问题的影响。
**Topics**
+ [OPS06-BP01 针对不成功的更改制定计划](ops_mit_deploy_risks_plan_for_unsucessful_changes.md)
+ [OPS06-BP02 测试部署](ops_mit_deploy_risks_test_val_chg.md)
+ [OPS06-BP03 采用安全部署策略](ops_mit_deploy_risks_deploy_mgmt_sys.md)
+ [OPS06-BP04 自动测试和回滚](ops_mit_deploy_risks_auto_testing_and_rollback.md)
# OPS06-BP01 针对不成功的更改制定计划
制定计划，以便在部署没有达到期望结果时，在生产环境中恢复到已知良好状态，或者进行修复。制定一项策略来建立这样的计划，有助于所有团队制定从失败的更改中恢复的策略。这样的示例策略包括部署和回滚步骤、更改策略、功能标记、流量隔离和流量转移。单个发布版本可能包括多个相关的组件更改。该策略应提供承受任何组件更改的失败或从中恢复过来的能力。
**期望结果：**已为更改失败准备了详细的恢复计划。此外，还缩小了发布内容的大小，以便最大限度地减少对其他工作负载组件的潜在影响。因此，通过缩短更改失败可能造成的停机时间，提高恢复时间的灵活性和效率，减少了对业务的影响。
**常见反模式：**
+ 执行部署后，应用程序变得不稳定，但是系统上似乎还有活动用户。您必须决定是回滚更改并影响活动用户，还是等到知道用户无论如何都可能受到影响后再回滚更改。
+ 执行例行更改后，可以访问新环境，但是无法访问其中一个子网。必须决定是回滚所有内容还是尝试修复无法访问的子网。做决定时，子网仍然无法访问。
+ 系统的架构不允许使用较小的发布版本进行更新。因此，在部署失败时，很难撤销这些大批量的更改。
+ 没有使用基础设施即代码（IaC）模式，而且对基础设施进行的手动更新导致了不希望出现的配置。无法有效地跟踪和撤销手动更改。
+ 由于没有将部署频率的增加作为衡量标准，因此团队没有动力来缩小更改规模，也不愿意改进每次更改的回滚计划，从而导致风险增加和失败率上升。
+ 没有衡量因更改失败而导致的中断的总持续时间。团队无法确定部署流程的优先顺序和恢复计划的有效性，也无法进行改进。
**建立此最佳实践的好处：**制定从失败更改中恢复的计划可以最大限度地缩短平均恢复时间（MTTR），并减少对业务的影响。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
发布团队采用的一致、有据可查的策略和实践，让组织能够计划在更改失败时应如何处理。该策略应允许在特定情况下向前修复。无论是哪种情况，在部署到实际生产环境之前，都应妥善记录并测试向前修复或回滚计划，以便最大限度地减少从更改中恢复所需的时间。
### 实施步骤
1. 记录策略，该策略要求团队制定有效计划以便在指定时间内撤销更改。
1. 策略应指定何时允许出现向前修复的情况。
1. 要求所有相关人员都能查阅记录在案的回滚计划。
1. 指定回滚要求（例如，当发现部署了未经授权的更改时）。
1. 分析与工作负载每个组件相关的所有更改的影响级别。
1. 如果可重复的更改遵循的工作流程，与执行更改策略的工作流程保持一致，则允许对这些更改进行标准化、模板化和预授权。
1. 通过缩小更改的规模来减少任何更改的潜在影响，从而减少恢复所需的时间和对业务的影响。
1. 确保回滚程序将代码恢复到已知的良好状态，尽可能避免意外事件。
1. 集成工具和工作流程，以编程方式执行策略。
1. 让其他工作负载所有者能够查看有关更改的数据，以便提高对无法回滚的任何失败更改的诊断速度。
1. 利用可见的更改数据来衡量这一做法是否成功，并确定迭代改进措施。
1. 使用监控工具来验证部署的成败，从而加快制定回滚决策的速度。
1. 衡量更改失败时的停机时间，以便不断改进恢复计划。
**实施计划的工作量级别：**中
## 资源
**相关最佳实践：**
+ [OPS06-BP04 自动测试和回滚](ops_mit_deploy_risks_auto_testing_and_rollback.md)
**相关文档：**
+ [AWS Builders Library \$1 确保部署期间安全回滚](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments/)
+ [AWS 白皮书 \$1 Change Management in the Cloud ](https://docs.aws.amazon.com/whitepapers/latest/change-management-in-the-cloud/change-management-in-the-cloud.html)
**相关视频：**
+ [re:Invent 2019 \$1 Amazon’s approach to high-availability deployment](https://aws.amazon.com/builders-library/amazon-approach-to-high-availability-deployment/)
# OPS06-BP02 测试部署
使用与生产环境相同的部署配置、安全控制、步骤和程序，在预生产环境中测试发布程序。验证所有部署步骤是否按预期完成，如检查文件、配置和服务。通过功能测试、集成测试和负载测试以及运行状况检查等各种监控方法，进一步测试所有更改。通过这些测试，可以及早发现部署问题，并有机会在进入生产之前规划和缓解问题。
可以创建临时的并行环境来测试每项更改。使用基础设施即代码（IaC）自动部署测试环境，有助于减少所涉及的工作量，确保稳定性、一致性和更快的功能交付。
**期望结果：**组织采用了包含测试部署在内的测试驱动型开发文化。这样可以确保团队专注于实现业务价值，而不是管理发布版本。各团队在发现部署风险后尽早参与进来，确定适当的缓解方案。
**常见反模式：**
+ 在发布生产版本期间，未经测试的部署会导致问题频发，需要进行故障排除和上报。
+ 发布版本包含用于更新现有资源的基础设施即代码（IaC）。不确定 IaC 是会成功运行，还是会对资源造成影响。
+ 在应用程序中部署一项新功能。此功能未按预期运行，并且在受影响的用户报告之前都无从了解问题。
+ 您更新了证书。您不小心将证书安装到了错误的组件上，而这却没有被发现，于是因为无法建立与网站的安全连接而影响网站访客。
**建立此最佳实践的好处：**在预生产环境中对部署程序及其引入的更改进行全面测试，可最大限度地减少部署步骤对生产的潜在影响。这增强了生产版本发布过程中的信心，并最大限度地减少了运营支持，而且不会减慢更改交付速度。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
测试部署过程与测试部署所产生的更改同样重要。要完成这一步骤，可以在尽可能接近生产环境的预生产环境中测试部署步骤。可以在投入生产之前发现一些常见问题，如部署步骤不完整、不正确或配置错误。此外，还可以测试恢复步骤。
**客户示例**
作为持续集成和持续交付（CI/CD）管道的一部分，AnyCompany Retail 在类似生产的环境中执行为客户发布基础设施和软件更新所需的既定步骤。该管道包含预检查过程，用于在部署之前检测资源中的偏差（检测在 IaC 之外对资源执行的更改），以及验证 IaC 在启动时采取的操作。该管道会验证部署步骤，例如在向负载均衡器重新注册之前，验证特定文件和配置是否已准备就绪，服务是否处于正在运行状态，以及是否正确响应本地主机上的运行状况检查。此外，所有更改都要进行一系列自动测试，如功能测试、安全测试、回归测试、集成测试和负载测试。
### 实施步骤
1. 执行预安装检查，模拟生产环境打造预生产环境。
1. 使用[偏差检测](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html)功能，检测是否在 CloudFormation 之外更改了资源。
1. 使用[更改集](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets.html)功能，验证堆栈更新的意图是否与 CloudFormation 在启动更改集时所采取的操作相匹配。
1. 这会触发 [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/approvals.html) 中的手动批准步骤，以授权部署到预生产环境。
1. 使用 [AWS CodeDeploy AppSpec](https://docs.aws.amazon.com/codedeploy/latest/userguide/application-specification-files.html) 文件等部署配置来定义部署和验证步骤。
1. 在适用的情况下，[将 AWS CodeDeploy 与其他 AWS 服务集成](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-aws.html)，或[将 AWS CodeDeploy 与合作伙伴的产品和服务集成](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-partners.html)。
1. 使用 Amazon CloudWatch、AWS CloudTrail 和 Amazon SNS 事件通知[监控部署](https://docs.aws.amazon.com/codedeploy/latest/userguide/monitoring.html)。
1. 执行部署后的自动化测试，包括功能测试、安全测试、回归测试、集成测试和负载测试。
1. 部署问题[疑难解答](https://docs.aws.amazon.com/codedeploy/latest/userguide/troubleshooting.html)。
1. 成功验证上述步骤后应启动手动审批工作流程，授权部署到生产环境。
**实施计划的工作量级别：**高
## 资源
**相关最佳实践：**
+ [OPS05-BP02 测试并验证更改](ops_dev_integ_test_val_chg.md)
**相关文档：**
+ [AWS Builders' Library \$1 自动实现无需干预的安全部署 \$1 测试部署](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/#Test_deployments_in_pre-production_environments)
+ [AWS 白皮书 \$1 在 AWS 上练习持续集成和持续交付](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/testing-stages-in-continuous-integration-and-continuous-delivery.html)
+ [The Story of Apollo - Amazon's Deployment Engine](https://www.allthingsdistributed.com/2014/11/apollo-amazon-deployment-engine.html)
+ [How to test and debug AWS CodeDeploy locally before you ship your code](https://aws.amazon.com/blogs/devops/how-to-test-and-debug-aws-codedeploy-locally-before-you-ship-your-code/)
+ [Integrating Network Connectivity Testing with Infrastructure Deployment](https://aws.amazon.com/blogs/networking-and-content-delivery/integrating-network-connectivity-testing-with-infrastructure-deployment/)
**相关视频：**
+ [re:Invent 2020 \$1 Testing software and systems at Amazon](https://www.youtube.com/watch?v=o1sc3cK9bMU)
**相关示例：**
+ [Tutorial \$1 Deploy and Amazon ECS service with a validation test](https://docs.aws.amazon.com/codedeploy/latest/userguide/tutorial-ecs-deployment-with-hooks.html)
# OPS06-BP03 采用安全部署策略
在安全的生产环境滚动部署中，会对有益更改的流程进行控制，目标是尽可能减少这些更改让客户感知到的任何影响。安全控制措施提供检查机制，用于验证是否达成期望结果，并针对由于更改或部署失败所引入的任何缺陷，限制这些缺陷的影响范围。安全滚动部署可包括功能标记、单盒、滚动（金丝雀版本）、不可变、流量分割和蓝绿部署等策略。
**期望结果：**组织使用持续集成/持续交付（CI/CD）系统，提供自动进行安全滚动部署的功能。团队必须使用适当的安全滚动部署策略。
**常见反模式：**
+ 将不成功的更改一次性部署到所有生产环境中。因此，所有客户同时受到影响。
+ 在同时部署到所有系统时，引入的缺陷需要紧急进行修复。为所有客户修复该缺陷需要几天时间。
+ 管理生产版本发布需要多个团队的规划和参与。这限制了为客户更新功能的频率。
+ 通过修改现有系统来执行可变部署。发现更改不成功后，被迫再次修改系统，还原旧版本，导致恢复时间延长。
**建立此最佳实践的好处：**自动化的部署，在快速滚动部署与持续向客户提供有益更改之间取得平衡。限制影响范围可以防止代价高昂的部署失败，并最大限度地提高团队有效应对失败的能力。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
持续交付失败会导致服务可用性降低，带来糟糕的客户体验。为了最大限度地提高部署成功率，请在端到端发布流程中实施安全控制措施，以便最大限度地减少部署错误，以达成零部署失败为目标。
**客户示例**
AnyCompany Retail 的目标是尽可能减少部署的停机时间，甚至实现零停机，这意味着在部署期间，不会对用户造成任何可察觉影响。为了实现这一目标，公司建立了部署模式（参阅以下工作流程图），例如滚动部署和蓝绿部署。所有团队在各自的 CI/CD 管道中都采用了其中一种或多种模式。
| 适用于 Amazon EC2 的 CodeDeploy 工作流程 | 适用于 Amazon ECS 的 CodeDeploy 工作流程 | 适用于 Lambda 的 CodeDeploy 工作流程 |
| --- | --- | --- |
| ![\[适用于 Amazon EC2 的部署流程\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/deployment-process-ec2.png) | ![\[适用于 Amazon ECS 的部署流程\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/deployment-process-ecs.png) | ![\[适用于 Lambda 的部署流程\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/deployment-process-lambda.png) |
### 实施步骤
1. 使用审批工作流程在提升到生产版本后，启动生产版本滚动部署步骤序列。
1. 使用 [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) 等自动化部署系统。AWS CodeDeploy [部署选项](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-steps.html)包括 EC2/本地就地部署及 EC2/本地蓝绿部署、AWS Lambda 和 Amazon ECS（参阅前面的工作流程图）。
1. 在适用的情况下，[将 AWS CodeDeploy 与其他 AWS 服务集成](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-aws.html)，或[将 AWS CodeDeploy 与合作伙伴的产品和服务集成](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-partners.html)。
1. 对诸如 [Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments.html) 和 [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html) 之类的数据库使用蓝/绿部署。
1. 使用 Amazon CloudWatch、AWS CloudTrail 和 Amazon Simple Notification Service（Amazon SNS）[监控部署](https://docs.aws.amazon.com/codedeploy/latest/userguide/monitoring.html)。
1. 执行部署后的自动化测试，包括功能测试、安全测试、回归测试、集成测试以及任何负载测试。
1. 部署问题[疑难解答](https://docs.aws.amazon.com/codedeploy/latest/userguide/troubleshooting.html)。
**实施计划的工作量级别：**中
## 资源
**相关最佳实践：**
+ [OPS05-BP02 测试并验证更改](ops_dev_integ_test_val_chg.md)
+ [OPS05-BP09 频繁进行可逆的小规模更改](ops_dev_integ_freq_sm_rev_chg.md)
+ [OPS05-BP10 完全自动化集成和部署](ops_dev_integ_auto_integ_deploy.md)
**相关文档：**
+ [AWS Builders Library \$1 自动实现无需干预的安全部署 \$1 生产部署](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/?did=ba_card&trk=ba_card#Production_deployments)
+ [AWS Builders Library \$1 My CI/CD pipeline is my release captain \$1 Safe, automatic production releases](https://aws.amazon.com//builders-library/cicd-pipeline/#Safe.2C_automatic_production_releases)
+ [AWS 白皮书 \$1 在 AWS 上练习持续集成和持续交付 \$1 部署方法](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/deployment-methods.html)
+ [AWS CodeDeploy《用户指南](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)》
+ [Working with deployment configurations in AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html)
+ [设置 API Gateway 金丝雀版本部署](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html)
+ [Amazon ECS Deployment Types](https://docs.aws.amazon.com/)
+ [Fully Managed Blue/Green Deployments in Amazon Aurora and Amazon RDS](https://aws.amazon.com/blogs/aws/new-fully-managed-blue-green-deployments-in-amazon-aurora-and-amazon-rds/)
+ [Blue/Green deployments with AWS Elastic Beanstalk](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html)
**相关视频：**
+ [re:Invent 2020 \$1 Hands-off: Automating continuous delivery pipelines at Amazon](https://www.youtube.com/watch?v=ngnMj1zbMPY)
+ [re:Invent 2019 \$1 Amazon's Approach to high-availability deployment](https://www.youtube.com/watch?v=bCgD2bX1LI4)
**相关示例：**
+ [Try a Sample Blue/Green Deployment in AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html)
+ [ Workshop \$1 Building CI/CD pipelines for Lambda canary deployments using AWS CDK](https://catalog.workshops.aws/cdk-cicd-for-lambda-canary-deployment/en-US)
+ [ Workshop \$1 Building your first DevOps Blue/Green pipeline with Amazon ECS ](https://catalog.us-east-1.prod.workshops.aws/workshops/4b59b9fb-48b6-461c-9377-907b2e33c9df/en-US)
+ [ Workshop \$1 Building your first DevOps Blue/Green pipeline with Amazon EKS ](https://catalog.us-east-1.prod.workshops.aws/workshops/4eab6682-09b2-43e5-93d4-1f58fd6cff6e/en-US)
+ [ Workshop \$1 EKS GitOps with ArgoCD ](https://catalog.workshops.aws/eksgitops-argocd-githubactions)
+ [ Workshop \$1 CI/CD on AWS Workshop ](https://catalog.workshops.aws/cicdonaws/en-US)
+ [ Implementing cross-account CI/CD with AWS SAM for container-based Lambda functions ](https://aws.amazon.com/blogs/compute/implementing-cross-account-cicd-with-aws-sam-for-container-based-lambda/)
# OPS06-BP04 自动测试和回滚
为了提高部署过程的速度和可靠性以及对该过程的信心，需要制定一项策略，用于在预生产环境和生产环境中实现自动化的测试和回滚功能。在部署到生产环境时自动进行测试，模拟人与系统的交互，从而验证已经部署的更改。利用自动回滚功能，可以快速恢复到先前已知的良好状态。回滚应在预先定义的条件下自动启动，例如更改未达到期望结果或自动化测试失败时。自动执行这两项活动可以提高部署的成功率，尽可能缩短恢复时间，并减少可能对业务造成的影响。
**期望结果：**自动化测试和回滚策略已集成到持续集成/持续交付（CI/CD）管道中。监控功能可以根据成功标准进行验证，并能在失败时启动自动回滚。这样可以最大限度地减少对终端用户和客户的任何影响。例如，对所有测试结果都感到满意时，可以将代码提升到生产环境中，该环境启动了使用相同测试案例的自动回归测试。如果回归测试结果与预期不符，则在管道工作流程中启动自动回滚。
**常见反模式：**
+ 系统的架构不允许使用较小的发布版本进行更新。因此，在部署失败时，很难撤销这些大批量的更改。
+ 部署流程包括一系列手动步骤。将更改部署到工作负载后，启动部署后测试。完成测试之后，发现工作负载不可操作，而且客户断开了连接。然后，开始回滚到之前的版本。所有这些手动步骤都会延误整个系统的恢复，并对客户造成长时间的影响。
+ 花时间为应用程序中不常用的功能开发了自动化测试案例，这极大地降低了在自动化测试功能上的投资回报率。
+ 发布版本由应用程序、基础设施、补丁和配置更新组成，这些组件相互独立。但是，只有一个 CI/CD 管道，只能同时交付所有更改。一个组件中的失败会迫使撤销所有更改，导致回滚过程复杂且效率低下。
+ 团队完成了冲刺一的编码工作并开始冲刺二的工作，但是按照计划，直到冲刺三才会进行测试。结果，自动化测试发现冲刺一中存在缺陷，必须先解决这些缺陷，才能开始测试冲刺二的可交付成果，这延误了整个发布过程，大大降低了自动化测试的价值。
+ 生产版本的自动化回归测试案例已完成，但没有监控工作负载运行状况。由于无法监控服务是否已重新启动，因此不确定是否需要回滚或者是否已经进行了回滚。
**建立此最佳实践的好处：**自动化测试可提高测试过程的透明度，以及在更短的时间内测试更多功能的能力。通过对生产环境中的更改进行测试和验证，可以立即发现问题。利用自动化测试工具改进一致性，可以更好地检测缺陷。通过自动回滚到之前的版本，可以将对客户的影响降至最低。自动回滚可以减少业务影响，最终提升对部署功能的信心。总体而言，这些功能可在确保质量的同时缩短交付时间。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
自动测试部署的环境，以便更快地确认期望结果。在没有达到预定义的结果时，自动回滚到之前的已知良好状态，尽可能地缩短恢复时间，并减少手动流程导致的错误。将测试工具与管道工作流程集成，以便一致地开展测试并尽可能减少手动输入。确定优先执行的自动化测试案例，例如能够降低最大风险的测试案例，以及每次更改都需要频繁测试的测试案例。此外，还可以根据在测试计划中预定义的特定条件自动回滚。
### 实施步骤
1. 为开发生命周期建立测试生命周期，针对测试过程，从需求规划到测试案例开发、工具配置、自动化测试和测试案例关闭，对每个阶段进行定义。
1. 根据整体测试策略，创建特定于工作负载的测试方法。
1. 考虑在整个开发生命周期中适宜的阶段实施持续测试策略。
1. 根据业务要求和管道投资，选择用于测试和回滚的自动化工具。
1. 确定要自动执行哪些测试案例，以及应手动执行哪些测试案例。这个过程可以根据所测试功能的业务价值优先级来定义。确保所有团队成员都遵守该计划，并核实执行手动测试的责任人。
1. 在自动化测试可以实现价值的特定测试案例上使用自动化测试功能，例如可重复或经常运行的案例、需要重复任务的案例或者多种配置中所需的案例。
1. 在自动化工具中定义测试自动化脚本和成功标准，以便在特定案例失败时可以启动持续的自动化工作流程。
1. 为自动回滚定义具体的失败标准。
1. 优先考虑测试自动化，在过于复杂和人工交互会导致更高失败风险的案例中，通过开发全面的测试案例来获得一致的结果。
1. 将自动化测试和回滚工具集成到 CI/CD 管道中。
1. 为更改制定明确的成功标准。
1. 监控并观察以便检测这些标准，以及在满足特定回滚标准时自动撤销更改。
1. 执行不同类型的自动化生产测试，例如：
1. A/B 测试，显示在两个用户测试组之间当前版本的结果对比。
1. 金丝雀测试，允许先对一部分用户部署更改，然后再向所有用户发布。
1. 功能标记测试，允许在应用程序外部，每次将新版本的单个功能标记为打开和关闭，以便每次逐个验证各个新功能。
1. 回归测试，用于验证现有相互关联组件的新功能。
1. 监控应用程序的操作情况、事务，以及与其他应用程序和组件的交互。编制报告，用于按工作负载显示更改是否成功，以便确定对自动化和工作流程的哪些部分进一步进行优化。
1. 编制测试结果报告，以便快速决定是否应调用回滚程序。
1. 实施策略，以便根据一种或多种测试方法的预定义失败条件进行自动回滚。
1. 开发自动化测试案例，以便在将来的可重复更改中重用。
**实施计划的工作量级别：**中
## 资源
**相关最佳实践：**
+ [OPS06-BP01 针对不成功的更改制定计划](ops_mit_deploy_risks_plan_for_unsucessful_changes.md)
+ [OPS06-BP02 测试部署](ops_mit_deploy_risks_test_val_chg.md)
**相关文档：**
+ [AWS Builders Library \$1 确保部署期间安全回滚](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments/)
+ [Redeploy and rollback a deployment with AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html)
+ [ 8 best practices when automating your deployments with AWS CloudFormation](https://aws.amazon.com/blogs/infrastructure-and-automation/best-practices-automating-deployments-with-aws-cloudformation/)
**相关示例：**
+ [Serverless UI testing using Selenium, AWS Lambda, AWS Fargate, and AWS Developer Tools](https://aws.amazon.com/blogs/devops/using-aws-codepipeline-aws-codebuild-and-aws-lambda-for-serverless-automated-ui-testing/)
**相关视频：**
+ [re:Invent 2020 \$1 Hands-off: Automating continuous delivery pipelines at Amazon](https://www.youtube.com/watch?v=ngnMj1zbMPY)
+ [re:Invent 2019 \$1 Amazon's Approach to high-availability deployment ](https://www.youtube.com/watch?v=bCgD2bX1LI4)
# OPS 7. 如何知道您已经准备好支持某种工作负载？
评估工作负载、流程及程序和工作人员的操作准备情况，以便了解与工作负载相关的操作风险。
**Topics**
+ [OPS07-BP01 确保员工能力](ops_ready_to_support_personnel_capability.md)
+ [OPS07-BP02 确保以一致的方式对运营准备情况进行审查](ops_ready_to_support_const_orr.md)
+ [OPS07-BP03 使用运行手册执行程序](ops_ready_to_support_use_runbooks.md)
+ [OPS07-BP04 根据行动手册调查问题](ops_ready_to_support_use_playbooks.md)
+ [OPS07-BP05 作出明智的决策来部署系统和变更](ops_ready_to_support_informed_deploy_decisions.md)
+ [OPS07-BP06 为生产工作负载创建支持计划](ops_ready_to_support_enable_support_plans.md)
# OPS07-BP01 确保员工能力
制定一种机制来验证是否有适当数量训练有素的员工来支持工作负载。必须针对构成工作负载的平台和服务对他们进行培训。为他们提供运营工作负载所需的知识。必须有足够训练有素的员工来支持工作负载的正常运营和排查发生的意外事件。拥有足够数量的员工，以便在值班和休假期间轮换，避免出现倦怠。
**期望结果：**
+ 在工作负载可用时，有足够训练有素的员工为工作负载提供支持。
+ 针对构成工作负载的软件和服务，对员工进行培训。
**常见反模式：**
+ 部署工作负载，但没有对团队成员进行培训来运营所使用的平台和服务。
+ 员工数量不足，无法支持轮流值班或休假。
**建立此最佳实践的好处：**
+ 拥有技能娴熟的团队成员能够为工作负载提供有效支持。
+ 有足够的团队成员，可以支持工作负载和实现轮流值班，同时降低出现倦怠的风险。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
确认是否有足够的训练有素的员工来支持工作负载。确认是否有足够的团队成员来执行正常运营活动，包括轮流值班。
**客户示例**
AnyCompany Retail 确保支持工作负载的团队配备了适当的人员，并经过培训。他们有足够的工程师支持轮流值班。他们针对构建工作负载的软件和平台对员工进行培训，并鼓励他们获得认证。他们有足够的员工，所以员工可以休假，同时仍然可以支持工作负载和轮流值班。
### 实施步骤
1. 分配足够数量的人员来运营和支持工作负载，包括随叫随到的职责、安全问题和生命周期事件，如终止支持和证书轮换任务。
1. 针对构成工作负载的软件和平台方面对员工进行培训。
1. [AWS 培训和认证](https://aws.amazon.com/training/)有一个关于 AWS 的课程库。这里提供线上和线下的免费和付费课程。
1. [AWS 举办活动和网络研讨会](https://aws.amazon.com/events/)，可以从中向 AWS 专家学习。
1. 定期执行以下操作：
+ 随着运营条件和工作负载发生变化，评估团队规模和技能。
+ 调整团队规模和技能来满足运营要求。
+ 验证通过 AWS Health 来[解决计划内生命周期事件](https://docs.aws.amazon.com/health/latest/ug/aws-health-planned-lifecycle-events.html)、计划外安全性和运营通知的能力。
**实施计划的工作量级别：**高。雇用和培训团队来支持工作负载需要付出巨大的努力，但可带来可观的长期效益。
## 资源
**相关最佳实践：**
+ [OPS11-BP04 执行知识管理](ops_evolve_ops_knowledge_management.md) – 团队成员必须具备运营和支持工作负载所需的信息。知识管理是提供这些信息的关键。
**相关文档：**
+ [AWS 活动和网络研讨会](https://aws.amazon.com/events/)
+ [AWS 培训和认证](https://aws.amazon.com/training/)
# OPS07-BP02 确保以一致的方式对运营准备情况进行审查
使用运营准备情况审查（ORR），确保可以运营工作负载。ORR 是 Amazon 开发的一种机制，用于验证团队是否可以安全地运营工作负载。ORR 是一个使用要求核对清单进行审查和检查的过程。ORR 是一种自助服务体验，供团队用于验证其工作负载。ORR 中包含的最佳实践源自我们多年构建软件的经验教训。
ORR 核对清单包括架构推荐、运营流程、事件管理和发布质量。我们的错误更正（CoE）流程是这些项目的主要推动因素。意外事件后分析应该可以推动自己的 ORR 演进。ORR 不仅在于遵循最佳实践，还在于预防以前的事件再次发生。最后，ORR 中还可以包括安全、治理和合规性方面的要求。
在工作负载正式公开发布之前运行 ORR，然后在整个软件开发生命周期中运行 ORR。在发布之前运行 ORR 可以提升安全运营工作负载的能力。在工作负载上定期重新运行 ORR 可以收集任何偏离最佳实践的情况。可以准备用于新服务发布的 ORR 核对清单以及用于定期审查的 ORR。这有助于遵循最新制定的最佳实践，并吸取从意外事件后分析中学到的经验教训。随着对云的使用日趋成熟，可以将 ORR 要求作为默认设置整合到自己的架构中。
**期望结果：**已准备好 ORR 核对清单，其中包括适用于组织的最佳实践。在工作负载发布之前执行 ORR。在整个工作负载生命周期中定期执行 ORR。
**常见反模式：**
+ 您启动了工作负载，但不知道自己是否能够运营工作负载。
+ 在验证工作负载以便发布时，没有包括治理和安全要求。
+ 没有定期重新评估工作负载。
+ 在未准备好所需程序的情况下发布工作负载。
+ 在多个工作负载中发现相同的根本原因反复导致出现故障。
**建立此最佳实践的好处：**
+ 工作负载包括架构、流程和管理最佳实践。
+ 学到的经验教训可合并到 ORR 流程中。
+ 在工作负载发布时已准备好所需程序。
+ 在工作负载的整个软件生命周期中执行 ORR。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
ORR 关系到两点：流程和核对清单。ORR 流程应该由组织采用并获得执行发起人支持。至少，在工作负载正式公开发布之前执行 ORR。在整个软件开发生命周期中执行 ORR，可确保软件始终遵循新的最佳实践或新要求。ORR 核对清单应包括组织的配置项目、安全要求和治理要求以及最佳实践。随着时间的推移，可以使用 [AWS Config](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) 和 [AWS Control Tower Guardrails](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html) 等服务将源自 ORR 的最佳实践构建到防护机制中，以便自动检测最佳实践。
**客户示例**
在经历了多起生产意外事件之后，AnyCompany Retail 决定实施 ORR 流程。他们构建了核对清单，其中包括最佳实践、治理要求和合规性要求，以及从中断中学到的经验教训。他们在发布新工作负载之前执行 ORR。每个工作负载会每年执行一次 ORR，其中包括一小组最佳实践，用于整合添加到 ORR 核对清单中的新最佳实践和要求。随着时间的推移，AnyCompany Retail 使用 [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) 来检测某些最佳实践，加快了 ORR 流程。
**实施步骤**
有关 ORR 的更多信息，请阅读《[Operational Readiness Reviews（ORR）白皮书](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html)》。其中详细介绍了 ORR 流程的历史、如何构建自己的 ORR 实践，以及如何制定自己的 ORR 核对清单。以下步骤是该文档的缩减版本。如需深入了解什么是 ORR 以及如何自行构建，建议阅读该白皮书。
1. 让关键利益相关方聚在一起讨论，包括来自安全、运营和开发部门的代表。
1. 让每个利益相关方至少提一项要求。对于第一次迭代，请尝试将项目数限制为不超过三十个。
+ [Appendix B: Example ORR questions](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/appendix-b-example-orr-questions.html) 源自《Operational Readiness Reviews（ORR）白皮书》，包含在开始着手时可借鉴的示例问题。
1. 在电子表格中收集要求。
+ 您可以使用 [AWS Well-Architected Tool](https://console.aws.amazon.com/wellarchiected/) 中的[自定义剖析](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html)来开发 ORR，并在账户和 AWS 组织中共享这些剖析。
1. 确定一个工作负载来执行 ORR。最好选择发布前的工作负载或内部工作负载。
1. 运行 ORR 核对清单并记录任何发现结果。如果采取了缓解措施，发现结果可能是可接受的。对于任何没有防范措施的发现结果，请将它们记录到项目的积压工作项中，并在发布之前处理它们。
1. 在一段时间后，继续在 ORR 核对清单中添加最佳实践和要求。
使用 Enterprise Support 的 支持 客户可以向其技术客户经理申请[运营准备情况审查讲习会](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/)。该讲习会是一个交互式*逆向工作*会议，旨在制定自己的 ORR 核对清单。
**实施计划的工作量级别：**高。在组织中采用 ORR 实践需要获得高管支持以及利益相关方的支持。利用整个组织的意见来构建和更新核对清单。
## 资源
**相关最佳实践：**
+ [OPS01-BP03 评估治理要求](ops_priorities_governance_reqs.md) – 治理要求非常适合包括在 ORR 核对清单中。
+ [OPS01-BP04 评估合规性要求](ops_priorities_compliance_reqs.md) – 合规性要求有时候包括在 ORR 核对清单中。另一些时候它们可作为单独的流程。
+ [OPS03-BP07 为团队配置适当的资源](ops_org_culture_team_res_appro.md) – 团队能力是适合加入 ORR 要求的候选项。
+ [OPS06-BP01 针对不成功的更改制定计划](ops_mit_deploy_risks_plan_for_unsucessful_changes.md) – 在发布工作负载之前，必须建立回滚或前滚计划。
+ [OPS07-BP01 确保员工能力](ops_ready_to_support_personnel_capability.md) – 为了支持工作负载，必须具备所需的人员。
+ [SEC01-BP03 确定和验证控制目标](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_control_objectives.html) – 安全控制目标进一步完善了 ORR 要求。
+ [REL13-BP01 定义停机和数据丢失的恢复目标](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_objective_defined_recovery.html) – 灾难恢复计划是一项很好的 ORR 要求。
+ [COST02-BP01 根据组织要求制定政策](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_govern_usage_policies.html) – 成本管理政策非常适合包含在 ORR 核对清单中。
**相关文档：**
+ [AWS Control Tower - Guardrails in AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html)
+ [AWS Well-Architected Tool - Custom Lenses](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html)
+ [Operational Readiness Review Template by Adrian Hornsby](https://medium.com/the-cloud-architect/operational-readiness-review-template-e23a4bfd8d79)
+ [Operational Readiness Reviews（ORR）白皮书](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html)
**相关视频：**
+ [AWS 支持s You \$1 Building an Effective Operational Readiness Review (ORR)](https://www.youtube.com/watch?v=Keo6zWMQqS8)
**相关示例：**
+ [运营准备情况审查（ORR）剖析示例](https://github.com/aws-samples/custom-lens-wa-sample/tree/main/ORR-Lens)
**相关服务：**
+ [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)
+ [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)
+ [AWS Well-Architected Tool](https://docs.aws.amazon.com/wellarchitected/latest/userguide/intro.html)
# OPS07-BP03 使用运行手册执行程序
*运行手册*是实现特定结果的书面流程。运行手册由人们为完成某件事而遵循的一系列步骤组成。早在航空发展的早期，运行手册便已用于运营。在云运营中，我们使用运行手册来降低风险并实现期望结果。简单而言，运行手册就是完成一项任务的核对清单。
运行手册是运营工作负载的重要组成部分。从新团队成员入职到部署主要版本，运行手册都是一个成文的流程，无论谁使用，都能获得一致的结果。运行手册应发布在中央位置，并随着流程的发展而更新，因为更新运行手册是变更管理流程的一个关键组成部分。运行手册还应包括关于错误处理、工具、权限、异常和出现问题时进行上报的指导。
随着组织日益成熟，应开始实现运行手册自动化。从简短且经常使用的运行手册开始。使用脚本语言来实现步骤自动化或让步骤更容易执行。自动化前几本运行手册后，将花时间自动化更复杂的运行手册。随着时间的推移，大多数运行手册应以某种方式实现自动化。
**期望结果：**团队有一系列执行工作负载任务的分步指南。运行手册包含期望结果、必要的工具和权限，以及关于错误处理的说明。运行手册存储在一个中央位置（版本控制系统）并经常更新。例如，在应用程序发出警报、出现操作问题和计划内生命周期事件期间，运行手册可为团队提供监控、沟通和响应关键账户 AWS Health 事件的功能。
**常见反模式：**
+ 依靠记忆完成流程的每个步骤。
+ 手动部署更改而不使用核对清单。
+ 不同的团队成员执行相同的流程，但执行不同的步骤或取得不同的结果。
+ 运行手册与系统更改和自动化不同步。
**建立此最佳实践的好处：**
+ 降低手动任务的错误率。
+ 以一致的方式执行操作。
+ 新的团队成员可以更早地开始执行任务。
+ 可以自动化运行手册来减少工作量。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
根据组织的成熟程度，运行手册可以采用多种形式。它们至少应该包含一个分步文本文档。应明确指出期望结果。清楚地记录必要的特殊权限或工具。提供关于错误处理和出现问题时进行上报的详细指导。列出运行手册负责人，并将运行手册发布在中央位置。一旦运行手册编写完成，让团队中的其他人运行它来进行验证。随着程序的发展，根据变更管理流程更新运行手册。
随着组织日益成熟，文本运行手册应实现自动化。使用 [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 等服务，可以将纯文本转换为可以根据工作负载运行的自动化代码。这些自动化代码可以根据发生的事件运行，从而减轻维持工作负载的运营负担。AWSSystems Manager Automation 还提供了低代码[视觉对象设计体验](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-visual-designer.html)，可以更轻松地创建自动化运行手册。
**客户示例**
AnyCompany Retail 必须在软件部署期间执行数据库架构更新。云运营团队与数据库管理团队合作，构建了一个用于手动部署这些更改的运行手册。该运行手册以核对清单的形式列出了流程中的每个步骤。其中有一节是关于出错时的错误处理。他们在内部 Wiki 上发布了该运行手册和其他运行手册。云运营团队计划在未来的冲刺阶段实现运行手册的自动化。
### 实施步骤
如果当前没有文档存储库，则版本控制存储库是开始构建运行手册库的理想之处。可以使用 Markdown 构建运行手册。我们提供了一个示例运行手册模板，您可以用该模板开始构建运行手册。
```
# Runbook Title
## Runbook Info
| Runbook ID | Description | Tools Used | Special Permissions | Runbook Author | Last Updated | Escalation POC |
|-------|-------|-------|-------|-------|-------|-------|
| RUN001 | What is this runbook for? What is the desired outcome? | Tools | Permissions | Your Name | 2022-09-21 | Escalation Name |
## Steps
1. Step one
2. Step two
```
1. 如果当前没有文档存储库或 Wiki，请在版本控制系统中创建一个新的版本控制存储库。
1. 确定没有运行手册的流程。理想流程是半定期执行的流程，步骤少，且故障影响小。
1. 在文档存储库中，使用模板创建新的草稿 Markdown 文档。填写运行手册书名以及“运行手册信息”下的必填字段。
1. 从第一步开始，填写运行手册的“步骤”部分。
1. 将运行手册分发给团队成员。让他们使用运行手册来验证这些步骤。如果有遗漏或需要澄清的地方，请更新运行手册。
1. 将运行手册发布到内部文档存储区。发布后，告诉团队和其他利益相关方。
1. 随着时间的推移，将构建运行手册库。随着该库的增长，开始努力实现运行手册的自动化。
**实施计划的工作量级别：**低。运行手册的最低标准是一个分步文本指南。实现运行手册自动化可能会增加实施工作量。
## 资源
**相关最佳实践：**
+ [OPS02-BP02 确定流程和程序负责人](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_proc_owners.html)
+ [OPS07-BP04 根据行动手册调查问题](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_playbooks.html)
+ [OPS10-BP01 使用流程来管理事件、意外事件和问题](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_event_incident_problem_process.html)
+ [OPS10-BP02 针对每个警报设置一个流程](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_process_per_alert.html)
+ [OPS11-BP04 执行知识管理](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html)
**相关文档：**
+ [Achieving Operational Excellence using automated playbook and runbook](https://aws.amazon.com/blogs/mt/achieving-operational-excellence-using-automated-playbook-and-runbook/)
+ [AWS Systems Manager：使用运行手册](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
+ [Migration playbook for AWS large migrations - Task 4: Improving your migration runbooks](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-migration-playbook/task-four-migration-runbooks.html)
+ [Use AWS Systems Manager Automation runbooks to resolve operational tasks](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/)
**相关视频：**
+ [AWS re:Invent 2019: DIY guide to runbooks, incident reports, and incident response](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [How to automate IT Operations on AWS \$1 Amazon Web Services](https://www.youtube.com/watch?v=GuWj_mlyTug)
+ [Integrate Scripts into AWS Systems Manager](https://www.youtube.com/watch?v=Seh1RbnF-uE)
**相关示例：**
+ [Well-Architected Lab：使用行动手册和运行手册实现运营自动化](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
+ [AWS 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 Systems Manager：自动化演练](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html)
+ [AWS Systems Manager：从最新的快照运行手册中还原根卷](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-document-sample-restore.html)
+ [Building an AWS incident response runbook using Jupyter notebooks and CloudTrail Lake](https://catalog.us-east-1.prod.workshops.aws/workshops/a5801f0c-7bd6-4282-91ae-4dfeb926a035/en-US)
+ [Gitlab – 运行手册](https://gitlab.com/gitlab-com/runbooks)
+ [Rubix – 用于在 Jupyter Notebook 中构建运行手册的 Python 库](https://github.com/Nurtch/rubix)
+ [使用文档生成器创建自定义运行手册](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html)
**相关服务：**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
# OPS07-BP04 根据行动手册调查问题
*行动手册*是用于调查意外事件的分步指南。发生意外事件时，行动手册用于开展调查，以及确定影响范围和根本原因。行动手册可用于从失败部署到安全事件的各种场景。在许多情况下，行动手册可确定根本原因，而运行手册可用来缓解根本原因带来的风险。行动手册是组织意外事件响应计划的必要组成部分。
出色的行动手册有几个主要特点。它逐步指导用户完成事件的发现过程。引导用户由外而内地进行思考，应执行哪些步骤来诊断意外事件？ 如果行动手册中需要特殊工具或提升的权限，行动手册中会明确定义。制定沟通计划，以便向利益相关方提供有关调查状态的最新信息，这是事件响应计划的关键组成部分。在无法确定根本原因的情况下，行动手册应具有上报计划。如果确定了根本原因，行动手册应指向介绍如何解决根本原因的运行手册。行动手册应集中存储并定期维护。如果行动手册用于特定提醒，请向团队提供关于提醒中行动手册的提示。
随着组织日趋成熟，可自动实施行动手册。从包含低风险意外事件的行动手册开始实施。使用脚本自动执行发现步骤。确保有配套的运行手册来缓解常见根本原因带来的风险。
**期望结果**：组织有针对常见意外事件的行动手册。行动手册存储在中心位置，可供团队成员使用。行动手册经常进行更新。对于任何已知的根本原因，将制定配套的运行手册。
**常见反模式：**
+ 没有调查意外事件的标准方法。
+ 团队成员依靠肌肉记忆或对机构的了解，对失败的部署进行故障排除。
+ 新的团队成员将了解如何通过试错法来调查问题。
+ 调查问题的最佳实践无法在团队间分享。
**建立此最佳实践的好处：**
+ 行动手册有助于缓解意外事件带来的影响。
+ 不同的团队成员可使用同一行动手册，以一致的方式确定根本原因。
+ 可以针对已知的根本原因制定运行手册，从而加快恢复速度。
+ 团队成员根据行动手册能够更快地开始行动。
+ 团队可以使用可重复的行动手册来扩展其流程。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
制定和使用行动手册的方式取决于组织的成熟度。如果是初次使用云，请在中央文档存储库中以文本形式制定行动手册。随着组织日趋成熟，可以使用 Python 等脚本语言实现行动手册的半自动化。可以在 Jupyter Notebook 中运行这些脚本来加快发现速度。先进的组织已针对可通过运行手册自动修正的常见问题，制定了完全自动化的行动手册。
通过列出工作负载所发生的常见意外事件，开始制定行动手册。为风险较低且根本原因范围已缩小到几个问题的意外事件选择行动手册。在为较简单的场景制定行动手册后，可以着手处理风险较高的场景或根本原因尚不确定的场景。
随着组织日趋成熟，文本形式的行动手册应实现自动化。使用 [AWS Systems Manager Automations](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 等服务，可以将纯文本转换为自动化代码。可以针对工作负载运行这些自动化代码，从而加快调查速度。可以激活这些自动化代码来响应事件，从而减少发现和解决意外事件所需的平均时间。
客户可以使用 [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) 来响应意外事件。此服务提供了一个单一界面，可对意外事件进行分类、在发现和缓解问题期间通知利益相关方，并在整个意外事件中进行协作。其使用 AWS Systems Manager Automations 加快检测和恢复的速度。
**客户示例**
一个生产意外事件影响了 AnyCompany Retail。随时待命的工程师根据行动手册调查了问题。随着他们逐步地解决问题，他们不断为行动手册中确定的关键利益相关方提供最新信息。工程师最终确定，根本原因是后端服务中出现竞态条件。根据运行手册，工程师重新启动了该服务，并使 AnyCompany Retail 重新联机。
### 实施步骤
如果当前没有文档存储库，建议为行动手册库创建版本控制存储库。可以使用 Markdown 制定行动手册，该服务与大多数行动手册自动化系统兼容。如果从头开始制定行动手册，请使用以下行动手册示例模板。
```
# Playbook Title
## Playbook Info
| Playbook ID | Description | Tools Used | Special Permissions | Playbook Author | Last Updated | Escalation POC | Stakeholders | Communication Plan |
|-------|-------|-------|-------|-------|-------|-------|-------|-------|
| RUN001 | What is this playbook for? What incident is it used for? | Tools | Permissions | Your Name | 2022-09-21 | Escalation Name | Stakeholder Name | How will updates be communicated during the investigation? |
## Steps
1. Step one
2. Step two
```
1. 如果当前没有文档存储库或 Wiki，请在版本控制系统中为行动手册创建一个新的版本控制存储库。
1. 确定需要进行调查的常见问题。这应该是根本原因范围限于几个问题且解决方案风险较低的场景。
1. 利用 Markdown 模板，填写“行动手册书名”部分，并填写“行动手册信息”下的字段。
1. 填写故障排除步骤。尽可能清楚地填写要采取哪些行动，或者应调查哪些方面。
1. 将行动手册分发给团队成员，让他们仔细阅读并加以验证。如果发现有遗漏之处或某些内容不清楚，请更新行动手册。
1. 在文档存储库中发布行动手册，并告知团队和任何利益相关方。
1. 随着添加更多的行动手册，这个行动手册库将会不断扩大。拥有多个行动手册后，可以开始使用 AWS Systems Manager Automations 等工具自动执行行动手册，从而使自动化操作和行动手册保持同步。
**实施计划的工作量级别：**低。行动手册应该是存储在中心位置的文本文档。对于更加成熟的组织，将转为自动化行动手册。
## 资源
**相关最佳实践：**
+ [OPS02-BP02 确定流程和程序负责人](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_proc_owners.html)
+ [OPS07-BP03 使用运行手册执行程序](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_runbooks.html)
+ [OPS10-BP01 使用流程来管理事件、意外事件和问题](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_event_incident_problem_process.html)
+ [OPS10-BP02 针对每个警报设置一个流程](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_process_per_alert.html)
+ [OPS11-BP04 执行知识管理](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html)
**相关文档：**
+ [Achieving Operational Excellence using automated playbook and runbook](https://aws.amazon.com/blogs/mt/achieving-operational-excellence-using-automated-playbook-and-runbook/)
+ [AWS Systems Manager：使用运行手册](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
+ [Use AWS Systems Manager Automation runbooks to resolve operational tasks](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/)
**相关视频：**
+ [AWS re:Invent 2019: DIY guide to runbooks, incident reports, and incident response (SEC318-R1)](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [AWS Systems Manager Incident Manager - AWS 虚拟讲习会](https://www.youtube.com/watch?v=KNOc0DxuBSY)
+ [Integrate Scripts into AWS Systems Manager](https://www.youtube.com/watch?v=Seh1RbnF-uE)
**相关示例：**
+ [AWS 客户行动手册框架](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [AWS Systems Manager：自动化演练](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html)
+ [Building an AWS incident response runbook using Jupyter notebooks and CloudTrail Lake](https://catalog.workshops.aws/workshops/a5801f0c-7bd6-4282-91ae-4dfeb926a035/en-US)
+ [Rubix – 用于在 Jupyter Notebook 中构建运行手册的 Python 库](https://github.com/Nurtch/rubix)
+ [使用文档生成器创建自定义运行手册](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html)
**相关服务：**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html)
# OPS07-BP05 作出明智的决策来部署系统和变更
为工作负载的成功和不成功变更制定恰当的流程。故障演练是一种演习，团队模拟发生故障的情况来制定缓解策略。使用故障演练来预测故障，并在适当的时候创建程序。评估将变更部署到工作负载所获得益处和产生的风险。确认所有变更符合治理要求。
**期望结果：**
+ 将变更部署到工作负载时作出明智的决策。
+ 变更符合治理要求。
**常见反模式：**
+ 将变更部署到工作负载，而没有处理失败部署的流程。
+ 对生产环境作出不符合治理要求的变更。
+ 部署新版本的工作负载，而不为资源利用建立基准。
**建立此最佳实践的好处：**
+ 为工作负载的不成功变更做好了准备。
+ 工作负载的变更符合治理政策。
**在未建立这种最佳实践的情况下暴露的风险等级：**低
## 实施指导
使用故障演练制定不成功变更的流程。记录不成功变更的流程。确保所有变更均符合治理要求。评估将变更部署到工作负载所获得益处和产生的风险。
**客户示例**
AnyCompany Retail 定期执行故障演练来验证不成功变更的流程。他们在共享的 Wiki 中记录流程并经常更新。所有变更均符合治理要求。
**实施步骤**
1. 将变更部署到工作负载时作出明智的决策。确立并审查成功部署的条件。制定将启动变更回滚的方案或条件。在部署变更带来的好处与不成功变更产生的风险之间进行权衡。
1. 确认所有变更均符合治理政策。
1. 使用故障演练为不成功的变更制定计划，并记录缓解策略。运行桌面演练，为不成功的变更建模，并验证回滚程序。
**实施计划的工作量级别：**中。实施故障演练的实践需要整个组织内的利益相关方进行协调和付出努力
## 资源
**相关最佳实践：**
+ [OPS01-BP03 评估治理要求](ops_priorities_governance_reqs.md) – 治理要求是确定是否部署变更的关键因素。
+ [OPS06-BP01 针对不成功的更改制定计划](ops_mit_deploy_risks_plan_for_unsucessful_changes.md) – 制定计划来缓解失败的部署，并使用故障演练来进行验证。
+ [OPS06-BP02 测试部署](ops_mit_deploy_risks_test_val_chg.md) – 在部署之前应适当地测试每项软件变更，以便减少生产中的缺陷。
+ [OPS07-BP01 确保员工能力](ops_ready_to_support_personnel_capability.md) – 有足够训练有素的人员来支持工作负载，这对于作出部署系统变更的明智决策很重要。
**相关文档：**
+ [亚马逊云科技：风险与合规性](https://docs.aws.amazon.com/whitepapers/latest/aws-risk-and-compliance/welcome.html)
+ [AWS 责任共担模式](https://aws.amazon.com/compliance/shared-responsibility-model/)
+ [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/)
# OPS07-BP06 为生产工作负载创建支持计划
为生产工作负载所依赖的所有软件和服务启用支持。选择适当的支持级别来满足生产服务水平需求。以防出现服务中断或软件问题，这些依赖项的支持计划必不可少。记录支持计划以及如何向所有服务和软件供应商请求支持。实施机制，以便确认主要支持联系人的信息保持最新。
**期望结果：**
+ 为生产工作负载所依赖的软件和服务实施支持计划。
+ 根据服务水平需求选择适当的支持计划。
+ 记录支持计划、支持级别以及如何请求支持。
**常见反模式：**
+ 没有制定面向关键软件供应商的支持计划。工作负载受到影响，无法采取任何措施来加快修复或从供应商获得及时更新。
+ 作为软件供应商主要联系人的开发人员离开了公司。您无法直接联系供应商支持人员。您必须花时间研究和浏览通用联系系统，延长在需要时作出反应所需的时间。
+ 软件供应商发生生产中断。没有关于如何提出支持案例的文档。
**建立此最佳实践的好处：**
+ 通过适当的支持级别，可以在满足服务水平需求所需的时间范围内获得响应。
+ 作为受支持的客户，如果存在生产问题，您可以上报。
+ 发生意外事件时，软件和服务供应商可协助排除故障。
**在未建立这种最佳实践的情况下暴露的风险等级：**低
## 实施指导
为生产工作负载所依赖的所有软件和服务供应商启用支持计划。设置适当的支持计划来满足服务水平需求。对于 AWS 客户，这意味着要在具有生产工作负载的任何账户上激活 AWS Business Support 或更高级别的支持。定期与支持供应商会面，获取有关支持产品、流程和联系人的更新。记录如何向软件和服务供应商请求支持，包括在出现中断时如何上报。实施机制，让支持联系人的信息保持最新。
**客户示例**
在 AnyCompany Retail，所有商用软件和服务依赖项均有支持计划。例如，他们在具有生产工作负载的所有账户上都激活了 AWS Enterprise Support。如果出现问题，任何开发人员都可以提出支持案例。有一个 Wiki 页面，其中包含有关如何请求支持、向谁发出通知以及加快处理案例最佳实践的信息。
**实施步骤**
1. 与组织内的利益相关方合作确定工作负载所依赖的软件和服务供应商。记录这些依赖项。
1. 确定工作负载的服务水平需求。选择与需求匹配的支持计划。
1. 对于商用软件和服务，与供应商一起制定支持计划。
1. 为所有生产账户订阅 AWS Business Support 或更高级别的支持，可以让 AWS 支持 更快响应，强烈建议订阅此支持。如果没有高级支持，则必须制定行动计划来处理问题，而这需要 AWS 支持 的帮助。AWS 支持 提供工具和技术的组合、人员和计划，旨在主动协助您优化性能、降低成本和加快创新速度。此外，AWS Business Support 还提供其它优势，包括 API 对 AWS Trusted Advisor 和 AWS Health 的访问权限以便与系统进行编程集成，以及其它访问方法，例如 AWS 管理控制台和 Amazon EventBridge 渠道。
1. 在知识管理工具中记录支持计划。包括如何请求支持、在提出支持案例时向谁发出通知以及在发生意外事件时如何上报。Wiki 是一种很好的机制，让任何人都可以在发现支持流程或联系人的更改时对文档进行必要的更新。
**实施计划的工作量级别：**低。大部分软件和服务供应商都提供选择加入的支持计划。在知识管理系统中记录和分享支持最佳实践，可以确认团队是否知道在出现生产问题时该怎么做。
## 资源
**相关最佳实践：**
+ [OPS02-BP02 确定流程和程序负责人](ops_ops_model_def_proc_owners.md)
**相关文档：**
+ [AWS 支持 Plans](https://docs.aws.amazon.com/awssupport/latest/user/aws-support-plans.html)
**相关服务：**
+ [AWS Business Support](https://aws.amazon.com/premiumsupport/plans/business/)
+ [AWS Enterprise Support](https://aws.amazon.com/premiumsupport/plans/enterprise/)
# 操作
**Topics**
+ [OPS 8. 如何在组织中利用工作负载可观测性？](ops-08.md)
+ [OPS 9. 如何了解自己的运营状况？](ops-09.md)
+ [OPS 10. 如何应对工作负载事件和运营事件？](ops-10.md)
# OPS 8. 如何在组织中利用工作负载可观测性？
利用可观测性确保最佳工作负载运行状况。利用相关的指标、日志和跟踪数据，全面了解工作负载的性能并有效地解决问题。
**Topics**
+ [OPS08-BP01 分析工作负载指标](ops_workload_observability_analyze_workload_metrics.md)
+ [OPS08-BP02 分析工作负载日志](ops_workload_observability_analyze_workload_logs.md)
+ [OPS08-BP03 分析工作负载跟踪数据](ops_workload_observability_analyze_workload_traces.md)
+ [OPS08-BP04 创建可操作的警报](ops_workload_observability_create_alerts.md)
+ [OPS08-BP05 创建控制面板](ops_workload_observability_create_dashboards.md)
# OPS08-BP01 分析工作负载指标
实施应用程序遥测后，定期分析收集的指标。虽然延迟、请求、错误和容量（或配额）有助于深入了解系统性能，但优先审查业务成果指标至关重要。这样可以确保作出与业务目标相一致的数据驱动型决策。
**期望结果：**准确洞察工作负载性能，推动作出以数据为依据的决策，确保与业务目标相一致。
**常见反模式：**
+ 孤立地分析指标，而不考虑其对业务成果的影响。
+ 过度依赖技术指标，而不重视业务指标。
+ 很少审查指标，错过了实时决策机会。
**建立此最佳实践的好处：**
+ 进一步了解技术性能与业务成果之间的相互关系。
+ 以实时数据为依据改善决策流程。
+ 在问题影响业务成果之前主动发现和缓解问题。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
利用 Amazon CloudWatch 之类的工具执行指标分析。Amazon CloudWatch 异常检测和 Amazon DevOps Guru 之类的 AWS 服务可用于检测异常，尤其是在静态阈值未知，或行为模式更适合进行异常检测时。
### 实施步骤
1. **分析和审查：**定期审查和解读工作负载指标。
1. 优先考虑业务成果指标，而不是只考虑纯粹的技术指标。
1. 了解数据中高峰、低谷或模式的重要性。
1. **利用 Amazon CloudWatch：**使用 Amazon CloudWatch 获取集中视图和进行深入分析。
1. 配置 CloudWatch 控制面板，以可视化形式呈现指标，并对一段时间内的指标进行比较。
1. 使用 [CloudWatch 中的百分位数](https://aws-observability.github.io/observability-best-practices/guides/operational/business/sla-percentile/)来清楚地了解指标分布，这有助于定义 SLA 和理解异常值。
1. 设置 [CloudWatch 异常检测](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)，在不依赖静态阈值的情况下识别异常模式。
1. 实施 [CloudWatch 跨账户可观测性](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html)，以监控跨越一个区域内多个账户的应用程序并对其进行故障排除。
1. 使用 [CloudWatch Metric Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html) 来查询和分析跨账户和区域的指标数据，从而识别趋势和异常情况。
1. 应用 [CloudWatch 指标数学](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html)，对指标进行转换、汇总或执行计算，从而获得更深入的洞察。
1. **采用 Amazon DevOps Guru：**加入 [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/)，以便利用其机器学习增强的异常检测功能，识别无服务器应用程序操作问题的早期迹象，并在对客户造成影响之前将其修复。
1. **根据洞察进行优化**：根据指标分析作出明智的决策，以便调整和改进工作负载。
**实施计划的工作量级别：**中
## 资源
**相关最佳实践：**
+ [OPS04-BP01 确定关键绩效指标](ops_observability_identify_kpis.md)
+ [OPS04-BP02 实施应用程序遥测](ops_observability_application_telemetry.md)
**相关文档：**
+ [The Wheel b博客 – 强调持续审查指标的重要性](https://aws.amazon.com/blogs/opensource/the-wheel/)
+ [Percentile are important](https://aws-observability.github.io/observability-best-practices/guides/operational/business/sla-percentile/)
+ [使用 AWS Cost Anomaly Detection](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)
+ [CloudWatch 跨账户可观测性](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html)
+ [使用 CloudWatch Metrics Insights 查询您的指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html)
**相关视频：**
+ [Enable Cross-Account Observability in Amazon CloudWatch](https://www.youtube.com/watch?v=lUaDO9dqISc)
+ [Introduction to Amazon DevOps Guru](https://www.youtube.com/watch?v=2uA8q-8mTZY)
+ [Continuously Analyze Metrics using AWS Cost Anomaly Detection](https://www.youtube.com/watch?v=IpQYBuay5OE)
**相关示例：**
+ [One Observability 讲习会](https://catalog.workshops.aws/observability/en-US/intro)
+ [Gaining operation insights with AIOps using Amazon DevOps Guru](https://catalog.us-east-1.prod.workshops.aws/workshops/f92df379-6add-4101-8b4b-38b788e1222b/en-US)
# OPS08-BP02 分析工作负载日志
定期分析工作负载日志对于更深入地了解应用程序的运行方面至关重要。通过高效地筛选、以可视化方式呈现和解读日志数据，可以持续优化应用程序性能和安全性。
**期望结果：**通过全面的日志分析获得对应用程序行为和运行的丰富洞察，确保主动检测和缓解问题。
**常见反模式：**
+ 在出现严重问题之前，忽视对日志的分析。
+ 没有使用可进行日志分析的全套工具，导致错过关键洞察。
+ 仅依靠人工查看日志，而不利用自动化和查询功能。
**建立此最佳实践的好处：**
+ 主动发现运行瓶颈、安全威胁和其他潜在问题。
+ 高效利用日志数据进行持续的应用程序优化。
+ 增进对应用程序行为的理解，有助于进行调试和故障排除。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
[Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) 是一款用于日志分析的强大工具。利用 CloudWatch Logs Insights 和 Contributor Insights 等集成功能，可以直观且高效地从日志中获取有意义的信息。
### 实施步骤
1. **设置 CloudWatch Logs**：配置应用程序和服务，以便将日志发送到 CloudWatch Logs。
1. **使用日志异常检测：**利用 [Amazon CloudWatch Logs 异常检测功能](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/LogsAnomalyDetection.html)来自动识别异常日志模式并发出警报。该工具有助于主动管理日志中的异常情况，及早检测到潜在问题。
1. **设置 CloudWatch Logs Insights**：使用 [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) 以交互方式进行搜索，并分析日志数据。
1. 创建查询来提取模式、以可视化形式呈现日志数据并获得切实可行的洞察。
1. 使用 [CloudWatch Logs Insights 模式分析](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_AnalyzeLogData_Patterns.html)来分析和可视化频繁使用的日志模式。该功能有助于了解日志数据中的常见运行趋势和潜在异常值。
1. 使用 [CloudWatch Logs 比较（diff）](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_AnalyzeLogData_Compare.html)对不同时间段或不同日志组之间进行差异分析。利用这一功能可查明变更，并评测其对系统性能或行为的影响。
1. **使用 Live Tail 实时监控日志：**使用 [Amazon CloudWatch Logs Live Tail](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CloudWatchLogs_LiveTail.html) 实时查看日志数据。可以在应用程序运行活动发生时主动对其进行监控，即时了解系统性能和潜在问题。
1. **利用 Contributor Insights**：使用 [CloudWatch Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html) 来识别 IP 地址或用户代理等高基数维度的用量最高者。
1. **实施 CloudWatch Logs 指标筛选条件**：配置 [CloudWatch Logs 指标筛选条件](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)，将日志数据转换为可操作的指标。这允许设置警报或进一步分析模式。
1. **实施 [CloudWatch 跨账户可观测性](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html)：**监控跨越一个区域内多个账户的应用程序并对其进行故障排除。
1. **定期审查和完善**：定期审查日志分析策略，以便捕获所有相关信息并持续优化应用程序性能。
**实施计划的工作量级别：**中
## 资源
**相关最佳实践：**
+ [OPS04-BP01 确定关键绩效指标](ops_observability_identify_kpis.md)
+ [OPS04-BP02 实施应用程序遥测](ops_observability_application_telemetry.md)
+ [OPS08-BP01 分析工作负载指标](ops_workload_observability_analyze_workload_metrics.md)
**相关文档：**
+ [Analyzing Log Data with CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ [Using CloudWatch Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html)
+ [Creating and Managing CloudWatch Log Metric Filters](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
**相关视频：**
+ [Analyze Log Data with CloudWatch Logs Insights](https://www.youtube.com/watch?v=2s2xcwm8QrM)
+ [Use CloudWatch Contributor Insights to Analyze High-Cardinality Data](https://www.youtube.com/watch?v=ErWRBLFkjGI)
**相关示例：**
+ [CloudWatch Logs Sample Queries](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [One Observability 讲习会](https://catalog.workshops.aws/observability/en-US/intro)
# OPS08-BP03 分析工作负载跟踪数据
分析跟踪数据对于全面了解应用程序的操作过程至关重要。通过以可视化方式呈现和理解各个组件之间的交互情况，可以微调性能，识别瓶颈并增强用户体验。
**期望结果：**清晰地了解应用程序的分布式操作，从而更快地解决问题并增强用户体验。
**常见反模式：**
+ 忽略跟踪数据，仅依赖日志和指标。
+ 不将跟踪数据与关联日志联系起来。
+ 忽略从跟踪数据中得出的指标，例如延迟和故障率。
**建立此最佳实践的好处：**
+ 改善故障排除并缩短平均解决时间（MTTR）。
+ 深入了解依赖项及其影响。
+ 迅速发现并纠正性能问题。
+ 利用从跟踪数据中得出的指标作出明智的决策。
+ 通过优化的组件交互来改善用户体验。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
[AWS X-Ray](https://www.docs.aws.com/xray/latest/devguide/aws-xray.html) 提供了分析跟踪数据的完整套件，可提供服务交互的整体视图、监控用户活动并检测性能问题。ServiceLens、X-Ray Insights、X-Ray Analytics 和 Amazon DevOps Guru 等功能，可增强从跟踪数据中获得的可行洞察的深度。
### 实施步骤
以下步骤提供了一种结构化方法，以便使用 AWS 服务有效地实施跟踪数据分析：
1. **集成 AWS X-Ray**：确保 X-Ray 已与应用程序集成，以便捕获跟踪数据。
1. **分析 X-Ray 指标**：使用[服务地图](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-servicemap.html#xray-console-servicemap-view)深入研究从 X-Ray 跟踪数据中得出的指标，例如延迟、请求率、故障率和响应时间分布等，以便监控应用程序的运行状况。
1. **使用 ServiceLens**：利用 [ServiceLens 地图](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/servicelens_service_map.html)增强服务和应用程序的可观测性。这允许以集成方式查看跟踪数据、指标、日志、警报和其他运行状况信息。
1. **启用 X-Ray Insights**：
1. 开启 [X-Ray Insights](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-insights.html)，可自动检测跟踪数据中的异常情况。
1. 研究洞察以查明模式并确定根本原因，例如故障率或延迟增加。
1. 查阅洞察时间表，按时间顺序分析检测到的问题。
1. **使用 X-Ray Analytics**：[X-Ray Analytics](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-analytics.html) 允许全面探索跟踪数据、查明模式并提取洞察。
1. **使用 X-Ray 中的组**：在 X-Ray 中创建组，根据高延迟等标准筛选跟踪数据，从而进行更有针对性的分析。
1. **加入 Amazon DevOps Guru**：利用 [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/) 从机器学习模型中受益，查明跟踪数据中的操作异常。
1. **使用 CloudWatch Synthetics**：使用 [CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries_tracing.html) 创建用于持续监控端点和工作流程的金丝雀。这些金丝雀可以与 X-Ray 集成来提供跟踪数据，用于对正在测试的应用程序进行深入分析。
1. **使用真实用户监控（RUM）**：借助 [AWS X-Ray 和 CloudWatch RUM](https://docs.aws.amazon.com/xray/latest/devguide/xray-services-RUM.html)，可以分析和调试从应用程序的终端用户开始，经过下游 AWS 托管服务的请求路径。可帮助您识别影响最终用户的延迟趋势和错误。
1. **与日志关联**：将[跟踪数据与 X-Ray 跟踪视图中的相关日志关联](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/servicelens_troubleshooting.html#servicelens_troubleshooting_Nologs)，从而详细了解应用程序行为。这允许查看与跟踪的事务直接关联的日志事件。
1. **实施 [CloudWatch 跨账户可观测性](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html)：**监控跨越一个区域内多个账户的应用程序并对其进行故障排除。
**实施计划的工作量级别：**中
## 资源
**相关最佳实践：**
+ [OPS08-BP01 分析工作负载指标](ops_workload_observability_analyze_workload_metrics.md)
+ [OPS08-BP02 分析工作负载日志](ops_workload_observability_analyze_workload_logs.md)
**相关文档：**
+ [Using ServiceLens to Monitor Application Health](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ServiceLens.html)
+ [Exploring Trace Data with X-Ray Analytics](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-analytics.html)
+ [Detecting Anomalies in Traces with X-Ray Insights](https://docs.aws.amazon.com/xray/latest/devguide/xray-insights.html)
+ [Continuous Monitoring with CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
**相关视频：**
+ [Analyze and Debug Applications Using Amazon CloudWatch Synthetics & AWS X-Ray](https://www.youtube.com/watch?v=s2WvaV2eDO4)
+ [使用 AWS X-Ray Insights](https://www.youtube.com/watch?v=tl8OWHl6jxw)
**相关示例：**
+ [One Observability 讲习会](https://catalog.workshops.aws/observability/en-US/intro)
+ [使用 AWS Lambda 实施 X-Ray](https://docs.aws.amazon.com/lambda/latest/dg/services-xray.html)
+ [CloudWatch Synthetics Canary Templates](https://github.com/aws-samples/cloudwatch-synthetics-canary-terraform)
# OPS08-BP04 创建可操作的警报
及时检测和响应应用程序行为的偏差至关重要。尤其重要的是，认识到基于关键绩效指标（KPI）的结果何时面临风险或何时出现意外异常。基于 KPI 的警报可确保收到的信号与业务或运营影响直接相关。这种可操作警报的方法可促进主动响应，并有助于维护系统性能和可靠性。
**期望结果：**接收及时、相关且可操作的警报，以便快速发现和缓解潜在问题，尤其是在 KPI 结果面临风险时。
**常见反模式：**
+ 设置过多非关键警报，导致警报疲劳。
+ 不根据 KPI 对警报进行优先级排序，因此很难了解问题对业务的影响。
+ 忽视解决根本原因，导致针对同一问题出现重复警报。
**建立此最佳实践的好处：**
+ 关注可操作的相关警报，减少警报疲劳。
+ 主动检测和缓解问题，增加系统的正常运行时间并提高可靠性。
+ 与常用的警报和通信工具集成，增强团队协作并更快解决问题。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
要创建有效的警报机制，必须使用指标、日志和跟踪数据来标记基于 KPI 的结果何时存在风险，或何时检测到异常情况。
### 实施步骤
1. **确定关键绩效指标（KPI）**：确定应用程序的 KPI。警报应与这些 KPI 相关联，以便准确反映业务影响。
1. **实施异常检测**：
+ **使用 Amazon CloudWatch 异常检测**：将 [Amazon CloudWatch 异常检测](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)设置为自动检测异常模式，这有助于仅针对真正的异常生成警报。
+ **使用 AWS X-Ray Insights**：
1. 设置 [X-Ray Insights](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-insights.html)，检测跟踪数据中的异常。
1. 配置 [X-Ray Insights 的通知](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-insights.html#xray-console-insight-notifications)，以便在检测到问题时收到警报。
+ **与 Amazon DevOps Guru 集成**：
1. 利用 [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/) 的机器学习功能，结合现有数据来检测操作异常。
1. 导航到 DevOps Guru 中的[通知设置](https://docs.aws.amazon.com/devops-guru/latest/userguide/update-notifications.html#navigate-to-notification-settings)以设置异常警报。
1. **实施可操作的警报**：设计能够提供足够信息的警报，以便立即采取行动。
1. [使用 Amazon EventBridge 规则监控 AWS Health 事件](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html)，或者以编程方式与 AWS Health API 集成，以便在收到 AWS Health 事件时自动执行操作。这些可以是常规操作，例如将所有计划的生命周期事件消息发送到聊天界面，也可以是特定操作，例如在 IT 服务管理工具中启动工作流程。
1. **减少警报疲劳**：尽量减少非关键警报。团队接收到大量无关紧要的警报时，他们可能无法监督关键问题，从而降低警报机制的整体有效性。
1. **设置复合警报**：使用 [Amazon CloudWatch 复合警报](https://aws.amazon.com/bloprove-monitoring-efficiency-using-amazon-cloudwatch-composite-alarms-2/)合并多个警报。
1. **与警报工具集成**：纳入 [Ops Genie](https://www.atlassian.com/software/opsgenie) 和 [PagerDuty](https://www.pagerduty.com/) 等工具。
1. **加入聊天应用程序中的 Amazon Q 开发者版**：集成[聊天应用程序中的 Amazon Q 开发者版](https://aws.amazon.com/chatbot/)，以便将警报转发给 Amazon Chime、Microsoft Teams 和 Slack。
1. **基于日志的警报**：使用 CloudWatch 中的[日志指标筛选条件](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)，根据特定的日志事件创建警报。
1. **审查和迭代**：定期重新审视和完善警报配置。
**实施计划的工作量级别：**中
## 资源
**相关最佳实践：**
+ [OPS04-BP01 确定关键绩效指标](ops_observability_identify_kpis.md)
+ [OPS04-BP02 实施应用程序遥测](ops_observability_application_telemetry.md)
+ [OPS04-BP03 实施用户体验遥测](ops_observability_customer_telemetry.md)
+ [OPS04-BP04 实施依赖项遥测](ops_observability_dependency_telemetry.md)
+ [OPS04-BP05 实施分布式跟踪](ops_observability_dist_trace.md)
+ [OPS08-BP01 分析工作负载指标](ops_workload_observability_analyze_workload_metrics.md)
+ [OPS08-BP02 分析工作负载日志](ops_workload_observability_analyze_workload_logs.md)
+ [OPS08-BP03 分析工作负载跟踪数据](ops_workload_observability_analyze_workload_traces.md)
**相关文档：**
+ [使用 Amazon CloudWatch 告警](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Create a composite alarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html)
+ [Create a CloudWatch alarm based on anomaly detection](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Anomaly_Detection_Alarm.html)
+ [DevOps Guru Notifications](https://docs.aws.amazon.com/devops-guru/latest/userguide/update-notifications.html)
+ [X-ray insights notifications](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-insights.html#xray-console-insight-notifications)
+ [使用交互式 ChatOps 对 AWS 资源进行监控、操作和故障排除](https://aws.amazon.com/chatbot/)
+ [Amazon CloudWatch Integration Guide \$1 PagerDuty](https://support.pagerduty.com/docs/amazon-cloudwatch-integration-guide)
+ [Integrate Opsgenie with Amazon CloudWatch](https://support.atlassian.com/opsgenie/docs/integrate-opsgenie-with-amazon-cloudwatch/)
**相关视频：**
+ [Create Composite Alarms in Amazon CloudWatch](https://www.youtube.com/watch?v=0LMQ-Mu-ZCY)
+ [Amazon Q Developer in chat applications Overview](https://www.youtube.com/watch?v=0jUSEfHbTYk)
+ [AWS On Air ft. Mutative Commands in Amazon Q Developer in chat applications](https://www.youtube.com/watch?v=u2pkw2vxrtk)
**相关示例：**
+ [Alarms, incident management, and remediation in the cloud with Amazon CloudWatch](https://aws.amazon.com/bloarms-incident-management-and-remediation-in-the-cloud-with-amazon-cloudwatch/)
+ [Tutorial: Creating an Amazon EventBridge rule that sends notifications to Amazon Q Developer in chat applications](https://docs.aws.amazon.com/chatbot/latest/adminguide/create-eventbridge-rule.html)
+ [One Observability 讲习会](https://catalog.workshops.aws/observability/en-US/intro)
# OPS08-BP05 创建控制面板
控制面板是以人为本的视图，可用于查看工作负载的遥测数据。虽然控制面板提供了重要的可视化界面，但不应取代警报机制，而是作为警报机制的补充。经过精心设计的控制面板不仅能迅速洞察系统的运行状况和性能，还能为利益相关方提供有关业务成果和问题影响的实时信息。
**期望结果：**
使用可视化形式，清晰地了解系统和业务运行状况，并据此采取行动。
**常见反模式：**
+ 指标过多，控制面板过于复杂。
+ 依靠没有警报功能的控制面板进行异常检测。
+ 不会随着工作负载的发展变化而更新控制面板。
**此最佳实践的好处：**
+ 即时了解关键系统指标和 KPI。
+ 增进利益相关方的沟通和理解。
+ 快速洞察运营问题的影响。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
**以业务为中心的控制面板**
为业务 KPI 量身定制的控制面板可吸引更广泛的利益相关方。尽管这些人可能对系统指标不感兴趣，但他们热衷于了解这些数字对业务的影响。以业务为中心的控制面板可确保所监控和分析的所有技术和运营指标与总体业务目标同步。这种一致性可让每个人清楚了解什么是至关重要的，什么不太重要，并就此达成共识。此外，突出业务 KPI 的控制面板往往更具操作性。利益相关方可以快速了解运营状况、需要关注的领域以及对业务成果的潜在影响。
考虑到这一点，在创建控制面板时，请确保技术指标和业务 KPI 之间保持平衡。两者都至关重要，但它们面向不同的受众。理想情况下，控制面板应该有助于全面了解系统的运行状况和性能，同时还要强调关键业务成果及其影响。
Amazon CloudWatch 控制面板是 CloudWatch 控制台中的可自定义主页，可用于在单一视图中监控资源，即便是分布在不同 AWS 区域 和账户的资源，也能对其进行监控。
### 实施步骤
1. **创建基本控制面板：**[在 CloudWatch 中创建一个新的控制面板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create_dashboard.html)，并给它起一个描述性名称。
1. **使用 Markdown 小组件：**在深入研究指标之前，[请使用 Markdown 小组件](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/add_remove_text_dashboard.html)在控制面板顶部添加文本上下文。文本上下文应该说明控制面板涵盖的内容、所呈现指标的重要性，还可以包含指向其他控制面板和故障排除工具的链接。
1. **创建控制面板变量：**在适当的地方[加入控制面板变量](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_dashboard_variables.html)，从而实现动态和灵活的控制面板视图。
1. **创建指标小组件：**[添加指标小组件](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-and-work-with-widgets.html)，以可视化形式呈现应用程序发出的各种指标，定制这些小组件，以便有效呈现系统运行状况和业务成果。
1. **日志洞察查询：**利用 [CloudWatch Log Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_ExportQueryResults.html) 从日志中获取可操作的指标，并在控制面板上显示这些洞察。
1. **设置警报：**将 [CloudWatch Alarms](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/add_remove_alarm_dashboard.html) 集成到控制面板中，以便快速查看任何超出阈值的指标。
1. **使用 Contributor Insights：**加入 [CloudWatch Contributor Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights-ViewReports.html) 来分析高基数字段，更清楚地了解资源的主要贡献者。
1. **设计自定义小组件：**对于标准小组件无法满足的特定需求，可以考虑创建[自定义小组件](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/add_custom_widget_dashboard.html)。自定义小部件可以从各种数据来源中提取数据，也可以以独特方式呈现数据。
1. **使用 AWS Health：**AWS Health 是有关 AWS 云资源运行状况的权威信息来源。开箱即用 [AWS Health Dashboard](https://health.aws.amazon.com/health/status)，或者在您自己的控制面板和工具中使用 AWS Health 数据，这样您就可以获得正确的信息来做出明智的决策。
1. **迭代和完善：**随着应用程序的发展，请定期重新审视控制面板，确保其仍然适用。
## 资源
**相关最佳实践：**
+ [OPS04-BP01 确定关键绩效指标](ops_observability_identify_kpis.md)
+ [OPS08-BP01 分析工作负载指标](ops_workload_observability_analyze_workload_metrics.md)
+ [OPS08-BP02 分析工作负载日志](ops_workload_observability_analyze_workload_logs.md)
+ [OPS08-BP03 分析工作负载跟踪数据](ops_workload_observability_analyze_workload_traces.md)
+ [OPS08-BP04 创建可操作的警报](ops_workload_observability_create_alerts.md)
**相关文档：**
+ [构建控制面板以获取操作可见性](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/)
+ [Using Amazon CloudWatch Dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
**相关视频：**
+ [Create Cross Account & Cross Region CloudWatch Dashboards](https://www.youtube.com/watch?v=eIUZdaqColg)
+ [AWS re:Invent 2021 - Gain enterprise visibility with AWS 云 operation dashboards)](https://www.youtube.com/watch?v=NfMpYiGwPGo)
**相关示例：**
+ [One Observability 讲习会](https://catalog.workshops.aws/observability/en-US/intro)
+ [使用 Amazon CloudWatch 进行应用程序监控](https://aws.amazon.com/solutions/implementations/application-monitoring-with-cloudwatch/)
+ [AWS Health Events Intelligence Dashboards and Insights](https://aws.amazon.com/blogs/mt/aws-health-events-intelligence-dashboards-insights/)
+ [Visualize AWS Health events using Amazon Managed Grafana](https://aws.amazon.com/blogs/mt/visualize-aws-health-events-using-amazon-managed-grafana/)
# OPS 9. 如何了解自己的运营状况？
定义、记录和分析运营指标以便了解运营事件，从而采取适当的行动。
**Topics**
+ [OPS09-BP01 使用指标衡量运营目标和 KPI](ops_operations_health_measure_ops_goals_kpis.md)
+ [OPS09-BP02 通报状态和趋势，确保了解运营情况](ops_operations_health_communicate_status_trends.md)
+ [OPS09-BP03 审查运营指标并确定改进优先顺序](ops_operations_health_review_ops_metrics_prioritize_improvement.md)
# OPS09-BP01 使用指标衡量运营目标和 KPI
从组织获取定义运营成功的目标和 KPI，并确定指标可反映这些目标和 KPI。将基线设置为参考点，并定期重新评估。制定机制，从团队收集这些指标以供评估。[DevOps Research and Assessment (DORA)](https://dora.dev/guides/dora-metrics-four-keys/) 指标提供了一种常用的方法来衡量软件交付 DevOps 实践的进展。
**期望结果：**
+ 组织发布并分享运营团队的目标和 KPI。
+ 您建立反映这些 KPI 的指标。示例可能包括：
+ 工单队列深度或平均工单时长
+ 按问题类型分组的工单数量
+ 使用或不使用标准化操作程序（SOP）时处理问题所花费的时间
+ 从失败的代码推送中恢复所花费的时间
+ 呼叫量
**常见反模式：**
+ 由于开发人员被抽调去执行故障排除任务，而错过部署截止日期。开发团队主张增加人手，但由于无法衡量所占用的时间，因此无法量化他们需要多少人手。
+ 设置了 1 级服务台来处理用户呼叫。随着时间的推移，工作负载越来越多，但没有为 1 级服务台分配人手。随着呼叫次数的增加以及问题解决时间的延长，客户满意度下降，但管理层看不到此类问题的任何指标，因此未采取任何行动。
+ 有问题的工作负载已移交给单独的运营团队进行处理。与其他工作负载不同，这种新的工作负载没有提供适当的文档和运行手册。因此，团队需要花费更长的时间排除和解决故障。但是，没有任何指标记录这一点，这使得问责制变得难以实施。
**建立此最佳实践的好处：**工作负载监控可以显示应用程序和服务的状态，而监控运营团队则可以让所有者深入了解这些工作负载使用者之间的变化，例如不断变化的业务需求。通过创建能够反映运营状态的指标，可衡量这些团队的效率，并根据业务目标对其进行评估。指标可以突出显示支持问题，或确定何时出现偏离服务水平目标的情况。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
安排时间与业务主管和利益相关方商谈，来确定服务的总体目标。确定各个运营团队的任务，以及他们可能应对哪些挑战。利用这些信息，针对可能反映这些运营目标的关键绩效指标（KPI）进行集思广益。这些指标可能是客户满意度、从功能构思到部署所花的时间、平均问题解决时间或成本效益。
根据 KPI，确定最能反映这些目标的指标和数据来源。客户满意度可能是各种指标的组合，例如呼叫等待或回复时间、满意度得分和提出的问题类型。部署时间可能是测试和部署所需的时间，加上需要添加的所有部署后修复的总和。统计数据显示了不同类型问题所花费的时间（或这些问题的数量），其可以提供一个窗口，便于了解需要在哪些方面开展有针对性的工作。
## 资源
**相关文档：**
+ [Quick - 使用 KPI](https://docs.aws.amazon.com/quicksight/latest/user/kpi.html)
+ [Amazon CloudWatch – 使用指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [构建控制面板](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/)
+ [How to track your cost optimization KPIs with KPI Dashboard](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-to-track-your-cost-optimization-kpis-with-the-kpi-dashboard/)
+ [AWS DevOps Guidance ](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/devops-guidance.html)
**相关示例：**
+ [ Monitor the performance of your software delivery using native AWS monitoring and observability tools ](https://catalog.us-east-1.prod.workshops.aws/workshops/3b7f3d77-c6ef-44b2-aa29-d2719b8be897/en-US)
+ [ Balance deployment speed and stability with DORA metrics ](https://aws.amazon.com/blogs/devops/balance-deployment-speed-and-stability-with-dora-metrics/)
+ [ Example MLOps operational metrics in the financial services industry ](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-unlock-value-data-financial-services/operational-metrics.html)
+ [How to track your cost optimization KPIs with the KPI Dashboard](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-to-track-your-cost-optimization-kpis-with-the-kpi-dashboard/)
# OPS09-BP02 通报状态和趋势，确保了解运营情况
了解运营状况及其趋势非常有必要，这样才能确定结果何时可能面临风险、是否可以支持新增的工作，或者变更对团队的影响。在运营事件期间，用户和运营团队可通过状态页面获取信息，从而减轻通信渠道的压力并主动传播信息。
**期望结果：**
+ 运营主管可以一目了然地了解其团队正在处理的呼叫量，以及可能正在开展的工作（如部署）。
+ 当正常运营受到影响时，会向利益相关方和用户群体发出警报。
+ 组织领导层和利益相关方可以查看状态页面，以响应警报或影响，并获取与运营事件相关的信息，如联系人、工单信息和预计恢复时间。
+ 向领导层和其他利益相关方提供报告，以便显示运营统计数据，例如一段时间内的呼叫量、用户满意度分数、未处理工单的数量及其时长。
**常见反模式：**
+ 工作负载出现故障，导致服务不可用。用户想知道发生了什么情况，呼叫量激增。管理人员想知道谁在处理问题，从而进一步增加了呼叫量。各个运营团队都加倍努力调查问题。
+ 由于人们都想获得新功能，导致几名人员被重新分配到工程工作中。没有提供候补人员，问题解决时间激增。没有记录这些信息，几周后，在收到用户表达不满的反馈时，领导层才意识到这个问题。
**建立此最佳实践的好处：**在业务受到影响的运营事件中，为了解情况而向不同团队查询信息可能会浪费大量时间和精力。通过建立广泛传播的状态页面和控制面板，利益相关方可以快速获得相关信息，例如是否检测到了问题、谁在负责处理问题，或者预计何时可以恢复正常运营。这样，团队成员就不必花太多时间与他人沟通状态，而是可以将更多时间花在解决问题上。
此外，控制面板和报告可以为决策者和利益相关方提供洞察，以便了解运营团队响应业务需求以及分配资源的方式。这对于确定是否有足够的资源来支持业务至关重要。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
构建控制面板，显示运营团队当前的关键指标，并让运营主管和管理层都能随时访问这些指标。
构建可以快速更新的状态页面，显示意外事件或事件何时发生、由谁负责以及谁在协调响应。在此页面上分享用户应考虑的任何步骤或解决方法，并广泛告知该位置。鼓励用户在遇到未知问题时先查看此位置。
收集并提供显示一段时间内运营状况的报告，并将其分发给领导者和决策者，以便说明运营工作以及挑战和需求。
在团队之间分享这些指标和报告，这些指标和报告最能反映目标和 KPI，以及在推动变革方面的影响力。投入时间开展这些活动，提升运营在团队内部和团队之间的重要性。
将 [AWS Health](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html) 与您自己的控制面板一起使用，或者将 AWS Health 事件集成到控制面板中，这样您的团队就可以将应用程序问题与 AWS 服务状态相关联。
## 资源
**相关最佳实践：**
+ [OPS09-BP01 使用指标衡量运营目标和 KPI](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_operations_health_measure_ops_goals_kpis.html)
**相关文档：**
+ [Measure Progress](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-cloud-operating-model/measure-progress.html)
+ [构建控制面板以获取操作可见性](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/)
**相关示例：**
+ [Data Operations](https://aws.amazon.com/solutions/app-development/data-operations)
+ [How to track your cost optimization KPIs with KPI Dashboard](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-to-track-your-cost-optimization-kpis-with-the-kpi-dashboard/)
+ [The Importance of Key Performance Indicators (KPIs) for Large-Scale Cloud Migrations](https://aws.amazon.com/blogs/mt/the-importance-of-key-performance-indicators-kpis-for-large-scale-cloud-migrations/)
# OPS09-BP03 审查运营指标并确定改进优先顺序
留出专门的时间和资源来审查运营状况，可确保为日常业务提供服务始终是优先事项。召集运营主管和利益相关方，定期审查指标，重申或修改长期和短期目标，并确定改进的优先顺序。
**期望结果：**
+ 运营主管和员工定期开会，审查给定报告期内的指标。交流挑战，庆祝胜利，分享经验教训。
+ 定期向利益相关方和业务领导者通报运营状况，并征求他们对目标、KPI 和未来举措的意见。结合相关背景，讨论服务交付、运营和维护之间的权衡。
**常见反模式：**
+ 推出了一款新产品，但一级和二级运营团队没有接受充分培训，无法为其提供支持，或者没有相应地增加人手。领导者看不到表明工单解决时间缩短和意外事件量增加的指标。几周后，心怀不满的用户离开平台，订阅数量开始下降，此时才采取行动。
+ 对工作负载进行维护的手动流程已经存在很长时间。尽管人们一直想要实现自动化，但考虑到该系统的重要性较低，自动化并未得到足够的重视。然而，随着时间的推移，该系统的重要性与日俱增，现在这些手动流程耗费了运营团队的大部分时间。没有安排资源为运营团队提供更多工具，这导致随着工作负载的增加，员工疲惫不堪。有人报告员工离职去了其他竞争对手那里时，领导层才意识到这一点。
**建立此最佳实践的好处：**在一些组织中，如何将同样的时间和精力用于提供新产品或新服务，可能是一项挑战。一旦出现这种情况，预期的服务水平会慢慢降低，业务线就会受到影响。这是因为运营团队没有随着业务的增长而做出改变和发展，很快就跟不上业务的节奏。如果不定期审查运营团队收集的洞察，等到发现业务面临的风险时，可能为时已晚。通过花时间与运营人员和领导层一起审查指标和程序，运营团队所发挥的关键作用将显而易见，并且能在风险达到临界水平之前及早发现。运营团队可以更好地洞察即将发生的业务变化和即将实施的计划，从而积极主动地开展工作。领导层对运营指标的了解展示了这些团队在客户满意度（包括内部和外部客户满意度）方面所发挥的作用，让他们能够更好地权衡选择的优先事项，或确保运营团队有足够的时间和资源随着新业务和工作负载计划的变化而做出改变和发展。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
花时间与利益相关方和运营团队一起审查运营指标和报告数据。结合组织的长期和短期目标来审查这些报告，以便确定是否实现了这些目标。在目标不明确的地方，或在要求的东西和给予的东西之间可能存在冲突的地方，找出含糊不清的根源。
确定时间、人员和工具可以在哪些方面推动实现运营成果。确定这将影响哪些 KPI 以及成功的目标应该是什么。定期重新审视，确保运营团队有足够的资源来支持业务线。
## 资源
**相关文档：**
+ [Amazon Athena](https://aws.amazon.com/athena/)
+ [Amazon CloudWatch 指标和维度参考](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [Amazon Quick](https://aws.amazon.com/quicksight/)
+ [AWS Glue](https://aws.amazon.com/glue/)
+ [AWS Glue Data Catalog](https://docs.aws.amazon.com/glue/latest/dg/populate-data-catalog.html)
+ [使用 Amazon CloudWatch 代理收集 Amazon EC2 实例和本地服务器的指标和日志](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)
+ [使用 Amazon CloudWatch 指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
# OPS 10. 如何应对工作负载事件和运营事件？
制定和验证用于响应事件的程序，以便尽可能减少其对工作负载的干扰。
**Topics**
+ [OPS10-BP01 使用流程来管理事件、意外事件和问题](ops_event_response_event_incident_problem_process.md)
+ [OPS10-BP02 针对每个警报设置一个流程](ops_event_response_process_per_alert.md)
+ [OPS10-BP03 根据业务影响确定运营事件的优先顺序](ops_event_response_prioritize_events.md)
+ [OPS10-BP04 定义上报路径](ops_event_response_define_escalation_paths.md)
+ [OPS10-BP05 为影响服务的事件定义客户沟通计划](ops_event_response_push_notify.md)
+ [OPS10-BP06 通过控制面板传达状态信息](ops_event_response_dashboards.md)
+ [OPS10-BP07 自动响应事件](ops_event_response_auto_event_response.md)
# OPS10-BP01 使用流程来管理事件、意外事件和问题
要想维持工作负载的运行状况和性能，对事件、意外事件和问题的高效管理能力非常关键。因此务必要认识和理解这些要素之间的不同，这样才能制定有效的响应和解决策略。针对各个方面确立并遵循明确的流程，有助于团队快速有效地应对出现的任何运营挑战。
**期望结果：**组织通过记录详实且集中存储的流程，高效地管理运营事件、意外事件和问题。这些流程会不断更新来反映变更，并简化处理过程，保持出色的服务可靠性和工作负载性能。
**常见反模式：**
+ 被动而不是主动地响应事件。
+ 面对不同类型的事件或意外事件，采取不一致的方法。
+ 组织没有分析意外事件并从中吸取教训，以防将来再次发生。
**建立此最佳实践的好处：**
+ 简化响应流程并使之标准化。
+ 降低意外事件对服务和客户的影响。
+ 加快问题解决速度。
+ 持续改进运营流程。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
实施这种最佳实践意味着您正在跟踪工作负载事件。建立用于处理意外事件和问题的流程。记录、分享并经常更新这些流程。发现问题，确定问题优先级并加以解决。
**了解事件、意外事件和问题**
+ **事件：***事件*是观察到的动作、事件或状态变化。事件可以是预先计划的，也可以是计划外的，可以源自工作负载内部，也可以源自工作负载外部。
+ **意外事件：***意外事件*是需要响应的事件，例如计划外的中断或服务质量下降。意外事件表示出现了中断，需要立即采取行动才能恢复工作负载正常运行。
+ **问题：***问题*是一起或多起意外事件的根本原因。发现和解决问题需要对意外事件进行更深入的研究，以防将来再次发生。
### 实施步骤
**Events**
1. **监控事件：**
+ [实现可观测性](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/implement-observability.html)并[利用工作负载可观测性](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/utilizing-workload-observability.html)。
+ 监控用户、角色或 AWS 服务执行的操作，并将其作为事件记录在 [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) 中。
+ 使用 [Amazon EventBridge](https://aws.amazon.com/eventbridge/) 实时响应应用程序的运营变化。
+ 使用 [AWS Config](https://aws.amazon.com/config/) 持续评测、监控和记录资源配置变更。
1. **创建流程：**
+ 制定一个流程来评测哪些事件很重要，需要进行监控。这包括为正常活动和异常活动设置阈值和参数。
+ 确定将事件升级为意外事件的标准。这些标准可以基于严重性、对用户的影响或与预期行为的偏差。
+ 定期审查事件监控情况和响应流程。这包括分析过去的意外事件、调整阈值和完善警报机制。
**意外事件**
1. **响应意外事件：**
+ 使用来自可观测性工具的洞察快速识别和响应意外事件。
+ 实施 [AWS Systems Manager Ops Center](https://aws.amazon.com/systems-manager/features/#OpsCenter) 来汇总和整理运营项目及意外事件，并确定其优先级。
+ 使用 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 和 [AWS X-Ray](https://aws.amazon.com/xray/) 等服务进行更深入的分析和故障排除。
+ 考虑使用 [AWS Managed Services（AMS）](https://aws.amazon.com/managed-services/)来增强事件管理，利用其主动、预防和侦查能力。AMS 借助监控、意外事件检测和响应以及安全管理等服务来扩展运营支持。
+ Enterprise Support 客户可以使用 [AWS 事件检测和响应](https://aws.amazon.com/premiumsupport/aws-incident-detection-response/)，为生产工作负载提供持续的主动监控和事件管理。
1. **创建事件管理流程：**
+ 建立结构化的事件管理流程，包括明确的角色、通信协议和解决步骤。
+ 将事件管理与[聊天应用程序中的 Amazon Q 开发者版](https://aws.amazon.com/chatbot/)等工具集成，来实现高效的响应和协调。
+ 按严重性对意外事件进行分类，并针对每个类别预先制定[意外事件响应计划](https://docs.aws.amazon.com/incident-manager/latest/userguide/response-plans.html)。
1. **学习和改进：**
+ 执行[意外事件后分析](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_perform_rca_process.html)，了解根本原因和解决方案的有效性。
+ 根据审查结果和不断发展的做法，持续更新和改进响应计划。
+ 记录学到的经验教训，并在各个团队之间分享，从而增强运营韧性。
+ Enterprise Support 客户可以向其技术客户经理申请[事件管理讲习会](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives)。这场有指导意义的讲习会可测试现有的意外事件响应计划，并帮助找出需要改进之处。
** 问题**
1. **确定问题：**
+ 使用先前意外事件的数据来确定反复出现的模式，这些模式可能表明出现了更深层次的系统性问题。
+ 利用 [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) 和 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 等工具来分析趋势并发现潜在问题。
+ 让运营、开发和业务部门等跨职能团队参与进来，从多元化的视角来审视根本原因。
1. **创建问题管理流程：**
+ 制定结构化的问题管理流程，重点在于制定长期解决方案，而不是快速的权宜之计。
+ 采用根本原因分析（RCA）技术来调查和了解意外事件的根本原因。
+ 根据调查发现来更新运营策略、程序和基础设施，以防问题再次发生。
1. **持续改进：**
+ 培养持续学习和改进的文化，鼓励团队主动发现和解决潜在问题。
+ 定期审查和修订问题管理流程及工具，适应不断变化的业务和技术形势。
+ 在整个组织内分享洞察和最佳实践，以便建立更具韧性、更高效的运营环境。
1. **利用 AWS 支持：**
+ 使用 [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/) 等 AWS 支持资源，获取主动指导和优化建议。
+ Enterprise Support 客户可以在关键事件期间访问 [AWS Countdown](https://aws.amazon.com/premiumsupport/aws-countdown/) 等专业计划，以便获取支持。
**实施计划的工作量级别：**中
## 资源
**相关最佳实践：**
+ [OPS04-BP01 确定关键绩效指标](ops_observability_identify_kpis.md)
+ [OPS04-BP02 实施应用程序遥测](ops_observability_application_telemetry.md)
+ [OPS07-BP03 使用运行手册执行程序](ops_ready_to_support_use_runbooks.md)
+ [OPS07-BP04 根据行动手册调查问题](ops_ready_to_support_use_playbooks.md)
+ [OPS08-BP01 分析工作负载指标](ops_workload_observability_analyze_workload_metrics.md)
+ [OPS11-BP02 在意外事件发生后执行分析](ops_evolve_ops_perform_rca_process.md)
**相关文档：**
+ 《[AWS Security Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)》
+ [AWS Incident Detection and Response](https://aws.amazon.com/premiumsupport/aws-incident-detection-response/)
+ [AWS Cloud Adoption Framework: Operations Perspective - Incident and problem management ](https://docs.aws.amazon.com/whitepapers/latest/aws-caf-operations-perspective/incident-and-problem-management.html)
+ [Incident Management in the Age of DevOps and SRE](https://www.infoq.com/presentations/incident-management-devops-sre/)
+ [PagerDuty - What is Incident Management?](https://www.pagerduty.com/resources/learn/what-is-incident-management/)
**相关视频：**
+ [Top incident response tips from AWS](https://www.youtube.com/watch?v=Cu20aOvnHwA)
+ [AWS re:Invent 2022 - The Amazon Builders' Library: 25 yrs of Amazon operational excellence](https://www.youtube.com/watch?v=DSRhgBd_gtw)
+ [AWS re:Invent 2022 - AWS Incident Detection and Response (SUP201)](https://www.youtube.com/watch?v=IbSgM4IP9IE)
+ [Introducing Incident Manager from AWS Systems Manager](https://www.youtube.com/watch?v=I6lScgh4qds)
**相关示例：**
+ [AWS Proactive Services – Incident Management 讲习会](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives)
+ [How to Automate Incident Response with PagerDuty and AWS Systems Manager Incident Manager](https://aws.amazon.com/blogs/mt/how-to-automate-incident-response-with-pagerduty-and-aws-systems-manager-incident-manager/)
+ [Engage Incident Responders with the On-Call Schedules in AWS Systems Manager Incident Manager](https://aws.amazon.com/blogs/mt/engage-incident-responders-with-the-on-call-schedules-in-aws-systems-manager-incident-manager/)
+ [Improve the Visibility and Collaboration during Incident Handling in AWS Systems Manager Incident Manager](https://aws.amazon.com/blogs/mt/improve-the-visibility-and-collaboration-during-incident-handling-in-aws-systems-manager-incident-manager/)
+ [Incident reports and service requests in AMS](https://docs.aws.amazon.com/managedservices/latest/userguide/support-experience.html)
**相关服务：**
+ [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)
# OPS10-BP02 针对每个警报设置一个流程
要想实现有效和高效的事件管理，为系统中的每个警报建立清晰明确的流程至关重要。这种做法可确保对每个警报都采取具体的、可操作的响应，从而提高运营的可靠性和响应能力。
**期望结果：**每个警报都会启动一个具体的、明确的响应计划。在可能的情况下，将响应过程自动化，并具有明确的负责人和上报路径。警报关联到最新的知识库，以便所有操作员都可以一致、有效地做出响应。响应速度快且全面统一，从而提高运营效率和可靠性。
**常见反模式：**
+ 没有针对警报预定义响应流程，导致采用了不及时的权宜解决方案。
+ 警报过载会导致遗漏重要的警报。
+ 由于缺乏明确的责任人和责任关系，警报的处理方式不一致。
**建立此最佳实践的好处：**
+ 仅发出可操作的警报，缓解警报疲劳情况。
+ 缩短了运营问题的平均解决时间（MTTR）。
+ 缩短了平均调查时间（MTTI)，这有助于减少 MTTR。
+ 增强了大范围运营响应的能力。
+ 提高了处理运营事件的一致性和可靠性。
例如，您为关键客户的 AWS Health 事件定义了一个流程，包括应用程序警报、运营问题和计划的生命周期事件（例如，在自动更新集群之前更新 Amazon EKS 版本），并且您为团队提供了主动监控、沟通和响应这些事件的功能。这些操作有助于防止由 AWS 方更改所造成的服务中断，或在出现意外问题时更快地缓解此类中断。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
针对每个警报设置一个流程，这包括为每个警报制定明确的响应计划，尽可能自动处理响应，并根据运营反馈和不断变化的要求不断完善这些流程。
### 实施步骤
下图说明了 [AWS Systems Manager Incident Manager](https://aws.amazon.com/systems-manager/features/incident-manager/) 中的事件管理工作流程。此服务旨在通过自动创建意外事件来响应 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 或 [Amazon EventBridge](https://aws.amazon.com/eventbridge/) 中的特定事件，从而快速响应运营问题。创建意外事件时，无论是自动还是手动创建，Incident Manager 都会集中管理意外事件，整理相关的 AWS 资源信息，并启动预定义的响应计划。这包括运行 Systems Manager Automation 运行手册，从而立即采取行动，以及在 OpsCenter 中创建父运营工作项，用于跟踪相关任务和分析。这种简化的流程可以加快和协调整个 AWS 环境中的意外事件响应。
![\[描述 Incident Manager 工作原理的流程图 – 聊天应用程序中的 Amazon Q 开发者版，上报计划和联系方式，运行手册流入响应计划，响应计划流入意外事件和分析。Amazon CloudWatch 也将流入响应计划。\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/incident-manager-how-it-works.png)
1. **使用复合警报：**在 CloudWatch 中创建[复合警报](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html)，以便对相关警报进行分组，减少噪音并实现更有意义的响应。
1. **随时了解 [AWS Health](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html) 的最新信息：**AWS Health 是有关 AWS 云资源运行状况的权威信息来源。使用 AWS Health 可视化并获得有关任何当前服务事件和即将发生的更改（例如计划的生命周期事件）的通知，以便您可以采取措施来减轻影响。
1. 通过 [AWS 用户通知服务](https://docs.aws.amazon.com/notifications/latest/userguide/what-is-service.html) 创建要发送到电子邮件和聊天渠道且[契合目标的 AWS Health 事件通知](https://docs.aws.amazon.com/health/latest/ug/user-notifications.html)，并通过 Amazon EventBridge 或 [AWS Health API](https://docs.aws.amazon.com/health/latest/APIReference/Welcome.html) 以编程方式与[监控和警报工具](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html)集成。
1. 通过与您可能已经通过 Amazon EventBridge 或 AWS Health API 使用的变更管理或 ITSM 工具（如 [Jira](https://docs.aws.amazon.com/smc/latest/ag/cloud-sys-health.html) 或 [ServiceNow](https://docs.aws.amazon.com/smc/latest/ag/sn-aws-health.html)）集成，规划和跟踪需要采取行动的运行状况事件的进度。
1. 如果您使用 AWS Organizations，请启用 [organization view for AWS Health](https://docs.aws.amazon.com/health/latest/ug/aggregate-events.html) 以跨账户聚合 AWS Health 事件。
1. **将 Amazon CloudWatch 警报与 Incident Manager 集成：**配置 CloudWatch 警报，以便在 [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/response-plans.html) 中自动创建事件。
1. **将 Amazon EventBridge 与 Incident Manager 集成：**创建[ EventBridge 规则](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-create-rule.html)，以便对事件做出反应，并使用定义的响应计划创建意外事件。
1. **在 Incident Manager 中为意外事件做准备：**
+ 在 Incident Manager 中为每种类型的警报制定详细的[响应计划](https://docs.aws.amazon.com/incident-manager/latest/userguide/response-plans.html)。
+ 通过 [Amazon Q Developer in chat applications](https://docs.aws.amazon.com/incident-manager/latest/userguide/chat.html) 建立聊天频道，连接到 Incident Manager 中的响应计划，在发生事件时，协调 Slack、Microsoft Teams 和 Amazon Chime 等各个平台之间的实时沟通。
+ 将 [Systems Manager Automation 运行手册](https://docs.aws.amazon.com/incident-manager/latest/userguide/runbooks.html)纳入 Incident Manager 中，推动对意外事件的自动响应。
## 资源
**相关最佳实践：**
+ [OPS04-BP01 确定关键绩效指标](ops_observability_identify_kpis.md)
+ [OPS08-BP04 创建可操作的警报](ops_workload_observability_create_alerts.md)
**相关文档：**
+ [AWS Cloud Adoption Framework: Operations Perspective - Incident and problem management ](https://docs.aws.amazon.com/whitepapers/latest/aws-caf-operations-perspective/incident-and-problem-management.html)
+ [使用 Amazon CloudWatch 告警](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Setting up AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/setting-up.html)
+ [Preparing for incidents in Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-response.html)
**相关视频：**
+ [Top incident response tips from AWS](https://www.youtube.com/watch?v=Cu20aOvnHwA)
+ [ re:Invent 2,023 \$1 Manage resource lifecycle events at scale with AWS Health](https://www.youtube.com/watch?v=VoLLNL5j9NA)
**相关示例：**
+ [AWS 讲习会 – AWS Systems Manager Incident Manager – Automate incident response to security events](https://catalog.workshops.aws/automate-incident-response/en-US/settingupim/onboarding)
# OPS10-BP03 根据业务影响确定运营事件的优先顺序
及时响应运营事件至关重要，但并非所有事件都应该一概而论。根据业务影响确定优先顺序时，同时确定了需要优先处理的、可能造成重大后果的事件，这些后果包括安全问题、财务损失、违反规章或声誉损害等。
**期望结果；**根据对业务运营和目标的潜在影响，确定运营事件响应的优先顺序。这使得应对措施既高效又有效。
**常见反模式：**
+ 以同样的紧急程度处理所有事件，这会导致混乱，并且耽误解决关键问题。
+ 无法区分高影响力事件和低影响力事件，从而导致资源分配不当。
+ 组织缺乏明确的优先级框架，导致对运营事件的响应不一致。
+ 根据报告的顺序来确定事件的优先处理顺序，而不是其对业务成果的影响。
**建立此最佳实践的好处：**
+ 确保首先关注关键业务职能，从而尽可能减少潜在损失。
+ 在同时发生多个事件时，可改善资源分配。
+ 增强组织维护信任关系和满足监管要求的能力。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
面对多个运营事件时，基于影响力和紧急程度制定优先顺序的结构化方法至关重要。这种方法有助于作出明智的决策，将工作重心放在最需要的地方，并降低影响业务连续性的风险。
### 实施步骤
1. **评测影响：**开发分类系统，根据事件对业务运营和目标的潜在影响来评估事件的严重性。以下示例展示了影响类别：
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/ops_event_response_prioritize_events.html)
1. **评测紧急程度：**考虑安全、财务影响和服务水平协议（SLA）等因素，定义需要对某个事件进行响应的紧急程度。以下示例展示了紧急程度类别：
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/ops_event_response_prioritize_events.html)
1. **创建优先级矩阵：**
+ 使用矩阵来交叉参考影响力和紧急程度，向不同的组合分配优先级。
+ 确保负责运营事件响应的所有团队成员都能访问并且理解矩阵。
+ 以下示例矩阵根据紧急程度和影响力显示意外事件的严重性：
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/ops_event_response_prioritize_events.html)
1. **培训和沟通：**培训响应团队，让其了解优先级矩阵以及在发生事件时遵循矩阵的重要性。与所有利益相关方沟通优先次序流程，并设定明确的期望。
1. **与意外事件响应集成：**
+ 将优先级矩阵纳入意外事件响应计划和工具中。
+ 尽可能自动对事件进行分类和优先级排序，以便加快响应速度。
+ Enterprise Support 客户可以使用 [AWS 事件检测和响应](https://aws.amazon.com/premiumsupport/aws-incident-detection-response/)，为生产工作负载提供全天候的主动监控和事件管理。
1. **审查和调整：**定期审查优先次序流程的有效性，并根据反馈和业务环境的变化进行调整。
## 资源
**相关最佳实践：**
+ [OPS03-BP03 鼓励上报](ops_org_culture_team_enc_escalation.md)
+ [OPS08-BP04 创建可操作的警报](ops_workload_observability_create_alerts.md)
+ [OPS09-BP01 使用指标衡量运营目标和 KPI](ops_operations_health_measure_ops_goals_kpis.md)
**相关文档：**
+ [Atlassian - Understanding incident severity levels](https://www.atlassian.com/incident-management/kpis/severity-levels)
+ [IT Process Map - Checklist Incident Priority](https://wiki.en.it-processmaps.com/index.php/Checklist_Incident_Priority)
# OPS10-BP04 定义上报路径
在意外事件响应协议中确立明确的上报路径，有助于及时地采取有效措施。这包括指定上报提示、详细说明上报流程，以及预先批准相关措施，以便加快决策速度并缩短平均解决时间（MTTR）。
**期望结果：**结构化的高效流程，可将意外事件上报给相应人员，从而尽可能减少响应时间和影响。
**常见反模式：**
+ 恢复程序不明确，导致在发生重大意外事件时采取权宜之计。
+ 没有明确的权限和负责人，导致在需要采取紧急措施时出现延误。
+ 发送给利益相关方和客户的通知不符合他们的预期。
+ 推迟重要决策。
**建立此最佳实践的好处：**
+ 通过预定义的上报程序简化意外事件响应。
+ 通过预先批准相关措施并明确负责人，减少停机时间。
+ 根据意外事件严重性，改进资源分配和支持级别调整。
+ 改善与利益相关方和客户的沟通。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
妥善定义的上报路径对于快速响应意外事件至关重要。AWS Systems Manager Incident Manager 支持设置结构化上报计划和随时待命方案，这可以在发生意外事件时提醒相关人员，让他们准备好采取行动。
### 实施步骤
1. **设置上报提示：**设置 [CloudWatch 警报](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions)，在 [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com//incident-manager/latest/userguide/incident-creation.html) 中创建意外事件。
1. **设置随时待命方案：**在 Incident Manager 中创建与上报路径一致的[随时待命方案](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-manager-on-call-schedule-create.html)。为随时待命人员提供必要的权限和工具，以便迅速采取行动。
1. **详细说明上报程序：**
+ 确定上报意外事件的具体条件。
+ 在 Incident Manager 中创建[上报计划](https://docs.aws.amazon.com/incident-manager/latest/userguide/escalation.html)。
+ 上报渠道应包括联系人或随时待命方案。
+ 定义团队在每个上报级别的角色和职责。
1. **预先批准缓解措施：**与决策者合作，针对预期场景预先批准措施。使用与 Incident Manager 集成的 [Systems Manager Automation 运行手册](https://docs.aws.amazon.com//incident-manager/latest/userguide/tutorials-runbooks.html)来加快意外事件的解决速度。
1. **指定负责人：**明确指定上报路径中每个环节的内部负责人。
1. **详细说明第三方上报情况：**
+ 记录第三方服务水平协议（SLA），将其与内部目标保持一致。
+ 针对发生意外事件时的供应商沟通情况，制定明确的协议。
+ 将供应商联系人集成到事件管理工具中，以便直接访问。
+ 定期开展演习，包括第三方响应场景。
+ 确保详细记录了供应商上报信息，以便轻松访问。
1. **针对上报计划进行培训和演习：**针对上报流程对团队进行培训，并定期进行意外事件响应演习或 GameDay 活动。Enterprise Support 客户可以申请[事件管理讲习会](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/)。
1. **不断改进：**定期审查上报路径的有效性。根据从意外事件事后分析中吸取的经验教训和持续反馈来更新流程。
**实施计划的工作量级别：**中
## 资源
**相关最佳实践：**
+ [OPS08-BP04 创建可操作的警报](ops_workload_observability_create_alerts.md)
+ [OPS10-BP02 针对每个警报设置一个流程](ops_event_response_process_per_alert.md)
+ [OPS11-BP02 在意外事件发生后执行分析](ops_evolve_ops_perform_rca_process.md)
**相关文档：**
+ [AWS Systems Manager Incident Manager Escalation Plans](https://docs.aws.amazon.com/incident-manager/latest/userguide/escalation.html)
+ [Working with on-call schedules in Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-manager-on-call-schedule.html)
+ [创建和管理运行手册](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
+ [Temporary elevated access management with AWS IAM Identity Center](https://aws.amazon.com/blogs/security/temporary-elevated-access-management-with-iam-identity-center/)
+ [Atlassian - Escalation policies for effective incident management](https://www.atlassian.com/incident-management/on-call/escalation-policies)
# OPS10-BP05 为影响服务的事件定义客户沟通计划
在发生影响服务的事件时，为了维护客户的信任和进行开诚布公地交流，有效的沟通至关重要。在发生意外事件时，明确定义的沟通计划有助于组织以快速清晰的方式，在内部和外部分享信息。
**期望结果：**
+ 在发生影响服务的事件时，可靠的沟通计划可有效地通知客户和利益相关方。
+ 开诚布公的交流可以建立信任关系，减少客户焦虑。
+ 尽可能减少影响服务的事件对客户体验和业务运营的影响。
**常见反模式：**
+ 未能充分或及时地进行沟通，导致客户困惑和不满。
+ 过于技术性或含糊不清的消息传递，无法传达对用户的实际影响。
+ 没有预定义的沟通策略，导致被动地传达消息，且不能确保消息的一致性。
**建立此最佳实践的好处：**
+ 通过进行主动、清晰的沟通，增强客户的信任和满意度。
+ 通过先行解决客户的问题，减轻支持团队的负担。
+ 提高了有效管理意外事件和从中恢复的能力。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
针对影响服务的事件，制定全面的沟通计划，这涉及从选择合适的渠道到精心撰写消息和使用合适的语气等多个方面。该计划应具有适应性、可扩展性，并能根据不同的中断场景进行调整。
### 实施步骤
1. **定义角色和职责：**
+ 指派一名重大意外事件经理，负责监管意外事件响应活动。
+ 指定一名沟通经理，负责协调所有内外部沟通。
+ 让支持经理参与进来，借助支持工单实现一致的沟通。
1. **确定沟通渠道：**选择工作聊天工具、电子邮件、短信、社交媒体、应用程序内通知和状态页面等渠道。这些渠道应具有韧性，能够在发生影响服务的事件期间独立运行。
1. **快速、清晰地与客户开展定期沟通：**
+ 针对各种服务受损场景开发模板，注重简化性和关键细节。提供有关服务受损、预期解决时间和影响的信息。
+ 使用 Amazon Pinpoint，通过推送通知、应用程序内通知、电子邮件、短信、语音消息以及自定义渠道消息，向客户发送提醒。
+ 使用 Amazon Simple Notification Service（Amazon SNS），以编程方式或通过电子邮件、移动推送通知和短信提醒订阅用户。
+ 通过公开分享 Amazon CloudWatch 控制面板，使用控制面板传达状态信息。
+ 鼓励进行社交媒体互动：
+ 积极监控社交媒体，了解客户情绪。
+ 在社交媒体平台上发布内容，面向公众提供最新信息，并参与社区互动。
+ 编制模板，以便实现一致、清晰的社交媒体沟通。
1. **协调内部沟通：**实施内部协议，使用聊天应用程序中的 Amazon Q 开发者版等工具进行团队协调和沟通。使用 CloudWatch 控制面板来传达状态信息。
1. **使用专用工具和服务来协调沟通：**
+ 将 AWS Systems Manager Incident Manager 与聊天应用程序中的 Amazon Q 开发者版结合使用来设置专用的聊天频道，以便在发生事件时进行实时内部沟通和协调。
+ 发生意外事件时，使用 AWS Systems Manager Incident Manager 运行手册，通过 Amazon Pinpoint、Amazon SNS 或社交媒体平台等第三方工具，自动通知客户。
+ 将审批工作流程纳入运行手册，以便在所有外部通信渠道发送信息之前，进行审核和授权（如需要）。
1. **练习和改进：**
+ 开展有关使用沟通工具和策略的培训。增强团队能力，以便在发生意外事件时及时作出决策。
+ 通过定期演习或 GameDay 活动来测试沟通计划。使用这些测试来完善消息传递流程，并评估渠道的有效性。
+ 实施反馈机制来评测发生意外事件时的沟通有效性。根据反馈和不断变化的需求，不断改进沟通计划。
**实施计划的工作量级别：**高
## 资源
**相关最佳实践：**
+ [OPS07-BP03 使用运行手册执行程序](ops_ready_to_support_use_runbooks.md)
+ [OPS10-BP06 通过控制面板传达状态信息](ops_event_response_dashboards.md)
+ [OPS11-BP02 在意外事件发生后执行分析](ops_evolve_ops_perform_rca_process.md)
**相关文档：**
+ [Atlassian - Incident communication best practices](https://www.atlassian.com/incident-management/incident-communication)
+ [Atlassian - How to write a good status update](https://www.atlassian.com/blog/statuspage/how-to-write-a-good-status-update)
+ [PagerDuty - A Guide to Incident Communications](https://www.pagerduty.com/resources/learn/a-guide-to-incident-communications/)
**相关视频：**
+ [Atlassian - Create your own incident communication plan: Incident templates](https://www.youtube.com/watch?v=ZROVn6-K2qU)
**相关示例：**
+ [AWS Health 控制面板](https://aws.amazon.com/premiumsupport/technology/aws-health-dashboard/)
# OPS10-BP06 通过控制面板传达状态信息
使用控制面板作为战略工具，面向内部技术团队、领导层和客户等不同受众，实时展现运营状态和关键指标。这些控制面板集中直观地展现系统运行状况和业务绩效，提高了透明度和决策效率。
**期望结果：**
+ 控制面板可向不同的利益相关方，提供与之相关的系统和业务指标的全面视图。
+ 利益相关方可以主动访问运营信息，这样就无需频繁地请求查看状态。
+ 增强了正常操作和发生意外事件期间的实时决策能力。
**常见反模式：**
+ 工程师加入事件管理呼叫，需要了解状态更新才能跟得上节奏。
+ 依赖人工报告进行管理，这会导致延迟和潜在的不准确性。
+ 在意外事件发生时，运营团队经常被状态更新打断。
**建立此最佳实践的好处：**
+ 让利益相关方能够立即获得关键信息，推动作出明智的决策。
+ 尽可能减少人工报告和频繁的状态查询，减少运营效率低下的问题。
+ 能够实时了解系统性能和业务指标，提高透明度和信任度。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
控制面板可以有效地传达系统状态和业务指标信息，并且可以根据不同受众群体的需求进行定制。利用 Amazon CloudWatch 控制面板和 Amazon Quick 等工具，可以创建交互式的实时控制面板，用于系统监控和商业智能。
### 实施步骤
1. **确定利益相关方的需求：**确定技术团队、领导层和客户等不同受众群体的特定信息需求。
1. **选择正确的工具：**选择合适的工具，例如用于系统监控的 [Amazon CloudWatch 控制面板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)，以及用于交互式商业智能的 [Amazon Quick](https://aws.amazon.com/quicksight/)。[AWS Health](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html) 在 [AWS Health Dashboard](https://health.aws.amazon.com/health/home) 中提供即用型体验，或者您可以在 Amazon EventBridge 中或通过 AWS Health API 使用运行状况事件来增强自己的控制面板。
1. **设计有效的控制面板：**
+ 设计控制面板，清晰地显示相关指标和 KPI，确保这些指标易于理解且可操作。
+ 根据需要，纳入系统级和业务级视图。
+ 包括高层控制面板（用于整体概述）和底层控制面板（用于详细分析）。
+ 在控制面板中集成自动警报，以便突出显示关键问题。
+ 在控制面板中添加重要指标阈值和目标等注释，以便即时查看。
1. **集成数据来源：**
+ 使用 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 汇总和显示各种 AWS 服务的指标，并[查询源自其他数据来源的指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/MultiDataSourceQuerying.html)，从而创建系统运行状况和业务指标的统一视图。
+ 使用 [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) 等功能来查询和可视化源自不同应用程序和服务的日志数据。
+ 使用 AWS Health 事件，通过 [AWS Health API](https://docs.aws.amazon.com/health/latest/APIReference/Welcome.html) 或 [AWS Health events on Amazon EventBridge](https://docs.aws.amazon.com/health/latest/ug/cloudwatch-events-health.html)，随时了解 AWS 服务中运营状态和已确认的运营问题。
1. **提供自助访问：**
+ 与相关利益相关方分享 CloudWatch 控制面板，以便使用[控制面板分享功能](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-dashboard-sharing.html)进行自助信息访问。
+ 确保控制面板易于访问，并可实时提供最新信息。
1. **定期更新和完善：**
+ 不断更新和完善控制面板，以便适应不断变化的业务需求，并与利益相关方的反馈保持一致。
+ 定期审查控制面板，确保其信息贴近用户需求，并有效地传达必要信息。
## 资源
**相关最佳实践：**
+ [OPS08-BP05 创建控制面板](ops_workload_observability_create_dashboards.md)
**相关文档：**
+ [构建控制面板以获取操作可见性](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/)
+ [Using Amazon CloudWatch Dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
+ [使用控制面板变量创建灵活的控制面板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_dashboard_variables.html)
+ [共享 CloudWatch 控制面板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-dashboard-sharing.html)
+ [查询源自其他数据来源的指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/MultiDataSourceQuerying.html)
+ [将自定义小组件添加到 CloudWatch 控制面板](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/add_custom_widget_dashboard.html)
**相关示例：**
+ [One Observability 讲习会 – Dashboards](https://catalog.us-east-1.prod.workshops.aws/workshops/31676d37-bbe9-4992-9cd1-ceae13c5116c/en-US/aws-native/dashboards)
# OPS10-BP07 自动响应事件
要想实现快速、一致和无错误的运营处理，自动响应事件是关键所在。创建简化的流程，使用多种工具来自动管理和响应事件，尽可能减少人工干预并提高运营效率。
**期望结果：**
+ 利用自动化功能，减少人为错误并缩短解决问题的用时。
+ 一致且可靠的运营事件处理。
+ 提高运营效率和系统可靠性。
**常见反模式：**
+ 手动处理事件，容易导致延误和出错。
+ 忽视了自动化功能在重复性关键任务中的作用。
+ 反复地手动执行任务，丧失了对警报的警惕性，导致遗漏关键问题。
**建立此最佳实践的好处：**
+ 加快事件响应速度，减少系统停机时间。
+ 通过自动化和一致的事件处理，实现可靠的运营。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
纳入自动化功能，创建高效的运营工作流程，并尽可能减少人工干预。
### 实施步骤
1. **发现自动化机会：**确定可以自动处理的重复性任务，例如问题修复、工单信息补充、容量管理、扩展、部署和测试。
1. **发现自动化提示：**
+ 使用 [Amazon CloudWatch 警报操作](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions)评测并定义启动自动响应的特定条件或指标。
+ 使用 [Amazon EventBridge](https://aws.amazon.com/eventbridge/) 响应 AWS 服务、自定义工作负载和 SaaS 应用程序中的事件。
+ 考虑启动事件，例如[特定日志条目](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)、[性能指标阈值](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)或 AWS 资源中的[状态变更](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)。
1. **实现事件驱动型自动化：**
+ 使用 AWS Systems Manager Automation 运行手册来简化维护、部署和修复任务。
+ [在 Incident Manager 中创建意外事件](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html)，自动收集并添加与意外事件相关的 AWS 资源的详细信息。
+ 使用[适用于 AWS 的配额监控程序](https://aws.amazon.com/solutions/implementations/quota-monitor/)主动监控配额。
+ 使用 [AWS Auto Scaling](https://aws.amazon.com/autoscaling/) 自动调整容量，维持可用性和性能。
+ 使用 [Amazon CodeCatalyst](https://codecatalyst.aws/explore) 实现开发管道自动化。
+ 使用[综合监控](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)进行烟雾测试或持续监控端点和 API。
1. **通过自动化功能执行风险缓解：**
+ 实施[自动安全响应](https://aws.amazon.com/solutions/implementations/automated-security-response-on-aws/)，以便快速应对风险。
+ 使用 [AWS Systems Manager State Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-state.html) 减少配置偏差。
+ [使用 AWS Config 规则 修复不合规的资源](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)。
**实施计划的工作量级别：**高
## 资源
**相关最佳实践：**
+ [OPS08-BP04 创建可操作的警报](ops_workload_observability_create_alerts.md)
+ [OPS10-BP02 针对每个警报设置一个流程](ops_event_response_process_per_alert.md)
**相关文档：**
+ [Using Systems Manager Automation runbooks with Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/tutorials-runbooks.html)
+ [Creating incidents in Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/incident-creation.html)
+ [AWS 服务限额](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html)
+ [Monitor resource usage and send notifications when approaching quotas](https://docs.aws.amazon.com/solutions/latest/quota-monitor-for-aws/solution-overview.html)
+ [AWS Auto Scaling](https://aws.amazon.com/autoscaling/)
+ [What is Amazon CodeCatalyst?](https://docs.aws.amazon.com/codecatalyst/latest/userguide/welcome.html)
+ [使用 Amazon CloudWatch 告警](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [使用 Amazon CloudWatch 警报操作](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarms-and-actions)
+ [Remediating Noncompliant Resources with AWS Config 规则](https://docs.aws.amazon.com/config/latest/developerguide/remediation.html)
+ [Creating metrics from log events using filters](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
+ [AWS Systems Manager State Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-state.html)
**相关视频：**
+ [Create Automation Runbooks with AWS Systems Manager](https://www.youtube.com/watch?v=fQ_KahCPBeU)
+ [How to automate IT Operations on AWS](https://www.youtube.com/watch?v=GuWj_mlyTug)
+ [AWS Security Hub CSPM automation rules](https://www.youtube.com/watch?v=XaMfO_MERH8)
+ [Start your software project fast with Amazon CodeCatalyst blueprints](https://www.youtube.com/watch?v=rp7roaoPzFE)
**相关示例：**
+ [Amazon CodeCatalyst Tutorial: Creating a project with the Modern three-tier web application blueprint](https://docs.aws.amazon.com/codecatalyst/latest/userguide/getting-started-template-project.html)
+ [One Observability 讲习会](https://catalog.us-east-1.prod.workshops.aws/workshops/31676d37-bbe9-4992-9cd1-ceae13c5116c/en-US)
+ [Respond to incidents using Incident Manager](https://catalog.workshops.aws/getting-started-with-com/en-US/operations-management/incident-manager)
# 改进
**Topics**
+ [OPS 11. 如何改进运营？](ops-11.md)
# OPS 11. 如何改进运营？
分配专门的时间和资源用于近乎持续的渐进式改进，以便提高运营的有效性和效率。
**Topics**
+ [OPS11-BP01 设置持续改进流程](ops_evolve_ops_process_cont_imp.md)
+ [OPS11-BP02 在意外事件发生后执行分析](ops_evolve_ops_perform_rca_process.md)
+ [OPS11-BP03 实施反馈环路](ops_evolve_ops_feedback_loops.md)
+ [OPS11-BP04 执行知识管理](ops_evolve_ops_knowledge_management.md)
+ [OPS11-BP05 确定推动改进的因素](ops_evolve_ops_drivers_for_imp.md)
+ [OPS11-BP06 验证分析结果](ops_evolve_ops_validate_insights.md)
+ [OPS11-BP07 审查运营指标](ops_evolve_ops_metrics_review.md)
+ [OPS11-BP08 记录和分享经验教训](ops_evolve_ops_share_lessons_learned.md)
+ [OPS11-BP09 分配时间进行改进](ops_evolve_ops_allocate_time_for_imp.md)
# OPS11-BP01 设置持续改进流程
根据内部和外部架构最佳实践评估工作负载。经常开展目标明确的工作负载审查工作。将改进机会优先纳入软件开发周期。
**期望结果：**
+ 经常根据架构最佳实践来分析工作负载。
+ 在软件开发过程中，同等重视性能改进机会。
**常见反模式：**
+ 自从几年前部署工作负载以来，没有对其进行过架构审查。
+ 不重视改进机会。相比新功能的开发，这些机会仍在积压工作中。
+ 不存在对组织最佳实践实施修改的标准。
**建立此最佳实践的好处：**
+ 工作负载符合最新的架构最佳实践。
+ 按照明确的目的来改进工作负载。
+ 可以利用组织最佳实践来改进所有工作负载。
+ 所获边际收益带来的影响会不断累积，从而推动效率的提升。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
经常对工作负载进行架构审查。利用内部和外部最佳实践，评估工作负载并确定改进机会。将改进机会优先纳入软件开发周期。
### 实施步骤
1. 按照议定的频率，定期对生产工作负载进行架构审查。使用记录在册的架构标准，包括 AWS 特定的最佳实践。
1. 使用内部定义的标准完成这些审查工作。如果没有内部标准，请使用 AWS Well-Architected Framework。
1. 使用 AWS Well-Architected Tool 来创建内部最佳实践的自定义剖析，并进行架构审查。
1. 联系 AWS 解决方案架构师或技术客户经理，在他们的指导下，对工作负载进行 Well-Architected Framework 审查。
1. 将审查中发现的改进机会优先纳入软件开发过程。
**实施计划的工作量级别：**低。可以使用 AWS Well-Architected Framework 执行年度架构审查。
## 资源
**相关最佳实践：**
+ [OPS11-BP02 在意外事件发生后执行分析](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_perform_rca_process.html)
+ [OPS11-BP08 记录和分享经验教训](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_share_lessons_learned.html)
+ [OPS04 实施可观测性](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_process_cont_imp.html)
**相关文档：**
+ [AWS Well-Architected Tool - Custom lenses](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html)
+ [AWS Well-Architected 白皮书 – 审查流程](https://docs.aws.amazon.com/wellarchitected/latest/framework/the-review-process.html)
+ [Customize Well-Architected Reviews using Custom Lenses and the AWS Well-Architected Tool](https://aws.amazon.com/blogs/mt/customize-well-architected-reviews-using-custom-lenses-and-the-aws-well-architected-tool/)
+ [Implementing the AWS Well-Architected Custom Lens lifecycle in your organization](https://aws.amazon.com/blogs/architecture/implementing-the-aws-well-architected-custom-lens-lifecycle-in-your-organization/)
**相关视频：**
+ [AWS re:Invent 2023 - Scaling AWS Well-Architected best practices across your organization](https://youtu.be/UXtZCoE9qfQ?si=OPATCOY2YAwiF2TS)
**相关示例：**
+ [AWS Well-Architected Tool](https://docs.aws.amazon.com/wellarchitected/latest/userguide/intro.html)
# OPS11-BP02 在意外事件发生后执行分析
审查影响客户的事件，确定这些事件的成因和预防措施。利用这些信息来制定缓解措施，限制或防止再次发生同类事件。制定程序，以便迅速有效地做出响应。根据目标受众，适当传达事件成因和纠正措施。
**期望结果：**
+ 已建立包括意外事件后分析在内的事件管理流程。
+ 已制定可观测性计划来收集事件数据。
+ 利用这些数据，可以了解并收集指标，用于支持意外事件后分析流程。
+ 从意外事件中吸取教训，以便改善以后的结果。
**常见反模式：**
+ 管理应用程序服务器。大约每 23 小时 55 分钟，所有活动会话都会终止。已尝试找出应用程序服务器上出现的问题。曾怀疑可能是网络问题，但由于网络团队工作繁忙无法提供支持，因此无法与他们合作。由于缺乏可遵循的预定义流程，因此难以获取支持并收集必要的信息，来确定发生了什么情况。
+ 工作负载中出现了数据丢失的情况。这是第一次发生，原因不明。您认为数据丢失不重要，因为可以重新创建数据。数据丢失变得愈发频繁，并对客户造成影响。还原丢失的数据时，这也会增加运营负担。
**建立此最佳实践的好处：**
+ 建立了预定义流程，可确定导致意外事件发生的要素、条件、操作和事件，有助于找到改进机会。
+ 可以使用来自意外事件后分析的数据进行改进。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
通过流程来确定事件成因。审查所有影响客户的意外事件。设置流程来确定并记录导致意外事件的因素，以便制定缓解措施来限制或防止事件再次发生，并且还可以据此制定及时有效的响应程序。酌情传达造成意外事件的根本原因，并针对目标受众量身定制传达内容。在组织内公开分享经验教训。
### 实施步骤
1. 收集各种指标，例如部署更改、配置更改、意外事件开始时间、警报时间、参与时间、缓解措施开始时间和意外事件解决时间。
1. 在时间表上描述关键时间点，用于了解意外事件。
1. 提出以下问题：
1. 能否缩短检测时间？
1. 是否更新了可以更快地检测到事件的指标和警报？
1. 能否缩短诊断时间？
1. 您的响应计划或上报计划是否有更新，可以更快地与正确的响应者进行互动？
1. 能否缩短缓解时间？
1. 可以添加或改进哪些运行手册或行动手册步骤？
1. 未来能否防止意外事件再次发生？
1. 创建检查清单和操作。跟踪并交付所有操作。
**实施计划的工作量级别：**中
## 资源
**相关最佳实践：**
+ [OPS11-BP01 设置持续改进流程](ops_evolve_ops_process_cont_imp.md)
+ [OPS4 – 实施可观测性](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/implement-observability.html)
**相关文档：**
+ [Performing a post-incident analysis in Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/analysis.html)
+ [Operational Readiness Review](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/iteration.html)
# OPS11-BP03 实施反馈环路
反馈环路提供了可操作的洞察，可推动决策的制定。在程序和工作负载中建立反馈环路。这有助于确定问题和需要改进的领域。还可以验证在改进方面所做的投入。这些反馈环路为持续改进工作负载奠定了基础。
反馈环路分为两类：*即时反馈*和*回顾性分析*。通过审查运营活动的绩效和成果来收集即时反馈。此反馈来自团队成员、客户或活动的自动化输出。通过 A/B 测试和发布新功能等方式接收即时反馈，这对于快速失效机制至关重要。
定期执行回顾性分析，可以获取对一段时间内的运营成果和指标的审查反馈。这些回顾可在冲刺结束时、按节奏或在重大发布或事件之后进行。这种类型的反馈环路可验证在运营或工作负载方面的投入。它有助于衡量成功并验证策略。
**期望结果：**可以使用即时反馈和回顾性分析来推动改进。有一种机制可用于捕获用户和团队成员的反馈。回顾性分析用于确定可推动改进的趋势。
**常见反模式：**
+ 推出了一项新功能，但无法接收客户对此新功能的反馈。
+ 在投资运营改进后，无需进行回顾来验证改进。
+ 收集客户反馈，但不定期审查。
+ 反馈环路会产生建议的操作项，但它们不包括在软件开发过程中。
+ 对于所提出的改进事项，客户不会收到关于它们的反馈。
**建立此最佳实践的好处：**
+ 可以从客户的角度逆向展开工作，以便推动新功能。
+ 组织文化能够更快地对变化做出反应。
+ 趋势用于确定改进机会。
+ 回顾将验证对工作负载和运营所做的投入。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
实施此最佳实践意味着同时使用即时反馈和回顾性分析。这些反馈环路将推动改进。有许多适用于即时反馈的机制，包括调查、客户投票或反馈表。组织还使用回顾来确定改进机会并验证计划。
**客户示例**
AnyCompany Retail 创建了一个 Web 表单，客户可使用此表单提供反馈或报告问题。在每周 Scrum 期间，软件开发团队将评估用户反馈。定期使用反馈来引导相应平台的发展。他们在每个冲刺结束时进行回顾，确定需要改进的项目。
## 实施步骤
1. 即时反馈
+ 需要一种机制来接收客户和团队成员提供的反馈。也可以将运营活动配置为提供自动反馈。
+ 组织需要一个流程来审查此反馈、确定要改进的方面并安排改进。
+ 必须将反馈纳入软件开发过程中。
+ 在实施改进时，请跟进反馈提交者。
+ 可以使用 [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html) 以 [OpsItems](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter-working-with-OpsItems.html) 的形式创建和跟踪这些改进。
1. 回顾性分析
+ 在开发周期结束时、按设定的节奏或在重大发布后进行回顾。
+ 召开回顾性会议，让工作负载中涉及的利益相关方参加。
+ 在白板或电子表格上创建三列：“停止”、“开始”和“继续”。
+ *停止*列针对的是希望团队停止执行的任何工作。
+ *开始*列针对的是要开始付诸行动的想法。
+ *继续*列针对的是要继续执行的项目。
+ 在会议室里四处走动，从利益相关方那里收集反馈。
+ 确定反馈的优先级。将操作和利益相关方分配给“开始”或“继续”项目。
+ 将操作添加到软件开发过程中，并在实施改进时将状态更新传达给利益相关方。
**实施计划的工作量级别：**中。要实施此最佳实践，您需要一种方法来获取并分析即时反馈。此外，还需要建立一个回顾性分析流程。
## 资源
**相关最佳实践：**
+ [OPS01-BP01 评估外部客户需求](ops_priorities_ext_cust_needs.md)：反馈环路是一种用于收集外部客户需求的机制。
+ [OPS01-BP02 评估内部客户需求](ops_priorities_int_cust_needs.md)：内部利益相关方可以使用反馈环路来传达需求和要求。
+ [OPS11-BP02 在意外事件发生后执行分析](ops_evolve_ops_perform_rca_process.md)：意外事件后分析是发生意外事件后进行回顾性分析的重要形式。
+ [OPS11-BP07 审查运营指标](ops_evolve_ops_metrics_review.md)：运营指标审查可确定趋势和需要改进的方面。
**相关文档：**
+ [7 Pitfalls to Avoid When Building a CCOE](https://aws.amazon.com/blogs/enterprise-strategy/7-pitfalls-to-avoid-when-building-a-ccoe/)
+ [Atlassian 团队行动手册 – 回顾](https://www.atlassian.com/team-playbook/plays/retrospective)
+ [Email Definitions: Feedback Loops](https://aws.amazon.com/blogs/messaging-and-targeting/email-definitions-feedback-loops/)
+ [Establishing Feedback Loops Based on the AWS Well-Architected Framework Review](https://aws.amazon.com/blogs/architecture/establishing-feedback-loops-based-on-the-aws-well-architected-framework-review/)
+ [IBM Garage 方法 – 保持回顾](https://www.ibm.com/garage/method/practices/learn/practice_retrospective_analysis/)
+ [Investopedia – The PDCS Cycle](https://www.investopedia.com/terms/p/pdca-cycle.asp)
+ [Tim Cochran 所著的《Maximizing Developer Effectiveness》](https://martinfowler.com/articles/developer-effectiveness.html)
+ [Operations Readiness Reviews（ORR）白皮书 – Iteration](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/iteration.html)
+ [ITIL CSI - Continual Service Improvement](https://wiki.en.it-processmaps.com/index.php/ITIL_CSI_-_Continual_Service_Improvement)
+ [When Toyota met e-commerce: Lean at Amazon](https://www.mckinsey.com/capabilities/operations/our-insights/when-toyota-met-e-commerce-lean-at-amazon)
**相关视频：**
+ [Building Effective Customer Feedback Loops](https://www.youtube.com/watch?v=zz_VImJRZ3U)
**相关示例：**
+ [Astuto – 客户反馈开源工具](https://github.com/riggraz/astuto)
+ [AWS 解决方案 – AWS 上的 QnABot](https://aws.amazon.com/solutions/implementations/qnabot-on-aws/)
+ [Fider – 客户反馈整理平台](https://github.com/getfider/fider)
**相关服务：**
+ [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html)
# OPS11-BP04 执行知识管理
知识管理帮助团队成员找到完成其工作所需的信息。在学习型组织中，成员自由分享信息，从而增强个人的能力。可以发现和搜索信息。信息准确且保持最新。制定可创建新信息、更新现有信息和归档过时信息的机制。知识管理平台最常见例子是 Wiki 之类的内容管理系统。
**期望结果：**
+ 团队成员可以及时获取准确的信息。
+ 信息可搜索。
+ 制定可添加、更新和归档信息的机制。
**常见反模式：**
+ 没有集中式知识存储。团队成员在其本地计算机上管理自己的笔记。
+ 有自托管 Wiki，但没有制定机制来管理信息，导致信息过时。
+ 有人发现了缺失的信息，但没有制定流程来请求将其添加到团队 Wiki 中。他们自己添加信息，但他们错过了一个关键步骤，导致发生中断。
**建立此最佳实践的好处：**
+ 由于可以自由分享信息，团队成员的能力得到了增强。
+ 由于文档保持最新且可搜索，新团队成员可以更快上手。
+ 信息及时、准确且富有实用价值。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
知识管理是学习型组织的一个重要方面。首先，需要一个中央存储库来存储知识（一个常见的例子是自托管 Wiki）。必须制定用于添加、更新和归档知识的流程。为应该记录的内容制定标准，并让每一个人都能做出贡献。
**客户示例**
AnyCompany Retail 托管了一个内部 Wiki，其中存储了他们的所有知识。公司鼓励团队成员在履行日常职责时向知识库中添加内容。每个季度，跨职能团队会评估哪些页面的内容更新最少，并确定这些页面是否需要归档或更新。
**实施步骤**
1. 首先确定用于存储知识的内容管理系统。获得整个组织的利益相关方的同意。
1. 如果还没有内容管理系统，则在刚开始的时候请考虑运行自托管 Wiki，或使用版本控制存储库。
1. 编制用于添加、更新和归档信息的运行手册。就这些流程对团队进行培训。
1. 确定应该在内容管理系统中存储哪些知识。从团队成员执行的日常活动（运行手册和行动手册）开始。与利益相关方一起对添加的知识进行优先级排序。
1. 定期与利益相关方一起找出过时的信息并将其归档或更新。
**实施计划的工作量级别：**中。如果还没有内容管理系统，则可以设置自托管 Wiki 或版本控制文档存储库。
## 资源
**相关最佳实践：**
+ [OPS11-BP08 记录和分享经验教训](ops_evolve_ops_share_lessons_learned.md) – 知识管理可促进有关经验教训的信息分享。
**相关文档：**
+ [Atlassian – 知识管理](https://www.atlassian.com/itsm/knowledge-management)
**相关示例：**
+ [DokuWiki](https://www.dokuwiki.org/dokuwiki)
+ [Gollum](https://github.com/gollum/gollum)
+ [MediaWiki](https://www.mediawiki.org/wiki/MediaWiki)
+ [Wiki.js](https://github.com/Requarks/wiki)
# OPS11-BP05 确定推动改进的因素
确定推动改进的因素，有助于根据数据和反馈环路来评估机会并进行优先级排序。探索系统和流程的改进机会，并根据具体情况相应采用自动化功能。
**期望结果：**
+ 跟踪整个环境中的数据。
+ 将事件和活动与业务成果相关联。
+ 可以在环境和系统之间进行比较和对比。
+ 保留部署和成果的详细活动历史记录。
+ 收集数据来支持安全态势。
**常见反模式：**
+ 您从整个环境中收集数据，但没有关联事件和活动。
+ 收集所有资产的详细数据，而这导致 Amazon CloudWatch 和 AWS CloudTrail 的活动及成本增加。但是，并没有让这些数据发挥出作用。
+ 在确定推动改进的因素时，没有考虑业务成果。
+ 没有衡量新功能的效果。
**建立此最佳实践的好处：**
+ 通过确定用于改进的标准，尽可能减小基于事件的动机或情感投入所带来的影响。
+ 可以响应业务事件，而不仅仅是技术事件。
+ 可以衡量环境来确定需要改进的方面。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
+ 了解推动改进的因素：应该只在能够实现期望结果的情况下更改某个系统。
+ 需要的功能：在评估改进机会时评估期望的特性和功能。
+ [AWS 的新功能](https://aws.amazon.com/new/)
+ 无法接受的问题：在评估改进机会时，评估无法接受的问题、错误和漏洞。跟踪合理调整大小选项，寻找优化机会。
+ [AWS 最新安全公告](https://aws.amazon.com/security/security-bulletins/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/)
+ [Cloud Intelligence Dashboards](https://www.wellarchitectedlabs.com/cloud-intelligence-dashboards/)
+ 合规性要求：在分析改进机会时，评估为了保持监管和政策合规性，或获取第三方支持，所需的更新和更改。
+ [AWS 合规性](https://aws.amazon.com/compliance/)
+ [AWS 合规性计划](https://aws.amazon.com/compliance/programs/)
+ [AWS 合规性最新消息](https://aws.amazon.com/compliance/compliance-latest-news/)
## 资源
**相关最佳实践：**
+ [OPS01 组织优先事项](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/organization-priorities.html)
+ [OPS02 关系和所有权](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/relationships-and-ownership.html)
+ [OPS04-BP01 确定关键绩效指标](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_observability_identify_kpis.html)
+ [OPS08 利用工作负载可观测性](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/utilizing-workload-observability.html)
+ [OPS09 了解运营状况](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/understanding-operational-health.html)
+ [OPS11-BP03 实施反馈环路](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_feedback_loops.html)
**相关文档：**
+ [Amazon Athena](https://aws.amazon.com/athena/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc)
+ [Quick](https://aws.amazon.com/quicksight/)
+ [AWS 合规性](https://aws.amazon.com/compliance/)
+ [AWS 合规性最新消息](https://aws.amazon.com/compliance/compliance-latest-news/)
+ [AWS 合规性计划](https://aws.amazon.com/compliance/programs/)
+ [AWS Glue](https://aws.amazon.com/glue/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc)
+ [AWS 最新安全公告](https://aws.amazon.com/security/security-bulletins/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/)
+ [Export your log data to Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html)
+ [AWS 的新功能](https://aws.amazon.com/new/)
+ [以客户为中心的创新势在必行](https://aws.amazon.com/executive-insights/content/the-imperatives-of-customer-centric-innovation/)
+ [Digital Transformation: Hype or a Strategic Necessity?](https://aws.amazon.com/blogs/enterprise-strategy/digital-transformation-hype-or-a-strategic-necessity/)
**相关视频**
+ [AWS re:Invent 2023 - Improve operational efficiency and resilience with 支持 (SUP310)](https://youtu.be/jaehZYBNG0Y?si=UNEaLZsXDrxcBgYo)
# OPS11-BP06 验证分析结果
与跨职能团队和业务负责人共同审查分析结果和响应措施。通过这些审查工作来建立共识、发现其他影响并确定行动方案。适当调整响应措施。
**期望结果：**
+ 与业务负责人一起定期审查分析结果。业务负责人为新获得的洞察提供更多背景信息。
+ 您审查分析结果并让技术同事提供反馈，然后在团队之间分享学到的经验教训。
+ 您发布数据和分析结果，让其他技术团队和业务团队进行审查。将学到的经验教训融入到其他部门的新实践中。
+ 与高层领导一起总结和审查新分析结果。高层领导使用新的分析结果来定义策略。
**常见反模式：**
+ 您发布了新功能。此功能改变了一些客户行为。可观测性没有考虑到这些变化。您无法量化这些变化带来的益处。
+ 推送新的更新，却忽略了刷新 CDN。CDN 缓存不再与最新版本兼容。衡量出错请求的百分比。所有用户在与后端服务器通信时，都报告了 HTTP 400 错误。调查客户端出现的错误时，发现是因为衡量了错误的维度，导致时间就这样白白浪费了。
+ 服务水平协议规定正常运行时间为 99.9%，恢复点目标是 4 小时。服务负责人坚持认为系统应该是零停机时间。您实施了昂贵而复杂的复制解决方案，浪费了时间和金钱。
**建立此最佳实践的好处：**
+ 与业务负责人和主题专家一起验证分析结果时，就可以建立共识并更有效地指导改进。
+ 发现隐藏的问题，并在未来的决策中考虑到这些问题。
+ 重心从技术成果转移到业务成果。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
+ **验证分析结果**：与业务负责人和主题专家沟通，确保对收集的数据价值达成共识和一致。找出其他问题、潜在影响并制定行动方案。
## 资源
**相关最佳实践：**
+ [OPS01-BP06 在管理益处与风险的同时评估各种权衡因素](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_priorities_eval_tradeoffs.html)
+ [OPS02-BP06 预先定义或协商团队间的职责](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_neg_team_agreements.html)
+ [OPS11-BP03 实施反馈环路](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_feedback_loops.html)
**相关文档：**
+ [Designing a Cloud Center of Excellence (CCOE)](https://aws.amazon.com/blogs/enterprise-strategy/designing-a-cloud-center-of-excellence-ccoe/)
**相关视频：**
+ [Building observability to increase resiliency](https://youtu.be/6bJkYtrMMPI?si=yu8tVMz4a6ax9f34&t=2695)
# OPS11-BP07 审查运营指标
定期与来自不同业务领域的跨团队参与者对运营指标进行回顾性分析。通过这些分析来确定改进机会和可能的行动方案，并分享经验教训。寻找所有环境（例如，开发、测试和生产环境）中的改进机会。
**期望结果：**
+ 经常审查影响业务的指标
+ 通过可观测性功能来检测和审查异常
+ 使用数据来支持实现业务成果和目标
**常见反模式：**
+ 维护时段导致一次重要的零售促销活动中断。如果存在其他影响业务的事件，可能延迟标准维护时段，而业务部门对此并不知晓。
+ 由于组织中广泛使用了过时的库，导致长时间停机。自此之后，迁移到受支持的库。组织中的其他团队尚未意识到风险的存在。
+ 您没有定期审查客户 SLA 的达成情况。您目前正趋向于无法满足客户 SLA。如果无法满足客户 SLA，将会受到经济处罚。
**建立此最佳实践的好处：**
+ 如果能够定期开会审查运营指标、事件和意外事件，就可以在团队之间达成共识。
+ 团队定期开会来审查指标和意外事件，这样可以很好地针对风险采取行动并实现客户 SLA。
+ 可以分享学到的经验教训，这样能提供数据，根据业务成果确定优先事项和有针对性的改进。
**在未建立这种最佳实践的情况下暴露的风险等级：**中
## 实施指导
+ 定期与来自不同业务领域的跨团队参与者对运营指标进行回顾性分析。
+ 与包括业务、开发和运营团队在内的利益相关方交流，共同验证通过即时反馈和回顾性分析得到的调查发现，并分享经验教训。
+ 根据他们的洞察来确定改进机会和可能的行动方案。
## 资源
**相关最佳实践：**
+ [OPS08-BP05 创建控制面板](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_workload_observability_create_dashboards.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)
**相关文档：**
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [Amazon CloudWatch 指标和维度参考](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [发布自定义指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [使用 Amazon CloudWatch 指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [Dashboards and visualizations with CloudWatch](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/cloudwatch-dashboards-visualizations.html)
# OPS11-BP08 记录和分享经验教训
记录和分享在运营活动中获得的经验教训，以便在内部和不同团队中运用。应分享团队学到的经验教训，从而增加整个组织获得的效益。分享信息和资源来防止可避免的错误，简化开发工作，并将重心放在交付所需的功能上。
使用 AWS Identity and Access Management（IAM）定义权限，允许对要在账户内和账户之间分享的资源进行受控访问。
**期望结果：**
+ 使用版本受控的存储库来分享应用程序库、脚本程序、程序文档和其他系统文档。
+ 将基础设施标准作为版本受控的 AWS CloudFormation 模板分享。
+ 查看各团队学到的经验教训。
**常见反模式：**
+ 由于组织中广泛使用有错误的库，导致长时间的停机。自此之后，迁移到受支持的库。组织中的其他团队尚未意识到风险的存在。没有人记录和分享使用这个库的体验，也没人意识到风险。
+ 您已经确定内部分享微服务中导致会话中断的边缘案例。为了避免这一边缘案例的出现，更新了对服务的调用。组织中的其他团队尚未意识到风险的存在。
+ 已找到一种方法，可以显著降低其中一个微服务的 CPU 利用率要求。不知道其他团队是否可以利用这种技术。
**建立此最佳实践的好处：**分享经验教训，从而支持改进并最大限度地发挥经验的益处。
**在未建立这种最佳实践的情况下暴露的风险等级：**低
## 实施指导
+ **记录和分享经验教训：**设置程序来记录在运营活动执行和回顾性分析过程中获得的经验教训，供其他团队利用。
+ **分享经验教训：**设置程序来在不同团队中分享经验教训和相关项目。例如，通过方便访问的 Wiki，分享更新后的程序、指南、管理机制和最佳实践。通过公共存储库分享脚本、代码和库。
+ 利用 [AWS re:Post Private](https://aws.amazon.com/repost-private/) 作为知识服务，来简化组织内的协作和知识共享。
## 资源
**相关最佳实践：**
+ [OPS02-BP06 预先定义或协商团队间的职责](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_neg_team_agreements.html)
+ [OPS05-BP01 使用版本控制](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_version_control.html)
+ [OPS05-BP06 共享设计标准](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_share_design_stds.html)
+ [OPS11-BP03 实施反馈环路](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_feedback_loops.html)
+ [OPS11-BP07 审查运营指标](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_metrics_review.html)
**相关文档：**
+ [ Increase collaboration and securely share cloud knowledge with AWS re:Post Private ](https://aws.amazon.com/blogs/aws/increase-collaboration-and-securely-share-cloud-knowledge-with-aws-repost-private/)
+ [ Reduce project delays with a docs-as-code solution ](https://aws.amazon.com/blogs/infrastructure-and-automation/reduce-project-delays-with-docs-as-code-solution/)
**相关视频：**
+ [AWS re:Invent 2023 - Collaborate within your company and with AWS using AWS re:Post Private ](https://www.youtube.com/watch?v=HNq_kU2QJLU)
+ [支持s You \$1 Exploring the Incident Management Tabletop Exercise](https://www.youtube.com/watch?v=0m8sGDx-pRM)
# OPS11-BP09 分配时间进行改进
流程中专用的时间和资源可以实现持续渐进式改进。
**期望结果：**
+ 创建了临时的环境副本，这可以降低试验和测试的风险、工作量及成本。
+ 这些重复的环境可用于测试根据分析得出的结论，对计划的改进进行试验、开发和测试。
+ 开展 GameDay 活动，并使用故障注入服务（FIS），提供团队在类似于生产环境的条件下开展实验所需的控制措施和防护机制。
**常见反模式：**
+ 应用程序服务器中存在一个已知性能问题。将其添加到积压工作中，列在所有计划功能实施之后。如果一直保持这种添加计划功能的速度，性能问题将永远无法得到解决。
+ 为了支持持续改进，批准管理员和开发人员利用他们所有的额外时间来选择和实施改进。没有完成任何改进。
+ 运营验收完成后，再也没有测试过运营实践。
**建立此最佳实践的好处：**通过在流程中投入专门的时间和资源，可以实现持续渐进式改进。
**在未建立这种最佳实践的情况下暴露的风险等级：**低
## 实施指导
+ 分配时间进行改进：在流程中投入专门的时间和资源，用于实现持续渐进式改进。
+ 实施更改以便改进，并评估结果来确定是否成功。
+ 如果结果不符合目标，并且仍然需要改进，则寻求其他行动方案。
+ 通过 GameDay 活动来模拟生产工作负载，并使用从这些模拟中学到的经验教训进行改进。
## 资源
**相关最佳实践：**
+ [OPS05-BP08 使用多个环境](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_dev_integ_multi_env.html)
**相关视频：**
+ [AWS re:Invent 2023 - Improve application resilience with AWS Fault Injection Service](https://youtu.be/N0aZZVVZiUw?si=ivYa9ScBfHcj-IAq)