回滚决策卡
用途
在出现发版/变更异常时，产出是否回滚的决策包：
- 现象与证据（只用用户提供的事实）
- 回滚 vs 继续观察 对比
- 建议结论（人裁定）
- 回滚步骤要点（描述到人可执行，不代跑命令）
- 沟通名单与观察项
空表见 references/rollback-card-template.md。
本技能不执行任何回滚、重启、切流命令。
适用场景
- 适合: 指标异常后的回滚决策；已决定回滚后的对内同步要点。
- 不适合: 「帮我直接回滚生产」、发版前 Go/No-Go（用
release-go-nogo）、写完整 RCA。
怎么使用(普通用户)
- 「用回滚决策卡，失败率升了，要不要滚」
- 「决定回滚 v2.3.1，整理步骤和通知谁」
- 「先别执行，帮我写回滚/不回滚的对比」
使用步骤
1. 澄清输入
| 字段 | 说明 |
|---|---|
| 当前版本/变更 | 要回滚的对象 |
| 现象与证据 | 指标、错误、时间 |
| 回滚目标 | 回到哪个版本/配置 |
| 已知副作用 | 数据是否不可逆等 |
缺回滚目标时追问；数据迁移不可逆时必须写入风险，不得淡化。
2. 对比选项
至少给出：
- 立即回滚
- 继续观察/热修（若用户未排除）
每项含：预期收益、主要风险、所需时间量级（未知则标未知）。
2.1 不可逆变更：回滚前必答三问
代码可以回滚，数据往往不能。 变更含数据迁移、格式升级或外部副作用（已发通知、已扣款、已同步第三方）时，「回滚」实际是两件事，必须分开判断：
| 必答问题 | 为什么必须先答 | 答不上来时 |
|---|---|---|
| 1. 故障期间产生的新数据，回滚后旧代码还读得了吗？ | 旧代码可能不认识新格式——回滚会把「部分用户报错」放大成「这批数据全部不可读」 | 标「回滚风险未知」，不把立即回滚当默认项 |
| 2. 是否已产生外部不可撤销副作用？ | 已发短信、已扣款、已推给第三方的数据，回滚代码不会撤销它们 | 先列副作用清单再决策 |
| 3. 有无数据回迁或双读兼容方案？ | 没有就意味着回滚是一道单向门 | 优先比较热修方案 |
判定规则：
- 三问中任一答案为「否」或「未知」时，立即回滚不再是默认选项，须与热修并列比较，并把该风险显式写进决策卡。
- 「回滚后数据不可读」的风险通常高于当前故障本身——把 5% 用户报错变成 100% 数据不可读，是典型的回滚事故。
- 存在数据迁移时，回滚步骤必须分列「代码回滚」与「数据处置」两段；后者无方案时写「无方案，需 DBA 参与评估」，不留空、不省略。
3. 建议与步骤
- 建议结论 + 理由；标注「最终由负责人裁定」
- 步骤要点用编号清单；每步可含验证点
- 禁止输出可直接粘贴执行的破坏性 shell（如
kubectl delete实参集群命令）；只写「回滚镜像至 vX」「恢复配置项 Y」级描述
4. 沟通与观察
- 通知：研发/值班/客服/业务（按用户场景勾选）
- 回滚后观察指标与时长
输出格式
# 回滚决策卡：{对象}
## 现象与证据
- …
## 选项对比
| 选项 | 收益 | 风险 | 时间 |
| --- | --- | --- | --- |
| 立即回滚 | … | … | … |
| 继续观察/热修 | … | … | … |
## 建议结论
- …
- 裁定人: （待填）
## 回滚步骤要点（人执行）
1. …
2. 验证: …
## 沟通
- …
## 回滚后观察
- …
示例
输入:
对象: 生产 v2.3.1 回调服务
现象: 14:20 起微信回调失败率从 0.3% 升到 4%；已持续 25 分钟
回滚目标: 镜像 v2.3.0；配置 ORDER_RETRY_MAX 可先保持
数据: 无迁移
值班: 小陈；TL 王敏
输出:
# 回滚决策卡：生产回调服务 v2.3.1
## 现象与证据
- 14:20 起微信回调失败率 0.3% → 4%，已持续约 25 分钟
- 变更对象: v2.3.1 回调服务；无数据迁移
## 选项对比
| 选项 | 收益 | 风险 | 时间 |
| --- | --- | --- | --- |
| 立即回滚至 v2.3.0 | 最快恢复已知稳定版本 | 丢失 v2.3.1 重试改进；需再发版 | 短（视发布耗时，未知具体分钟） |
| 继续观察/热修 | 保留新逻辑 | 失败率可能继续伤用户与客服 | 不确定 |
## 建议结论
- 建议**立即回滚**至 v2.3.0（失败率已高且持续）
- 裁定人: （待填，建议 TL 王敏或值班负责人）
## 回滚步骤要点（人执行）
1. 按现网发布流程将回调服务镜像回滚至 v2.3.0
2. 确认实例滚动完成后抽查健康检查
3. 验证: 失败率是否在约定窗口内回落（目标接近变更前 0.3% 量级）
4. ORDER_RETRY_MAX 配置：按你方策略保留或另行评估（本次输入为可保持）
## 沟通
- 值班小陈：执行与观察
- TL 王敏：裁定与升级
- 客服：若用户侧仍有积压咨询，同步「正在回滚恢复」
## 回滚后观察
- 回调失败率、积压队列；建议至少观察 30 分钟（可按你们 SLO 调整）
对照示例：含不可逆数据迁移（立即回滚不再是默认项）
输入:
对象: 生产 v3.0.0 订单服务
现象: 15:10 起下单接口 P99 从 400ms 升到 3.2s；错误率 2%
回滚目标: 镜像 v2.9.4
数据: v3.0.0 上线时执行了订单表结构迁移，新增字段并把金额存储从「分」改为「元+精度位」；已有约 1.2 万笔新订单按新格式写入
副作用: 其中约 900 笔已推送给物流系统
值班: 小李；TL 周凯
输出（节选）:
# 回滚决策卡：生产订单服务 v3.0.0
## 不可逆变更三问
1. 回滚后旧代码能读新数据吗？—— **不能**。1.2 万笔订单按新金额格式写入，v2.9.4 按「分」解析会读出错误金额（风险：金额显示/结算错误，影响面大于当前 2% 错误率）
2. 已产生外部副作用？—— **是**。约 900 笔已推送物流系统，回滚代码不会撤回已推送数据
3. 有数据回迁或双读兼容方案吗？—— **本批未提供**，需 DBA 评估
## 选项对比
| 选项 | 收益 | 风险 | 时间 |
| --- | --- | --- | --- |
| 立即回滚至 v2.9.4 | 恢复 P99 与错误率 | **1.2 万笔新格式订单将被旧代码错误解析**；900 笔物流数据不一致；风险高于当前故障 | 短，但后果不可逆 |
| 热修（优先） | 不触碰数据格式，仅修性能问题 | 修复时间未知；期间 P99 持续劣化 | 未知 |
| 回滚 + 数据回迁 | 彻底回退 | 需 DBA 编写回迁脚本并验证；窗口内需停写 | 未知，通常以小时计 |
## 建议结论
- **不建议立即回滚**。三问中两问为「否/未提供」，回滚风险高于当前故障。
- 建议优先热修性能问题；若必须回退，须先由 DBA 出具数据回迁方案与停写窗口。
- 裁定人: （待填，建议 TL 周凯 + DBA）
## 回滚步骤要点（人执行）
**代码回滚**：按发布流程回滚镜像至 v2.9.4
**数据处置**：**无方案，需 DBA 参与评估**——须覆盖 1.2 万笔新格式订单的回迁与 900 笔已推送物流数据的对账；未有方案前不执行代码回滚
对照要点：前一例无数据迁移，回滚是单纯的版本回退，故建议立即回滚；本例的回滚代价高于故障本身，所以立即回滚从默认项降为需权衡项，且回滚步骤强制拆成代码与数据两段。
常见问题(FAQ)
- 要我执行回滚: 拒绝；只给决策卡与步骤要点。
- 数据已写坏: 在风险中明确「回滚代码无法撤销已写数据」，必要时建议停写/人工修复路径（不编造具体 SQL）。
- 与发版门禁混淆: 未上线前用
release-go-nogo；已异常用本技能。
已知限制
- 不访问监控与集群
- 不保证回滚一定恢复服务
- 不替代正式变更/事故流程
- 数据回迁方案需 DBA 出具，本技能只提示必要性与缺口
变更说明
- 0.1.1: 新增「不可逆变更：回滚前必答三问」（原扣分点）——回滚后旧代码能否读新数据、是否已产生外部不可撤销副作用、有无数据回迁或双读兼容方案；配判定规则：任一答「否/未知」则立即回滚不再是默认项，「回滚后数据不可读」的风险通常高于当前故障，回滚步骤须拆分「代码回滚」与「数据处置」两段。补含数据迁移的完整对照示例（金额存储格式变更 + 已推送第三方），演示结论从「立即回滚」降为「不建议立即回滚」。
- 0.1.0: 首发。把故障现象与回滚目标整理成回滚决策卡。
