3. 回滚策略总览：回滚的三种模式与选择决策树
在 IaC 变更失败后，选择正确的回滚策略是 Runbook 的核心决策点。错误的回滚方式可能导致更长的故障时间、数据不一致或资源残留。本章系统梳理三种回滚模式的定义、适用场景与风险，并给出可操作的决策树。
3.1 三种回滚模式对比
| 模式 | 核心动作 | 恢复时间 | 数据一致性 | 典型场景 |
|---|---|---|---|---|
| 完全回滚 | 将整个环境恢复到变更前的已知良好状态 | 中（依赖快照/备份大小） | 高（全量恢复） | 基础设施核心组件（VPC、K8s 集群）变更失败 |
| 部分回滚 | 仅撤销失败的资源或模块，保留其他变更 | 快（精准操作） | 中（需验证未回滚部分） | 多模块部署中单个模块异常 |
| 前滚修复 | 不撤销失败变更，直接部署修复版本 | 快（增量修复） | 高（向前推进） | 配置错误、依赖版本不兼容 |
关键指标： 完全回滚的 MTTR（平均恢复时间）通常比部分回滚高 2-3 倍，但数据一致性保障最强。前滚修复在 CI/CD 流水线中成功率最高，但要求团队具备快速修复能力。
3.2 模式详解与风险点
3.2.1 完全回滚
通过 Terraform terraform destroy + 历史状态恢复，或 CloudFormation 的 ChangeSet 回滚，将整个堆栈重置到上一个稳定版本。
- 优点： 确定性高，状态可预期；适合数据库 schema 变更、网络 ACL 重写等高风险操作。
- 风险： 如果变更期间有外部系统写入数据，完全回滚可能导致数据丢失；回滚期间服务完全不可用。
- Runbook 建议： 执行前必须确认数据备份完整性，并设置
prevent_destroy保护关键资源。
3.2.2 部分回滚
利用 IaC 工具的模块化能力，只回滚失败模块。例如 Terraform target 参数或 Pulumi 的 stack update --target。
- 优点： 恢复速度快，不影响其他正常模块；适合微服务架构中单个服务部署失败。
- 风险： 模块间依赖可能被破坏；需要额外验证未回滚模块的兼容性。
- Runbook 建议： 在 IaC 代码中显式声明模块依赖图，部分回滚后自动触发依赖检查。
3.2.3 前滚修复
不执行回滚，而是提交一个新的 IaC 变更来修复问题。例如修正 Terraform 变量值后重新 apply。
- 优点： 变更历史清晰，适合 CI/CD 自动化；避免回滚导致的二次中断。
- 风险： 如果失败原因是 IaC 代码逻辑错误（如循环依赖），前滚可能无法快速修复。
- Runbook 建议： 前滚修复必须配合自动化测试，确保修复版本通过所有验证关卡。
避坑提示： 部分回滚时，不要依赖 Terraform
target 进行生产环境操作——该参数会绕过依赖图，容易导致状态文件损坏。优先使用模块级别的 count 或 for_each 控制回滚范围。
3.3 回滚策略决策树
以下决策树帮助 Runbook 执行者在 30 秒内确定回滚模式。决策依据三个维度：变更范围、数据风险、修复时间。
3.4 决策树使用示例
实战案例： 某团队通过 Terraform 部署了 3 个微服务模块（A、B、C），其中模块 B 因变量配置错误导致 apply 失败。模块 B 与 A、C 无直接依赖（通过 API 通信）。决策树路径：非核心基础设施 → 无强依赖 → 修复时间预计 10 分钟 → 选择前滚修复。团队提交修复 PR 后重新 apply，5 分钟内恢复。
3.5 回滚模式选择清单
- 确认变更范围： 是否涉及网络、安全组、存储等核心资源？是 → 完全回滚。
- 检查模块依赖： 失败模块是否被其他模块引用（如数据源、输出变量）？是 → 完全回滚。
- 评估修复能力： 团队能否在 15 分钟内定位并修复 IaC 代码？是 → 前滚修复。
- 执行部分回滚： 仅当以上条件均不满足时，使用部分回滚，并立即执行依赖验证。
- 记录决策日志： 在 Runbook 中记录选择的模式、决策理由、执行时间，用于事后复盘。
自动化建议： 将决策树逻辑编码为 CI/CD 流水线中的条件判断。例如 GitLab CI 中通过
rules 关键字根据变更文件路径自动选择回滚模式，减少人工决策延迟。