# OPS06-BP01 针对不成功的更改制定计划
制定计划，以便在部署没有达到期望结果时，在生产环境中恢复到已知良好状态，或者进行修复。制定一项策略来建立这样的计划，有助于所有团队制定从失败的更改中恢复的策略。这样的示例策略包括部署和回滚步骤、更改策略、功能标记、流量隔离和流量转移。单个发布版本可能包括多个相关的组件更改。该策略应提供承受任何组件更改的失败或从中恢复过来的能力。
**期望结果：**已为更改失败准备了详细的恢复计划。此外，还缩小了发布内容的大小，以便最大限度地减少对其他工作负载组件的潜在影响。因此，通过缩短更改失败可能造成的停机时间，提高恢复时间的灵活性和效率，减少了对业务的影响。
**常见反模式：**
+ 执行部署后，应用程序变得不稳定，但是系统上似乎还有活动用户。您必须决定是回滚更改并影响活动用户，还是等到知道用户无论如何都可能受到影响后再回滚更改。
+ 执行例行更改后，可以访问新环境，但是无法访问其中一个子网。必须决定是回滚所有内容还是尝试修复无法访问的子网。做决定时，子网仍然无法访问。
+ 系统的架构不允许使用较小的发布版本进行更新。因此，在部署失败时，很难撤销这些大批量的更改。
+ 没有使用基础设施即代码（IaC）模式，而且对基础设施进行的手动更新导致了不希望出现的配置。无法有效地跟踪和撤销手动更改。
+ 由于没有将部署频率的增加作为衡量标准，因此团队没有动力来缩小更改规模，也不愿意改进每次更改的回滚计划，从而导致风险增加和失败率上升。
+ 没有衡量因更改失败而导致的中断的总持续时间。团队无法确定部署流程的优先顺序和恢复计划的有效性，也无法进行改进。
**建立此最佳实践的好处：**制定从失败更改中恢复的计划可以最大限度地缩短平均恢复时间（MTTR），并减少对业务的影响。
**在未建立这种最佳实践的情况下暴露的风险等级：**高
## 实施指导
发布团队采用的一致、有据可查的策略和实践，让组织能够计划在更改失败时应如何处理。该策略应允许在特定情况下向前修复。无论是哪种情况，在部署到实际生产环境之前，都应妥善记录并测试向前修复或回滚计划，以便最大限度地减少从更改中恢复所需的时间。
### 实施步骤
1. 记录策略，该策略要求团队制定有效计划以便在指定时间内撤销更改。
1. 策略应指定何时允许出现向前修复的情况。
1. 要求所有相关人员都能查阅记录在案的回滚计划。
1. 指定回滚要求（例如，当发现部署了未经授权的更改时）。
1. 分析与工作负载每个组件相关的所有更改的影响级别。
1. 如果可重复的更改遵循的工作流程，与执行更改策略的工作流程保持一致，则允许对这些更改进行标准化、模板化和预授权。
1. 通过缩小更改的规模来减少任何更改的潜在影响，从而减少恢复所需的时间和对业务的影响。
1. 确保回滚程序将代码恢复到已知的良好状态，尽可能避免意外事件。
1. 集成工具和工作流程，以编程方式执行策略。
1. 让其他工作负载所有者能够查看有关更改的数据，以便提高对无法回滚的任何失败更改的诊断速度。
1. 利用可见的更改数据来衡量这一做法是否成功，并确定迭代改进措施。
1. 使用监控工具来验证部署的成败，从而加快制定回滚决策的速度。
1. 衡量更改失败时的停机时间，以便不断改进恢复计划。
**实施计划的工作量级别：**中
## 资源
**相关最佳实践：**
+ [OPS06-BP04 自动测试和回滚](ops_mit_deploy_risks_auto_testing_and_rollback.md)
**相关文档：**
+ [AWS Builders Library \$1 确保部署期间安全回滚](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments/)
+ [AWS 白皮书 \$1 Change Management in the Cloud ](https://docs.aws.amazon.com/whitepapers/latest/change-management-in-the-cloud/change-management-in-the-cloud.html)
**相关视频：**
+ [re:Invent 2019 \$1 Amazon’s approach to high-availability deployment](https://aws.amazon.com/builders-library/amazon-approach-to-high-availability-deployment/)