痛点
一个中等规模的 K8s 集群，Prometheus + Alertmanager 稳定运行，规则写了 200 条，每天深夜告警轰炸值班手机，80% 是无效抖动。工程师花大量时间盯着 Grafana 大盘做「人肉关联分析」——CPU 飙高是哪个 Pod 引起的？流量突增是正常促销还是攻击前兆？
这是传统运维告警体系的天花板：规则驱动，被动响应，缺乏上下文。AIOps（AI for IT Operations）的切入点正在这里。
什么是 AIOps，什么不是
AIOps 不是用 ChatGPT 回答"我的 Pod 为什么 CrashLoopBackOff"（虽然这也有用），核心是把 机器学习能力嵌入运维数据管道，完成三件事：
- 异常检测：从时序指标里识别超出正常基线的行为，而不是靠人写阈值规则
- 根因分析（RCA）：多维指标联动分析，自动缩小排查范围
- 自动化响应：低风险故障自愈，高风险故障辅助决策
工具栈选型
| 能力层 | 推荐工具 | 说明 |
|---|---|---|
| 数据采集 | Prometheus + OTEL Collector | 指标、Trace、日志统一入口 |
| 异常检测 | Prophet / Isolation Forest | 时序预测 + 无监督离群检测 |
| 告警关联 | Alertmanager + Robusta | 抑制 + 智能分组 |
| 根因分析 | k8sgpt / Holmesgpt | LLM 驱动的 K8s 诊断 |
| 自动化响应 | n8n / Argo Workflows | 低代码工单流 + 声明式修复 |
实操：三个可落地的场景
场景一：基于 Prophet 的时序异常检测
用 Facebook Prophet 对 QPS 做预测，偏离预测区间超过 3σ 时触发告警，替代硬阈值。
# anomaly_detect.py
from prophet import Prophet
import pandas as pd
import requests
# 从 Prometheus 拉最近 7 天 QPS 数据
PROM = "http://prometheus:9090"
resp = requests.get(f"{PROM}/api/v1/query_range", params={
"query": 'sum(rate(http_requests_total[5m]))',
"start": "2026-10-12T00:00:00Z",
"end": "2026-10-19T00:00:00Z",
"step": "300",
})
data = resp.json()["data"]["result"][0]["values"]
df = pd.DataFrame(data, columns=["ds", "y"])
df["ds"] = pd.to_datetime(df["ds"], unit="s")
df["y"] = df["y"].astype(float)
# 训练模型
m = Prophet(interval_width=0.99, daily_seasonality=True)
m.fit(df)
# 预测未来 1 小时
future = m.make_future_dataframe(periods=12, freq="5min")
forecast = m.predict(future)
# 检查最新点是否在置信区间外
latest = forecast.iloc[-1]
current_qps = df["y"].iloc[-1]
if current_qps < latest["yhat_lower"] or current_qps > latest["yhat_upper"]:
print(f"ANOMALY: current={current_qps:.1f}, "
f"expected=[{latest['yhat_lower']:.1f}, {latest['yhat_upper']:.1f}]")
跑成 CronJob，检测结果推 Alertmanager 或 Webhook，比手写阈值规则准确率高 40%+（实测误报从每天 20+ 降到 3 以内）。
场景二：k8sgpt 接入 Bedrock 做根因分析
k8sgpt 会扫描集群里所有异常资源，调用 LLM 做解释和修复建议。
# 安装
brew install k8sgpt # 或 curl -sLo k8sgpt https://github.com/k8sgpt-ai/k8sgpt/releases/latest/download/k8sgpt_linux_amd64 && chmod +x k8sgpt
# 配置 AWS Bedrock 作为后端
k8sgpt auth add \
--backend amazonbedrock \
--model anthropic.claude-3-5-sonnet-20241022-v2:0 \
--region us-east-1
# 扫描集群异常
k8sgpt analyze --explain --backend amazonbedrock
输出示例：
0 default/pod/nginx-7d9f8b-xk2p9(nginx-7d9f8b-xk2p9)
- Error: Back-off restarting failed container
AI Analysis:
容器因 OOMKilled 重启。建议：1) 调整 resources.limits.memory（当前 128Mi 不足）；
2) 检查是否存在内存泄漏；3) 考虑 VPA 动态调整。
场景三：Robusta 告警智能分组 + 自动注入上下文
Robusta 在 Alertmanager 和工程师之间加了一层：告警触发时自动拉取相关指标截图、最近 Pod 日志、关联事件，打包推送到 Slack/钉钉。
# robusta-config.yaml
sinksConfig:
- slack_sink:
name: main_slack
slack_channel: "#alerts"
token: env:SLACK_TOKEN
customPlaybooks:
- triggers:
- on_prometheus_alert:
alert_name: KubePodCrashLooping
actions:
- logs_enricher: {} # 自动附加 Pod 日志
- pod_events_enricher: {} # 自动附加 K8s Events
- python_enricher: # 自定义：调用 k8sgpt 补充 AI 分析
action_name: "k8sgpt_enrich"
值班工程师收到告警时，上下文已经齐全，平均 MTTR 降低 50%。
避坑
1. 不要用 AIOps 替代告警规则，而是分层
异常检测适合 QPS、延迟、错误率这类连续型指标；磁盘满了、证书快过期这种确定性事件还是用规则，更可靠。
2. 训练数据要包含促销/发版等周期性事件
Prophet 默认只学日周期和周周期。如果有大促，一定要手动加 holidays，否则促销期间流量正常波动全报异常。
from prophet import Prophet
import pandas as pd
promotions = pd.DataFrame({
"holiday": "big_sale",
"ds": pd.to_datetime(["2026-10-01", "2026-11-11", "2026-12-12"]),
"lower_window": -1,
"upper_window": 1,
})
m = Prophet(holidays=promotions)
3. LLM 分析结果不可直接执行
k8sgpt 给出的修复命令要人工审核后再跑，绝对不能接 kubectl apply 的自动管道——LLM 幻觉在生产环境后果不可控。
4. 成本控制
每次告警都调 LLM 分析成本不低。建议只对 P1/P2 级告警开启，或先用本地模型（Ollama + llama3）做一次粗筛，再把置信度低的打给云端模型。
总结
AIOps 的价值不在于"AI 替代运维"，而在于把运维工程师从重复性的数据关联工作里解放出来。落地优先级建议：
- 先做告警降噪（Robusta/Prophet）→ 效果最直接，一周内见效
- 再做根因辅助（k8sgpt）→ 需要接入 LLM，成本可控
- 最后做自动修复→ 门槛最高，需要充分的测试和权限隔离
从一个点切入，跑通闭环，比全套上线空转更有价值。