一、职业定位（What & Why）
1. 一句话定义 + 通俗解释
一句话定义： MLOps Engineer负责构建和维护机器学习模型的持续集成、持续部署（CI/CD）和生产运维体系，让模型从实验环境到生产环境的过程自动化、可重复、可监控。
通俗解释（生活类比）：
想象你是一家餐厅的老板，主厨（数据科学家）在厨房里研究出了一道新菜谱（模型），在试吃时味道很好。
但要把这道菜每天卖给1000个客人，你需要：
- 标准化的食材采购（数据管道）
- 可复制的烹饪流程（模型训练流水线）
- 出菜前的质量检查（模型验证）
- 保证每桌客人都能稳定吃到相同口味（模型部署与监控）
- 如果某天食材变了，要能快速调整（数据漂移应对）
MLOps Engineer就是设计这套"菜品生产线"的人：
- 把主厨的"手工作坊"变成"工业流水线"
- 确保新菜谱上线不砸招牌（灰度发布）
- 监控每天的菜品质量（模型效果监控）
- 食材不够时自动补货（数据管道）
- 出了问题能快速回滚到昨天的菜谱（版本管理）
没有MLOps Engineer，公司永远停留在"主厨在厨房里手搓，但无法批量供应"的阶段。
2. 在业务/行业流程中的位置
【AI系统与架构层】
数据科学家 / AI/ML Engineer 在实验环境训练模型
↓
【MLOps Pipeline】------ 核心位置
├─ 代码版本管理（Git）：模型代码、训练脚本、配置
├─ 数据版本管理（DVC）：训练数据集、特征数据
├─ 模型训练流水线：自动触发训练、超参数调优、实验追踪
├─ 模型验证：自动化测试（单元测试、集成测试、模型性能测试）
├─ 模型注册与版本管理：将合格的模型推入模型仓库
├─ 模型部署：自动打包（Docker）、部署到推理服务（K8s/SageMaker）
├─ 模型监控：延迟、吞吐、数据漂移、概念漂移、效果指标
└─ 反馈闭环：监控异常触发自动重训练
↓
生产环境推理服务（API / 批处理）
↓
业务系统调用协作角色：
- 上游输入： AI/ML Engineer（模型代码、训练脚本）、数据工程师（数据管道）
- 下游输出： 生产可用的模型API、监控数据、告警
- 平级协作： AI Workflow Engineer（业务工作流与模型推理的集成）、SRE（基础设施）、数据平台团队
3. 核心价值（为什么企业需要这个岗位）
商业价值：
- 缩短模型上线周期：从"训练完到上线"从几周缩短到几小时，甚至自动触发。
- 保证模型质量一致性：自动化测试和验证，避免"训练时95分，上线后50分"的惨剧。
- 降低运维成本：模型监控、自动扩缩容、自动重训练，减少人工介入。
- 满足合规与审计：完整的模型版本、数据版本、训练参数记录，满足监管要求。
没有这个岗位会发生什么：
- 数据科学家训练完模型，把pkl文件扔给后端 → 后端不知道怎么部署 → 一周后模型终于上线，但效果崩了
- 每次模型更新都要手动复制文件、重启服务 → 容易出错、回滚困难
- 模型上线后效果慢慢变差，但没有人发现 → 业务指标下滑几周后才被察觉
- 监管审查时，无法回答"这个模型是用什么数据、什么代码训练的？"
二、工作内容拆解（What exactly they do）
1. 核心职责模块（按模块拆解）
| 模块 | 核心任务 | 具体动作（必须具体） |
|---|---|---|
| 1. 训练流水线构建 | 让模型训练自动化、可重复 | ① 搭建CI/CD流水线（GitHub Actions / GitLab CI / Jenkins）→ ② 当代码push到特定分支时，自动触发模型训练 → ③ 集成数据版本管理（DVC），确保训练使用正确的数据集版本 → ④ 运行超参数调优（Optuna / Hyperopt）并记录 → ⑤ 自动记录实验指标到MLflow / Weights & Biases → ⑥ 训练完成后自动运行模型验证测试 |
| 2. 模型验证与测试 | 确保模型"上线前没问题" | ① 编写单元测试：数据预处理函数、特征工程逻辑 → ② 编写模型验证测试：在验证集上计算指标，对比基线模型（指标下降超过阈值则失败）→ ③ 编写鲁棒性测试：输入缺失值、异常值时的模型行为 → ④ 编写一致性测试：相同输入多次推理输出一致 → ⑤ 集成测试：端到端推理pipeline（数据输入→预处理→模型→后处理）→ ⑥ 性能测试：在预期QPS下的延迟和吞吐 |
| 3. 模型部署与发布 | 把模型安全送上线 | ① 模型打包：将模型工件（pkl/ONNX/TensorRT）和推理代码打包成Docker镜像 → ② 镜像推送到私有仓库 → ③ 部署到K8s / SageMaker / Vertex AI → ④ 实现部署策略：蓝绿部署、金丝雀发布（先5%流量，再全量）→ ⑤ 配置自动扩缩容（HPA）→ ⑥ 部署后运行烟雾测试（smoke test）→ ⑦ 支持模型版本切换和回滚 |
| 4. 模型监控与告警 | 让模型"不出事" | ① 配置模型服务监控：延迟（P50/P99）、吞吐（QPS）、错误率 → ② 配置数据监控：输入特征分布（PSI）、缺失率、异常值占比 → ③ 配置模型效果监控：当有真实标签时（如推荐系统有点击反馈），计算在线指标（AUC、准确率）→ ④ 设置告警阈值：PSI>0.2、延迟P99>100ms、错误率>1% → ⑤ 集成告警通道（钉钉、Slack、PagerDuty）→ ⑥ 搭建可视化看板（Grafana） |
| 5. 模型持续更新（CI/CD for ML） | 让模型"越变越好" | ① 设计自动重训练触发条件：定时（每周）、数据量累积（新增10万条）、效果监控触发（PSI超标）→ ② 自动拉取最新数据，触发训练流水线 → ③ 新模型验证通过后，自动部署到预发环境 → ④ 在预发环境运行A/B测试或影子对比 → ⑤ 效果优于当前生产模型则自动全量上线 → ⑥ 记录模型版本变更历史 |
2. 不同级别职责差异
| 级别 | 做什么 | 典型工作内容 |
|---|---|---|
| 初级（0-2年） | 执行与维护 | 写Dockerfile、配置CI脚本、部署模型到预发环境、查看监控看板、处理告警 |
| 中级（2-5年） | 设计流水线 | 设计完整的MLOps流水线（代码→训练→验证→部署→监控）→ 选型工具（Kubeflow/MLflow/Seldon）→ 优化性能与成本 → 培训初级 |
| 高级（5年+） | 平台架构 | 设计公司级MLOps平台（支持多团队、多模型、多环境）→ 自动化模型治理和合规 → 解决大规模模型服务的性能瓶颈 → 制定MLOps最佳实践 |
三、能力要求（Skills）
1. 硬技能（必须具体）
| 类别 | 具体技能 | 实际用途 |
|---|---|---|
| 容器化 | Docker | 打包模型和推理代码 |
| 编排 | Kubernetes（熟练） | 部署和管理推理服务 |
| CI/CD | GitHub Actions / GitLab CI / Jenkins | 自动化训练和部署流水线 |
| 模型实验 | MLflow / Weights & Biases | 实验追踪、模型注册 |
| 工作流编排 | Kubeflow / Argo Workflows / Airflow | 编排复杂的训练pipeline |
| 数据版本 | DVC / LakeFS | 版本管理大数据集 |
| 监控 | Prometheus + Grafana | 收集指标、可视化告警 |
| 日志 | ELK / Loki | 收集推理日志，排查问题 |
| 追踪 | OpenTelemetry / Jaeger | 分布式追踪（模型服务链） |
| 云平台 | AWS/GCP/Azure（至少一个） | 使用托管ML服务（SageMaker/Vertex AI） |
| 编程 | Python（熟练） | 写测试脚本、监控脚本、pipeline定义 |
| 概念 | 特征存储（Feast / Tecton） | 保证训练和推理特征一致 |
2. 软技能（必须具体，不要空话）
| 能力 | 具体行为 |
|---|---|
| 自动化思维 | 遇到重复操作时，第一反应是"写脚本自动化"，而不是手动再做一次 |
| 故障排查能力 | 模型部署失败时，能一步步排查：代码问题？依赖问题？镜像问题？权限问题？资源不足？ |
| 容量规划 | 根据QPS增长预测，提前扩容或优化推理性能 |
| 沟通协调 | 能跟数据科学家解释"为什么你的模型不能直接上线"（缺少测试、依赖不全），并帮助他们改进 |
| 安全与合规意识 | 设计流水线时考虑：模型访问权限、数据隐私、推理日志脱敏 |
3. 必须 vs 加分项
| 类型 | 内容 |
|---|---|
| 必须 | Docker、Kubernetes、Python、至少一个CI/CD工具、MLflow、Prometheus + Grafana |
| 加分 | Kubeflow/Argo经验、特征存储经验、GPU推理优化（TensorRT/vLLM）、有SRE背景、熟悉模型监控（WhyLabs/Arize） |
4. 常见能力误区（非常关键）
| 误区 | 真相 |
|---|---|
| "MLOps就是DevOps+ML" | MLOps增加了数据版本、模型验证、模型漂移监控等ML特有环节，比普通DevOps复杂 |
| "用SageMaker/Vertex AI就不用MLOps了" | 托管服务解决了基础设施，但流水线设计、测试、监控仍需自己搭建 |
| "模型监控只看延迟和QPS就行" | 数据漂移和效果下降才是MLOps特有的、更难监控的内容 |
| "MLOps工程师不需要懂模型" | 不懂模型就写不出正确的验证测试、看不懂效果监控指标。至少要有ML基础 |
四、知识体系（Knowledge）
1. 核心知识模块（3-5个）
| 模块 | 实际用途 |
|---|---|
| MLOps生命周期（数据、训练、部署、监控、重训练） | 理解端到端流程，知道每个环节的痛点 |
| Kubernetes与云原生 | 部署和管理模型推理服务 |
| CI/CD for ML | 代码、数据、模型的自动化测试与发布 |
| 模型监控与可观测性 | 数据漂移检测、概念漂移检测、模型效果评估 |
| 特征存储 | 解决训练/推理特征不一致的经典问题 |
2. 学习方式建议
| 知识模块 | 是否需要系统学习 | 可边做边学？ | 推荐路径 |
|---|---|---|---|
| Kubernetes | 需要系统学 | ⚠️ 建议系统学 | CKA认证课程（2-3个月） |
| CI/CD for ML | 边做边学 | ✅ 可以 | 用GitHub Actions搭一个ML训练流水线 |
| 模型监控 | 边做边学 | ✅ 可以 | 用Prometheus + 自定义exporter监控模型 |
| 特征存储 | 需要系统学 | ⚠️ 概念较新 | 读Feast官方文档，理解在线/离线一致性 |
| MLflow | 边做边学 | ✅ 可以 | 跑一遍MLflow官方教程 |
判断： MLOps Engineer需要较强的工程基础（尤其是K8s），建议系统学习K8s后再切入。没有K8s基础很难做好MLOps。
五、典型工作日（Day in the Life）
角色设定：中级MLOps Engineer，在电商公司做推荐模型
| 时间段 | 做什么 | 具体内容 |
|---|---|---|
| 09:30-10:00 | 检查监控 | 看Grafana：推荐模型API延迟P99=85ms（正常），QPS=320（正常），PSI=0.18（接近告警阈值0.2）→ 需关注 |
| 10:00-11:30 | 排查PSI上升 | 分析输入特征分布：用户年龄特征分布偏移 → 与数据团队确认：最近上线了新用户渠道，年龄结构不同 → 决定触发模型重训练 |
| 11:30-12:00 | 协作 | 跟AI/ML Engineer沟通：需要他们提供新的训练代码分支，适配新数据 → 约定下午4点前提交 |
| 12:00-13:30 | 午餐+休息 | - |
| 13:30-15:00 | 优化推理服务 | 发现模型推理GPU利用率只有30% → 尝试增大批处理（batch size from 1 to 8）→ 测试后P99延迟从85ms升到110ms，但吞吐翻倍 → 权衡后决定上线批处理配置 |
| 15:00-16:00 | 搭建自动重训练流水线 | 用Kubeflow定义Pipeline：数据拉取 → 特征工程 → 训练 → 验证 → 模型注册 → 部署到预发 → 如果指标提升>2%则自动上线 → 写Pipeline定义文件 |
| 16:00-16:30 | 会议 | 跟SRE团队对齐：模型服务需要保证99.9%可用性 → 设计多可用区部署、自动故障转移 |
| 16:30-17:30 | 模型版本回滚演练 | 模拟新模型上线后效果下降 → 执行回滚脚本：切换模型版本到上一个 → 验证流量切回 → 记录回滚时间（2分钟） |
| 17:30-18:00 | 文档+复盘 | 更新MLOps runbook（新增PSI告警处理流程）→ 写周报：完成自动重训练流水线原型 |
会议占比： 约10-15%
最大压力点：
- 生产模型效果突然暴跌，需要快速定位是数据问题、模型问题还是推理代码问题
- 模型推理服务被大量请求打爆，需要紧急扩容和限流
- 自动重训练流水线跑失败，导致模型过期未更新，业务方投诉
六、就业市场情况（Market）
1. 招聘行业（具体）
| 行业 | 典型公司 | MLOps需求 |
|---|---|---|
| 大型科技公司 | 字节、阿里、腾讯、百度、美团 | 自研MLOps平台，支持海量模型 |
| AI创业公司（B轮+） | 各类AI独角兽 | 需要搭建标准MLOps流程 |
| 金融/银行 | 蚂蚁、微众、各大银行 | 风控模型需要合规、可审计的MLOps |
| 自动驾驶 | 蔚来、小鹏、地平线 | 模型频繁更新，需要自动化流水线 |
| 传统企业AI部门 | 制造、能源、零售 | 从零搭建MLOps能力 |
2. JD共性要求（真实总结）
- "精通Kubernetes和Docker" ------ 核心技能
- "熟悉MLflow/Kubeflow/Argo等MLOps工具" ------ 有实际使用经验
- "有CI/CD流水线搭建经验" ------ Jenkins/GitLab CI/GitHub Actions
- "了解模型监控和数据漂移检测" ------ 会用Prometheus或专门工具
- "加分：有云平台认证（AWS/GCP）" ------ 托管服务经验
3. 市场趋势（行业经验判断）
- 增长趋势： 持续高增长。MLOps是AI工程化的基础设施，每个认真做AI的公司都需要。需求稳定，不易被炒作泡沫影响。
- 哪一层最缺人： 中高级非常缺。K8s+ML工具链学习曲线陡峭，有生产经验的人少。初级岗位可以从DevOps转。
- 判断： MLOps Engineer是长期稳定需求的岗位，适合喜欢工程化、自动化的技术人。薪资增长稳健。
七、薪酬情况（Salary）
1. 分地区薪资范围（人民币/年薪，税前）
| 地区 | 初级（0-2年） | 中级（2-5年） | 高级（5年+） |
|---|---|---|---|
| 中国一线城市 | 30-45万 | 50-85万 | 90-150万 |
| 美国（非湾区） | 12-16万美元 | 17-25万美元 | 26-40万美元 |
| 美国（湾区） | 15-20万美元 | 22-35万美元 | 38-60万美元 |
2. 薪资差异关键因素（非常重要）
| 因素 | 影响幅度 | 说明 |
|---|---|---|
| K8s深度 | ±30% | 能自己写Operator/CRD的比只会用kubectl的值钱 |
| 工具链广度 | ±25% | 熟悉Kubeflow/Argo/MLflow全套的稀缺 |
| 行业（大厂 vs 中小） | ±50% | 大厂MLOps工程师薪资远高于普通公司 |
| 模型监控实战经验 | ±20% | 解决过真实的数据漂移问题 |
八、职业发展路径（Career Path）
1. 横向发展（转哪些岗位）
| 转岗方向 | 难度 | 需要补什么 |
|---|---|---|
| DevOps/SRE | ⭐ | 已经很接近，补更通用的基础设施 |
| AI Platform Engineer | ⭐ | 同样做平台，更侧重平台开发而非运维 |
| 数据工程师 | ⭐⭐ | 补数据管道、数据仓库 |
| AI/ML Engineer | ⭐⭐ | 补模型算法、训练调优 |
| AI Workflow Engineer | ⭐⭐ | 补业务工作流编排 |
2. 纵向发展（清晰路径）
DevOps/后端工程师（2-4年）
↓ 转向MLOps
初级MLOps Engineer（0-2年）
↓ 能维护流水线、处理告警
中级MLOps Engineer（2-5年）
↓ 设计完整MLOps平台、优化性能
高级MLOps Engineer / MLOps架构师（5-8年）
↓ 两条路
├─ 技术专家：公司级MLOps平台负责人 → 基础设施技术委员会
└─ 管理路线：ML平台团队Lead → 技术总监3. 天花板分析（判断）
- 天花板高：MLOps是AI基础设施的核心，大厂资深MLOps工程师可达P8/P9级别。但天花板低于核心算法岗位。
- 判断： 适合喜欢工程、稳定、不想追论文的人。长期需求稳健，收入体面。
九、适合人群（Fit）
1. 适合人群（"如果你是这样的人..."）
- "我喜欢自动化，讨厌重复手工操作" ------ 你会享受写脚本把一切自动化
- "我对K8s、Docker有热情" ------ 容器编排是你的舒适区
- "我喜欢看监控面板，追求系统稳定性" ------ 你对SLI/SLA有执念
- "我懂一点ML，但不想调模型参数" ------ 你的兴趣在工程不在算法
- "我能处理生产环境压力" ------ 出故障时能冷静排查
2. 不适合人群（劝退）
- "我不想学K8s，太复杂" ------ MLOps离不开K8s
- "我只想做算法，不想碰运维" ------ 这个岗位80%是运维和工程
- "我讨厌on-call" ------ 模型服务出问题需要你处理
- "我不喜欢写YAML" ------ K8s和CI/CD配置都是YAML
十、进入路径（How to get in）
1. 标准路径（现实版）
Step 1：打好K8s基础（2-3个月）
- 本地用minikube或kind搭集群
- 学kubectl常用命令、Deployment、Service、ConfigMap、Ingress
- 考CKA认证（加分）
Step 2：学CI/CD（2-3周）
- 用GitHub Actions搭一个简单流水线：代码push → 运行测试 → 构建镜像 → 推送到仓库
Step 3：学MLflow（1周）
- 跑通MLflow tracking、model registry
Step 4：搭建完整MLOps流水线（2-3周）
- 场景：训练一个简单sklearn模型
- 流水线：Git push → 自动训练 → 记录指标 → 验证 → 打包镜像 → 部署到K8s → 监控
Step 5：加监控（1周）
- 部署Prometheus + Grafana
- 暴露模型服务的/metrics接口，采集延迟、QPS
- 加自定义指标：PSI
Step 6：做作品集（1周）
- GitHub：完整的MLOps流水线代码 + K8s yaml + 监控配置 + README
- 写博客：《从零搭建生产级MLOps流水线》
2. 常见转行路径
| 转行前背景 | 优势 | 需补什么 |
|---|---|---|
| DevOps/SRE | K8s、CI/CD、监控 | 补ML基础、MLflow、模型验证 |
| 后端工程师 | 编程、系统设计 | 补K8s、ML基础、MLOps工具 |
| 数据工程师 | 数据管道 | 补K8s、CI/CD、模型部署 |
| AI/ML Engineer | 懂模型 | 补K8s、CI/CD、监控 |
| Python脚本开发 | 编码 | 补K8s、CI/CD、Linux系统知识 |
3. 学习顺序（精简路径）
① K8s基础（CKA课程）（2-3个月）
↓
② CI/CD（GitHub Actions）（2周）
↓
③ MLflow（1周）
↓
④ 搭建完整流水线（2-3周）
↓
⑤ Prometheus + Grafana监控（1周）
↓
⑥ 完整项目（1周）
↓
⑦ 投递"MLOps Engineer"总时间： 全职学习约3-4个月（有后端基础）；零基础需先补Linux、网络、编程，共6-8个月。
十一、常见误解 & 真相（Reality Check）
| 误解 | 真相 |
|---|---|
| "MLOps就是DevOps，会K8s就行" | 还需要数据版本、模型验证、漂移检测等ML特有知识 |
| "用SageMaker就不用MLOps了" | SageMaker帮你管了基础设施，但CI/CD、测试、监控仍需自己搭 |
| "MLOps工程师不用写代码" | 写很多代码：pipeline定义、监控exporter、测试脚本 |
| "模型监控只看系统指标" | 数据漂移、模型效果才是MLOps的核心监控内容 |
| "MLOps只需要大厂才需要" | 任何要把模型上线生产的公司都需要，只是规模不同 |