两条链路合起来才叫 MLOps
MLOps 拆开看是 DevOps 加 DataOps 再加 ModelOps。它管的是端到端、全生命周期的数据加 AI/ML 运营模型，本质上是把「数据推动场景」和「AI 模型落地」这两条链路拼成一张整合视图。
落到流水线上，就是一条通用作业链：
Organize（管数据）→ Engineer（做特征）→ Science（建模型）→ Deploy（上线）→ Analyze（看效果）
这条链不是画着好看的。制造业质量监测可以这样走：采集 MES 传感器数据，实时流式处理，调参缺陷分类模型，上线到边缘网关，产线大屏报警。零售智能补货则是另一条路：POS 交易数据走 Batch，特征聚合，销量时序模型，每天自动把补货建议输出到 ERP。
传统 ML 交付卡在哪
老做法是手动 Jupyter、手动打包、手动上线、人力观测。一次部署 2 到 4 周，数据、模型、代码三者迭代错位，出了问题无法复现。
MLOps 交付换成 Git Push 触发流水线，自动调参、自动评测、灰度发布。一天内能上线 N 次，任意迭代的三元组可以秒级还原。
差距不在工具多寡，在于「可复现」这三个字。传统流程里模型效果掉了，你连当时用的是哪版特征都说不清。
CI/CD 各阶段，验证人员该盯什么
代码提交阶段（Pre-CI）用本地钩子 pre-commit，配 black、flake8、pytest。这一步跑在开发机上，成本最低。
延续整合阶段（CI）做自动单元测试，工具是 GitHub Actions、GitLab CI 或 Jenkins；代码覆盖率门禁用 pytest-cov 加 codecov；静态代码扫描上 SonarQube、SpotBugs、ESLint；安全扫描（SAST/DAST）用 safe（Python）、npm audit、ZAP。
制品构建阶段（Build）做容器镜像冒烟测试，流程是 docker build 到 docker run 再到 curl /health。
部署阶段（CD）做多环境自动部署，工具是 Argo CD、GitLab CD、Jenkins X；数据库 Schema 迁移校验用 Flyway 或 Liquibase，再配自写校验 SQL。
验证加速阶段（CI-Test）跑并行 UI 自动化，命令是 playwright test –workers=8；契约验证走消费者驱动测试，用 Pact JS 或 Spring Cloud Contract；性能基线测试用 Gatling 或 k6。
发布后阶段（Post-CD）做生产可观测性断言，PromQL 加 Grafana；自动回滚与复盘用 Argo Rollouts、Flagger、ChatOps。
一个容易踩的坑：健康检查过了不代表服务可用
上面 Build 阶段那条 docker run + curl /health 的冒烟测试，很多团队直接照抄。这里有个坑：/health 返回 200 只能说明进程活着，不能说明依赖就绪。
如果应用启动时连不上数据库或消息队列，但健康端点只检查了 HTTP 端口，冒烟测试照样绿。等流量切过去才发现问题，回滚窗口已经被吃掉。
更稳的做法是区分存活探针和就绪探针：存活探针只判断进程是否僵死，就绪探针要真实探测下游依赖。Kubernetes 里对应 livenessProbe 和 readinessProbe，两者不要配成同一个端点。
两套 CI/CD 的结构差异
DevOps CI/CD 完全开源，Jenkins、GitLab CI、GitHub Actions 任选一个就能用。
MLOps CI/CD 的开源方案也成熟了，MLflow 加 Kubeflow 加 DVC 加 Evidently 加 Feast 这套组合，能实现「数据-模型-代码」三元组的延续交付。
这套方案什么时候别用
MLOps 流水线不是所有团队都该上。模型一天更新多次、特征需要版本回溯、有合规审计要求的场景，收益明显。
反过来，如果模型半年才重训一次，特征靠几个 SQL 就能算完，团队又没有专职的平台工程师，硬搭 Kubeflow 只会增加维护负担。这时候用 MLflow 做实验追踪加一个定时训练脚本，性价比更高。
另一个风险点是 DVC 和 Git 的配合。数据文件走 DVC 指向远端存储，Git 里只留指针文件。如果远端存储的凭证轮换没同步到 CI runner，流水线会在拉取数据这一步挂掉，而且报错信息通常很含糊。建议在 CI 里加一步显式的 dvc pull 校验，失败就早停。
