凌晨2点的PagerDuty风暴

2026年6月，凌晨2:17。PagerDuty在5分钟内发出了8条告警：推荐模型P99延迟 > 5秒、风控模型错误率 > 10%、特征存储在线服务不可用、NLP模型GPU OOM、数据管道延迟超过2小时…

On-call工程师被同时拉入了3个War Room。2小时后，故障定位：上游Kafka集群故障，导致所有实时特征管道中断，进而导致所有模型收到空特征。

金句：ML系统的故障不是"会不会发生"，而是"什么时候发生"和"你准备好了吗？"

ML故障的独特性

ML系统的故障模式与传统软件系统有本质不同：传统软件故障通常是"二元"的（工作/不工作）。ML系统故障通常是"渐进"的（慢慢变差）。而且，ML故障可能不触发任何传统告警（CPU、内存、错误率都正常），但模型输出已经"悄悄变蠢"了。

MLOps故障分级

P0 - 紧急（Critical）： 模型服务完全不可用、模型输出严重错误、数据严重泄露。响应时间：5分钟内确认，30分钟内恢复。P1 - 严重（Major）： 模型P99延迟超过SLA的2倍、模型AUC下降超过10%。响应时间：15分钟内确认，2小时内恢复。P2 - 一般（Minor）： 数据漂移PSI超过0.25、模型AUC下降5-10%。响应时间：4小时内处理。P3 - 轻微（Trivial）： 单个特征统计异常、模型训练Pipeline失败。响应时间：下一个工作日。

On-Call轮值机制

MLOps On-Call应该是双人轮值——“系统On-Call”（处理基础设施故障）+ “模型On-Call”（处理模型性能问题）。因为一个人很难同时精通K8s和模型漂移检测。

故障应急流程（War Room）

  1. Triage（0-5分钟）：确认故障范围。2. Contain（5-15分钟）：止损——回滚到上一个稳定版本。3. Diagnose（15-60分钟）：根因分析。4. Resolve（1-4小时）：修复。5. Verify（15-30分钟）：验证。

事后复盘（Postmortem）

每个P0和P1故障后，24小时内完成事后复盘。复盘不是"找责任人"，而是"找到系统性改进"。复盘模板：时间线、根因（5-Why分析）、影响、做得好的、做得不好的、Action Items。

结论：MLOps的故障应急不是"出了事再说"，而是"没出事时准备好的"。 一个团队在故障中的表现，不是看它有多聪明，而是看它准备得有多充分。最好的故障应急，是让故障不发生。其次是让故障在5分钟内恢复。