MLOps 解决的是”如何让机器学习模型可靠地上线”，而 AIOps 解决的是”如何让 AI 系统自主运维、自我优化”。两者是演进关系，而非替代关系。

运维范式的三次演进

IT 运维经历了三个阶段的演进：

关键洞察：

• DevOps 管理的是代码的生命周期
• MLOps 管理的是模型的生命周期
• AIOps 管理的是AI 系统的运维（包括模型、基础设施、业务流程）

MLOps：机器学习模型的工业化

MLOps 的核心挑战

传统软件开发的 CI/CD 无法直接应用于机器学习，因为 ML 引入了数据和模型两个额外维度：

1
2

传统 CI/CD：代码 → 构建 → 测试 → 部署
MLOps：数据 + 代码 → 训练 → 评估 → 注册 → 部署 → 监控

三大核心挑战：

1. 实验可复现性：如何保证相同的代码、数据、超参数能复现相同的模型？
2. 模型版本管理：模型不是代码，如何追踪模型版本、训练数据、评估指标？
3. 模型漂移检测：生产数据分布变化导致模型性能下降，如何及时发现？

MLOps 的核心流程

完整的 MLOps 流程包含六个阶段：

1. 数据准备与版本化

• 数据收集：从多源收集训练数据
• 数据清洗：去重、纠错、标准化
• 数据标注：人工或半自动标注（关键瓶颈）
• 数据版本化：使用 DVC、LakeFS 等工具管理数据版本

最佳实践：

1
2
3
4

# 使用 DVC 版本化数据
dvc add data/train.csv
git add data/train.csv.dvc
git commit -m "Add training data v1.0"

2. 实验管理与追踪

每次训练实验需要记录：

• 代码版本（Git commit）
• 数据版本（DVC hash）
• 超参数（学习率、batch size 等）
• 评估指标（准确率、F1、延迟）
• 模型权重（artifact）

工具推荐：MLflow

1
2
3
4
5
6

import mlflow

with mlflow.start_run():
    mlflow.log_param("learning_rate", 0.001)
    mlflow.log_metric("accuracy", 0.92)
    mlflow.sklearn.log_model(model, "model")

3. 模型注册与审批

训练好的模型需要：

• 注册到 Model Registry：统一管理模型版本
• 添加元数据：训练数据、评估指标、适用场景
• 审批流程：从 Staging → Production 需人工审核

MLflow Model Registry 示例：

1
2
3
4
5
6
7
8
9
10
11
12

# 注册模型
mlflow.register_model(
    "runs:/<run_id>/model",
    "fraud-detector"
)

# 更新阶段
client.transition_model_version_stage(
    name="fraud-detector",
    version=1,
    stage="Production"
)

4. 模型部署与服务化

部署策略：

• 实时推理：REST API，低延迟要求
• 批量推理：定时任务，高吞吐
• 边缘推理：设备端部署，离线可用

工具推荐：KServe + Kubernetes

1
2
3
4
5
6
7
8

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: fraud-detector
spec:
  predictor:
    sklearn:
      storageUri: "s3://models/fraud-detector/v1"

5. 监控与漂移检测

生产环境需要持续监控：

• 模型性能：准确率、召回率、F1
• 数据漂移：输入数据分布变化
• 概念漂移：输入输出关系变化
• 系统指标：延迟、吞吐、错误率

漂移检测方法：

• 统计检验：KS 检验、卡方检验
• 距离度量：KL 散度、Wasserstein 距离
• 模型对比：新旧模型在相同数据上的预测差异

6. 持续训练与更新

当检测到漂移或性能下降时：

1. 收集新数据
2. 重新训练模型
3. 评估新模型
4. 灰度发布（A/B 测试）
5. 全量切换

自动化训练管道：

1
2
3
4
5

# 定时触发重新训练
if detect_drift(production_data, training_data):
    new_model = train_model(new_data)
    if evaluate(new_model) > baseline:
        deploy(new_model, strategy="canary")

MLOps 成熟度模型

大多数企业停留在 L1-L2 级别，达到 L3 需要完善的监控和反馈机制。

AIOps：AI 驱动的智能运维

AIOps 的核心能力

AIOps 不是”运维 AI 模型”，而是”用 AI 做运维”。其核心能力包括：

1. 异常检测（Anomaly Detection）

传统基于阈值的告警（如 CPU > 80%）存在局限：

• 无法捕捉复杂模式（如缓慢内存泄漏）
• 阈值设置困难（不同业务、不同时段阈值不同）
• 误报率高，导致告警疲劳

AI 异常检测的优势：

• 自适应基线：自动学习正常模式，动态调整基线
• 多维关联：同时分析 CPU、内存、网络、日志等多个维度
• 预测性告警：在故障发生前预警（如预测磁盘将在 2 小时后耗尽）

实现方式：

1
2
3
4
5
6
7
8
9
10

# 使用时序异常检测模型
from sklearn.ensemble import IsolationForest

model = IsolationForest(contamination=0.01)
model.fit(historical_metrics)

# 检测异常
anomalies = model.predict(current_metrics)
if -1 in anomalies:
    alert("Anomaly detected!")

2. 根因分析（Root Cause Analysis）

传统运维依赖人工排查，耗时长、易遗漏。AIOps 通过以下方式加速根因定位：

• 拓扑分析：基于服务依赖图，自动定位故障传播路径
• 日志聚类：将海量日志聚类为模式，快速定位异常日志
• 因果推断：使用因果图分析事件之间的因果关系

示例：服务依赖图分析

1
2
3

用户请求 → API Gateway → Service A → Service B → Database
                              ↓
                         Service C

如果 Service B 延迟上升，AIOps 可以自动判断：

• 是 Service B 自身问题（CPU、内存、代码缺陷）？
• 是下游 Database 问题（慢查询、连接池耗尽）？
• 是上游 Service A 流量突增导致？

3. 自动修复（Auto-Remediation）

AIOps 不仅能发现问题，还能自动修复常见问题：

实现方式：Runbook 自动化

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

# 定义自动修复 Runbook
runbook = {
    "memory_leak": {
        "condition": "memory_usage > 90% for 5m",
        "action": "restart_pod",
        "approval": "auto"
    },
    "disk_full": {
        "condition": "disk_usage > 85%",
        "action": "cleanup_logs",
        "approval": "auto"
    },
    "config_error": {
        "condition": "error_rate > 5% after deploy",
        "action": "rollback_deployment",
        "approval": "manual"  # 高风险操作需人工确认
    }
}

4. 容量规划与成本优化

AIOps 可以预测资源需求，优化成本：

• 容量预测：基于历史趋势预测未来资源需求
• 弹性伸缩：自动调整副本数，平衡性能与成本
• 资源推荐：为每个服务推荐最优的 CPU/内存配置

示例：HPA 智能伸缩

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 60  # 避免频繁扩容
    scaleDown:
      stabilizationWindowSeconds: 300  # 缩容更保守

AIOps 架构模式

典型的 AIOps 系统包含四个层次：

1
2
3
4
5
6
7
8
9
10
11
12
13

┌─────────────────────────────────────┐
│         决策与执行层                  │
│  (自动修复、容量调整、告警路由)         │
├─────────────────────────────────────┤
│         分析与推理层                  │
│  (异常检测、根因分析、预测)            │
├─────────────────────────────────────┤
│         数据处理层                    │
│  (数据清洗、特征提取、关联)            │
├─────────────────────────────────────┤
│         数据采集层                    │
│  (Metrics、Logs、Traces、Events)     │
└─────────────────────────────────────┘

关键技术选型：

MLOps vs AIOps：关键差异

核心区别：

• MLOps 是面向模型开发者的工具链
• AIOps 是面向运维团队的智能助手

融合趋势：AI for IT Operations + ML for Models

随着 AI 原生应用的普及，MLOps 和 AIOps 正在融合：

场景 1：用 AIOps 监控 MLOps 管道

• 问题：训练任务失败、模型性能下降、数据管道延迟
• 解决方案：用 AIOps 监控 MLOps 基础设施，自动检测异常并告警

1
2
3
4
5
6
7

# 监控训练任务
if training_job.duration > expected_duration * 1.5:
    aiostreams.alert("Training job abnormally slow")

# 监控模型性能
if model.accuracy < baseline - 0.05:
    aiostreams.alert("Model performance degradation detected")

场景 2：用 MLOps 管理 AIOps 模型

• 问题：AIOps 的异常检测模型也需要训练、评估、更新
• 解决方案：用 MLOps 流程管理 AIOps 模型，确保模型质量

1
2
3
4
5
6
7
8

# 注册异常检测模型
mlflow.register_model(
    "runs:/<run_id>/anomaly_detector",
    "cpu-anomaly-detector"
)

# 定期重新训练
schedule.every(30).days.do(retrain_anomaly_model)

场景 3：统一的 AI Platform

未来趋势是构建统一的 AI Platform，同时支持 MLOps 和 AIOps：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

┌─────────────────────────────────────┐
│         AI Platform                 │
├──────────────┬──────────────────────┤
│   MLOps      │       AIOps          │
│   - 模型训练  │   - 异常检测          │
│   - 模型部署  │   - 根因分析          │
│   - 模型监控  │   - 自动修复          │
├──────────────┴──────────────────────┤
│   共享基础设施                        │
│   - Kubernetes                      │
│   - 可观测性平台                     │
│   - 模型注册中心                     │
│   - AI Gateway                      │
└─────────────────────────────────────┘

实践建议

何时引入 MLOps？

信号：

• 数据科学家手动训练、手动部署模型
• 模型版本混乱，无法复现历史实验
• 模型上线后性能下降，但无法及时发现
• 多个模型并行运行，缺乏统一管理

建议：

• 从 MLflow 开始，建立实验追踪和模型注册
• 引入 KServe，标准化模型部署
• 建立基础监控，跟踪模型性能

何时引入 AIOps？

信号：

• 告警疲劳，大量误报被忽略
• 故障排查耗时长，依赖资深工程师
• 重复性故障频繁发生，人工修复成本高
• 资源利用率低，成本持续上升

建议：

• 从异常检测开始，用 AI 替代静态阈值
• 引入日志聚类，加速故障定位
• 实现常见问题的自动修复（如 Pod 重启、日志清理）

分阶段实施路径

阶段 1：基础可观测性（0-3 个月）

• 部署 Prometheus + Grafana，采集 Metrics
• 部署 Loki 或 ELK，集中化日志
• 部署 Jaeger 或 Tempo，分布式追踪

阶段 2：MLOps 基础（3-6 个月）

• 引入 MLflow，管理实验和模型
• 引入 KServe，标准化模型部署
• 建立基础模型监控（准确率、延迟）

阶段 3：AIOps 试点（6-12 个月）

• 引入异常检测，替代静态阈值告警
• 实现日志聚类，加速故障定位
• 试点自动修复（低风险场景）

阶段 4：深度融合（12-18 个月）

• 用 AIOps 监控 MLOps 管道
• 用 MLOps 管理 AIOps 模型
• 构建统一 AI Platform

总结

MLOps 和 AIOps 是 AI 原生时代的两大运维范式：

• MLOps 解决”如何让 ML 模型可靠地上线并持续优化”
• AIOps 解决”如何让 IT 系统智能运维、自我修复”

两者不是替代关系，而是互补且融合的关系。未来的 AI Platform 将同时支持 MLOps 和 AIOps，形成完整的 AI 运维体系。

核心要点：

1. MLOps 是基础：没有 MLOps，AI 模型无法工业化
2. AIOps 是进阶：没有 AIOps，AI 系统无法自治
3. 融合是趋势：统一的 AI Platform 是未来方向

实践建议：

• 从小处开始：先解决最痛的问题（模型版本管理 or 告警疲劳）
• 分阶段推进：基础可观测性 → MLOps → AIOps → 深度融合
• 工具选型：优先开源方案（MLflow、Prometheus），必要时引入商业方案

运维的未来不是”人运维机器”，也不是”人用工具运维机器”，而是”AI 运维 AI”。MLOps 和 AIOps 的结合，是通往这一未来的必经之路。

参考文献

• Google MLOps 白皮书
• MLflow 官方文档
• KServe 官方文档
• AIOps 平台对比
• Prometheus + Grafana 实战