先缩量再关开关
把放量比例降到零或退回上一档，是影响面最小的一步，通常一两分钟就能完成。为什么放第一位：它能在不动代码与数据的前提下先止血，为后续判断争取时间；很多问题缩量后就不再扩大，处置压力随之下降。
开关优于版本回退
功能开关能精确关掉出问题的那一层，而版本回退会把整包改动一起撤掉，包括已稳定的部分。边界在粒度：把模型、提示词、检索与写操作拆成独立开关，只有开关无法收敛时才回退版本。
注意会话与缓存残留
灰度用户可能持有新版本写入的会话状态或缓存，回退后读到旧结构会出现空白与报错。怎么做：清理相关缓存或做兼容读取，并确认队列里没有待处理的新格式消息；不做这步，异常仍会零散复现。
数据修正要有顺序
若新版本已写入错误数据，先停止写入再修数据，最后恢复读取。为什么顺序不能反：反向操作会让修正过程继续产生脏数据；修正前留一份现场快照，便于评估影响范围，也便于二次回退。
恢复后要验证三件事
业务能否正常完成、指标是否回到基线、残留异常是否清零。为什么不能只看系统状态页：页面恢复不代表业务恢复，积压任务、缓存与人工待办都可能还在；验证由业务方与值班人员共同确认，才算真正恢复。
适用与不适用
适合谁
- 正在灰度、已经出现指标异常的系统
- 多版本共存、需要精确收缩范围的改版
- 涉及写操作、可能产生脏数据的场景
不适合谁
- 只读展示类功能、无数据写入的调整
- 尚无开关与版本管理、无法分批的系统
典型场景
某政务服务平台的事项检索改版在第二档出现结果缺失。值班人员先缩量到首档，再关闭新版检索开关，十分钟内恢复旧逻辑；随后清理该批用户的缓存并核对队列，确认没有新格式消息积压。业务方复核了三个高频事项的检索结果，指标回到基线后才重新排期。
可执行步骤
- 立即把放量比例降到零或者退回上一档，首先把受影响的范围控制住
- 确认问题属于哪一层，优先关闭对应的开关，而不是直接整体回退版本
- 清理相关的会话与缓存，同时检查队列里是否有新格式的待处理消息
- 若已经产生错误写入，先停止写入再修数据，修正之前留存现场快照
- 由业务方与值班人员共同验证业务已经可用，并确认各项指标回到基线
常见坑
- 直接回退版本而没有缩量，回退过程中新旧请求交错，异常持续出现，看起来像回退失败。
- 只清缓存不停写，旧数据不断被新逻辑覆盖，修正完又出现新的错误记录，反复两三次才收敛。
- 回退后只看系统状态页恢复就宣布结束，积压任务与人工待办仍在，业务侧第二天才反馈未恢复。
- 没有留现场快照就动手修数据，影响范围无法评估，事后追溯时连原始错误样本都找不到。
自检与验收清单
- 是否先缩小放量范围，再决定要不要回退版本
- 开关清单是否覆盖模型、提示词、检索与写操作
- 相关的会话、缓存与队列是否已经清理并确认
- 修改数据之前是否留存了现场快照与影响范围
- 业务可用与指标回到基线是否由双方共同确认
常见问题
缩量能解决还要回退吗？
缩量能控制影响面，但不能代替修复。若问题只出现在特定请求组合，缩量后可以继续观察并定位；若错误来自版本本身的逻辑缺陷，缩量只是把问题延后，仍需回退或修复后再放量，否则全量时同样会遇到。
回退会不会影响已正常使用的用户？
会有影响，但可控。回退通常让所有用户退回旧版本，已适应新界面的用户会感到变化；如果新版本仅小范围可用，可在回退时保留白名单继续使用旧逻辑，其余用户不受影响，但要在记录中写清保留范围。
多久内必须完成回退？
取决于业务性质。涉及资金、合同与对外承诺的场景，应把目标定在一刻钟到半小时内；内部工具可以放宽到一小时。目标时间要在方案里写明并演练过，否则只是纸面数字，真出事时无人知道该按什么节奏推进。