凌晨3点的PagerDuty

2026年6月，凌晨3:07，PagerDuty响了。告警信息：推荐模型P99延迟12秒（正常值200ms），错误率15%。3:08，我们确认是新模型部署导致的。3:09，执行回滚。3:12，服务恢复正常。

从告警到恢复，5分钟。这5分钟是我们花了3个月建立的回滚体系换来的。

金句：模型回滚不是一个"技术操作"，而是一个"组织能力"。 回滚速度 = 组织响应速度 + 技术自动化程度。

三种回滚策略

策略一：蓝绿部署（Blue-Green Deployment）。 最安全、最快速的回滚方式。同时运行两套完整的模型服务——蓝色（当前生产）和绿色（新版本）。流量切换器（Istio/Envoy）将流量指向蓝色。如果出问题，一键切回蓝色。回滚时间： < 1秒。资源成本： 双倍。

策略二：金丝雀发布（Canary Release）。 新模型先接收5%流量，观察15分钟。如果无异常，扩大到20%，再观察30分钟。然后50%，最后100%。任何阶段出现异常，立即回滚。回滚时间： < 1分钟。这是2026年的最佳实践。

策略三：模型注册表回滚。 通过MLflow Model Registry切换到上一个版本。用client.transition_model_version_stage()将上一个Archived版本标记为Production。回滚时间： 取决于模型加载时间。

回滚SOP（标准操作流程）

  1. 触发（0-1分钟）：监控告警触发，值班工程师确认。2. 诊断（1-5分钟）：检查Grafana Dashboard，确认是否新部署导致。3. 回滚执行（5-10分钟）：蓝绿/金丝雀/注册表回滚。4. 验证（10-15分钟）：监控恢复，业务指标正常。5. 根因分析（24小时内）：为什么新模型出问题？如何防止再次发生？

回滚的常见陷阱

陷阱1：回滚了代码，但没回滚模型。 代码和模型版本必须"绑定"——用MLflow Run ID关联。

陷阱2：回滚后，下游系统不适应。 回滚前检查下游兼容性。

陷阱3：没有"回滚演练"。 每月进行一次"回滚演练"（Fire Drill），验证回滚流程的有效性。

结论：模型回滚不是"出问题才想到的事"，而是"上线前就准备好的事"。 一个可靠的模型回滚体系，是MLOps工程成熟度的最高标志。