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