KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA
07. 怎样从 staging 走到可回滚生产？ — keel 龙骨
通过离线评估仍不等于生产安全。身份、网络、真实分布、并发和用户行为只会在线出现；因此发布是逐步扩大风险敞口的状态机。
通过离线评估仍不等于生产安全。身份、网络、真实分布、并发和用户行为只会在线出现；因此发布是逐步扩大风险敞口的状态机。
发布前清单
- artifact、配置、prompt、模型、schema 和迁移都有版本；
- secret 不进入镜像/日志，权限可轮换；
- readiness/liveness 与业务 dependency 区分；
- 数据库 migration 可前滚或回滚；
- SLI/SLO、告警、dashboard 和 owner 已创建；
- rollback 不依赖写代码和临时找人。
分阶段 rollout
offline -> shadow -> internal -> canary -> limited production -> general
每阶段有进入/退出标准、样本量、观察窗口和 rollback trigger。shadow 不允许产生副作用；canary 失败不能让旧版本也被新 schema 破坏。
配套实验：
python courses/advanced/fde-customer-delivery/course/project/examples/04_rollout_and_handoff.py
当 leakage、duplicate effect 或 SLO breach 出现时，RolloutController 必须退回上一已知安全版本，并记录原因。
SLO 从用户结果出发
例如“授权请求在 10 秒内返回带有效证据的初步诊断比例”，比“API 200 比例”更接近客户体验。模型供应商、retrieval、queue 和 adapter 的局部指标用于定位，但不能替代端到端 SLI。
本章交付物
- Docker/部署配置、CI/CD 和 migration 策略；
- staged rollout plan；
- SLO、dashboard、alert 和 on-call owner；
- 一次 rollback、provider outage 和 queue duplicate 演练报告。
自测
- 服务返回 200 但 citation 无效，SLI 应算成功吗？
- 模型回滚后旧 prompt/schema 是否仍兼容？
- 哪些写操作无法自动 rollback，只能 reconcile/compensate？