部署、Canary 与回滚
本节目标
根据任务形态选择部署方式，并用影子、Canary、Blue-Green 和回滚控制变更风险。
先选择服务形态
| 形态 | 适用场景 | 重点风险 |
|---|---|---|
| 批处理 | 每小时/每天评分，允许等待 | 数据快照错位、任务中断、重复写入 |
| 在线请求 | 用户操作后需要立即预测 | 尾延迟、突发流量、依赖故障 |
| 流式处理 | 连续事件、需要低延迟更新 | 顺序、重复事件、状态恢复 |
| 边缘/端侧 | 网络受限、隐私或实时性要求高 | 设备差异、升级困难、资源限制 |
“部署成 REST API”不是默认答案。批处理能满足需求时，通常更容易复现和回滚。
四种发布方式
滚动更新
逐步用新实例替换旧实例。适合兼容性好、风险可控的常规更新。新旧版本可能短时间并存，因此输入输出契约必须兼容。
影子运行（shadow）
复制真实请求给候选模型，但候选结果不返回用户。它能比较延迟和预测分布，却不能完全证明候选在真实决策闭环中的业务效果。
Canary
让候选只承接有限、可识别的真实流量，观察后再扩大。比例和观察时长必须由流量规模、风险与指标统计稳定性决定，不能照抄教程数值。Kubernetes 官方示例使用独立的稳定版与 Canary Deployment，通过标签让二者并行；更精细的流量控制通常还需要网关或服务网格。
Blue-Green
维护两套可切换环境：一套服务，一套待验证。切换和回退快，但资源成本更高，数据库或特征状态兼容仍需单独处理。
健康检查不等于模型正确
- liveness：进程是否还活着；
- readiness：实例是否已加载制品、可以接收请求；
- 冒烟预测：典型输入能否得到符合签名的输出；
- 质量观察：用户 SLI、模型切片、漂移与业务结果是否正常。
HTTP 200 只能说明请求被处理，不能说明预测有用。
回滚要冻结一整套发布单元
回滚清单至少包括：
- 模型与预处理器版本；
- 特征定义及线上计算版本；
- 服务代码和依赖环境；
- 输入输出 schema；
- 配置、策略和资源规格；
- 数据库或状态变更的兼容方案。
如果只回滚模型，却保留不兼容的新特征代码，故障会继续存在。旧制品还必须保持可读取并定期演练加载，否则“支持回滚”只是文档承诺。
发布判定表
| 观察 | 可能动作 |
|---|---|
| 技术错误或尾延迟明显恶化 | 停止扩大，必要时立即回滚 |
| 整体稳定但关键切片退化 | 保持小流量并调查，通常不扩大 |
| 只有输入分布变化，暂无质量标签 | 继续收集证据，不能直接断言模型变差 |
| 候选正常，监控系统自身缺数据 | 暂停扩大，先恢复可观测性 |
练习与自测
为“每晚生成客户流失名单”和“实时支付拦截”分别选部署形态与发布策略，解释差异。再回答：
- 影子运行为什么不能测出候选对用户行为的全部影响？
- Canary 没有告警是否足以扩大？还要确认什么？
- 数据库 schema 不向后兼容时，为什么应用回滚可能失败？
小结与下一步
渐进发布限制影响面，监控决定是否继续。下一步学习 模型监控、漂移与反馈。
参考资料
- Kubernetes Deployment（核对于 2026-07-14）
- Kubernetes Canary Deployments（核对于 2026-07-14）
- KServe 官方文档（核对于 2026-07-14；Kubernetes 模型服务平台选项）
- MLflow Model Deployment（核对于 2026-07-14）