300万的学费
2026年，我们团队在MLOps上踩过的坑，换算成直接经济损失，大约300万人民币。包括：一次模型部署故障导致推荐系统宕机6小时，直接损失约50万；一次数据泄露，合规罚款80万；一次A/B测试设计错误，损失约120万；其他小坑小碰，约50万。
这300万换来了7条MLOps铁律。每一条后面都有真金白银的故事。
金句：MLOps不是"锦上添花"，而是"避免灾难"。这些铁律，每一条都是学费。
铁律一：训练和推理的特征必须来自同一套代码
我们的一个风控模型，离线AUC 0.93，上线后0.71。排查了3天才发现：训练时用Pandas对"用户年龄"做了分箱处理，但推理时用了不同的分箱逻辑。用Feature Store（如Feast）确保训练和推理使用完全相同的特征定义。
铁律二：永远不要用生产数据训练，除非你做了严格的隔离
我们的推荐模型把生产环境的推理日志直接作为训练数据。结果模型学会了"推荐用户已经看过的东西"——这是个经典的"反馈回路"问题。必须用epsilon-greedy或多臂老虎机在生产中注入探索。
铁律三：模型版本 = 代码版本 + 数据版本 + 超参数版本
模型回滚时，代码回滚了，但模型没回滚——因为代码和模型版本是分开管理的。用MLflow的Run ID作为"单一真相来源"。
铁律四：离线评估好不等于线上效果好
我们的推荐模型，离线AUC提升了2%，上线后CTR反而下降了5%。原因：离线评估存在"幸存者偏差"。离线评估主要用来"排除差模型"，而不是"确认好模型"。
铁律五：监控必须覆盖"模型性能"而不只是"系统状态"
监控了CPU、内存、延迟、错误率——一切正常。但模型AUC从0.9掉到了0.7，没有人知道。监控体系必须包含三层：基础设施层、服务层、模型层。
铁律六：在真实数据上做"破坏性测试"
双十一那天，流量翻了10倍，用户行为模式也变了，模型预测完全失效。定期做"混沌工程"——往生产环境注入异常，看模型和系统如何响应。
铁律七：MLOps是人的问题，不是工具的问题
我们买了全套MLOps工具。但6个月后，数据科学家还是在Jupyter Notebook里手动训练，版本管理还是靠"model_v1_final_final.pkl"。MLOps的成功需要三个条件：数据科学家愿意用、工程团队能维护、管理层愿意投入。
结论：MLOps的成熟度，不是看你用了多少工具，而是看你的模型在生产中稳定运行了多久。 这7条铁律，每一条都是用真金白银换来的。希望你的学费比我们少。