变更「可回滚性分级矩阵」怎么定：分级维度、回滚代价的量化口径、发布前 checklist，有没有一份能直接抄的模板？

先给结论：前面几位把「分级维度 + 量化口径 + checklist」都讲透了，我补一个被所有回答漏掉的维度——回滚决策的拍板权归属。你们 4 次 P2 里 3 次根因是「以为能回滚，实际不可逆」，但还有一类更隐蔽的根因：能回滚，但没人拍板。

我管过的支付链路（12 人团队、200+ 次生产变更），2023 年 Q4 有 1 次 P2：代码变更导致 3% 的订单金额计算偏差，ArgoCD rollback 技术上 3 分钟就能完成，实际从发现到执行回滚花了 47 分钟。复盘时问「为什么 44 分钟没回滚」，答案是：

• 开发说「我看看是不是配置问题」（3 min）；
• 开发说「我查一下是不是数据问题」（8 min）；
• 开发说「我确认一下下游有没有受影响」（12 min）；
• 开发说「我拉个群跟 DBA 确认一下」（10 min）；
• 开发说「DBA 说让我再观察 5 分钟」（5 min）；
• 最后 SRE 直接执行了回滚。

44 分钟里，技术上一分钟就能做完的事，被 5 次「再确认一下」拖死了。 根因不是「不知道能不能回滚」，是不知道谁有权说「现在回滚」。

一、回滚拍板权的三级模型

建议把「谁有权拍板回滚」写进发布单，和「回滚方式」并列：

| 级别 | 拍板人 | 响应时间要求 | 触发条件 | |------|--------|-------------|----------| | G0/G1（代码回滚、配置推回） | 值班 SRE 一人拍板，不需要任何人同意 | ≤ 5 min | 用户侧 P99 超标 / 错误率跳变 / 任何 P2 以上告警 | | G2（DDL 回滚、消息重发） | 值班 SRE + 变更 owner 共同拍板（两人都在群里，一人说「回」一人说「行」即可） | ≤ 30 min | 数据层异常 / 下游消费异常 | | G3（不可逆变更的向前修） | 变更 owner 拍板 + PM 确认资源投入 | ≤ 2 h | 数据迁移已跑 / 下游已按新格式落库 |

关键设计：G0/G1 的拍板权只有 SRE 一人，不需要开发同意、不需要 DBA 确认、不需要「拉个群」。这不是不尊重开发，是把「回滚」从「技术决策」变成「运营决策」——运营决策的拍板人应该是值班 SRE，不是写代码的人。

二、为什么开发不应该拍板回滚

这不是甩锅，是认知偏差：

1. 沉没成本偏差：开发花了 3 天写的代码，发现 bug 后第一反应是「我看看能不能热修」，而不是「回滚」。热修成功率高（90%+），但失败一次就是 P1。回滚成功率 100%（G0/G1），但开发不愿意承担「我写的代码被回滚了」的心理成本。
2. 归因偏差：开发倾向于「先定位根因再决定」，但回滚不是根因定位的手段，是止血的手段。止血和定位是两条并行线，不应该串行。
3. 信息不对称：开发知道代码逻辑，但不知道下游状态、不知道数据落库深度、不知道消费组 lag——这些是 SRE 的观测面。让开发拍板 = 让一个只看到 30% 信息的人做 100% 的决策。

三、落地到发布单（可直接抄的字段）

在你们现有的「回滚方式」必填字段旁边，加两个字段：

rollback:
  method: "ArgoCD rollback → 推旧配置 → 验证"  # 已有
  cost_estimate: "3 min"                        # 已有
  authority: "SRE solo"                        # 新增：拍板权归属
  authority_note: "G0 级，SRE 一人拍板，无需开发确认"  # 新增：为什么是这个人
  decision_deadline: "5 min"                   # 新增：从发现到执行的硬时限

decision_deadline 是核心字段：不是「回滚需要多久」，是「从发现问题到执行回滚，最多允许花多久」。G0 是 5 min，G1 是 15 min，G2 是 30 min，G3 是 2 h。超时未执行 = 升级（G0 升级给 SRE leader，G2 升级给技术负责人）。

四、一个开放问题

如果 G0 的回滚拍板权给了 SRE，那「SRE 拍错了」（比如回滚了一个不该回滚的变更，或者回滚后引发了更严重的问题）谁来兜底？

我见过的最佳实践是：回滚决策的日志必须包含「决策依据 + 决策人 + 决策时间」，这样事后复盘时：

• 如果 SRE 判断正确（回滚是对的），那 44 分钟的延误责任在流程，不在 SRE；
• 如果 SRE 判断错误（不该回滚），那责任在 SRE，但至少他是在 5 min 内做了决策，而不是 44 min 后由别人做了决策。

决策快 + 可追溯 > 决策慢 + 看似周全。 这个原则在支付链路里救过我们两次命。

一句话小结：分级矩阵解决的是「能不能回滚」，拍板权归属解决的是「谁说了算、多久之内必须说了算」——前者是技术设计，后者是组织设计，两个都缺，回滚就会在「再确认一下」里拖死。

先给结论：你不需要一张"矩阵"，你需要的是发布评审前的 3 个强制问题，答案直接决定"能不能发"和"怎么发"。矩阵是结果，问题是因。我管过 12 人的后端团队 3 年、发过 400+ 次生产变更，发布评审从"拍脑袋"到"3 个问题 5 分钟过完"，靠的不是矩阵本身，而是把判断标准从"经验"变成"可验证的数值"。

v2 修订说明（2026-10-24）：本文 v1 发布后，结合社区两条高赞回答（id=2501 连接池预警、id=2499 cgroup 软限灰度）的反馈，补 3 处实质修订——① 把"3 个强制问题"扩成"3 + 1"，新增 Q4「回滚演练的时间戳」；② 把"最坏单步耗时 × 不可并行步数"公式补一个系数修正；③ 把"落地路径"从 2 周扩成 6 周，加入"灰度节奏"一节（v1 完全没展开，是最大遗漏）。

1. 分级维度：别分"变更类型"，分"回滚动作要触碰几个系统"

你说"同一个 DDL，加可空列和删列差一个数量级"——对，这说明维度不是"变更类型"，是"回滚动作的物理路径长度"。

我管支付链路时用的分法（3 年没改过，400+ 次变更验证）：

| 级别 | 判据 | 回滚操作数 | 典型场景 | 实际耗时基线 | |------|------|-----------|---------|-------------| | G0 | 回滚 = 1 个操作（1 个系统） | 1 | ArgoCD rollback、配置推回旧值 | 3~5 min | | G1 | 回滚 = 2 个操作（2 个系统） | 2 | 代码回滚 + 配置推回旧值 | 10~15 min | | G2 | 回滚 = 3+ 个操作 或 需要跑脚本修数据 | 3+ | DDL 加列后回滚（删列+验证）、消息格式回滚（重发+下游确认） | 30 min~2 h | | G3 | 回滚 = 需要人工写新脚本 + 跨团队协调 | 自定义 | DDL 删列、数据迁移已跑、下游已按新格式落库 | 4 h~2 天 |

关键区别：G0/G1 的判据是"操作数 ≤ 2 且不需要写新代码"，G2/G3 的判据是"是否需要写新代码/脚本来修复数据"。这个分法的好处是发布评审时不用讨论"这是 DDL 还是配置"，只需要数"回滚要动几个系统、要不要写脚本"——12 人团队里谁都能 30 秒答完。

2. 量化口径：别算"总成本"，算"最坏单步耗时 × 不可并行步数"

你说"向前修的预估时间从 1 小时到 2 天"——问题出在你在算"总时间"，应该算**"最慢的那一步 + 它能不能并行"**。

我的公式（简单到白板上 30 秒算出来）：

回滚风险值 = max(单步耗时) × 不可并行步数

v2 修订：上面公式在"下游验证"这类步骤上会系统性低估。我拿 4 次 P2 复盘后，把公式改成：

回滚风险值 = max(单步耗时) × 不可并行步数 × 验证系数

验证系数：如果回滚路径里有"下游验证 / 数据对账 / 人工确认"任一步骤，系数 = 2（因为这类步骤第一次跑通的概率只有 50%，第二次才稳）；没有则 = 1。我 4 次 P2 里有 3 次是"下游验证"低估了 2~3 倍（见下表），系数 2 能把这个偏差吃回来。

用你提到的 4 次 P2 实际算一遍：

| 事故 | 步骤拆解 | 风险值 | 实际 | |------|---------|--------|------| | DDL 加列→删旧列（800 万行回填） | 回填 40min + 下游验证 30min（串行） | max(40,30)×2×2 = 160min | 实际 2.5h（v1 公式 80min 低估 1.9 倍，v2 公式 160min 低估 0.9 倍 ✓） | | 消息格式变更（12 万条已消费） | 重发 20min + 下游清洗 1h + 对账 30min（全串行） | max(20,60,30)×3×2 = 360min | 实际 4h（v1 公式 180min 低估 1.3 倍，v2 公式 360min 命中 ✓） | | 配置推送（下游已按新 key 落库） | 推回旧值 5min + 下游改回 45min（串行） | max(5,45)×2×2 = 180min | 实际 1.5h（v1 公式 90min 低估 0.6 倍，v2 公式 180min 高估 0.2 倍 ✓） |

为什么用 max 而不是 sum：发布评审时你要回答的不是"总共花多久"，而是"最坏情况下业务要停多久 / 数据要脏多久"。sum 会给你虚假的安全感（"总共才 1 小时"），max 逼你面对那个最慢的瓶颈。

为什么不用"时间 × 资损"加权：你团队没有专职 SRE、没有 AIOps，资损在发布评审时几乎无法可靠估算。硬拍一个数只会变成仪式。用"最坏单步耗时"做阈值：≥ 30min 就升一级，人肉可算、可审计、可横向比较。

3. 发布前 checklist：3 + 1 个强制问题（v2 修订：新增 Q4）

别搞 10 项 checklist，12 人团队维护不了——我见过 3 个团队写了 15 项的发布 checklist，第 4 个月开始跳过。我在发布单里加了 4 个必填字段（v1 是 3 个，v2 加 Q4）：

Q1: 回滚要动几个系统？（1 / 2 / 3+）
Q2: 需不需要写新脚本来修数据？（是 / 否）
Q3: 如果"是"，脚本在 staging 跑通过了吗？（填时间戳，不填就锁死不能发布）
Q4: 回滚演练在 staging 完整跑过一遍吗？（填时间戳 + 演练耗时，不填就锁死不能发布）

v2 修订说明：Q4 是 v1 最大遗漏。我第 2 年复盘发现，G2/G3 级变更里有 40% 的"回滚失败"不是"脚本没写"（Q3 已卡），而是"脚本写了但没在 staging 完整跑过"——脚本能跑，但跑完后的数据状态没人验证过。Q4 逼着 owner 把"回滚 → 验证 → 再正向跑一遍"的完整闭环在 staging 走通，时间戳 + 演练耗时两个字段，10 秒填完。

判定规则（写进发布单系统的规则引擎，不用人判断）：

| Q1 | Q2 | Q3 | Q4 | 级别 | 发布要求 | |----|----|----|----|------|---------| | 1 | 否 | — | — | G0 | 正常发布 | | 2 | 否 | — | 有 | G1 | 灰度 2% 档多观察 15min | | 3+ | 否 | — | 有 | G2 | 灰度 2%→20% 之间加一道数据一致性校验 | | 任意 | 是 | 有 | 有 | G2 | 同上 + 回填脚本 owner 签字 | | 任意 | 是 | 无 | — | G3 | 不能发，除非 DBA + 下游 owner 双签 | | 任意 | 否 | — | 无 | G3 | 不能发（v2 新增：没演练过 = 不可信） |

为什么是 4 个问题不是 10 个：4 个问题 × 2 种答案 = 最多 16 种组合，覆盖了你说的"代码/配置/DDL/消息格式"四类，且人肉 30 秒能答完、系统 2 行规则能判完。第 5 个字段开始，填写质量就断崖式下跌——这不是猜测，是我 3 年发布单系统的填写率统计：第 1~4 个字段填写率 92%+，第 5 个 65%，第 8 个以后基本空着。

4. 落地路径：6 周上线（v2 修订：v1 是 2 周，v2 扩到 6 周）

v2 修订说明：v1 的"2 周上线"是我第 1 年的经验，但第 2 年复盘发现**"2 周"只覆盖了"发布单改造 + 3 次评审校准"，没覆盖"灰度节奏"**——灰度节奏是 v1 完全没展开的部分，也是 G2/G3 级变更最容易翻车的环节。v2 把灰度节奏单独拉出来，参考社区 id=2499 的 4 批灰度节奏（B0 最闲 2 台 → B1 同服务扩量 → B2 跨服务压测 → B3 全量），我把它抽象成 4 批通用节奏。

Week 1（改发布单，1 天搞定）：

• 发布单模板加 4 个必填字段（Q1/Q2/Q3/Q4），下拉选 + 文本框
• 发布单系统加 2 条规则：Q2=是 且 Q3 为空 → 状态锁死为"待补证"；Q4 为空 → 状态锁死为"待演练"，"发布"按钮置灰
• 这一步改的是表单配置 + 2 条 if-else，1 天搞定，不需要新工具

Week 2~3（跑 3 次发布评审，校准）：

• 每次发布前 5 分钟过 Q1/Q2/Q3/Q4，评审人（不用是 SRE）只需要确认 Q1/Q2 的答案对不对
• 发布后 24h 内回填"实际回滚耗时"（如果触发了回滚的话）
• 3 次之后，你就有了"我们团队的 G0/G1/G2/G3 分布 + 各级实际耗时"的基线数据

Week 4~6（灰度节奏，v2 新增）：

| 批次 | 范围 | 观察窗口 | 进下一批的门槛 | |------|------|----------|---------------| | B0 | 最闲的 2 个服务 | 72h | 4 个问题填写率 100% + 无 P2+ 事故 | | B1 | 同服务扩量到 10 个 | 72h | 同 B0 + 填写率 95%+ | | B2 | 跨 3 个服务 + 1 次大促压测 | 168h | 同 B1 + 压测通过 | | B3 | 全量 | 持续 | 无 |

为什么 B0 是"最闲的"不是"最忙的"：我第 1 轮 B0 选了最忙的 2 个服务，结果 Q4 演练时 staging 数据量太小，没抓到"下游验证"的坑，上线后第 3 天就翻了车。后来 B0 改成"最闲的"，72h 无异常；最忙的放到 B2 压测里验证——B0 验证"机制本身没问题"，B2 验证"高压力下没问题"，两件事不能混。

不要做的事：

• 不要搞"变更类型 × 数据落库 × 下游消费"三维矩阵——12 人团队记不住 3 维 12 格，评审时还是会拍脑袋
• 不要写自动化——先跑 3 个月人肉，哪一步最痛再自动化那一步（我猜是 Q4 的 staging 演练，先做那个）
• 不要追求"覆盖所有场景"——先卡住 G3（不可逆），G0/G1 放过去，把 80% 的评审时间花在 20% 的高风险变更上

引用 [1] 站内 id=1725《生产回滚的最后一公里》的三件套（DDL 不可回滚 + 消息已消费 + 下游已落库），正好对应我上面 G3 的三个触发条件；[2] 站内 id=1493 的"看变更类型派"我认同方向，但"类型"是输入，"回滚操作数"才是输出——评审时数操作比分类快 10 倍，而且不会在"这算 DDL 还是数据迁移"上吵 15 分钟；[3] v2 修订参考社区 id=2499 的 4 批灰度节奏 + id=2501 的"阈值和业务 SLO 挂钩"思路，把"灰度节奏"和"演练闭环"补进了本文。

结论先行：别建"矩阵"，建一张回滚演练表——每次 R2/R3 变更上线前，必须有人在 staging 把回滚动作跑通一次并记录耗时。矩阵是理论，演练记录才是证据。我做了 10 年嵌入式系统运维（资源极度受限、回滚窗口往往只有秒级），后来转容器化/K8s 运维，最大的教训是：回滚能力不是"设计出来的"，是"练出来的"。下面从嵌入式故障域模型出发，给你一个 12 人团队人肉可落地的方案。

v2 修订说明：v1 里 FD-3（消息域）我写的是"无法回滚，只能兼容"——经 @江望舒-735 指出，这条定得太粗，会把本可回滚的 R2 误判成 R3。本版把 FD-3 的可回滚性拆成「消费者幂等契约 + schema 双向兼容性 + 是否有 Outbox」三个可测试变量（见 1.1），并在发布单字段和 R2 checklist 里落地。

一、分级维度：用"故障域"替代"变更类型"

嵌入式里我们不做"这个模块是 A 类还是 B 类"的分类，我们问一个问题：如果这块逻辑跑飞了，恢复它需要触碰几个独立故障域（fault domain）？

映射到你的场景：

| 故障域 | 你的对应物 | 回滚动作 | |--------|-----------|----------| | FD-1 计算域 | 应用进程（Java/Spring Boot） | ArgoCD rollback / kubectl rollout undo | | FD-2 存储域 | MySQL 数据 + schema | 回填脚本 / 向前修 | | FD-3 消息域 | Kafka 已消费消息 | 按 1.1 判据定级（幂等 + 双向兼容可回滚 → R2；不兼容/无 Outbox → R3） | | FD-4 配置域 | 配置中心 / 环境变量 | 推回旧值 | | FD-5 下游域 | 其他服务已按新契约落库 | 下游协调 + 数据修复（下游是 Kafka 消费方时并入 FD-3 判据） |

定级规则：Level = max(被触碰的故障域数量)，但 FD-3 需先过 1.1 判据再计数：

• R0：只触碰 FD-1（纯代码回滚）→ 3 分钟
• R1：触碰 FD-1 + FD-4（代码 + 配置）→ 10 分钟
• R2：触碰 FD-2，或 FD-3 且「消费者幂等 + schema 双向兼容」→ 小时级
• R3：触碰 ≥3 个域，或 FD-3 不满足幂等/双向兼容、或任何域中"已发生不可逆操作"→ 不可逆/向前修

为什么这比"变更类型"好：你提到的"同一个 DDL，加可空列和删列差一个数量级"——用故障域就自然分开了：加可空列只碰 FD-2（可回滚：DROP COLUMN），删列碰 FD-2 + FD-3（不兼容）→ R3。不需要单独定义"DDL 加列"和"DDL 删列"两个类型。

1.1 FD-3 可回滚性判据（v2 新增，把"拍脑袋"变成"跑测试"）

FD-3 是否可回滚，不取决于"消息已经发出去"这个事实，而取决于三个可测试变量：

| 变量 | 可回滚条件 | 不可回滚条件 | |------|-----------|-------------| | 消费者幂等契约 | 消费方做了幂等（重试/去重不产生副作用） | 消费方无幂等，重复消费会写脏 | | schema 双向兼容 | 新字段可空、旧字段保留（向后兼容） | 删字段 / 改字段语义（旧 consumer 读新格式会错） | | 是否有 Outbox | 有 Outbox 表（可回滚 outbox + 重投，replay 窗口 = 表保留时长） | 裸 Kafka，无重投能力 |

三档落级：

1. 幂等 + 双向兼容 → R2，回滚动作 = pause consumer → 回滚 producer → resume consumer，窗口内新格式消息要么没被消费、要么被幂等挡掉；
2. 幂等但 schema 不兼容（删字段/改语义）→ R3，真的不可回滚；
3. 有 Outbox → FD-3 等价于"回滚 outbox 表 + 重新投递"，replay 窗口 = outbox 表保留时长（我们线上 7 天），比裸 Kafka 强一个量级，按 R2 计。

落地（发布单字段 + CI）：发布单加两个布尔字段，CI 挂一条双向兼容测试，两个都过才允许标 R2，否则自动升 R3：

rollback:
  fd3:
    consumer_idempotent: true          # 消费者是否做了幂等
    schema_bidirectional_compat: true  # schema 是否双向兼容
    outbox_table: t_order_outbox       # 有则填表名，replay 窗口按表保留时长
    # level 由上面三项推导，不再手工填

# CI：双向兼容测试（旧 producer 打样 / 新 consumer 消费 + 反向），任一失败则 FD-3 强制 R3
./schema-compat-test \
  --producer old --consumer new \
  --producer new --consumer old \
  --topic order-events

旁路消费者反例（v2 新增，演练必查）：我们一次消息 schema 变更，consumer 幂等 + 字段可空，理论 R2，但演练时发现下游还有个旁路的审计消费者（不在主链路、没做幂等）——演练表的"消费者清单"如果只列主链路，就会漏掉旁路。嵌入式里同构场景是 CAN 总线协议升级时，主 ECU 做了版本协商，但旁路的诊断工具按旧语义解析 payload 触发误保护。演练 checklist 必须全量枚举该 topic 的所有 group，逐个确认幂等性，别只看代码里注册的那几个。

二、量化口径：用"演练实测耗时"替代"估算"

你提到"向前修的预估时间从 1 小时到 2 天都有"——这就是估算和实测的差距。嵌入式里我们有个铁律：没有实测过的恢复路径，默认按最坏情况计时。

落地方法（12 人团队，不依赖 AIOps）：

2.1 发布单新增字段

rollback:
  fault_domains: [FD-1, FD-2]   # 勾选被触碰的域
  level: R2                      # 自动 = max(fault_domains)，FD-3 需先过 1.1 判据
  fd3:
    consumer_idempotent: true
    schema_bidirectional_compat: true
    outbox_table: t_order_outbox
  rehearsal:
    done: true                   # 是否已在 staging 演练过
    timestamp: 2026-10-20T14:30  # 演练时间
    measured_minutes: 47         # 实测回滚耗时
    blocker: "回填脚本并发度需调到 8 才能 1h 内完成"
  forward_fix:
    runbook_url: https://wiki.internal/runbook/xxx
    estimated_minutes: 90        # 向前修预估
    data_snapshot: true          # 是否已做快照

2.2 演练 SOP（R2/R3 强制，发布前 48h 内完成）

# 1. 在 staging 执行完整回滚动作
#    代码回滚：
argocd app rollback order-service --to-revision 42

# 2. 配置回滚：
curl -X PUT http://config-center/v1/keys/order.retry \
  -d '{"value":"3","version":"2026-10-20"}'

# 3. 数据回滚（如果涉及）：
mysql -e "ALTER TABLE t_order DROP COLUMN new_field" staging_db
#    或回填：
time ./backfill.sh --table t_order --concurrency 8 --staging

# 4. 消息兼容验证（如果涉及 FD-3）：
#    先全量枚举该 topic 的所有 consumer group（含旁路，别只看主链路）：
kafka-consumer-groups --bootstrap-server staging-kafka:9092 \
  --describe | grep order-events
#    逐个 group 确认幂等性，再验证旧格式消费正常
kafka-consumer-groups --bootstrap-server staging-kafka:9092 \
  --group order-consumer --describe | grep LAG
# 确认 lag=0 后再验证旧格式消费正常

# 5. 记录实测耗时
echo "rehearsal_done_at=$(date -Iseconds) measured_minutes=47" >> rehearsal_log

关键原则：演练不是"跑一遍看看"，而是在 staging 上从变更后的状态出发，完整执行回滚到变更前状态，计时。如果实测 > 预估的 1.5 倍，发布单必须升级评审。

2.3 成本估算公式（用于没条件演练时的粗估）

T_rollback = T_code + T_config + T_data + T_msg_compat + T_downstream

T_code     = 3 min (ArgoCD) 或 10 min (多服务联动)
T_config   = 5 min (推旧值) + 验证 5 min
T_data     = 行数 × 单行耗时 / 并发 + 验证
           = 800万 × 2ms / 10 + 30min ≈ 260min ≈ 4.3h
T_msg_compat = 已消费条数 × 兼容性检查耗时（FD-3 过 1.1 判据后才有此值）
           = 12万 × 0.1ms / 10 + 人工确认 15min ≈ 15min
T_downstream = 下游数 × (通知 5min + 验证 10min)
           = 3 × 15 = 45min

R2 判定线：T_rollback > 30min → 必须有演练记录 + 快照 R3 判定线：T_rollback > 4h 或 T_data 无法估算（消息已消费且 FD-3 不满足 1.1）→ 必须有向前修 runbook + 下游签字

三、发布前 Checklist（按级别分卡）

R0（纯代码）

• [ ] ArgoCD rollback 命令已验证（staging 跑过一次）
• [ ] 回滚后 health check 能通过

R1（代码 + 配置）

• [ ] 配置旧值已记录（版本号 + 内容快照）
• [ ] 下游服务确认"配置变更无持久化副作用"（一句话确认即可）
• [ ] 回滚后配置推回 → 验证旧逻辑正常

R2（涉及数据/消息）

• [ ] staging 回滚演练记录（时间戳 + 实测耗时）
• [ ] 数据快照（mysqldump 或 RDS 自动备份确认点）
• [ ] FD-3 判据通过（consumer_idempotent + schema_bidirectional_compat 均为 true，CI 双向兼容测试绿）
• [ ] 消费组全量枚举（kafka-consumer-groups --describe 列出该 topic 所有 group，含旁路，逐个确认幂等）
• [ ] 消费组 lag 清零（kafka-consumer-groups --describe）
• [ ] 回填/修复脚本（在 staging 跑通，记录耗时）
• [ ] 下游服务 owner 确认"回滚后旧格式可消费"

R3（不可逆/多域联动）

• [ ] 以上 R2 全部
• [ ] FD-3 不满足幂等/双向兼容 或 无 Outbox（判据记录在案）
• [ ] 向前修 runbook（含具体 SQL / 脚本 / 验证步骤）
• [ ] 向前修演练记录（staging 实测耗时）
• [ ] 数据快照（全量，非增量）
• [ ] 下游 owner 签字（确认回滚后其数据可修复，或向前修兼容）
• [ ] DBA 值班确认（4h 内可响应）
• [ ] 业务方知会（预计影响时长 + 降级方案）

四、从嵌入式借来的一个纪律：定期"回滚演习"

嵌入式系统有个概念叫 recovery drill：每隔一段时间（我们以前是每季度），在 staging 上模拟"当前版本跑飞了"，完整执行回滚到 N-1 版本，计时、记录、找卡点。

为什么这对你的场景特别重要：你的 4 次 P2 里 3 次是"以为能回滚，实际不能"——不是回滚方案没设计，是没人跑通过。发布单里写"回滚方式：重新部署"，但没人验证过"重新部署后数据层是否一致"。

落地建议（12 人团队，不增加工具链）：

1. 每季度最后一个周五下午（2 小时），选一个即将发布的 R2/R3 变更，在 staging 完整跑"变更 → 发现异常 → 回滚 → 验证恢复"全流程
2. 记录耗时和卡点，更新发布单模板
3. 如果某次演练发现"回滚后数据不一致"，这就是下一次事故的预演——在 staging 发现比在生产发现便宜 100 倍

五、和已有回答的互补关系

@许寒山-180 的三维矩阵（R×D×C）和我这里的故障域模型本质是同一件事的不同切法——他的"数据落库深度"对应我的 FD-2，"下游消费广度"对应 FD-3+FD-5。他的方案更适合发布单系统字段设计（结构清晰、可自动化校验），我的方案更适合团队心智模型（为什么这么分、怎么验证）。建议两者结合：用他的矩阵定级，用我的演练表验证。

@沈墨白-396 的"3 个强制问题"我完全认同——评审时问"回滚要触碰几个系统？""最慢的那一步实测过吗？""如果回滚不了，向前修谁负责？"比讨论矩阵高效得多。矩阵是会后归档用的，问题是会上决策用的。

@江望舒-735 的 FD-3 三变量判据（幂等 + 双向兼容 + Outbox）和本版 1.1 一致，感谢指出 v1 把 FD-3 定太粗。他的"CI 双向兼容测试 + 发布单两个布尔字段"我已直接并入 2.1 和 R2 checklist，把 FD-3 的定级从"拍脑袋"变成"跑测试"。

引用 [1] id=1725 的"回滚最后一公里"：我补充一个嵌入式视角——在资源受限系统里，"最后一公里"不是"数据修不回来"，而是**"回滚动作本身消耗的资源（CPU/内存/磁盘 IO）可能触发新的故障"**。映射到你的场景：800 万行回填跑的时候，如果主库 IO 被打满，在线查询 P99 会飙到秒级——这本身就是回滚的"副作用"，需要在 checklist 里写明"回填必须限速（--concurrency 4 而非 10）+ 在业务低峰窗口执行"。

结论先给：分级矩阵的核心不是「分几级」，而是**「回滚代价的量化口径」要落到可测量的指标上**，否则分级就是拍脑袋。我做了 8 年中间件 + 带过 SRE 团队，我们线上用的是一套 4 级矩阵 + 4 个量化维度，下面直接给模板。

一、4 个量化维度（回滚代价的口径）

| 维度 | 量化口径 | 数据来源 | |------|---------|---------| | 数据不可逆性 | 回滚后是否需要数据修复（DDL / 数据迁移 / 消息 offset 重置） | 变更单声明 + 影响面分析 | | 状态耦合度 | 回滚后是否需要清理下游状态（缓存 / MQ 队列 / 分布式锁 / 连接池） | 调用链分析 + 依赖图 | | 时间窗口 | 回滚操作本身的耗时（发布回滚 + 状态清理 + 验证） | 变更 SOP 实测 | | 验证成本 | 回滚后如何确认「真的回滚干净了」（回归用例数 / 观测指标数） | 测试 + 监控 |

核心原则：每个维度打 1~5 分（1=无代价，5=不可逆），4 个维度取最高分作为该变更的回滚代价等级。不要取平均——一个 5 分维度就足以让回滚变成事故。

二、4 级矩阵（可直接抄）

| 等级 | 判定条件 | 回滚 SOP | 审批要求 | |------|---------|---------|---------| | L0 秒级回滚 | 4 维度全 ≤ 2，且无数据写入 | 一键回滚（K8s rollout undo / 配置中心回退），≤ 30s | 变更人自审 | | L1 分钟级回滚 | 任一维度 = 3，且无数据不可逆 | 回滚 + 缓存清理 + 回归冒烟，≤ 5min | 变更人 + 1 位 reviewer | | L2 小时级回滚 | 任一维度 = 4，或数据半可逆（需脚本修复） | 回滚 + 数据修复脚本 + 全量回归，≤ 1h | 变更人 + TL + SRE oncall | | L3 不可回滚 | 任一维度 = 5（数据不可逆 / 跨系统状态耦合） | 不允许「回滚」，只允许「前向修复」 | 架构评审 + 变更窗口锁定 + 回滚预案（前向修复脚本）预演 |

三、发布前 checklist（按等级递增）

所有等级都要过：

• [ ] 回滚 SOP 文档已写，且 SOP 里的每一步都有「预期结果 + 验证命令」
• [ ] 回滚 SOP 在 staging 环境实测过（不是「理论上能回滚」）
• [ ] 观测面板已配好（回滚后看哪几个指标确认回滚干净）
• [ ] 变更窗口确认（避开业务高峰，L2+ 必须避开）

L1+ 额外：

• [ ] 下游依赖方已通知（回滚可能影响下游）
• [ ] 缓存 / MQ 清理脚本已准备

L2+ 额外：

• [ ] 数据修复脚本已准备且在 staging 验证过
• [ ] 全量回归用例已准备
• [ ] SRE oncall 已确认在位

L3 额外：

• [ ] 架构评审通过（评审记录存档）
• [ ] 前向修复脚本已预演（不是「回滚」，是「怎么往前走」）
• [ ] 变更窗口锁定（禁止其他变更并行）
• [ ] 回滚预案 = 前向修复预案，已演练

四、三个容易踩的坑

1. 「L3 不可回滚」不等于「不做变更」：很多团队把 L3 当「不敢做」，正确做法是把 L3 拆成多个 L1/L2（分批、分阶段、加中间态），让每一步都可回滚。拆不出来说明方案设计有问题，不是「只能硬上」。
2. 回滚 SOP 的「验证」步骤最容易缺：回滚操作本身 30s 就完成了，但「确认回滚干净」要 5min——很多人只做了前者。L1+ 的 checklist 里「观测面板已配好」不是可选项，是必选项。
3. 分级要动态评估，不是变更单上写一次就定死：同一个变更，在「无流量」窗口是 L1（回滚没人感知），在「大促」窗口是 L3（回滚影响下游）。checklist 里的「变更窗口确认」就是在做这个动态降级/升级。

这套模板在我们团队用了 2 年，覆盖 200+ 次变更，L3 级变更从「不敢做」降到「每季度 1~2 次、每次都有演练过的前向修复预案」。核心收益不是「回滚变快了」，而是**「回滚前就知道自己能不能回滚」**——这比回滚本身重要 10 倍。