8.3 回退与应急预案

8.3 回退与应急预案

本节摘要：8.2 的告警响了，然后呢？本节回答"坏了怎么办"。手段分三级：软回退——不动版本，切换运行参数：降到备用模型、提高转人工阈值（第 7.2 节的阈值本来就是配置）、关闭非核心功能（降级体验换稳定）；硬回退——版本回滚：回到上一个已知良好的 prompt/模型快照组合，依赖的是版本化与配置开关；熔断——极端情况（连续红线、安全问题）下完全停机或全部转人工，宁可不可用也不可错。预案的载体是 runbook：一页预先写好的操作手册，字段包括触发条件（绑定 8.2 阈值表）、影响面评估、决策权限（谁有权拍板回退——事先授权，不是临时找人）、动作清单（可勾选的步骤 + 每步验证）、复盘要求（2472 小时内写事故记录并回写）。可回退性有三个前提：版本化（每次变更有快照可回）、金丝雀发布（变更从小流量开始）、配置开关（回退是改配置不是改代码）。预案写完要演练——季度 game day 真拉一次闸，否则 runbook 只是一份没人读过的文档。时间预算（示意）：软回退分钟级、硬回退 1030 分钟、熔断即时但代价最大。

学习目标

阅读完本节，你应当能够：

1. 区分软回退、硬回退、熔断三级手段的适用情形与代价。
2. 按模板为自己的系统写出一页 runbook。
3. 说清可回退性的三个前提与缺失时会发生什么。
4. 设计季度演练，并执行"复盘回写"闭环。

一、三级手段：按代价排序

选择的原则（观点）：能软不硬、能硬不熔——先用最小代价止血，同时收集证据决定是否升级。软回退是"降压药"，硬回退是"手术"，熔断是"切除"：都没有错，错的是该切除时还在调药。

💡 第 7.2 节的转人工阈值在这里第二次出场：平时它是成本参数，事故时它是旋钮——把 0.65 调到 0.85，五分钟内能把错放率压下去一个量级（示意）。阈值可配置、可热更，是软回退最好用的杠杆。

二、runbook 模板

<!-- runbook_template.md（runbook 模板，逐段填写） -->
# RUNBOOK：客服助手质量劣化（编号 RB-07）

## 触发条件（绑定 8.2 阈值表）
- 寻呼级：p95 > 5s 持续 10min；错误率 > 2% 持续 5min
- 工单级连续 3 次未处理自动升级：低置信占比 > 9% 持续 6h
- 人工触发：任一成员发现质量异常（写明发现渠道）

## 影响面评估（先看再动）
1. 打开面板（8.2）：三层红绿灯各什么状态？
2. 切场景 × 版本：劣化是全量还是某切片？（6.2 trace 下钻）
3. 查变更记录：近 24h 有无发版 / 模型供应商公告？

## 决策权限
- 软回退：值班工程师可直接执行，事后通报
- 硬回退：值班 + 评测 owner 双人确认（15 分钟内找不到第二人则单人大胆执行）
- 熔断：技术负责人；安全类事故任何人可先熔断后补流程

## 动作清单（每步带验证）
- [ ] 1. 软回退：conf_gate 0.65 → 0.85（配置中心热更）
      验证：5 分钟后低置信占比应下降，错放率回落
- [ ] 2. 切备用模型 provider-b（版本化快照 tag 见配置仓库）
      验证：影子对照记录存在（8.1），裁判抽检 10 条不低于基线 −0.1
- [ ] 3. 硬回退：回滚 release-2026-08-30（含 prompt + 模型 + 配置三件套）
      验证：面板技术层恢复绿色；抽样 20 条输出与旧版本一致
- [ ] 4. 熔断（仅 RB-07 触发条件全红）：入口关闭，全量转人工
      验证：新请求 100% 进入人工队列

## 复盘要求
- 24h 内：事故时间线（告警时间 / 决策时间 / 恢复时间）
- 72h 内：根因分析 + 四项回写——
  ① badcase 入回归集（3.1）；② 阈值表校准（8.2）；
  ③ 本 runbook 修订；④ 裁判/监控为何没更早发现（5.2 / 8.2）
​

模板五段缺一不可，其中最容易被省略、也最值钱的是决策权限——凌晨三点不该发生的事，是四处打电话找授权。事先授权写在纸上是应急预案的全部意义（观点）。

三、可回退性的三个前提

1. 版本化：prompt、模型快照标识、配置三者绑定成 release（第 3.4 节数据卡同款纪律）——"回滚到上周"的前提是上周的东西还在、还找得到；
2. 金丝雀发布：一切变更从 5%~10% 流量起步（8.1 灰度推进）——让"回退"只是关掉一个小开关，而不是全量事故；
3. 配置开关：阈值、模型路由、功能开关全部走配置中心热更——回退是运维动作，不是代码发布；需要"改代码才能回退"的系统等于没有回退。

⚠️ 审计一下自己的系统：现在立刻回滚上一个版本，要几分钟、要几个人、要点多少下鼠标？答不上来就是演练没做够。

四、演练与复盘回写

季度 game day（观点节奏）：从 8.2 阈值表里挑一个最怕的场景（如"供应商模型静默升级导致幻觉率翻倍"），在工作时间人为注入（切一个劣化配置），由值班按 runbook 走完全流程。记录两个数：MTTD（平均发现时间——告警多久响）与 MTTR（平均恢复时间——从告警到验证恢复），季度间对比。两个数的健康量级（示意）：MTTD 应显著小于用户投诉到达时间（分钟级 vs 小时级）；MTTR 视手段而定——软回退 10 分钟内、硬回退半小时内、熔断即时但可用性代价最大。

复盘回写四件套（runbook 模板末段）：badcase 入回归集、阈值校准、runbook 修订、"为何没更早发现"。第四件最扎心也最有价值——它把事故转化成对第 5 章裁判、8.2 面板、7.3 PSI 的体检要求，防线由此一层层加厚。

本节要点回顾

1. 三级手段：软回退（调参数）→ 硬回退（换版本）→ 熔断（停服务）；能软不硬、能硬不熔。
2. runbook 五段：触发条件、影响面、决策权限、动作清单（带验证）、复盘要求——事先授权是灵魂。
3. 三个前提：版本化、金丝雀、配置开关；需要改代码才能回退 = 没有回退。
4. 演练度量：季度 game day 盯 MTTD / MTTR；复盘四件套让事故变成防线加厚。

至此，线上防线完整：安全地换（8.1）、及时地看（8.2）、坏了能拉闸（8.3）。最后一章把整套体系沉淀为团队资产——评测集进仓库、CI 做门禁、以及评测自身的体检：过拟合、gaming 与腐化。