回滚方案要写成可执行的东西
「如果出问题就回滚」不算方案。合格的回滚方案要回答四个问题：什么现象判定为失败、按什么步骤回滚、每步预计耗时多少、数据是否可回退。再配一份「已知问题清单」记录历史踩过的坑，实际救火时比通用流程有用得多。
基本信息
| 适用平台 | 全部平台，流程类条目 |
|---|---|
| 必备要素 | 触发条件、回滚步骤、数据影响、验证方式 |
| 写入位置 | 随变更单一起审批，不单独存放 |
| 基线 | 回滚方案可执行且经过演练 |
典型使用场景
- 批量补丁窗口：明确哪一批出问题就停在哪一批，回滚到哪一版
- 内核升级：确认旧内核仍在引导菜单里，保留可控的回退路径
- 数据库与中间件升级：评估是否涉及不可逆的数据格式变更
- 事后复盘：用回滚记录说明处置时间线，形成团队经验
回滚方案要素
回滚方案要素
# 触发条件：什么现象判为失败（要可观测，例如连续 5 分钟错误率超阈值）
# 回滚步骤：命令级步骤 + 每步预计耗时 + 执行人
# 数据影响：是否涉及不可逆变更（数据库结构、存储格式）
# 验证方式：回滚后如何确认业务恢复
# 确认旧内核仍在，必要时可回退引导
rpm -q --last kernel | head -3要素读法
| 要素 | 合格写法 | 常见缺陷 |
|---|---|---|
| 触发条件 | 可观测指标加时间窗口 | 写「异常就回滚」，判断全靠感觉 |
| 回滚步骤 | 命令级步骤并标注耗时 | 只写「恢复备份」，没说怎么恢复 |
| 数据影响 | 明确是否可逆 | 忽略数据结构变更，回滚后数据不可用 |
| 验证方式 | 业务侧加技术侧双确认 | 只 ping 通就算恢复 |
维护一份「已知问题清单」（例如某补丁与某软件冲突、某版本需要额外配置）并每月更新，值班同事的实际救火效率取决于它，而不是通用流程文档。
回滚方案必须演练过：未演练的方案在真实故障中往往缺步骤、耗时长；部分回滚（只回滚应用不回滚数据）比不回滚更危险。