故障、回滚与再训练决策
本节目标
面对线上异常时先限制损害、保存证据，再选择回滚、数据修复、规则修复或再训练。
先做分诊，不急着训练
“指标变差”可能来自不同根因：
| 现象 | 可能根因 | 优先动作 |
|---|---|---|
| 大量 5xx 或超时 | 服务、依赖、资源、配置 | 限流、降级、回滚服务 |
| schema/缺失异常 | 上游数据或特征管线 | 隔离坏数据、恢复契约 |
| 仅新版本退化 | 模型、预处理器或配置 | 停止发布并回滚完整发布单元 |
| 多版本同时退化 | 外部环境、标签定义或共同依赖 | 扩大调查，不盲目回滚单模型 |
| 漂移但有标签质量稳定 | 真实输入变化但模型仍适用 | 继续观察，不必自动再训练 |
| 概念关系变化且有足够新标签 | 模型陈旧 | 评估再训练或重新设计 |
再训练不是通用修复。若根因是单位错误，用坏数据重训会制造一个更难发现的新故障。
事件响应的最小流程
- 声明与分级：记录开始时间、影响、负责人和沟通渠道；
- 遏制：停止扩大、切换旧版本、禁用高风险功能或进入人工处理；
- 保存证据：冻结相关 release、模型、配置、特征版本和脱敏请求样本；
- 诊断：沿数据—特征—模型—服务—下游决策逐层排查；
- 恢复：验证替代路径与监控后逐步恢复；
- 复盘：写时间线、根因、促成因素、检测缺口和可验证改进项。
NIST SP 800-61 Rev. 3 将事件响应纳入组织风险管理。实践中应同时覆盖准备、检测、响应和恢复，而不是只写事后报告。
回滚判据
适合快速回滚的情况：影响明确来自新发布、旧版本仍兼容且风险更低、制品和数据契约可用。以下情况需要更谨慎：
- 新旧版本共享已损坏的上游数据；
- 数据库或特征状态已发生不可逆变化；
- 旧版本有已知安全问题；
- 环境已经真实变化，旧模型反而更差。
因此回滚计划要定期演练，而不是事故时第一次执行。
何时再训练
再训练前至少确认：
- 新标签定义稳定，且标签覆盖偏差可接受；
- 数据变化与目标性能问题有关，而非只看到了相关漂移；
- 训练管线、基线与切片评测仍适用；
- 新数据不会把事故期间的错误决策无限放大；
- 新候选仍经过完整质量门和渐进发布。
如果任务目标、标签或输入含义变了，可能需要重新设计问题，而不是延续旧训练脚本。
无责复盘不等于无责任边界
复盘应聚焦系统如何允许故障发生，避免用“操作员粗心”终止分析。同时明确决策所有者、审批责任和整改截止条件。好的行动项可验证，例如“为单位字段增加生产契约测试并在 Canary 前阻断”，而不是“以后更仔细”。
练习与自测
情景：新模型发布后，某地区拒绝率升高；输入缺失率也上升，整体延迟正常。写出前 30 分钟的调查与遏制顺序，并回答：
- 何时回滚模型，何时先修数据？
- 需要冻结哪些证据？
- 哪些事实足以支持再训练，哪些仍只是线索？
小结与下一步
故障处置的优先级是保护用户、保留证据、恢复服务，再改进模型。下一步学习 平台安全与治理，把身份、供应链、审计和责任边界纳入整条生命周期。
参考资料
- NIST SP 800-61 Rev. 3（发布于 2025-04；核对于 2026-07-14）
- Kubernetes Deployment（核对于 2026-07-14）