# 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)