

# 准备
<a name="a-prepare"></a>

**Topics**
+ [OPS 4  如何设计工作负载以便自己了解其状态？](w2aac19b5b7b5.md)
+ [OPS 5  如何减少缺陷、简化修复和改进生产流程？](w2aac19b5b7b7.md)
+ [OPS 6  您如何缓解部署风险？](w2aac19b5b7b9.md)
+ [OPS 7 如何知道您已经准备好支持某种工作负载？](w2aac19b5b7c11.md)

# OPS 4  如何设计工作负载以便自己了解其状态？
<a name="w2aac19b5b7b5"></a>

 将工作负载设计成能够提供所有组件（例如指标、日志和跟踪信息）的必要信息，以便您了解其内部状态。这让您能够在适当的时候提供有效的响应。 

**Topics**
+ [OPS04-BP01 实施应用程序遥测](ops_telemetry_application_telemetry.md)
+ [OPS04-BP02 实施和配置工作负载遥测](ops_telemetry_workload_telemetry.md)
+ [OPS04-BP03 实施用户活动遥测](ops_telemetry_customer_telemetry.md)
+ [OPS04-BP04 实施依赖项遥测](ops_telemetry_dependency_telemetry.md)
+ [OPS04-BP05 实施事务跟踪](ops_telemetry_dist_trace.md)

# OPS04-BP01 实施应用程序遥测
<a name="ops_telemetry_application_telemetry"></a>

 应用程序遥测是实现工作负载可观测性的基础。您的应用程序应该发送遥测数据，提供对应用程序状态以及所实现业务成果的洞察。从故障排除到衡量新功能的影响，应用程序遥测可以为您构建、操作和演进工作负载的方法提供信息。 

 应用程序遥测数据包括指标和日志。指标是诊断信息，例如您的脉搏和体温。所有指标结合在一起，用于描述应用程序的状态。收集一段时间的指标，以便用于制定基准和检测异常。日志是应用程序发送的消息，说明其内部状态或所发生的事件。所记录事件的例子包括错误代码、事务标识符以及用户操作。 

 **期望结果：** 
+  应用程序发送指标和日志，提供对其运行状况以及所取得业务成果的洞察。 
+  工作负载中所有应用程序的指标和日志集中存储。 

 **常见反模式：** 
+  您的应用程序无法发出遥测。出现问题时，只能通过客户获知。 
+  客户反映您的应用程序没有响应。由于没有遥测，如果不亲自使用应用程序来了解当前的用户体验，就无法确认问题的存在，也无法确定问题的特征。 

 **建立此最佳实践的好处：** 
+  您可以了解应用程序的运行状况、用户体验以及所取得的业务成果。 
+  您可以更快地对应用程序运行状况中的更改做出反应。 
+  您可以了解应用程序运行状况趋势。 
+  您可以做出明智的决定来改进应用程序。 
+  您可以更快地检测并解决应用程序问题。 

 **未建立这种最佳实践的情况下暴露的风险等级：** 高 

## 实施指导
<a name="implementation-guidance"></a>

 实施应用程序遥测由三个步骤组成：确定存储遥测数据的位置，确定描述应用程序状态的遥测数据，以及指示应用程序发送遥测数据。 

 例如，电子商务公司采用了基于微服务的架构。作为其架构设计流程的一部分，他们确定了可以帮助了解各个微服务状态的应用程序遥测。例如，用户购物车服务可以针对商品添加到购物车、放弃购物车以及将商品添加到购物车所用时间长度等事件，发送遥测数据。所有微服务将记录错误、警告和事务信息。遥测数据可以发送到 Amazon CloudWatch 进行存储和分析。 

 **实施步骤** 

 第一步是针对工作负载中的应用程序，确定用于遥测数据存储的集中位置。如果您还没有现有平台， [Amazon CloudWatch](https://aws.amazon.com/cloudwatch) 会提供遥测数据收集、控制面板、分析和事件生成功能。 

 若要确定您需要哪些遥测数据，可以从以下问题开始着手： 
+  我的应用程序是否正常运行？ 
+  我的应用程序是否实现了业务成果？ 

   您的应用程序应该会发送日志和指标，综合起来即可解答这些问题。如果您无法利用现有的应用程序遥测解答这些问题，请与业务和工程设计利益相关方合作，创建可以做到这一点的遥测列表。在确定和开发新应用程序遥测的过程中，您可以请求 AWS 账户团队向您提供专家技术建议。 

   在确定其他应用程序遥测之后，与工程设计利益相关方合作来检测应用程序。 [适用于 OpenTelemetry 的 AWS Distro](https://aws-otel.github.io/) 提供收集应用程序遥测数据的 API、库和代理。 [此示例展示了如何使用自定义指标检测 JavaScript 应用程序](https://aws-otel.github.io/docs/getting-started/js-sdk/metric-manual-instr)。 

   客户如果希望了解 AWS 提供的可观测性服务，可以亲自参加 [可观测性研讨会](https://catalog.workshops.aws/observability/en-US) ，或者请求 AWS 账户团队的支持来提供指导。此研讨会引导您了解 AWS 上的可观测性解决方案，并提供如何使用这些解决方案的动手实践示例。 

   如需更深入地了解应用程序遥测，请阅读 Amazon Builders' Library 中的 [检测分布式系统的运营可见性](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) 文章。它说明了 Amazon 如何检测应用程序，并可供您用作开发自己的检测准则的指南。 

 **实施计划的工作量级别：** 中 

## 资源
<a name="resources"></a>

 **相关最佳实践：** 

[OPS04-BP02 实施和配置工作负载遥测](ops_telemetry_workload_telemetry.md) – 应用程序遥测是工作负载遥测的组件。为了理解工作负载的整体运行状况，您需要了解组成工作负载的单独应用程序的运行状况。

[OPS04-BP03 实施用户活动遥测](ops_telemetry_customer_telemetry.md) – 用户活动遥测通常是应用程序遥测的子集。添加商品到购物车、点击流或者已完成事务等用户活动可以提供对用户体验的洞察。

[OPS04-BP04 实施依赖项遥测](ops_telemetry_dependency_telemetry.md) – 依赖项检查与应用程序遥测相关，可以在应用程序中检测。如果您的应用程序依赖于外部依赖项，例如 DNS 或数据库，则应用程序可以发送有关可访问性、超时和其他事件的指标和日志。

[OPS04-BP05 实施事务跟踪](ops_telemetry_dist_trace.md) – 跨工作负载跟踪事务需要各个应用程序发送有关如何处理共享事件的信息。单独应用程序处理这些事件的方式通过其应用程序遥测发送。

[OPS08-BP02 定义工作负载指标](ops_workload_health_design_workload_metrics.md) – 工作负载指标是工作负载运行状况的主要指标。主要应用程序指标是工作负载指标的一部分。

 **相关文档：** 
+  [AWS Builders Library – 检测分布式系统的运营可见性](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility/) 
+  [适用于 OpenTelemetry 的 AWS Distro](https://aws-otel.github.io/) 
+  [AWS Well-Architected 卓越运营白皮书 – 设计遥测](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/design-telemetry.html) 
+  [使用筛选条件根据日志事件创建指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) 
+  [使用 Amazon CloudWatch 实施日志记录和监控](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/welcome.html) 
+  [使用适用于 OpenTelemetry 的 AWS Distro 监控应用程序运行状况和性能](https://aws.amazon.com/blogs/opensource/monitoring-application-health-and-performance-with-aws-distro-for-opentelemetry/) 
+  [新增 – 如何使用 Amazon CloudWatch 代理更好地监控自定义应用程序指标](https://aws.amazon.com/blogs/devops/new-how-to-better-monitor-your-custom-application-metrics-using-amazon-cloudwatch-agent/) 
+  [AWS 上的可观测性](https://aws.amazon.com/products/management-and-governance/use-cases/monitoring-and-observability/) 
+  [场景 – 发布指标到 CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/PublishMetrics.html) 
+  [开始构建 – 如何高效地监控应用程序](https://aws.amazon.com/startups/start-building/how-to-monitor-applications/) 
+  [将 CloudWatch 与 AWS SDK 结合使用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/sdk-general-information-section.html) 

 **相关视频：** 
+  [AWS re:Invent 2021 – 开源方式的可观测性](https://www.youtube.com/watch?v=vAnIhIwE5hY) 
+  [使用 CloudWatch 代理从 Amazon EC2 实例收集指标和日志](https://www.youtube.com/watch?v=vAnIhIwE5hY) 
+  [如何为 AWS 工作负载轻松设置应用程序监控 – AWS 在线技术讲座](https://www.youtube.com/watch?v=LKCth30RqnA) 
+  [掌握无服务器应用程序的可观测性 – AWS 在线技术讲座](https://www.youtube.com/watch?v=CtsiXhiAUq8) 
+  [AWS 上的开源可观测性 – AWS 虚拟研讨会](https://www.youtube.com/watch?v=vAnIhIwE5hY) 

 **相关示例：** 
+  [AWS 日志记录和监控示例资源](https://github.com/aws-samples/logging-monitoring-apg-guide-examples) 
+  [AWS 解决方案：Amazon CloudWatch 监控框架](https://aws.amazon.com/solutions/implementations/amazon-cloudwatch-monitoring-framework/?did=sl_card&trk=sl_card) 
+  [AWS 解决方案：集中式日志记录](https://aws.amazon.com/solutions/implementations/centralized-logging/) 
+  [可观测性研讨会](https://catalog.workshops.aws/observability/en-US) 

# OPS04-BP02 实施和配置工作负载遥测
<a name="ops_telemetry_workload_telemetry"></a>

 设计和配置工作负载，使其能够发出关于其内部状态和当前状态的信息，例如 API 调用量、HTTP 状态代码和扩展事件。使用这些信息帮助确定需要在什么时候响应。 

 使用 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 等服务聚合工作负载组件中的日志和指标（例如， [AWS CloudTrail 的 API 日志](https://aws.amazon.com/cloudtrail/)， [AWS Lambda 指标](https://docs.aws.amazon.com/lambda/latest/dg/lambda-monitoring.html)， [Amazon VPC 流日志](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html)和 [其他服务](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/aws-services-sending-logs.html)）。 

 **常见反模式：** 
+  您的客户抱怨性能不佳。您最近没有更改应用程序，因此您怀疑是工作负载组件的问题。由于没有遥测，您无法分析，难以确定是哪个或哪些组件导致了性能不佳。 
+  无法访问您的应用程序。由于没有遥测，难以确定是否是网络问题。 

 **建立此最佳实践的好处：** 了解工作负载的内部情况可让您能够在必要时做出响应。 

 **未建立此最佳实践暴露的风险等级：** 高 

## 实施指导
<a name="implementation-guidance"></a>
+  实施日志和指标遥测：构建工作负载，使其能够提供其内部状态和业务成果实现情况的信息。使用这些信息来确定需要在什么时候响应。 
  +  [使用 Amazon CloudWatch 获得对 VM 更好的可观测性 – AWS 在线技术讲座](https://youtu.be/1Ck_me4azMw) 
  +  [Amazon CloudWatch 的工作原理](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_architecture.html) 
  +  [什么是 Amazon CloudWatch？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) 
  +  [使用 Amazon CloudWatch 指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) 
  +  [什么是 Amazon CloudWatch Logs？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) 
    +  实施和配置工作负载遥测：设计和配置工作负载，使其能够发出关于其内部状态和当前状态的信息（例如 API 调用量、HTTP 状态代码和扩展事件）。 
      +  [Amazon CloudWatch 指标和维度参考](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) 
      +  [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) 
      +  [什么是 AWS CloudTrail？](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) 
      +  [VPC 流日志](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) 

## 资源
<a name="resources"></a>

 **相关文档：** 
+  [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) 
+  [Amazon CloudWatch 文档](https://docs.aws.amazon.com/cloudwatch/index.html) 
+  [Amazon CloudWatch 指标和维度参考](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html) 
+  [Amazon CloudWatch 的工作原理](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_architecture.html) 
+  [使用 Amazon CloudWatch 指标](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html) 
+  [VPC 流日志](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs.html) 
+  [什么是 AWS CloudTrail？](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) 
+  [什么是 Amazon CloudWatch Logs？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) 
+  [什么是 Amazon CloudWatch？](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) 

 **相关视频：** 
+  [AWS 上的应用程序性能管理](https://www.youtube.com/watch?v=5T4stR-HFas) 
+  [使用 Amazon CloudWatch 获得对 VM 更好的可观测性](https://youtu.be/1Ck_me4azMw) 
+  [使用 Amazon CloudWatch 获得对 VM 更好的可观测性 – AWS 在线技术讲座](https://youtu.be/1Ck_me4azMw) 

# OPS04-BP03 实施用户活动遥测
<a name="ops_telemetry_customer_telemetry"></a>

 构建应用程序代码，使其能够发出关于用户活动的信息，例如点击流或者开始、放弃和完成的事务。使用这些信息来帮助了解应用程序的使用方式和使用量模式，并确定需要在什么时候响应。 

 **常见反模式：** 
+  您的开发人员部署了无需用户遥测的新功能，并且利用率有所提高。您不能确定增加的利用率是由于新功能的使用，还是新代码导致的问题。 
+  您的开发人员部署了无需用户遥测的新功能。如果不联系客户并询问他们，您就无法判断客户是否正在使用新功能。 

 **建立此最佳实践的好处：** 了解客户如何通过您的应用程序来确定使用模式、意外行为，以及在必要时让您做出响应。 

 **未建立这种最佳实践的情况下暴露的风险等级：** 中 

## 实施指导
<a name="implementation-guidance"></a>
+  实施用户活动遥测：设计应用程序代码，使其能够发出关于用户活动的信息（例如点击流或者开始、放弃和完成的事务）。使用这些信息来帮助了解应用程序的使用方式和使用量模式，并确定需要在什么时候响应。 

# OPS04-BP04 实施依赖项遥测
<a name="ops_telemetry_dependency_telemetry"></a>

 设计和配置工作负载，使其能够提供关于其依赖的资源状态（例如可访问性或响应时间）的信息。外部依赖项的示例可以包括外部数据库、DNS 和网络连接。使用这些信息来确定需要在什么时候响应。 

 **常见反模式：** 
+  如果不手动执行检查，了解 DNS 提供程序是否正常运行，就难以确定无法访问应用程序是否是 DNS 的问题。 
+  您的购物车应用程序无法完成交易。如果不与信用卡处理提供商联系进行确认，就无法确定是否是他们的问题。 

 **建立此最佳实践的好处：** 了解依赖项的运行状况有助于您在必要时做出响应。 

 **未建立此最佳实践暴露的风险等级：** 中 

## 实施指导
<a name="implementation-guidance"></a>
+  实施依赖项遥测：设计和配置工作负载，使其能够发出关于其状态及其依赖的系统状态的信息。例如：外部数据库、DNS、网络连接以及外部信用卡处理服务。 
  +  [Amazon CloudWatch 代理与 AWS Systems Manager 集成 – 适用于 Linux 和 Windows 的统一指标和日志收集](https://aws.amazon.com/blogs/aws/new-amazon-cloudwatch-agent-with-aws-systems-manager-integration-unified-metrics-log-collection-for-linux-windows/) 
  +  [使用 CloudWatch 代理从 Amazon EC2 实例和本地服务器收集指标和日志](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html) 

## 资源
<a name="resources"></a>

 **相关文档：** 
+  [Amazon CloudWatch 代理与 AWS Systems Manager 集成 – 适用于 Linux 和 Windows 的统一指标和日志收集](https://aws.amazon.com/blogs/aws/new-amazon-cloudwatch-agent-with-aws-systems-manager-integration-unified-metrics-log-collection-for-linux-windows/) 
+  [使用 CloudWatch 代理从 Amazon EC2 实例和本地服务器收集指标和日志](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html) 

   **相关示例：** 
+  [Well-Architected 实验室 – 依赖项监控](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_dependency_monitoring/) 

# OPS04-BP05 实施事务跟踪
<a name="ops_telemetry_dist_trace"></a>

 实施应用程序代码并配置工作负载组件，提供关于工作负载之间的事务流的信息。使用这些信息来确定需要在什么时候做出响应，并帮助您确定导致问题的因素。 

 在 AWS 中，您可以使用分布式跟踪服务（例如 [AWS X-Ray](https://aws.amazon.com/xray/)）来收集和记录事务通过工作负载时的跟踪记录，生成地图以查看事务如何在工作负载和服务之间流动，深入了解组件之间的关系，并实时识别和分析问题。 

 **常见反模式：** 
+  您跨多个账户实施了无服务器微服务架构。您的客户遇到间歇性性能问题。您无法确定是哪项功能还是哪个组件的问题，因为您缺少跟踪信息，无法明确指出应用程序哪里出现了性能问题以及导致问题的原因。 
+  您尝试确定工作负载中的性能问题，以便在开发工作中解决它们。您无法查看应用程序组件以及与它们交互的服务之间的关系，难以确定问题出在哪里；这是因为您缺少跟踪信息，无法深入了解影响应用程序性能的具体服务和路径。 

 **建立此最佳实践的好处：** 了解跨工作负载的事务流可让您了解工作负载事务的预期行为及其在整个工作负载中的变化，使您能够在必要时做出响应。 

 **未建立这种最佳实践的情况下暴露的风险等级：** 低 

## 实施指导
<a name="implementation-guidance"></a>
+  实施事务跟踪：设计应用程序和工作负载，使其发出有关系统组件间的事务流的信息，例如事务阶段、活动组件以及完成活动的时间。使用这些信息来确定正在进行的活动、已完成的活动以及已完成活动的结果。这可以帮助您确定需要在什么时候响应。例如，组件内的事务响应时间长于预期，这可能表明该组件存在问题。 
  +  [AWS X-Ray](https://aws.amazon.com/xray/) 
  +  [什么是 AWS X-Ray？](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) 

## 资源
<a name="resources"></a>

 **相关文档：** 
+  [AWS X-Ray](https://aws.amazon.com/xray/) 
+  [什么是 AWS X-Ray？](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) 

# OPS 5  如何减少缺陷、简化修复和改进生产流程？
<a name="w2aac19b5b7b7"></a>

 支持在生产时调整改进流程并支持重构、快速质量反馈和错误修复方法。这些方法可以加快有益更改进入生产环境的速度、减少产生的问题，并能够快速识别和修复通过部署活动引入的问题。 

**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 使用版本控制
<a name="ops_dev_integ_version_control"></a>

 使用版本控制来跟踪更改和发布。 

 许多 AWS 服务都提供版本控制功能。使用修订或源代码控制系统（如 [AWS CodeCommit](https://aws.amazon.com/codecommit/) ）管理代码和其他构件，如基础设施的版本控制的 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 模板。 

 **常见反模式：** 
+  您一直在在工作站上开发和存储代码。工作站上发生了不可恢复的存储故障，您的代码丢失了。 
+  用更改内容覆盖现有代码后，您重新启动应用程序，但其无法运行。您无法恢复为更改内容。 
+  您对报告文件执行了写入锁定，而其他人需要对此文件进行编辑。他们与您联系要求您停止写入锁定，以便他们可以完成自己的任务。 
+  您的研究团队一直在进行详细的分析，以便对未来的工作进行规划。有人不小心把购物单保存在最终报告上了。您无法还原更改，不得不重新创建报告。 

 **建立此最佳实践的好处：** 借助版本控制功能，您可以轻松地恢复到已知的良好状态、以前的版本，并降低资产丢失的风险。 

 **未建立这种最佳实践的情况下暴露的风险等级：** 高 

## 实施指导
<a name="implementation-guidance"></a>
+  使用版本控制：在采用了版本控制的存储库中维护资产。这让您能够跟踪更改、部署新版本、检测对现有版本的更改，以及恢复到以前的版本（例如在发生故障时回滚到已知的良好状态）。将配置管理系统的版本控制功能集成到程序中。 
  +  [AWS CodeCommit 简介](https://youtu.be/46PRLMW8otg) 
  +  [什么是 AWS CodeCommit？](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) 

## 资源
<a name="resources"></a>

 **相关文档：** 
+  [什么是 AWS CodeCommit？](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html) 

 **相关视频：** 
+  [AWS CodeCommit 简介](https://youtu.be/46PRLMW8otg) 

# OPS05-BP02 测试并验证变更
<a name="ops_dev_integ_test_val_chg"></a>

 测试并验证变更以便发现并减少错误。实现自动测试以便减少手动过程引起的错误，并减少测试工作量。 

 许多 AWS 服务都提供版本控制功能。使用修订或源代码控制系统（如 [AWS CodeCommit](https://aws.amazon.com/codecommit/) ）管理代码和其他构件，如基础设施的版本控制的 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 模板。 

 **常见反模式：** 
+  在将新代码部署到生产环境后，由于应用程序无法再运行，客户开始打电话投诉。 
+  为了增强周边安全，您应用了新安全组。它运行以后产生了意想不到的后果，用户无法访问您的应用程序。 
+  您修改了新函数调用的方法。另一个依赖于该方法的函数也无法运行。没有检测到问题，开始投产。由于一段时间内没有调用另一个函数，最终导致生产失败，但是没有找到原因。 

 **建立此最佳实践的好处：** 在早期进行测试和验证更改，可以将解决问题的成本降至最低，并降低对客户的影响。经过测试之后再部署，可以最大限度地减少错误。 

 **未建立这种最佳实践的情况下暴露的风险等级：** 高 

## 实施指导
<a name="implementation-guidance"></a>
+  测试并验证变更：应该在所有生命周期阶段（例如开发、测试和生产阶段）测试更改并验证结果。使用测试结果来确认新功能，并减少部署失败的风险和影响。实现自动测试和验证，以便确保审核的一致性、减少手动过程引起的错误并减少工作量。 
  +  [什么是 AWS CodeBuild？](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) 
  +  [AWS CodeBuild 的本地构建支持](https://aws.amazon.com/blogs/devops/announcing-local-build-support-for-aws-codebuild/) 

## 资源
<a name="resources"></a>

 **相关文档：** 
+  [AWS 开发人员工具](https://aws.amazon.com/products/developer-tools/) 
+  [AWS CodeBuild 的本地构建支持](https://aws.amazon.com/blogs/devops/announcing-local-build-support-for-aws-codebuild/) 
+  [什么是 AWS CodeBuild？](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) 

# OPS05-BP03 使用配置管理系统
<a name="ops_dev_integ_conf_mgmt_sys"></a>

 使用配置管理系统来实现和跟踪配置更改。这些系统可以减少手动过程引起的错误，并减少部署更改的工作量。 

 静态配置管理在初始化资源时设置的值，这些值在资源的生命周期内预期保持一致。这样的例子包括为实例上的 Web 或应用程序服务器设置配置，或者定义 AWS 服务的配置（在 [AWS 管理控制台](https://docs.aws.amazon.com/awsconsolehelpdocs/index.html) 内或者通过 [AWS CLI](https://aws.amazon.com/cli/)）。 

 动态配置管理在初始化时设置值，这些值在资源的生命周期内可能或预期会发生变化。例如，您可以设置一个功能切换，通过配置更改在代码中启用功能，或者在意外事件期间更改日志详细级别以捕获更多数据，然后在意外事件完成后更改回来，避免再不必要的日志记录及其相关费用。 

 如果您在实例、容器、无服务器函数或设备上运行的应用程序具有动态配置，您可以使用 [AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html) 在您的环境中管理和部署它们。 

 在 AWS 上，您可以使用 [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) 跨账户和区域持续监控 AWS 资源 [配置](https://docs.aws.amazon.com/config/latest/developerguide/aggregate-data.html)。这使您可以跟踪其配置历史记录，了解配置更改可能如何影响其他资源，并使用 [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). 

 在 AWS 中，您可以使用像 [AWS 开发人员工具](https://aws.amazon.com/products/developer-tools/) （例如，AWS CodeCommit、 [AWS CodeBuild](https://aws.amazon.com/codebuild/)， [AWS CodePipeline](https://aws.amazon.com/codepipeline/)， [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)和 [AWS CodeStar](https://aws.amazon.com/codestar/)）这样的服务来构建持续集成/持续部署（CI/CD）管道。 

 当计划的重要业务、运营活动或事件受到更改实施的影响时，建立更改日历并进行跟踪。围绕这些计划来调整活动以管理风险。 [AWS Systems Manager 变更日历](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-change-calendar.html) 提供了一种机制，可以记录更改开始或结束的时间块及更改原因，并与 [其他](https://docs.aws.amazon.com/systems-manager/latest/userguide/change-calendar-share.html) AWS 账户分享该信息。AWS Systems Manager Automation 脚本可以配置为符合更改日历状态。 

 [AWS Systems Manager 维护时段](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html) 可用于安排在指定的时间执行 AWS SSM Run Command 或 Automation 脚本、AWS Lambda 调用或 AWS Step Functions 活动。在更改日历中标记这些活动，以便将其包含在您的评估中。 

 **常见反模式：** 
+  您手动更新整个队列中的 Web 服务器配置，由于更新错误，许多服务器变得没有响应。 
+  手动更新应用程序服务器队列需要花费很长时间。在变更过程中，如果配置不一致会导致意外行为发生。 
+  有人更新了您的安全组，您的 Web 服务器无法访问了。如果不知道发生了哪些变更，您需要花费大量时间来调查问题，导致恢复时间延长。 

 **建立此最佳实践的好处：** 采用配置管理系统可以减少更改及对其进行跟踪的工作量，还可以降低手动程序导致错误的频率。 

 **未建立这种最佳实践的情况下暴露的风险等级：** 中 

## 实施指导
<a name="implementation-guidance"></a>
+  使用配置管理系统：使用配置管理系统来跟踪并实施更改，以便减少手动过程引起的错误，并减少工作量。 
  +  [基础设施配置管理](https://aws.amazon.com/answers/configuration-management/aws-infrastructure-configuration-management/) 
  +  [AWS Config](https://aws.amazon.com/config/) 
  +  [什么是 AWS Config？](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) 
  +  [AWS CloudFormation 简介](https://youtu.be/Omppm_YUG2g) 
  +  [什么是 AWS CloudFormation？](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) 
  +  [AWS OpsWorks](https://aws.amazon.com/opsworks/) 
  +  [什么是 AWS OpsWorks？](https://docs.aws.amazon.com/opsworks/latest/userguide/welcome.html) 
  +  [AWS Elastic Beanstalk 简介](https://youtu.be/SrwxAScdyT0) 
  +  [什么是 AWS Elastic Beanstalk？](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html) 

## 资源
<a name="resources"></a>

 **相关文档：** 
+  [AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html) 
+  [AWS 开发人员工具](https://aws.amazon.com/products/developer-tools/) 
+  [AWS OpsWorks](https://aws.amazon.com/opsworks/) 
+  [AWS Systems Manager 变更日历](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/systems-manager-maintenance.html) 
+  [基础设施配置管理](https://aws.amazon.com/answers/configuration-management/aws-infrastructure-configuration-management/) 
+  [什么是 AWS CloudFormation？](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) 
+  [什么是 AWS Config？](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) 
+  [什么是 AWS Elastic Beanstalk？](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html) 
+  [什么是 AWS OpsWorks？](https://docs.aws.amazon.com/opsworks/latest/userguide/welcome.html) 

 **相关视频：** 
+  [AWS CloudFormation 简介](https://youtu.be/Omppm_YUG2g) 
+  [AWS Elastic Beanstalk 简介](https://youtu.be/SrwxAScdyT0) 

# OPS05-BP04 使用构建和部署管理系统
<a name="ops_dev_integ_build_mgmt_sys"></a>

 使用构建和部署管理系统。这些系统可以减少手动过程引起的错误，并减少部署更改的工作量。 

 在 AWS 中，您可以使用像 [AWS 开发人员工具](https://aws.amazon.com/products/developer-tools/) （例如，AWS CodeCommit、 [AWS CodeBuild](https://aws.amazon.com/codebuild/)， [AWS CodePipeline](https://aws.amazon.com/codepipeline/)， [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)和 [AWS CodeStar](https://aws.amazon.com/codestar/)）这样的服务来构建持续集成/持续部署（CI/CD）管道。 

 **常见反模式：** 
+  在开发系统上编译代码后，您将可执行文件复制到生产系统上，但它无法启动。本地日志文件显示这是因为缺少依赖项。 
+  您成功地在开发环境中构建了具有新功能的应用程序，并将代码送交质量检查（QA，Quality Assurance）。由于缺少静态资产，它没有通过质量检查。 
+  星期五，经过大量的努力，您成功地在开发环境中手动构建了应用程序，包括新编码的功能。星期一，您无法重复这一成功构建应用程序的步骤。 
+  您执行为新版本创建的测试。下周，您将设置测试环境，并执行所有现有的集成测试，然后执行性能测试。新代码产生了难以接受的性能影响，因此必须重新开发并测试。 

 **建立此最佳实践的好处：** 制定相应机制来管理活动的构建和部署。这样，您可以减少执行重复任务的工作量，让团队成员腾出时间专注于高价值的创造性任务，还可以减少手动程序导致的错误。 

 **未建立这种最佳实践的情况下暴露的风险等级：** 中 

## 实施指导
<a name="implementation-guidance"></a>
+  使用构建和部署管理系统：使用构建和部署管理系统来跟踪并实施更改，以便减少手动过程引起的错误，并减少工作量。将集成和部署管道完全自动化，从代码签入到构建、测试、部署和验证都包含在内。这可以减少准备时间、提高更改频率，并减少工作量。 
  +  [什么是 AWS CodeBuild？](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) 
  +  [面向软件开发的持续集成最佳实践](https://www.youtube.com/watch?v=GEPJ7Lo346A) 
  +  [Slalom：AWS 上面向无服务器应用程序的 CI/CD](https://www.youtube.com/watch?v=tEpx5VaW4WE) 
  +  [AWS CodeDeploy 简介 – 使用 Amazon Web Services 自动完成软件部署](https://www.youtube.com/watch?v=Wx-ain8UryM) 
  +  [什么是 AWS CodeDeploy？](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) 

## 资源
<a name="resources"></a>

 **相关文档：** 
+  [AWS 开发人员工具](https://aws.amazon.com/products/developer-tools/) 
+  [什么是 AWS CodeBuild？](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) 
+  [什么是 AWS CodeDeploy？](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) 

 **相关视频：** 
+  [面向软件开发的持续集成最佳实践](https://www.youtube.com/watch?v=GEPJ7Lo346A) 
+  [AWS CodeDeploy 简介 – 使用 Amazon Web Services 自动完成软件部署](https://www.youtube.com/watch?v=Wx-ain8UryM) 
+  [Slalom：AWS 上面向无服务器应用程序的 CI/CD](https://www.youtube.com/watch?v=tEpx5VaW4WE) 

# OPS05-BP05 执行补丁管理
<a name="ops_dev_integ_patch_mgmt"></a>

 执行补丁管理以便实现功能、解决问题并保持监管合规性。实现自动补丁管理以便减少手动过程引起的错误，并减少修补工作量。 

 补丁和漏洞管理是优势和风险管理活动的一部分。最好是具有不可变的基础设施和在已验证的已知良好状态下部署工作负载。如果该方法都不可行，那就只能进行修补。 

 更新系统映像、容器映像或 Lambda [自定义运行时和其他库](https://docs.aws.amazon.com/lambda/latest/dg/security-configuration.html) 以消除漏洞，是补丁管理的一部分。您应使用以下工具来 [管理适用于 Linux 或 Windows Server 映像的](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) Amazon 系统映像 (AMI) 的更新： [EC2 Image Builder](https://aws.amazon.com/image-builder/).您可以将 [Amazon Elastic Container Registry](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) 与现有管道配合使用以 [管理 Amazon ECS 映像](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_ECS.html) 和 [管理 Amazon EKS 映像](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_EKS.html)。AWS Lambda 包括 [版本](https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html) 管理功能。 

 在未事先在安全环境中测试的情况下，不应对生产系统执行修补操作。仅当补丁支持操作或业务结果时，才应该应用补丁。在 AWS 上，您可以使用 [AWS Systems Manager 补丁管理器](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) 和 [AWS Systems Manager 维护时段来自动执行修补托管系统的过程和安排修补活动](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html). 

 **常见反模式：** 
+  您接到任务，需要在两个小时内应用所有新的安全补丁，但由于应用程序与补丁不兼容，导致了多次停机。 
+  没有安装补丁的库会引发意外后果，这是因为未知方会利用其中的漏洞来访问您的工作负载。 
+  您在未通知开发人员的情况下自动修补开发人员环境。您收到来自开发人员的多起投诉，称他们的环境不能按预期运行。 
+  您尚未修补持久性实例上的现有商用软件。当您遇到软件问题并与供应商联系时，他们告知您已不再为该版本提供支持，您必须安装特定级别的补丁才能获得帮助。 
+  您使用的加密软件最近发布了新补丁，对性能进行了重大改进。您未安装补丁的系统仍然存在性能问题，恰恰是因为没有安装补丁造成的。 

 **建立此最佳实践的好处：** 您可以通过建立补丁管理流程（包括修补标准和在整个环境中分发的方法）来实现收益并控制影响。这样一来，可以采用所需功能、解决问题并保持监管合规性。实施补丁管理系统和自动化，以减少部署补丁的工作量，并减少手动过程引起的错误。 

 **未建立此最佳实践暴露的风险等级：** 中 

## 实施指导
<a name="implementation-guidance"></a>
+  补丁管理：修补系统以便纠正问题、获得所需的特性或功能、符合监管政策并满足供应商支持需求。在不可变系统中，使用适当的补丁集进行部署，以便实现所需结果。自动执行补丁管理机制以便缩短修补时间、减少手动过程引起的错误，并减少修补工作量。 
  +  [AWS Systems Manager 补丁管理器](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) 

## 资源
<a name="resources"></a>

 **相关文档：** 
+  [AWS 开发人员工具](https://aws.amazon.com/products/developer-tools/) 
+  [AWS Systems Manager 补丁管理器](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) 

 **相关视频：** 
+  [AWS 上面向无服务器应用程序的 CI/CD](https://www.youtube.com/watch?v=tEpx5VaW4WE) 
+  [Ops 设计理念](https://youtu.be/uh19jfW7hw4) 

   **相关示例：** 
+  [Well-Architected 实验室 – 清单和补丁管理](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_inventory_patch_management/) 

# OPS05-BP06 共享设计标准
<a name="ops_dev_integ_share_design_stds"></a>

 在不同团队间共享最佳实践，以便提高认识并最大程度地实现开发工作的效益。 

 在 AWS 上，您可以使用代码方法定义和管理应用程序、计算、基础设施和运营。这让您可以轻松地发布、分享和采用。 

 许多 AWS 服务和资源都可以设计为跨账户共享，从而使您能够跨团队分享所创建的资产和所学到的知识。例如，您可以与特定账户共享 [CodeCommit](https://docs.aws.amazon.com/codecommit/latest/userguide/cross-account.html) 存储库、 [Lambda](https://docs.aws.amazon.com/lambda/latest/dg/lambda-permissions.html) 函数、 [Amazon S3 存储桶](https://aws.amazon.com/premiumsupport/knowledge-center/cross-account-access-s3/)和 [AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html) 。 

 发布新资源或更新时，请使用 Amazon SNS 提供 [跨账户通知](https://docs.aws.amazon.com/lambda/latest/dg/with-sns-example.html).订阅者可以使用 Lambda 获取新版本。 

 如果在组织中强制实施了共享标准，则必须存在相应的机制来以请求增加、更改标准和标准例外，以为团队的活动提供支持。如果没有这样的机制，标准将成为创新的约束。 

 **常见反模式：** 
+  您创建了自己的用户身份验证机制，组织中的其他开发团队亦是如此。对于用户想要访问的系统的每一部分，他们都不得不使用一套单独的凭据。 
+  您创建了自己的用户身份验证机制，组织中的其他开发团队亦是如此。您的组织必须满足一项新的合规性要求。现在，每个开发团队都必须投入资源来实施新的要求。 
+  您创建了自己的屏幕布局，组织中的所有其他开发团队也各自创建了屏幕布局。用户抱怨界面不一致，难以导航。 

 **建立此最佳实践的好处：** 在标准满足多个应用程序或组织的要求的情况下，使用共享标准来支持最佳实践的采用并最大程度地实现开发工作的效益。 

 **未建立此最佳实践暴露的风险等级：** 中 

## 实施指导
<a name="implementation-guidance"></a>
+  共享设计标准：在不同团队间共享现有的最佳实践、设计标准、检查清单、操作程序、指南和监管要求，以便降低复杂性并充分发挥开发工作的作用。确保建立针对设计标准的更改、补充和例外请求程序，以便支持持续改进和创新。确保团队了解已发布的内容，从而让他们能够利用内容，并减少返工和浪费的工作。 
  +  [授权访问 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) 

## 资源
<a name="resources"></a>

 **相关文档：** 
+  [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) 

# OPS05-BP07 实施提高代码质量的实践
<a name="ops_dev_integ_code_quality"></a>

 实施能够提高代码质量并尽可能减少缺陷的最佳实践。一些示例包括测试驱动型开发、代码审查和标准采用。 

 在 AWS 上，您可以将 [Amazon CodeGuru](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) 等服务与管道集成，以 [使用计划分析和机器学习来](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/how-codeguru-reviewer-works.html) 识别潜在的代码和安全问题。CodeGuru 提供有关如何实施 AWS 最佳实践来解决这些问题的推荐。 

 **常见反模式：** 
+  为了能更快地测试您的功能，您决定不集成标准输入过滤库。测试完成之后，您提交代码时没有合并入库。 
+  对于正在处理的数据集，您经验不足，并不知道数据集中可能存在一系列边缘案例。这些边缘案例与您实施的代码不兼容。 

 **建立此最佳实践的好处：** 通过采用提高代码质量的实践，能够将引入生产中的问题降至最低。 

 **未建立这种最佳实践的情况下暴露的风险等级：** 中 

## 实施指导
<a name="implementation-guidance"></a>
+  实施提高代码质量的实践：实施提高代码质量的实践，以便尽可能减少缺陷并降低部署代码的风险。例如测试驱动型开发、结对编程、代码审查和标准采用。 
  +  [Amazon CodeGuru](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) 

## 资源
<a name="resources"></a>

 **相关文档：** 
+  [Amazon CodeGuru](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) 

# OPS05-BP08 使用多个环境
<a name="ops_dev_integ_multi_env"></a>

 使用多个环境来试验、开发和测试您的工作负载。当环境接近于生产环境时，逐步加强控制，以确保工作负载在部署后能够按预期运行。 

 **常见反模式：** 
+  您正在共享开发环境中执行开发，另一位开发人员将覆盖您的代码更改。 
+  共享开发环境上严苛的安全控制令您无法试验新的服务和功能。 
+  您在生产系统上执行负载测试，导致用户停机。 
+  生产中发生了严重错误，导致数据丢失。在生产环境中，您尝试重新创建导致数据丢失的条件，以便能够确定它是如何发生的，并防止它再次发生。为了防止在测试期间再次丢失数据，您被迫采取措施，让用户无法使用应用程序。 
+  您正在运行多租户服务，无法支持客户对专用环境的请求。 
+  您不可能每次都测试，但在生产环境中会执行测试。 
+  您认为单一环境的简单性比更改在环境中的影响范围更加重要。 

 **建立此最佳实践的好处：** 通过部署多个环境，可以让您为多个同时进行的开发、测试和生产环境提供支持，而不会在开发人员或用户社区间造成冲突。 

 **未建立此最佳实践暴露的风险等级：** 中 

## 实施指导
<a name="implementation-guidance"></a>
+  使用多个环境：为开发人员提供控制机制最少的沙盒环境，以便支持试验。提供单独的开发环境以便支持并行工作，并提高开发的灵活性。在接近生产的环境中实施更严格的控制，让开发人员能够创新。使用基础设施即代码和配置管理系统来部署与生产环境中的控制机制配置一致的环境，以便确保系统在部署后按照预期运行。关闭不使用的环境，以免空闲资源（例如晚上和周末的开发系统）产生费用。在负载测试时部署与生产等效的环境，以便实现有效结果。 
  +  [什么是 AWS CloudFormation？](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) 
  +  [如何使用 AWS Lambda 按固定间隔停止和启动 Amazon EC2 实例？](https://aws.amazon.com/premiumsupport/knowledge-center/start-stop-lambda-cloudwatch/) 

## 资源
<a name="resources"></a>

 **相关文档：** 
+  [如何使用 AWS Lambda 按固定间隔停止和启动 Amazon EC2 实例？](https://aws.amazon.com/premiumsupport/knowledge-center/start-stop-lambda-cloudwatch/) 
+  [什么是 AWS CloudFormation？](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) 

# OPS05-BP09 频繁进行可逆的小规模更改
<a name="ops_dev_integ_freq_sm_rev_chg"></a>

 频繁进行可逆的小规模变更可以减少变更的范围和影响。这可以简化故障排除、支持更快的修复，并提供回滚更改的选项。 

 **常见反模式：** 
+  您每季度都部署新版应用程序。 
+  您经常更改数据库架构。 
+  您执行手动就地更新，覆盖现有安装和配置。 

 **建立此最佳实践的好处：** 频繁部署小的更改可让您更快地发现开发工作带来的效益。更改很小时，更易于确定是否会带来意外后果。更改可逆时，由于简化了恢复，因此实施更改的风险更小。 

 **未建立此最佳实践暴露的风险等级：** 低 

## 实施指导
<a name="implementation-guidance"></a>
+  频繁进行可逆的小规模更改：频繁进行可逆的小规模更改可以减小更改的范围和影响。这可以简化故障排除、支持更快的修复，并提供回滚更改的选项。这还可以加快企业实现价值的速度。 

# OPS05-BP10 完全自动化集成和部署
<a name="ops_dev_integ_auto_integ_deploy"></a>

 实现自动构建、部署和测试工作负载。这可以减少手动过程引起的错误，并减少部署更改的工作量。 

 使用 [资源标签](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/) 应用元数据，以标识您的资源。标记您的资源，以便进行整理、成本核算、访问控制并有针对性地自动执行操作活动。 

 **常见反模式：** 
+  星期五，您完成为分支功能编写新代码的工作。星期一，在运行代码质量测试脚本和各单元测试脚本后，您将代码签入计划发行的下一版本中。 
+  您接到任务，需要为重要问题编写修复代码，该问题在生产中影响了大量客户。对修复代码进行测试后，您提交代码并通过电子邮件发送更改管理，请求批准以将其部署到生产环境中。 

 **建立此最佳实践的好处：** 通过自动构建和部署管理系统，可以减少由手动流程引发的错误，并减少部署更改的工作量，使您的团队成员能够专注于实现商业价值。 

 **未建立此最佳实践暴露的风险等级：** 低 

## 实施指导
<a name="implementation-guidance"></a>
+  使用构建和部署管理系统：使用构建和部署管理系统来跟踪并实施更改，以便减少手动过程引起的错误，并减少工作量。将集成和部署管道完全自动化，从代码签入到构建、测试、部署和验证都包含在内。这可以减少准备时间、提高更改频率，并减少工作量。 
  +  [什么是 AWS CodeBuild？](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) 
  +  [面向软件开发的持续集成最佳实践](https://www.youtube.com/watch?v=GEPJ7Lo346A) 
  +  [Slalom：AWS 上面向无服务器应用程序的 CI/CD](https://www.youtube.com/watch?v=tEpx5VaW4WE) 
  +  [AWS CodeDeploy 简介 – 使用 Amazon Web Services 自动完成软件部署](https://www.youtube.com/watch?v=Wx-ain8UryM) 
  +  [什么是 AWS CodeDeploy？](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) 

## 资源
<a name="resources"></a>

 **相关文档：** 
+  [什么是 AWS CodeBuild？](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) 
+  [什么是 AWS CodeDeploy？](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) 

 **相关视频：** 
+  [面向软件开发的持续集成最佳实践](https://www.youtube.com/watch?v=GEPJ7Lo346A) 
+  [AWS CodeDeploy 简介 – 使用 Amazon Web Services 自动完成软件部署](https://www.youtube.com/watch?v=Wx-ain8UryM) 
+  [Slalom：AWS 上面向无服务器应用程序的 CI/CD](https://www.youtube.com/watch?v=tEpx5VaW4WE) 

# OPS 6  您如何缓解部署风险？
<a name="w2aac19b5b7b9"></a>

 采用提供快速质量反馈，并且若更改没有达到目标成效，则支持快速恢复的方法。使用这些实践可以减轻因部署更改而产生的问题的影响。 

**Topics**
+ [OPS06-BP01 针对不成功的更改制定计划](ops_mit_deploy_risks_plan_for_unsucessful_changes.md)
+ [OPS05-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_test_limited_deploy.md)
+ [OPS06-BP05 使用并行环境进行部署](ops_mit_deploy_risks_deploy_to_parallel_env.md)
+ [OPS06-BP06 部署频繁、小规模、可逆的更改](ops_mit_deploy_risks_freq_sm_rev_chg.md)
+ [OPS06-BP07 完全自动化集成和部署](ops_mit_deploy_risks_auto_integ_deploy.md)
+ [OPS06-BP08 自动测试和回滚](ops_mit_deploy_risks_auto_testing_and_rollback.md)

# OPS06-BP01 针对不成功的更改制定计划
<a name="ops_mit_deploy_risks_plan_for_unsucessful_changes"></a>

 制定计划，以便在变更没有达到目标成效时在生产环境中恢复到已知良好状态，或者进行修复。做好充分的准备，以备快速响应，最大限度缩短回滚时间。 

 **常见反模式：** 
+  您执行部署以后应用程序变得不稳定，但是系统上似乎还有活动用户。您必须决定是回滚更改并影响活动用户，还是等到知道用户无论如何都可能受到影响后再回滚更改。 
+  更改路由后，可以访问新环境，但是其中一个子网无法访问。您必须决定是回滚所有内容还是尝试修复无法访问的子网。在您做决定时，子网仍然无法访问。 

 **建立此最佳实践的好处：** 实施计划来缩短不成功更改的平均修复时间（MTTR，Mean Time To Recover），减少对最终用户的影响。 

 **未建立这种最佳实践的情况下暴露的风险等级：** 高 

## 实施指导
<a name="implementation-guidance"></a>
+  针对不成功的更改制定计划：制定计划，以便在更改没有实现所需成果时在生产环境中恢复到已知良好状态（即回滚更改），或者进行修复（即前滚更改）。如果发现在失败后无法回滚的更改，请在提交更改之前做好准备。 

# OPS05-BP02 测试并验证变更
<a name="ops_mit_deploy_risks_test_val_chg"></a>

 在所有生命周期阶段测试更改并验证结果，以便确认新功能并尽可能减少部署失败的风险和影响。 

 在 AWS 上，您可以创建临时并行环境，以降低试验和测试的风险、工作量及成本。使用 [AWS CloudFormation](https://aws.amazon.com/cloudformation/) 自动部署这些环境，以确保以一致的方式实施您的临时环境。 

 **常见反模式：** 
+  您在应用程序中部署了一个很酷的新功能，它无法运行，而您却不知道。 
+  您更新了证书。您不小心将证书安装到了错误的组件上。而您却不知道。 

 **建立此最佳实践的好处：** 在部署后对更改进行测试和验证，您可以及早发现问题，从而有机会减轻对客户的影响。 

 **未建立这种最佳实践的情况下暴露的风险等级：** 高 

## 实施指导
<a name="implementation-guidance"></a>
+  测试并验证更改：在所有生命周期阶段（例如开发、测试和生产）测试更改并验证结果，以便确认新功能并尽可能减少部署失败的风险和影响。 
  +  [AWS Cloud9](https://aws.amazon.com/cloud9/) 
  +  [什么是 AWS Cloud9？](https://docs.aws.amazon.com/cloud9/latest/user-guide/welcome.html) 
  +  [如何在发送代码之前在本地测试和调试 AWS CodeDeploy](https://aws.amazon.com/blogs/devops/how-to-test-and-debug-aws-codedeploy-locally-before-you-ship-your-code/) 

## 资源
<a name="resources"></a>

 **相关文档：** 
+  [AWS Cloud9](https://aws.amazon.com/cloud9/) 
+  [AWS 开发人员工具](https://aws.amazon.com/products/developer-tools/) 
+  [如何在发送代码之前在本地测试和调试 AWS CodeDeploy](https://aws.amazon.com/blogs/devops/how-to-test-and-debug-aws-codedeploy-locally-before-you-ship-your-code/) 
+  [什么是 AWS Cloud9？](https://docs.aws.amazon.com/cloud9/latest/user-guide/welcome.html) 

# OPS06-BP03 使用部署管理系统
<a name="ops_mit_deploy_risks_deploy_mgmt_sys"></a>

 使用部署管理系统来跟踪并实施更改。这可以减少手动过程引起的错误，并减少部署更改的工作量。 

 在 AWS 中，您可以使用像 [AWS 开发人员工具](https://aws.amazon.com/products/developer-tools/) （例如，AWS CodeCommit、 [AWS CodeBuild](https://aws.amazon.com/codebuild/)， [AWS CodePipeline](https://aws.amazon.com/codepipeline/)， [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)和 [AWS CodeStar](https://aws.amazon.com/codestar/)）这样的服务来构建持续集成/持续部署（CI/CD）管道。 

 **常见反模式：** 
+  您手动将更新部署到整个队列中的应用程序服务器，由于更新错误，许多服务器变得没有响应。 
+  手动部署到应用程序服务器队列需要花费很长时间。在更改过程中，如果版本不一致会导致意外行为发生。 

 **建立此最佳实践的好处：** 采用部署管理系统可以减少部署更改的工作量，还可以降低手动程序导致错误的频率。 

 **未建立此最佳实践暴露的风险等级：** 中 

## 实施指导
<a name="implementation-guidance"></a>
+  使用部署管理系统：使用部署管理系统来跟踪并实施更改。这可以减少手动过程引起的错误，并减少部署更改的工作量。将集成和部署管道自动化，从代码签入到测试、部署和验证都包含在内。这可以减少准备时间、提高更改频率，并进一步减少工作量。 
  +  [AWS CodeDeploy 简介 – 使用 Amazon Web Services 自动完成软件部署](https://www.youtube.com/watch?v=Wx-ain8UryM) 
  +  [什么是 AWS CodeDeploy？](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) 
  +  [什么是 AWS Elastic Beanstalk？](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html) 
  +  [什么是 Amazon API Gateway？](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) 

## 资源
<a name="resources"></a>

 **相关文档：** 
+  [AWS CodeDeploy 用户指南](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) 
+  [AWS 开发人员工具](https://aws.amazon.com/products/developer-tools/) 
+  [在 AWS CodeDeploy 中尝试示例蓝绿部署](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html) 
+  [什么是 AWS CodeDeploy？](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) 
+  [什么是 AWS Elastic Beanstalk？](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html) 
+  [什么是 Amazon API Gateway？](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html) 

 **相关视频：** 
+  [使用 AWS 深入了解高级持续交付技术](https://www.youtube.com/watch?v=Lrrgd0Kemhw) 
+  [AWS CodeDeploy 简介 – 使用 Amazon Web Services 自动完成软件部署](https://www.youtube.com/watch?v=Wx-ain8UryM) 

# OPS06-BP04 使用有限部署进行测试
<a name="ops_mit_deploy_risks_test_limited_deploy"></a>

 与现有系统一起进行有限部署测试，以在全面部署前确认预期结果。例如使用 Canary 部署测试或一体化部署。 

 **常见反模式：** 
+  您一次性将不成功的更改部署到所有生产环境中。而您却不知道。 

 **建立此最佳实践的好处：** 通过在完成有限部署后对更改进行测试和验证，您可以及早发现问题，从而有机会进一步减轻对客户的影响，将对客户的影响降至最低。 

 **未建立这种最佳实践的情况下暴露的风险等级：** 中 

## 实施指导
<a name="implementation-guidance"></a>
+  使用有限部署进行测试：在全面部署之前使用有限的部署和现有系统进行测试，以确认实现所需成果。例如使用 Canary 部署测试或一体化部署。 
  +  [AWS CodeDeploy 用户指南](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) 
  +  [使用 AWS Elastic Beanstalk 进行蓝/绿部署](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html) 
  +  [设置 API Gateway 金丝雀发布部署](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html) 
  +  [在 AWS CodeDeploy 中尝试示例蓝绿部署](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html) 
  +  [在 AWS CodeDeploy 中使用部署配置](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html) 

## 资源
<a name="resources"></a>

 **相关文档：** 
+  [AWS CodeDeploy 用户指南](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) 
+  [使用 AWS Elastic Beanstalk 进行蓝/绿部署](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html) 
+  [设置 API Gateway 金丝雀发布部署](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html) 
+  [在 AWS CodeDeploy 中尝试示例蓝绿部署](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html) 
+  [在 AWS CodeDeploy 中使用部署配置](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html) 

# OPS06-BP05 使用并行环境进行部署
<a name="ops_mit_deploy_risks_deploy_to_parallel_env"></a>

 在并行环境中实施变更，然后过渡到新环境。保留之前的环境，直到确认部署成功为止。这样可以支持回滚到以前的环境，从而尽可能缩短恢复时间。 

 **常见反模式：** 
+  您通过修改现有系统来执行可变部署。发现更改不成功后，您被迫再次修改系统以还原旧版本，从而导致恢复时间延长。 
+  在维护时段内，您停用旧环境，然后开始构建新环境。在这一过程进行了许多时间后，您发现部署中出现了无法恢复的问题。虽然非常疲惫，您还是不得不找回以前的部署过程，并开始重新构建旧环境。 

 **建立此最佳实践的好处：** 使用并行环境后，您可以预先部署新环境并在需要时过渡到新环境。如果新环境不成功，则可以转换回原始环境，完成快速恢复。 

 **未建立这种最佳实践的情况下暴露的风险等级：** 中 

## 实施指导
<a name="implementation-guidance"></a>
+  使用并行环境进行部署：对并行环境实施更改，然后过渡或切换到新环境。保留之前的环境，直到确认部署成功为止。这样可以支持回滚到以前的环境，从而尽可能缩短恢复时间。例如在不可变基础设施中采用蓝/绿部署。 
  +  [在 AWS CodeDeploy 中使用部署配置](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html) 
  +  [使用 AWS Elastic Beanstalk 进行蓝/绿部署](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html) 
  +  [设置 API Gateway 金丝雀发布部署](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html) 
  +  [在 AWS CodeDeploy 中尝试示例蓝绿部署](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html) 

## 资源
<a name="resources"></a>

 **相关文档：** 
+  [AWS CodeDeploy 用户指南](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) 
+  [使用 AWS Elastic Beanstalk 进行蓝/绿部署](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html) 
+  [设置 API Gateway 金丝雀发布部署](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html) 
+  [在 AWS CodeDeploy 中尝试示例蓝绿部署](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html) 
+  [在 AWS CodeDeploy 中使用部署配置](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html) 

 **相关视频：** 
+  [使用 AWS 深入了解高级持续交付技术](https://www.youtube.com/watch?v=Lrrgd0Kemhw) 

# OPS06-BP06 部署频繁、小规模、可逆的更改
<a name="ops_mit_deploy_risks_freq_sm_rev_chg"></a>

 频繁进行可逆的小规模更改可以缩小变更的范围。这样可以简化故障排除工作、加快修复速度，并支持回滚更改。 

 **常见反模式：** 
+  您每季度都部署新版应用程序。 
+  您经常更改数据库架构。 
+  您执行手动就地更新，覆盖现有安装和配置。 

 **建立此最佳实践的好处：** 频繁部署小的更改可让您更快地发现开发工作带来的效益。更改很小时，更易于确定是否会带来意外后果。更改可逆时，由于简化了恢复，因此实施更改的风险更小。 

 **未建立此最佳实践暴露的风险等级：** 低 

## 实施指导
<a name="implementation-guidance"></a>
+  部署频繁、小规模、可逆的更改：频繁进行可逆的小规模更改可以缩小更改影响的范围。这样可以简化故障排除工作、加快修复速度，并支持回滚更改。 

# OPS06-BP07 完全自动化集成和部署
<a name="ops_mit_deploy_risks_auto_integ_deploy"></a>

 实现自动构建、部署和测试工作负载。这可以减少手动过程引起的错误，并减少部署更改的工作量。 

 使用 [资源标签](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/) 应用元数据，以标识您的资源。标记您的资源，以便进行整理、成本核算、访问控制并有针对性地自动执行操作活动。 

 **常见反模式：** 
+  星期五，您完成为分支功能编写新代码的工作。星期一，在运行代码质量测试脚本和各单元测试脚本后，您将代码签入计划发行的下一版本中。 
+  您接到任务，需要为重要问题编写修复代码，该问题在生产中影响了大量客户。对修复代码进行测试后，您提交代码并通过电子邮件发送更改管理，请求批准以将其部署到生产环境中。 

 **建立此最佳实践的好处：** 通过自动构建和部署管理系统，可以减少由手动流程引发的错误，并减少部署更改的工作量，使您的团队成员能够专注于实现商业价值。 

 **未建立这种最佳实践的情况下暴露的风险等级：** 低 

## 实施指导
<a name="implementation-guidance"></a>
+  使用构建和部署管理系统：使用构建和部署管理系统来跟踪并实施更改，以便减少手动过程引起的错误，并减少工作量。将集成和部署管道完全自动化，从代码签入到构建、测试、部署和验证都包含在内。这可以减少准备时间、提高更改频率，并减少工作量。 
  +  [什么是 AWS CodeBuild？](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) 
  +  [面向软件开发的持续集成最佳实践](https://www.youtube.com/watch?v=GEPJ7Lo346A) 
  +  [Slalom：AWS 上面向无服务器应用程序的 CI/CD](https://www.youtube.com/watch?v=tEpx5VaW4WE) 
  +  [AWS CodeDeploy 简介 – 使用 Amazon Web Services 自动完成软件部署](https://www.youtube.com/watch?v=Wx-ain8UryM) 
  +  [什么是 AWS CodeDeploy？](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) 
  +  [使用 AWS 深入了解高级持续交付技术](https://www.youtube.com/watch?v=Lrrgd0Kemhw) 

## 资源
<a name="resources"></a>

 **相关文档：** 
+  [在 AWS CodeDeploy 中尝试示例蓝绿部署](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html) 
+  [什么是 AWS CodeBuild？](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) 
+  [什么是 AWS CodeDeploy？](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) 

 **相关视频：** 
+  [面向软件开发的持续集成最佳实践](https://www.youtube.com/watch?v=GEPJ7Lo346A) 
+  [使用 AWS 深入了解高级持续交付技术](https://www.youtube.com/watch?v=Lrrgd0Kemhw) 
+  [AWS CodeDeploy 简介 – 使用 Amazon Web Services 自动完成软件部署](https://www.youtube.com/watch?v=Wx-ain8UryM) 
+  [Slalom：AWS 上面向无服务器应用程序的 CI/CD](https://www.youtube.com/watch?v=tEpx5VaW4WE) 

# OPS06-BP08 自动测试和回滚
<a name="ops_mit_deploy_risks_auto_testing_and_rollback"></a>

 自动测试部署的环境以便确认目标效果。在没有达到预期结果时，自动回滚到之前的已知良好状态，尽可能地缩短恢复时间，并减少手动过程引起的错误。 

 **常见反模式：** 
+  您为工作负载部署更改。您看到更改完成后，开始进行部署后测试。完成测试之后，您发现工作负载不可操作，而且客户断开了连接。然后，您开始回滚到之前的版本。经过较长时间检测，发现问题之后，通过手动重新部署会延长恢复时间。 

 **建立此最佳实践的好处：** 在部署之后对更改进行测试和验证，可以让您立即发现问题。自动回滚到以前的版本，可以将对客户的影响降至最低。 

 **未建立这种最佳实践的情况下暴露的风险等级：** 低 

## 实施指导
<a name="implementation-guidance"></a>
+  自动测试和回滚：自动测试部署的环境以确认达成所需效果。在没有达到预期结果时，自动回滚到之前的已知良好状态，尽可能地缩短恢复时间，并减少手动过程引起的错误。例如，在部署之后执行详细的综合用户事务、验证结果，并在失败时回滚。 
  +  [使用 AWS CodeDeploy 重新部署和回滚部署](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html) 

## 资源
<a name="resources"></a>

 **相关文档：** 
+  [使用 AWS CodeDeploy 重新部署和回滚部署](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html) 

# OPS 7 如何知道您已经准备好支持某种工作负载？
<a name="w2aac19b5b7c11"></a>

 评估工作负载、流程及程序和工作人员的操作准备就绪情况，以便了解与工作负载相关的操作风险。 

**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-BP01 确保员工能力
<a name="ops_ready_to_support_personnel_capability"></a>

 通过一种机制来验证您是否有适当数量技术娴熟的员工来提供对运营需求的支持。根据需要进行员工培训并调整人员产能，以便保持有效的支持。 

 您需要拥有足够的团队成员来完成所有活动（包括待命的团队成员）。确保您的团队拥有必要的技能，以便能够成功完成关于您的工作负载、运营工具和 AWS 的培训。 

 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 实验室](https://wellarchitectedlabs.com/)，这些资源提供了指导、示例和详细演练，用以培训您的团队。此外， [AWS 培训与认证](https://aws.amazon.com/training/) 提供了一些免费培训，可以通过自定进度的数字课程，学习 AWS 的基础知识。您还可以注册讲师指导培训，进一步帮助培养您团队的 AWS 技能。 

 **常见反模式：** 
+  在以下情况下部署工作负载：团队成员不能熟练使用平台和服务。 
+  在以下情况下部署工作负载：在预期的支持时间内没有团队成员可以提供支持。 
+  在以下情况下部署工作负载：如果有团队成员正在休假或生病，则没有足够的团队成员来提供支持。 
+  在以下情况下部署额外的工作负载：没有考虑团队成员为它和其他工作负载提供支持时的额外影响。 

 **建立此最佳实践的好处：** 拥有技能娴熟的团队成员能够为您的工作负载提供有效支持。 

 **未建立这种最佳实践的情况下暴露的风险等级：** 高 

## 实施指导
<a name="implementation-guidance"></a>
+  员工能力：确认是否有足够的训练有素的人员来有效地支持工作负载。 
  +  团队规模：确保您拥有足够的团队成员来执行运营活动，以及随时待命。 
  +  团队技能：确保您的团队成员接受了足够的 AWS、工作负载及运营工具的培训，以履行其职责。 
    +  [AWS 活动和网络研讨会](https://aws.amazon.com/about-aws/events/) 
    +  [欢迎参加 AWS 培训与认证](https://aws.amazon.com/training/) 
  +  了解能力：在操作环境和工作负载发生变化时查看团队规模和技能，以确保有足够的能力保持卓越运营。进行适当调整，以确保团队规模和技能与团队所支持的工作负载的操作要求相匹配。 

## 资源
<a name="resources"></a>

 **相关文档：** 
+  [AWS Blog](https://aws.amazon.com/blogs/) 
+  [AWS 活动和网络研讨会](https://aws.amazon.com/about-aws/events/) 
+  [AWS 入门资源中心](https://aws.amazon.com/getting-started/) 
+  [AWS 在线技术讲座](https://aws.amazon.com/getting-started/) 
+  [欢迎参加 AWS 培训与认证](https://aws.amazon.com/training/) 

 **相关示例：** 
+  [Well-Architected 实验室](https://wellarchitectedlabs.com/) 

# OPS07-BP02 确保以一致的方式对运维准备情况进行审查
<a name="ops_ready_to_support_const_orr"></a>

使用运维准备情况审查（ORR，Operational Readiness Review），确保可以运营您的工作负载。ORR 是 Amazon 开发的一种机制，用于验证团队可以安全地运营其工作负载。ORR 是一个使用要求核对清单进行审查和检查的过程。ORR 是一种自助服务体验，供团队用于验证其工作负载。ORR 中包含的最佳实践源自我们多年构建软件的经验教训。 

 ORR 核对清单包括架构推荐、运维过程、事件管理和发布质量。我们的更正错误（CoE，Correction of Error）流程是这些项目的主要推动因素。您的事后分析应该可以推动自己的 ORR 演进。ORR 并不仅仅关系到遵循最佳实践，还关系到预防以前的事件再次发生。最后，ORR 中还可以包括安全性、监管和合规性要求。

 在工作负载正式公开发布之前运行 ORR，然后在整个软件开发生命周期中运行 ORR。在发布之前运行 ORR 可以提升安全运营工作负载的能力。对工作负载定期重新运行 ORR 可以收集任何偏离最佳实践的情况。您可以准备用于新服务发布的 ORR 以及用于定期审查的 ORR。这可以帮助您遵循最新制定的最佳实践，并吸取从事后分析中学到的经验教训。随着您对云的使用日趋成熟，您可以将 ORR 要求作为默认设置整合到自己的架构中。

 **期望的结果：**  您已准备好 ORR 核对清单，其中包括适合您组织的最佳实践。在工作负载发布之前运行 ORR。在整个工作负载生命周期中定期运行 ORR。 

 **常见反模式：** 
+ 您启动了工作负载，但不知道谁负责其运维工作。
+ 在验证工作负载以便发布时，没有包括监管和安全性要求。
+ 没有定期重新评估工作负载。
+ 发布工作负载而没有准备好所需的规程。
+ 您在多个工作负载中看到相同的根本原因反复导致出现故障。

 **建立此最佳实践的好处：** 
+  您的工作负载包括架构、流程和管理最佳实践。 
+  学到的经验教训可合并到 ORR 流程中。 
+  在工作负载发布时已准备好所需的规程。 
+  在工作负载的整个软件生命周期中运行 ORR。 

 **未建立这种最佳实践的情况下的风险等级：** 高 

## 实施指导
<a name="implementation-guidance"></a>

 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 防护机制](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，请阅读 [运维准备情况审查（ORR）白皮书](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html)。其中详细介绍了 ORR 流程的历史，如何构建自己的 ORR 实践，以及如何制定自己的 ORR 核对清单。以下步骤是该文档的缩减版本。如需深入了解什么是 ORR 以及如何自行构建，建议您阅读该白皮书。 

1. 让关键利益相关方聚在一起讨论，包括来自安全、运维和开发部门的代表。

1. 让每个利益相关方至少提一个要求。对于第一次迭代，请尝试将项目数限制为不超过三十个。
   +  [附录 B：ORR 问题示例](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/appendix-b-example-orr-questions.html) 源自运维准备情况审查（ORR）白皮书，包含您在开始着手时可借鉴的示例问题。 

1. 在电子表格中收集您的要求。
   + 您可以使用 [自定义剖析](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html) （位于 [AWS Well-Architected Tool](https://console.aws.amazon.com/wellarchiected/) 中）开发自己的 ORR，并跨账户以及在 AWS Organization 中分享它们。

1. 确定一个工作负载来运行 ORR。最好选择发布前的工作负载或者内部工作负载。

1. 运行 ORR 核对清单并记录任何发现结果。如果已经有防范措施，那么发现结果可能就不太重要。对于任何没有防范措施的发现结果，请将它们记录到项目的待办事项中，并在发布之前实施它们。

1. 在一段时间后，继续在 ORR 中添加最佳实践和要求。

 具有 Enterprise Support 的 支持 客户可以向其技术客户经理请求举行 [运维准备情况审查研讨会](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/) 。该研讨会是一个交互式研讨会，采用 *反推式工作方法* ，可帮助您制定自己的 ORR 核对清单。

 **实施计划的工作量级别：** 高。在组织中采用 ORR 实践需要获得高管以及利益相关方的支持。使用整个组织中获得的反馈意见来构建和更新核对清单。 

## 资源
<a name="resources"></a>

 **相关最佳实践：** 
+ [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 – AWS Control Tower 中的防护机制](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html) 
+  [AWS Well-Architected Tool – 自定义剖析](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html) 
+  [Adrian Hornsby 提供的运维准备情况审查模板](https://medium.com/the-cloud-architect/operational-readiness-review-template-e23a4bfd8d79) 
+  [运维准备情况审查（ORR）白皮书](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) 

 **相关视频：** 
+  [AWS 支持 为您提供支持 \$1 构建高效的运维准备情况审查（ORR，Operational Readiness Review）](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 使用运行手册执行程序
<a name="ops_ready_to_support_use_runbooks"></a>

 A *运行手册* 是实现特定结果的书面流程。运行手册由某人为完成某件事而遵循的一系列步骤组成。早在航空发展的早期，运行手册便已用于运营。在云运营中，我们使用运行手册来降低风险并实现预期结果。简单而言，运行手册就是完成一项任务的核对清单。

 运行手册是运营工作负载的重要组成部分。从新团队成员入职到部署一个主要版本，运行手册都是一个成文的流程，无论谁使用它们，都能获得一致的结果。运行手册应发布在一个中央位置，并随着流程的发展而更新，因为更新运行手册是变更管理流程的一个关键组成部分。它们还应包括关于错误处理、工具、权限、异常和问题发生时上报的指导。 

 随着贵组织日益成熟，开始自动编写运行手册。从简短且经常使用的运行手册开始。使用脚本语言来实现步骤自动化或使步骤更容易执行。当您自动化前几本运行手册后，您将花时间自动化更复杂的运行手册。随着时间的推移，大多数运行手册应以某种方式实现自动化。 

 **期望结果：** 您的团队有一系列执行工作负载任务的分步指南。运行手册包含期望结果、必要的工具和权限，以及关于错误处理的说明。它们存储在一个中央位置并经常更新。 

 **常见反模式：** 
+  依靠记忆完成流程的每个步骤。 
+  手动部署更改而不使用核对清单。 
+  不同的团队成员执行相同的流程，但执行不同的步骤或取得不同的结果。 
+  让运行手册与系统更改和自动化不同步。 

 **建立此最佳实践的好处：** 
+  降低人工任务的错误率。 
+  以一致的方式执行操作。 
+  新的团队成员可以更早地开始执行任务。 
+  可以自动编写运行手册以减少工作量。 

 **未建立这种最佳实践的情况下暴露的风险等级：** 中 

## 实施指导
<a name="implementation-guidance"></a>

 根据贵组织的成熟度级别，运行手册可以采用多种形式。它们至少应该包含一个分步文本文档。应明确指出期望结果。清楚地记录必要的特殊权限或工具。提供关于错误处理和出现问题时进行上报的详细指导。列出运行手册负责人，并将运行手册发布在一个中央位置。一旦运行手册编写完成，让您团队中的其他人运行它来进行验证。随着过程的发展，根据变更管理流程更新运行手册。 

 随着贵组织日益成熟，您的文本运行手册应实现自动化。使用诸如 [AWS Systems Manager 自动化之类的服务](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)，您可以将纯文本转换为可针对您的工作负载运行的自动化功能。这些自动化功能可以根据事件的发生而运行，从而减轻维持工作负载的运营负担。

 **客户示例** 

 AnyCompany Retail 必须在软件部署期间执行数据库模式更新。云运营团队与数据库管理团队合作，构建了一个用于手动部署这些更改的运行手册。运行手册以核对清单的形式列出了流程中的每个步骤。其中有一节是关于出错时的错误处理。他们在内部 Wiki 上发布了该运行手册和其他运行手册。云运营团队计划在未来的冲刺阶段实现运行手册的自动化。 

## 实施步骤
<a name="implementation-steps"></a>

 如果您没有现有的文档存储库，那么版本控制存储库是开始构建运行手册库的绝佳场所。您可以使用 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 文档。填写 `Runbook Title` 以及 `Runbook Info 下的必填字段`。 

1.  从第一步开始，填写运行手册的 `Steps` 部分。 

1.  将运行手册交给团队成员。让他们使用运行手册来验证这些步骤。如果有遗漏或需要澄清的地方，请更新运行手册。 

1.  将运行手册发布到您的内部文档存储区。发布后，告诉您的团队和其他利益相关者。 

1.  随着时间的推移，您将构建一个运行手册库。随着该库的增长，开始努力实现运行手册的自动化。 

 **实施计划的工作量级别：** 低。运行手册的最低标准是一个分步文本指南。实现运行手册自动化可能会增加实施工作量。 

## 资源
<a name="resources"></a>

 **相关最佳实践：** 
+  [OPS02-BP02 确定流程和程序所有者](ops_ops_model_def_proc_owners.md)：运行手册应该有一个负责人负责维护。 
+  [OPS07-BP04 根据行动手册调查问题](ops_ready_to_support_use_playbooks.md)：运行手册和行动手册彼此相似，但有一个关键区别：运行手册包含期望结果。在许多情况下，一旦行动手册确定了根本原因，就会触发运行手册。 
+  [OPS10-BP01 使用流程来管理事件、意外事件和问题](ops_event_response_event_incident_problem_process.md)：运行手册是良好的事件、意外事件和问题管理实践的一部分。 
+  [OPS10-BP02 针对每个提醒设置一个流程](ops_event_response_process_per_alert.md)：应使用运行手册和行动手册来响应警报。随着时间的推移，应自动进行这些响应。 
+  [OPS11-BP04 执行知识管理](ops_evolve_ops_knowledge_management.md)：维护运行手册是知识管理的一个关键部分。 

 **相关文档：** 
+ [利用自动化行动手册和运行手册实现卓越运营](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) 
+ [适用于 AWS 大型迁移的迁移行动手册 - 任务 4：改进迁移运行手册](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-migration-playbook/task-four-migration-runbooks.html) 
+ [使用 AWS Systems Manager Automation 运行手册解决运营任务](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/) 

 **相关视频：** 
+  [AWS re:Invent 2019：运行手册、事件报告和事件响应 DIY 指南（SEC318-R1）](https://www.youtube.com/watch?v=E1NaYN_fJUo) 
+  [如何在 AWS \$1 Amazon Web Services 上实现 IT 运营自动化](https://www.youtube.com/watch?v=GuWj_mlyTug) 
+  [将脚本集成到 AWS Systems Manager](https://www.youtube.com/watch?v=Seh1RbnF-uE) 

 **相关示例：** 
+  [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)
+  [使用 Jupyter Notebook 和 CloudTrail Lake 构建 AWS 意外事件响应运行手册](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) 
+  [使用 Document Builder 创建自定义运行手册](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html) 
+  [Well-Architected 实验室：使用行动手册和运行手册自动完成操作](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/) 

 **相关服务：** 
+  [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 

# OPS07-BP04 根据行动手册调查问题
<a name="ops_ready_to_support_use_playbooks"></a>

 行动手册是用于调查事件的分步指南。发生事件时，行动手册用于开展调查，以及确定影响的范围和根本原因。行动手册可用于从失败的部署到安全事件的各种场景。在许多情况下，行动手册可确定根本原因，而运行手册可用来缓解其带来的风险。行动手册是贵组织事件响应计划的必要组成部分。 

 出色的行动手册有几个主要特点。它逐步指导用户完成事件发现过程。由外而内地思考，用户应执行哪些步骤来诊断事件？ 如果行动手册中需要特殊工具或提升的权限，请在行动手册中明确地定义。请制定沟通计划，以向利益相关者提供有关调查状态的最新信息，这是事件响应计划的一个重要组成部分。在无法确定根本原因的情况下，行动手册应制定上报计划。如果确定了根本原因，行动手册应指出介绍如何解决根本原因的运行手册。应集中存储并定期维护行动手册。如果行动手册用于特定提醒，请向团队提供关于提醒中的行动手册的提示。 

 随着组织日趋成熟，可自动实施行动手册。从包含低风险事件的行动手册开始实施。使用脚本自动执行发现步骤。确保有配套的运行手册来缓解常见根本原因带来的风险。 

 **期望的结果：** 您的组织有针对常见事件的行动手册。行动手册集中存储在一个位置，可供团队成员使用。行动手册经常进行更新。对于任何已知的根本原因，将制定配套的运行手册。 

 **常见反模式：** 
+  要调查事件，并没有标准方法。 
+  团队成员依靠肌肉记忆或对机构的了解，对失败的部署进行排查。 
+  新的团队成员将学习如何通过试错法来调查问题。 
+  调查问题的最佳实践无法在不同团队之间共享。 

 **建立此最佳实践的好处：** 
+  行动手册可帮助您减轻事件带来的影响。 
+  不同的团队成员可使用同一行动手册，以一致的方式确定根本原因。 
+  可以针对已知的根本原因制定运行手册，从而加快恢复速度。 
+  团队成员根据行动手册能够更快地开始行动。 
+  团队可以使用可重复的行动手册来扩展其流程。 

 **未建立这种最佳实践的情况下暴露的风险等级：** 中 

## 实施指导
<a name="implementation-guidance"></a>

 制定和使用行动手册的方式取决于组织的成熟度。如果您是初次使用云，请在中央文档存储库中以文本形式制定行动手册。随着组织日趋成熟，可以使用 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 重新联机。 

## 实施步骤
<a name="implementation-steps"></a>

 如果您当前没有文档存储库，建议您为行动手册库创建版本控制存储库。您可以使用 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 模板填写 `Playbook Name（行动手册名称）` 部分以及 `Playbook Info（行动手册信息）`下的字段。 

1.  填写问题排查步骤。尽可能清楚地知道要采取哪些行动，或者应调查哪些方面。 

1.  将行动手册提供给团队成员，让他们仔细阅读并加以验证。如果发现有遗漏之处或某些内容不清楚，请更新行动手册。 

1.  在文档存储库中发布您的行动手册，并告知您的团队和任何利益相关者。 

1.  随着您添加更多的行动手册，这个行动手册库将会不断扩大。在您拥有多个行动手册后，可以开始使用 AWS Systems Manager Automations 等工具自动执行它们，从而使自动化操作和行动手册保持同步。 

 **实施计划的工作量级别：** 低。行动手册应该是集中存储在一个位置的文本文档。对于更加成熟的组织，将转为自动实施行动手册。 

## 资源
<a name="resources"></a>

 **相关最佳实践：** 
+  [OPS02-BP02 确定流程和程序所有者](ops_ops_model_def_proc_owners.md)：行动手册应该有一个负责人来负责维护。 
+  [OPS07-BP03 使用运行手册执行程序](ops_ready_to_support_use_runbooks.md)：运行手册和行动手册类似，但有一个关键区别：运行手册包含期望的结果。在许多情况下，一旦行动手册确定了根本原因，就会使用运行手册。 
+  [OPS10-BP01 使用流程来管理事件、意外事件和问题](ops_event_response_event_incident_problem_process.md)：行动手册是良好的事件、意外事件和问题管理实践的一部分。 
+  [OPS10-BP02 针对每个提醒设置一个流程](ops_event_response_process_per_alert.md)：应使用运行手册和行动手册来响应警报。随着时间的推移，应自动进行这些响应。 
+  [OPS11-BP04 执行知识管理](ops_evolve_ops_knowledge_management.md)：维护行动手册是知识管理的一个关键部分。 

 **相关文档：** 
+ [ 利用自动化行动手册和运行手册实现卓越运营 ](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) 
+ [ 使用 AWS Systems Manager Automation 运行手册解决运营任务 ](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/)

 **相关视频：** 
+ [AWS re:Invent 2019：运行手册、事件报告和事件响应 DIY 指南（SEC318-R1） ](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [AWS Systems Manager Incident Manager – AWS 虚拟研讨会 ](https://www.youtube.com/watch?v=KNOc0DxuBSY)
+ [ 将脚本集成到 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)
+ [ 使用 Jupyter notebook 和 CloudTrail Lake 构建 AWS 事件响应运行手册 ](https://catalog.workshops.aws/workshops/a5801f0c-7bd6-4282-91ae-4dfeb926a035/en-US)
+ [ Rubix – 用于在 Jupyter notebook 中构建运行手册的 Python 库 ](https://github.com/Nurtch/rubix)
+ [ 使用 Document Builder 创建自定义运行手册 ](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html)
+ [ Well-Architected 实验室：根据行动手册和运行手册自动完成操作 ](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
+ [ Well-Architected 实验室：使用 Jupyter 的事件响应行动手册 ](https://www.wellarchitectedlabs.com/security/300_labs/300_incident_response_playbook_with_jupyter-aws_iam/)

 **相关服务：** 
+ [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 做出明智的决策来部署系统和更改
<a name="ops_ready_to_support_informed_deploy_decisions"></a>

 评估团队支持工作负载的能力以及工作负载的监管合规性。在决定是否将系统或更改投入生产环境时，将这些与部署的收益进行比较。了解收益和风险，以便做出明智的决策。 

 故障演练是一种演习，团队模拟发生故障的情况来制定防范策略。使用故障演练来预测故障，并根据需要创建程序。当您对用于评估工作负载的检查清单进行更改时，请计划要对不再符合条件的活动系统执行哪些操作。 

 **常见反模式：** 
+  决定在以下情况下部署工作负载：不了解工作负载中存在安全风险。 
+  决定在以下情况下部署工作负载：不了解它是否符合监管要求和标准。 
+  决定在以下情况下部署工作负载：不了解您的团队是否可以为它提供支持。 
+  决定在以下情况下部署工作负载：不了解组织会如何从中获益。 

 **建立此最佳实践的好处：** 拥有技能娴熟的团队成员能够为您的工作负载提供有效支持。 

 **未建立这种最佳实践的情况下暴露的风险等级：** 低 

## 实施指导
<a name="implementation-guidance"></a>
+  做出部署工作负载和更改的明智决策：评估团队支持工作负载的能力以及工作负载的监管合规性。在决定是否将系统或更改投入生产环境时，将这些与部署的收益进行比较。了解收益和风险，并做出明智的决策。 