# 演进
**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 设置持续改进流程
根据内部和外部架构最佳实践评估您的工作负载。至少每年执行一次工作负载审核。将改进机会优先纳入您的软件开发周期。
**期望结果：**
+ 至少每年都根据架构最佳实践来分析工作负载。
+ 在软件开发过程中，为改进机会赋予同等的优先级。
**常见反模式：**
+ 自从几年前部署工作负载以来，您没有对其进行过架构审查。
+ 改进机会的优先级较低，并停留在待办事项列表中。
+ 不存在对组织的最佳实践实施修改的标准。
**建立此最佳实践的好处：**
+ 您的工作负载符合最新的架构最佳实践。
+ 深思熟虑地推进工作负载的演变。
+ 您可以利用组织的最佳实践来改善所有工作负载。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
至少每年一次，对工作负载进行架构审查。利用内部和外部最佳实践，评估您的工作负载并确定改进机会。将改进机会优先纳入您的软件开发周期。
**客户示例**
AnyCompany Retail 的所有工作负载都要经过每年一次的架构审查过程。他们开发了自己的最佳实践清单，适用于所有工作负载。使用 AWS Well-Architected Tool 的自定义剖析功能，他们通过该工具和最佳实践自定义剖析进行审查。通过审查发现的改进机会在他们的软件冲刺中被优先考虑。
**实施步骤**
1. 至少每年一次，对您的生产工作负载进行定期架构审查。使用记录在册的架构标准，包括 AWS 特定的最佳实践。
1. 建议您使用您自己内部定义的标准来进行这些审查。如果没有内部标准，建议您使用 AWS Well-Architected Framework。
1. 您可以使用 AWS Well-Architected Tool 来创建自己的内部最佳实践的自定义剖析，并进行架构审查。
1. 客户可以联系他们的 AWS 解决方案架构师，对他们的工作负载进行一次指导式 Well-Architected Framework 审查。
1. 将审查中发现的改进机会优先纳入您的软件开发过程。
**实施计划的工作量级别：**低。可以使用 AWS Well-Architected Framework 执行年度架构审核。
### 资源
**相关最佳实践：**
+ [OPS11-BP02 在意外事件发生后执行分析](ops_evolve_ops_perform_rca_process.md) - 事件后分析是改进项目的另一个来源。将学到的经验教训纳入您自己的内部架构最佳实践清单。
+ [OPS11-BP08 记录和分享经验教训](ops_evolve_ops_share_lessons_learned.md) - 在开发自己的架构最佳实践时，在组织内分享这些最佳实践。
**相关文档：**
+ [AWS Well-Architected Tool – 自定义剖析](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)
+ [使用自定义剖析和 AWS Well-Architected Tool 定制 Well-Architected 审查](https://aws.amazon.com/blogs/mt/customize-well-architected-reviews-using-custom-lenses-and-the-aws-well-architected-tool/)
+ [在组织中实施 AWS Well-Architected 自定义剖析生命周期](https://aws.amazon.com/blogs/architecture/implementing-the-aws-well-architected-custom-lens-lifecycle-in-your-organization/)
**相关视频：**
+ [Well-Architected 实验室 - 级别 100：AWS Well-Architected Tool 自定义剖析](https://www.wellarchitectedlabs.com/well-architectedtool/100_labs/100_custom_lenses_on_watool/)
**相关示例：**
+ [AWS Well-Architected Tool](https://docs.aws.amazon.com/wellarchitected/latest/userguide/intro.html)
# OPS11-BP02 在意外事件发生后执行分析
审核影响客户的事件，确定导致这些事件的因素和预防措施。利用这些信息来制定缓解措施，以限制或防止再次发生同类事件。制定程序以迅速有效地做出响应。根据目标受众，适当传达事件成因和纠正措施。
**常见反模式：**
+ 您管理应用程序服务器。大约每 23 小时 55 分钟，所有活动会话都会终止。您已尝试找出应用程序服务器上出现的问题。您怀疑可能是网络问题，但由于网络团队工作繁忙无法为您提供支持，因此无法与他们合作。由于缺乏可遵循的预定义流程，因此难以获取支持并收集必要的信息来确定发生了什么情况。
+ 您的工作负载中出现了数据丢失的情况。这是第一次发生，原因不明。您认为它不重要，因为可以重新创建数据。数据丢失对客户的影响开始变得愈发频繁。还原丢失的数据时，这也会增加您的操作负担。
**建立此最佳实践的好处：** 设置预定义的流程，以确定导致意外事件发生的要素、条件、操作和事件，从而帮助您找到改进机会。
**未建立这种最佳实践的情况下暴露的风险等级：** 高
## 实施指导
+ 通过流程来确定事件成因：审查所有影响客户的意外事件。设置流程来确定和记录导致意外事件的因素，以便制定缓解措施来限制或防止事件再次发生，并且您还可以据此制定及时有效的应对措施。在适当的情况下向目标受众说明根本原因。
# OPS11-BP03 实施反馈环路
反馈环路提供了可操作的见解，进而推动决策的制定。将反馈环路融入过程和工作负载中。这可帮助您确定问题和需要改进的领域。它们还可以验证在改进方面所做的投入。这些反馈环路为持续改进工作负载奠定了基础。
反馈环路分为两大类： *即时反馈* 和 *回顾性分析*。通过审查运营活动的绩效和成果来收集即时反馈。此反馈来自团队成员、客户或活动的自动化输出。通过 A/B 测试和发布新功能等方式接收即时反馈，这对于快速失效机制至关重要。
定期执行回顾性分析，可以获得在运营成果审核和指标审核过程中产生的反馈。这些回顾在冲刺结束时进行、有节奏地进行或者在重大发布或事件之后进行。这种类型的反馈环路验证了在运营或工作负载方面的投入。它有助于衡量成功并验证您的策略。
**期望的结果：** 您可以使用即时反馈和回顾性分析来加快改进。有一种机制可用于捕获用户和团队成员的反馈。回顾性分析用于确定可推动改进的趋势。
**常见反模式：**
+ 您推出了一项新功能，但无法接收客户对此新功能的反馈。
+ 在投资进行运营改进后，您无需回顾来验证它们。
+ 您可以收集客户反馈，但不用定期进行审查。
+ 反馈环路会产生建议的操作项，但它们不包括在软件开发过程中。
+ 对于所提出的改进事项，客户不会收到关于它们的反馈意见。
**建立此最佳实践的好处：**
+ 您可以反过来从客户出发，以便推动新的功能。
+ 您的组织文化能够更快地对变更做出回应。
+ 趋势用于确定改进机会。
+ 回顾将验证对工作负载和运营所做的投入。
**未建立这种最佳实践的情况下暴露的风险等级：** 高
## 实施指导
实施此最佳实践意味着同时使用即时反馈和回顾性分析。这些反馈环路将推动改进。有许多适用于即时反馈的机制，包括调查、客户投票或反馈表。您的组织还使用回顾来确定改进机会并验证计划。
**客户示例**
AnyCompany Retail 创建了一个 Web 表单，客户可使用此表单提供反馈或报告问题。在每周 Scrum 期间，软件开发团队将评估用户反馈。反馈定期用于引导相应平台的发展。他们在每个冲刺结束时进行回顾，确定需要改进的项目。
## 实施步骤
1. 即时反馈
+ 您需要一种机制来接收由客户和团队成员提供的反馈，也可以将您的运营活动配置为交付自动反馈。
+ 您的组织需要一个流程，来审查此反馈、确定要改进的方面并安排改进。
+ 必须将反馈纳入您的软件开发过程中。
+ 在实施改进时，请对反馈提交者进行跟进。
+ 您可以使用 [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html) 将这些改进创建为 [OpsItem 并进行跟踪](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)：运营指标审查可确定趋势和需要改进的方面。
**相关文档：**
+ [构建 CCOE 时应避免的 7 个陷阱](https://aws.amazon.com/blogs/enterprise-strategy/7-pitfalls-to-avoid-when-building-a-ccoe/)
+ [Atlassian 团队行动手册 – 回顾](https://www.atlassian.com/team-playbook/plays/retrospective)
+ [电子邮件定义：反馈环路](https://aws.amazon.com/blogs/messaging-and-targeting/email-definitions-feedback-loops/)
+ [建立基于 AWS Well-Architected Framework 审查的反馈环路](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 – PDCS 循环](https://www.investopedia.com/terms/p/pdca-cycle.asp)
+ [Tim Cochran 所著的《最大限度地提高开发人员效率》](https://martinfowler.com/articles/developer-effectiveness.html)
+ [运营准备情况审查（ORR）白皮书 – 迭代](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/iteration.html)
+ [TIL CSI – 持续服务改进](https://wiki.en.it-processmaps.com/index.php/ITIL_CSI_-_Continual_Service_Improvement)
+ [当丰田转向电子商务：Amazon 的精益方法](https://www.mckinsey.com/capabilities/operations/our-insights/when-toyota-met-e-commerce-lean-at-amazon)
**相关视频：**
+ [构建有效的客户反馈环路](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 确定推动改进的因素
确定推动改进的因素，以便评估各种机会并确定其优先顺序。
在 AWS 上，您可以聚合所有运营活动、工作负载和基础设施的日志，以创建详细的活动历史记录。然后，您可以根据推动因素，使用 AWS 工具分析您在一段时间内的运营状况和工作负载运行状况（例如，确定趋势、将事件和活动与结果相关联，并在环境之间/跨系统进行比较和对比），以发现改进机会。
您应该使用 CloudTrail 跟踪 API 活动（通过 AWS 管理控制台、CLI、开发工具包和 API），以了解您账户中发生的情况。您可以使用 CloudTrail 和 CloudWatch 跟踪您的 AWS 开发人员工具部署活动。这将向您的 CloudWatch Logs 日志数据添加部署的详细活动历史记录及其结果。
[将您的日志数据导出到 Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html) 以便长期存储。使用 [AWS Glue](https://aws.amazon.com/glue/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc)，您可以在 Amazon S3 中发现并准备您的日志数据以供分析。使用 [Amazon Athena](https://aws.amazon.com/athena/?whats-new-cards.sort-by=item.additionalFields.postDateTime&whats-new-cards.sort-order=desc)，借助其与 AWS Glue 的原生集成来分析您的日志数据。使用像 [Quick](https://aws.amazon.com/quicksight/) 这样的商业智能工具，您可以直观显示、浏览和分析您的数据
**常见反模式：**
+ 您有一个脚本，可以正常运行但不完美。您投入时间重新编写。现在，它完美无缺。
+ 您的初创公司正试图从风险投资人那里获得另一笔资金。他们希望您证明符合 PCI DSS。您希望让他们满意，因此您记录合规性，但却错过了客户的交付日期，导致客户流失。您没有做错，但是现在您怀疑这样做是否合适。
**建立此最佳实践的好处：** 确定希望用于改进的标准后，您可以最大程度地减小基于事件的动机或情感投入所带来的影响。
**未建立这种最佳实践的情况下暴露的风险等级：** 中
## 实施指导
+ 了解推动改进的因素：您只应该在能够实现所需成果的情况下更改某个系统。
+ 需要的功能：在评估改进机会时评估需要的特性和功能。
+ [AWS 的新增功能](https://aws.amazon.com/new/)
+ 无法接受的问题：在评估改进机会时评估无法接受的问题、错误和漏洞。
+ [AWS 最新安全公告](https://aws.amazon.com/security/security-bulletins/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/)
+ 合规性要求：在分析改进机会时，评估保持监管和政策合规性或获取第三方支持所需的更新和更改。
+ [AWS 合规性](https://aws.amazon.com/compliance/)
+ [AWS 合规性计划](https://aws.amazon.com/compliance/programs/)
+ [AWS 合规性最新新闻](https://aws.amazon.com/compliance/compliance-latest-news/)
## 资源
**相关文档：**
+ [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/)
+ [将您的日志数据导出到 Amazon S3](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/S3Export.html)
+ [AWS 的新增功能](https://aws.amazon.com/new/)
# OPS11-BP06 验证分析结果
与跨职能团队和业务负责人共同查看分析结果和响应措施。通过这些工作来建立共识、发现其他影响并确定行动方案。适当调整响应措施。
**常见反模式：**
+ 您看到某个系统上的 CPU 利用率达到 95％，因此优先考虑寻找一种方法来减少系统上的负载。您认为最佳行动方案是进行扩展。系统是一个转码器，您可对它进行扩展，让它始终以 95％ 的 CPU 利用率运行。如果您先与系统负责人联系，他们会向您做出解释。您浪费了时间。
+ 系统负责人坚持认为他们的系统是关键任务型系统。系统未置于高安全性环境中。为了提高安全性，您需要对关键任务型系统实施额外的检测和预防控制措施。您通知系统负责人工作已完成，并向他收取额外资源的费用。在收到此通知后的沟通过程中，系统负责人了解到对于关键任务型系统有一个正式定义，而他的系统并不满足。
**建立此最佳实践的好处：** 通过与业务负责人和主题专家一起验证分析结果，您可以建立共识并更有效地指导改进。
**未建立这种最佳实践的情况下暴露的风险等级：** 中
## 实施指导
+ 验证分析结果：与业务负责人和主题专家沟通，以确保对您收集的数据的价值达成共识和一致。确定其他问题、潜在影响并制定行动方案。
# OPS11-BP07 审核运营指标
定期与来自不同业务领域的跨团队参与者对运营指标进行回顾性分析。通过这些分析来确定改进机会和可能的行动方案，并分享经验教训。
寻找在所有环境（例如，开发、测试和生产环境）中改进的机会。
**常见反模式：**
+ 维护时段导致一次重要的零售促销中断。如果存在其他影响业务的事件，可以延迟标准维护时段，而业务部门对此并不知晓。
+ 由于使用了组织中常用的错误库，导致了长时间的停机。自此之后，您已经迁移到可靠的库。您组织中的其他团队尚未意识到风险的存在。如果您定期开会并审核此意外事件，他们应该注意到这种风险。
+ 转码器的性能一直在不断下降，这对媒体团队产生了影响。但这还不算多严重。真正糟糕的是，除非情况严重到足以引发意外事件，否则您将难以发现。如果您与媒体团队一起审核运营指标，就有机会发现指标的变化，同时认识到他们的经验并利用这些经验将问题解决。
+ 您没有审核对客户 SLA 的满足程度。您目前正趋向于无法满足客户 SLA。如果无法满足客户 SLA，将会受到经济处罚。如果您定期开会审核这些 SLA 的指标，您将有机会发现并解决这一问题。
**建立此最佳实践的好处：** 您可以通过会议定期审核运营指标、事件和意外事件，在团队之间保持共识、分享经验教训，以及确定改进的优先级和目标。
**未建立此最佳实践暴露的风险等级：** 中
## 实施指导
+ 审核运营指标：定期与来自不同业务领域的跨团队参与者对运营指标进行回顾性分析。与包括业务、开发和运营团队在内的利益相关方共同分析通过即时反馈和回顾性分析得到的发现，并分享经验教训。根据他们的见解来确定改进机会和可能的行动方案。
+ [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/)
+ [使用 Amazon CloudWatch 指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [发布自定义指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Amazon CloudWatch 指标和维度参考](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.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)
# OPS11-BP08 记录和分享经验教训
记录和分享在运营活动中获得的经验教训，以便在内部和不同团队中利用。
您应该分享团队学到的经验教训，以增加整个组织的效益。您需要分享信息和资源，以防止出现可避免的错误并简化开发工作。这让您可以专注于交付所需的功能。
使用 AWS Identity and Access Management (IAM) 定义权限，以允许对您要在账户内和账户之间共享的资源进行受控访问。然后，您应该使用版本受控的 AWS CodeCommit 存储库来分享应用程序库、脚本程序、程序文档和其他系统文档。您可以共享对 AMI 的访问权限并授权跨账户使用 Lambda 函数，以此来分享您的计算标准。您还应将您的基础设施标准共享为 AWS CloudFormation 模板。
通过 AWS API 和 SDK，您可以集成外部和第三方工具和存储库（例如，GitHub、BitBucket 和 SourceForge）。在分享您学到的和开发的内容时，请注意设定权限以确保共享存储库的完整性。
**常见反模式：**
+ 由于使用了组织中常用的错误库，导致了长时间的停机。自此之后，您已经迁移到可靠的库。您组织中的其他团队尚未意识到风险的存在。如果您记录并分享对于此库的经验，他们就可能会注意到风险。
+ 您已经确定了内部共享微服务中导致会话中断的边缘案例。为了避免这一边缘案例的出现，您更新了对服务的调用。您组织中的其他团队尚未意识到风险的存在。如果您记录并分享对于此库的经验，他们就可能会注意到风险。
+ 您已找到一种方法，可以显著降低其中一个微服务的 CPU 利用率要求。您不知道其他团队是否可以利用这种技术。如果您记录并分享对于此库的经验，他们将有机会加以利用。
**建立此最佳实践的好处：** 分享经验教训可以为改进提供支持，并最大程度地从经验中获益。
**未建立这种最佳实践的情况下暴露的风险等级：** 低
## 实施指导
+ 记录和分享经验教训：设置程序来记录在运营活动执行和回顾性分析过程中获得的经验教训，供其他团队利用。
+ 分享经验教训：设置程序在不同团队中分享经验教训和相关构件。例如，通过可以访问的 Wiki 共享更新后的程序、指南、管理机制和最佳实践。通过公共存储库共享脚本、代码和库。
+ [授权访问 AWS 环境](https://www.youtube.com/watch?v=0zJuULHFS6A&t=849s)
+ [共享 AWS CodeCommit 存储库](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-share-repository.html)
+ [AWS Lambda 函数的简单授权](https://aws.amazon.com/blogs/compute/easy-authorization-of-aws-lambda-functions/)
+ [将 AMI 与特定 AWS 账户共享](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html)
+ [利用 AWS CloudFormation Designer URL 快速共享模板](https://aws.amazon.com/blogs/devops/speed-template-sharing-with-an-aws-cloudformation-designer-url/)
+ [将 AWS Lambda 与 Amazon SNS 配合使用](https://docs.aws.amazon.com/lambda/latest/dg/with-sns-example.html)
## 资源
**相关文档：**
+ [AWS Lambda 函数的简单授权](https://aws.amazon.com/blogs/compute/easy-authorization-of-aws-lambda-functions/)
+ [共享 AWS CodeCommit 存储库](https://docs.aws.amazon.com/codecommit/latest/userguide/how-to-share-repository.html)
+ [将 AMI 与特定 AWS 账户共享](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html)
+ [利用 AWS CloudFormation Designer URL 快速共享模板](https://aws.amazon.com/blogs/devops/speed-template-sharing-with-an-aws-cloudformation-designer-url/)
+ [将 AWS Lambda 与 Amazon SNS 配合使用](https://docs.aws.amazon.com/lambda/latest/dg/with-sns-example.html)
**相关视频：**
+ [授权访问 AWS 环境](https://www.youtube.com/watch?v=0zJuULHFS6A&t=849s)
# OPS11-BP09 分配时间进行改进
流程中专用的时间和资源可以实现持续增量改进。
在 AWS 上，您可以创建临时的环境副本，从而降低试验和测试的风险、工作量及成本。这些重复的环境可用于测试分析、试验、开发和测试计划改进时所得出的结论。
**常见反模式：**
+ 您的应用程序服务器中存在一个已知性能问题。它被添加到每个计划内功能实施之后的待办事项中。如果计划功能的添加速率保持不变，那么性能问题将永远无法解决。
+ 为了支持持续改进，您批准管理员和开发人员利用他们所有的额外时间来选择和实施改进。没有完成任何改进。
**建立此最佳实践的好处：** 通过在流程中投入专用时间和资源，您可以实现持续增量改进。
**未建立这种最佳实践的情况下暴露的风险等级：** 低
## 实施指导
+ 分配时间进行改进：在流程中抽出专门的时间和资源，用于实现持续增量改进。实施更改以便改进，并评估结果以确定是否成功。如果结果不符合目标，并且仍然需要改进，则寻求其他行动方案。