

# OPS 7. 如何知道您已经准备好支持某种工作负载？
<a name="ops-07"></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-BP06 为生产工作负载创建支持计划
](ops_ready_to_support_enable_support_plans.md)

# OPS07-BP01 确保员工能力
<a name="ops_ready_to_support_personnel_capability"></a>

制定一种机制来验证是否有适当数量训练有素的员工来支持工作负载。必须针对构成工作负载的平台和服务对他们进行培训。为他们提供运营工作负载所需的知识。必须有足够训练有素的员工来支持工作负载的正常运营和排查发生的意外事件。拥有足够数量的员工，以便在值班和休假期间轮换，避免出现倦怠。

 **期望结果：**
+  在工作负载可用时，有足够训练有素的员工为工作负载提供支持。
+  针对构成工作负载的软件和服务，对员工进行培训。

 **常见反模式：**
+ 部署工作负载，但没有对团队成员进行培训来运营所使用的平台和服务。
+  员工数量不足，无法支持轮流值班或休假。

 **建立此最佳实践的好处：**
+  拥有技能娴熟的团队成员能够为工作负载提供有效支持。
+  有足够的团队成员，可以支持工作负载和实现轮流值班，同时降低出现倦怠的风险。

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

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

 确认是否有足够的训练有素的员工来支持工作负载。确认是否有足够的团队成员来执行正常运营活动，包括轮流值班。

 **客户示例** 

 AnyCompany Retail 确保支持工作负载的团队配备了适当的人员，并经过培训。他们有足够的工程师支持轮流值班。他们针对构建工作负载的软件和平台对员工进行培训，并鼓励他们获得认证。他们有足够的员工，所以员工可以休假，同时仍然可以支持工作负载和轮流值班。

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

1.  分配足够数量的人员来运营和支持工作负载，包括随叫随到的职责、安全问题和生命周期事件，如终止支持和证书轮换任务。

1.  针对构成工作负载的软件和平台方面对员工进行培训。

   1.  [AWS 培训和认证](https://aws.amazon.com/training/)有一个关于 AWS 的课程库。这里提供线上和线下的免费和付费课程。

   1.  [AWS 举办活动和网络研讨会](https://aws.amazon.com/events/)，可以从中向 AWS 专家学习。

1. 定期执行以下操作：
   +  随着运营条件和工作负载发生变化，评估团队规模和技能。
   +  调整团队规模和技能来满足运营要求。
   +  验证通过 AWS Health 来[解决计划内生命周期事件](https://docs.aws.amazon.com/health/latest/ug/aws-health-planned-lifecycle-events.html)、计划外安全性和运营通知的能力。

 **实施计划的工作量级别：**高。雇用和培训团队来支持工作负载需要付出巨大的努力，但可带来可观的长期效益。

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

 **相关最佳实践：**
+  [OPS11-BP04 执行知识管理](ops_evolve_ops_knowledge_management.md) – 团队成员必须具备运营和支持工作负载所需的信息。知识管理是提供这些信息的关键。

 **相关文档：**
+  [AWS 活动和网络研讨会](https://aws.amazon.com/events/) 
+  [AWS 培训和认证](https://aws.amazon.com/training/) 

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

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

 ORR 核对清单包括架构推荐、运营流程、事件管理和发布质量。我们的错误更正（CoE）流程是这些项目的主要推动因素。意外事件后分析应该可以推动自己的 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 Guardrails](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html) 等服务将源自 ORR 的最佳实践构建到防护机制中，以便自动检测最佳实践。

 **客户示例** 

 在经历了多起生产意外事件之后，AnyCompany Retail 决定实施 ORR 流程。他们构建了核对清单，其中包括最佳实践、治理要求和合规性要求，以及从中断中学到的经验教训。他们在发布新工作负载之前执行 ORR。每个工作负载会每年执行一次 ORR，其中包括一小组最佳实践，用于整合添加到 ORR 核对清单中的新最佳实践和要求。随着时间的推移，AnyCompany Retail 使用 [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) 来检测某些最佳实践，加快了 ORR 流程。

 **实施步骤** 

 有关 ORR 的更多信息，请阅读《[Operational Readiness Reviews（ORR）白皮书](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html)》。其中详细介绍了 ORR 流程的历史、如何构建自己的 ORR 实践，以及如何制定自己的 ORR 核对清单。以下步骤是该文档的缩减版本。如需深入了解什么是 ORR 以及如何自行构建，建议阅读该白皮书。

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

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

1. 在电子表格中收集要求。
   + 您可以使用 [AWS Well-Architected Tool](https://console.aws.amazon.com/wellarchiected/) 中的[自定义剖析](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html)来开发 ORR，并在账户和 AWS 组织中共享这些剖析。

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

1. 运行 ORR 核对清单并记录任何发现结果。如果采取了缓解措施，发现结果可能是可接受的。对于任何没有防范措施的发现结果，请将它们记录到项目的积压工作项中，并在发布之前处理它们。

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

 使用 Enterprise Support 的 支持 客户可以向其技术客户经理申请[运营准备情况审查讲习会](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/)。该讲习会是一个交互式*逆向工作*会议，旨在制定自己的 ORR 核对清单。

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

## 资源
<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 - Guardrails in AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html) 
+  [AWS Well-Architected Tool - Custom Lenses](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html) 
+  [Operational Readiness Review Template by Adrian Hornsby](https://medium.com/the-cloud-architect/operational-readiness-review-template-e23a4bfd8d79) 
+  [Operational Readiness Reviews（ORR）白皮书](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html) 

 **相关视频：**
+  [AWS 支持s You \$1 Building an Effective Operational Readiness Review (ORR)](https://www.youtube.com/watch?v=Keo6zWMQqS8) 

 **相关示例：**
+  [运营准备情况审查（ORR）剖析示例](https://github.com/aws-samples/custom-lens-wa-sample/tree/main/ORR-Lens) 

 **相关服务：**
+  [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) 
+  [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) 
+  [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) 
+  [AWS Well-Architected Tool](https://docs.aws.amazon.com/wellarchitected/latest/userguide/intro.html) 

# OPS07-BP03 使用运行手册执行程序
<a name="ops_ready_to_support_use_runbooks"></a>

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

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

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

 **期望结果：**团队有一系列执行工作负载任务的分步指南。运行手册包含期望结果、必要的工具和权限，以及关于错误处理的说明。运行手册存储在一个中央位置（版本控制系统）并经常更新。例如，在应用程序发出警报、出现操作问题和计划内生命周期事件期间，运行手册可为团队提供监控、沟通和响应关键账户 AWS Health 事件的功能。

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

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

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

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

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

 随着组织日益成熟，文本运行手册应实现自动化。使用 [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) 等服务，可以将纯文本转换为可以根据工作负载运行的自动化代码。这些自动化代码可以根据发生的事件运行，从而减轻维持工作负载的运营负担。AWSSystems Manager Automation 还提供了低代码[视觉对象设计体验](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-visual-designer.html)，可以更轻松地创建自动化运行手册。

 **客户示例** 

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

### 实施步骤
<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 文档。填写运行手册书名以及“运行手册信息”下的必填字段。

1.  从第一步开始，填写运行手册的“步骤”部分。

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

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

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

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

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

 **相关最佳实践：**
+  [OPS02-BP02 确定流程和程序负责人](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_proc_owners.html) 
+  [OPS07-BP04 根据行动手册调查问题](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_playbooks.html) 
+  [OPS10-BP01 使用流程来管理事件、意外事件和问题](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_event_incident_problem_process.html) 
+  [OPS10-BP02 针对每个警报设置一个流程](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_process_per_alert.html) 
+  [OPS11-BP04 执行知识管理](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html) 

 **相关文档：**
+  [Achieving Operational Excellence using automated playbook and runbook](https://aws.amazon.com/blogs/mt/achieving-operational-excellence-using-automated-playbook-and-runbook/) 
+  [AWS Systems Manager：使用运行手册](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html) 
+  [Migration playbook for AWS large migrations - Task 4: Improving your migration runbooks](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-migration-playbook/task-four-migration-runbooks.html) 
+  [Use AWS Systems Manager Automation runbooks to resolve operational tasks](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/) 

 **相关视频：**
+  [AWS re:Invent 2019: DIY guide to runbooks, incident reports, and incident response](https://www.youtube.com/watch?v=E1NaYN_fJUo) 
+  [How to automate IT Operations on AWS \$1 Amazon Web Services](https://www.youtube.com/watch?v=GuWj_mlyTug) 
+  [Integrate Scripts into AWS Systems Manager](https://www.youtube.com/watch?v=Seh1RbnF-uE) 

 **相关示例：**
+  [Well-Architected Lab：使用行动手册和运行手册实现运营自动化](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/) 
+  [AWS Blog 文章：Build a Cloud Automation Practice for Operational Excellence: Best Practices from AWS Managed Services](https://aws.amazon.com/blogs/mt/build-a-cloud-automation-practice-for-operational-excellence-best-practices-from-aws-managed-services/) 
+  [AWS Systems Manager：自动化演练](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html) 
+  [AWS Systems Manager：从最新的快照运行手册中还原根卷](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-document-sample-restore.html) 
+  [Building an AWS incident response runbook using Jupyter notebooks and CloudTrail Lake](https://catalog.us-east-1.prod.workshops.aws/workshops/a5801f0c-7bd6-4282-91ae-4dfeb926a035/en-US) 
+  [Gitlab – 运行手册](https://gitlab.com/gitlab-com/runbooks) 
+  [Rubix – 用于在 Jupyter Notebook 中构建运行手册的 Python 库](https://github.com/Nurtch/rubix) 
+  [使用文档生成器创建自定义运行手册](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html) 

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

# OPS07-BP04 根据行动手册调查问题
<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 模板，填写“行动手册书名”部分，并填写“行动手册信息”下的字段。

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

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

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

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

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

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

 **相关最佳实践：**
+  [OPS02-BP02 确定流程和程序负责人](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_proc_owners.html) 
+  [OPS07-BP03 使用运行手册执行程序](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_runbooks.html) 
+  [OPS10-BP01 使用流程来管理事件、意外事件和问题](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_event_incident_problem_process.html) 
+  [OPS10-BP02 针对每个警报设置一个流程](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_process_per_alert.html) 
+  [OPS11-BP04 执行知识管理](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html) 

 **相关文档：**
+  [Achieving Operational Excellence using automated playbook and runbook](https://aws.amazon.com/blogs/mt/achieving-operational-excellence-using-automated-playbook-and-runbook/) 
+  [AWS Systems Manager：使用运行手册](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html) 
+  [Use AWS Systems Manager Automation runbooks to resolve operational tasks](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/) 

 **相关视频：**
+  [AWS re:Invent 2019: DIY guide to runbooks, incident reports, and incident response (SEC318-R1)](https://www.youtube.com/watch?v=E1NaYN_fJUo) 
+  [AWS Systems Manager Incident Manager - AWS 虚拟讲习会](https://www.youtube.com/watch?v=KNOc0DxuBSY) 
+  [Integrate Scripts into AWS Systems Manager](https://www.youtube.com/watch?v=Seh1RbnF-uE) 

 **相关示例：**
+  [AWS 客户行动手册框架](https://github.com/aws-samples/aws-customer-playbook-framework) 
+  [AWS Systems Manager：自动化演练](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html) 
+  [Building an AWS incident response runbook using Jupyter notebooks and CloudTrail Lake](https://catalog.workshops.aws/workshops/a5801f0c-7bd6-4282-91ae-4dfeb926a035/en-US) 
+  [Rubix – 用于在 Jupyter Notebook 中构建运行手册的 Python 库](https://github.com/Nurtch/rubix) 
+  [使用文档生成器创建自定义运行手册](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html) 

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

# OPS07-BP05 作出明智的决策来部署系统和变更
<a name="ops_ready_to_support_informed_deploy_decisions"></a>

为工作负载的成功和不成功变更制定恰当的流程。故障演练是一种演习，团队模拟发生故障的情况来制定缓解策略。使用故障演练来预测故障，并在适当的时候创建程序。评估将变更部署到工作负载所获得益处和产生的风险。确认所有变更符合治理要求。

 **期望结果：**
+  将变更部署到工作负载时作出明智的决策。
+  变更符合治理要求。

 **常见反模式：**
+ 将变更部署到工作负载，而没有处理失败部署的流程。
+ 对生产环境作出不符合治理要求的变更。
+ 部署新版本的工作负载，而不为资源利用建立基准。

 **建立此最佳实践的好处：**
+  为工作负载的不成功变更做好了准备。
+  工作负载的变更符合治理政策。

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

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

 使用故障演练制定不成功变更的流程。记录不成功变更的流程。确保所有变更均符合治理要求。评估将变更部署到工作负载所获得益处和产生的风险。

 **客户示例** 

 AnyCompany Retail 定期执行故障演练来验证不成功变更的流程。他们在共享的 Wiki 中记录流程并经常更新。所有变更均符合治理要求。

 **实施步骤** 

1.  将变更部署到工作负载时作出明智的决策。确立并审查成功部署的条件。制定将启动变更回滚的方案或条件。在部署变更带来的好处与不成功变更产生的风险之间进行权衡。

1.  确认所有变更均符合治理政策。

1.  使用故障演练为不成功的变更制定计划，并记录缓解策略。运行桌面演练，为不成功的变更建模，并验证回滚程序。

 **实施计划的工作量级别：**中。实施故障演练的实践需要整个组织内的利益相关方进行协调和付出努力 

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

 **相关最佳实践：**
+  [OPS01-BP03 评估治理要求](ops_priorities_governance_reqs.md) – 治理要求是确定是否部署变更的关键因素。
+  [OPS06-BP01 针对不成功的更改制定计划](ops_mit_deploy_risks_plan_for_unsucessful_changes.md) – 制定计划来缓解失败的部署，并使用故障演练来进行验证。
+  [OPS06-BP02 测试部署](ops_mit_deploy_risks_test_val_chg.md) – 在部署之前应适当地测试每项软件变更，以便减少生产中的缺陷。
+  [OPS07-BP01 确保员工能力](ops_ready_to_support_personnel_capability.md) – 有足够训练有素的人员来支持工作负载，这对于作出部署系统变更的明智决策很重要。

 **相关文档：**
+ [亚马逊云科技：风险与合规性](https://docs.aws.amazon.com/whitepapers/latest/aws-risk-and-compliance/welcome.html)
+ [AWS 责任共担模式](https://aws.amazon.com/compliance/shared-responsibility-model/)
+ [Governance in the AWS 云: The Right Balance Between Agility and Safety](https://aws.amazon.com/blogs/apn/governance-in-the-aws-cloud-the-right-balance-between-agility-and-safety/)

# OPS07-BP06 为生产工作负载创建支持计划
<a name="ops_ready_to_support_enable_support_plans"></a>

 为生产工作负载所依赖的所有软件和服务启用支持。选择适当的支持级别来满足生产服务水平需求。以防出现服务中断或软件问题，这些依赖项的支持计划必不可少。记录支持计划以及如何向所有服务和软件供应商请求支持。实施机制，以便确认主要支持联系人的信息保持最新。

 **期望结果：**
+  为生产工作负载所依赖的软件和服务实施支持计划。
+  根据服务水平需求选择适当的支持计划。
+  记录支持计划、支持级别以及如何请求支持。

 **常见反模式：**
+  没有制定面向关键软件供应商的支持计划。工作负载受到影响，无法采取任何措施来加快修复或从供应商获得及时更新。
+  作为软件供应商主要联系人的开发人员离开了公司。您无法直接联系供应商支持人员。您必须花时间研究和浏览通用联系系统，延长在需要时作出反应所需的时间。
+  软件供应商发生生产中断。没有关于如何提出支持案例的文档。

 **建立此最佳实践的好处：**
+  通过适当的支持级别，可以在满足服务水平需求所需的时间范围内获得响应。
+  作为受支持的客户，如果存在生产问题，您可以上报。
+  发生意外事件时，软件和服务供应商可协助排除故障。

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

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

 为生产工作负载所依赖的所有软件和服务供应商启用支持计划。设置适当的支持计划来满足服务水平需求。对于 AWS 客户，这意味着要在具有生产工作负载的任何账户上激活 AWS Business Support 或更高级别的支持。定期与支持供应商会面，获取有关支持产品、流程和联系人的更新。记录如何向软件和服务供应商请求支持，包括在出现中断时如何上报。实施机制，让支持联系人的信息保持最新。

 **客户示例** 

 在 AnyCompany Retail，所有商用软件和服务依赖项均有支持计划。例如，他们在具有生产工作负载的所有账户上都激活了 AWS Enterprise Support。如果出现问题，任何开发人员都可以提出支持案例。有一个 Wiki 页面，其中包含有关如何请求支持、向谁发出通知以及加快处理案例最佳实践的信息。

 **实施步骤** 

1.  与组织内的利益相关方合作确定工作负载所依赖的软件和服务供应商。记录这些依赖项。

1.  确定工作负载的服务水平需求。选择与需求匹配的支持计划。

1.  对于商用软件和服务，与供应商一起制定支持计划。

   1.  为所有生产账户订阅 AWS Business Support 或更高级别的支持，可以让 AWS 支持 更快响应，强烈建议订阅此支持。如果没有高级支持，则必须制定行动计划来处理问题，而这需要 AWS 支持 的帮助。AWS 支持 提供工具和技术的组合、人员和计划，旨在主动协助您优化性能、降低成本和加快创新速度。此外，AWS Business Support 还提供其它优势，包括 API 对 AWS Trusted Advisor 和 AWS Health 的访问权限以便与系统进行编程集成，以及其它访问方法，例如 AWS 管理控制台和 Amazon EventBridge 渠道。

1.  在知识管理工具中记录支持计划。包括如何请求支持、在提出支持案例时向谁发出通知以及在发生意外事件时如何上报。Wiki 是一种很好的机制，让任何人都可以在发现支持流程或联系人的更改时对文档进行必要的更新。

 **实施计划的工作量级别：**低。大部分软件和服务供应商都提供选择加入的支持计划。在知识管理系统中记录和分享支持最佳实践，可以确认团队是否知道在出现生产问题时该怎么做。

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

 **相关最佳实践：**
+  [OPS02-BP02 确定流程和程序负责人](ops_ops_model_def_proc_owners.md) 

 **相关文档：**
+ [AWS 支持 Plans](https://docs.aws.amazon.com/awssupport/latest/user/aws-support-plans.html)

 **相关服务：**
+ [AWS Business Support](https://aws.amazon.com/premiumsupport/plans/business/)
+ [AWS Enterprise Support](https://aws.amazon.com/premiumsupport/plans/enterprise/)