斯坦福CS146S：一次说清楚三者关系烂芒

SRE（Site Reliability Engineer，站点可靠性工程师）：专门负责保障线上系统稳定运行的工程师，出了故障第一个被呼机叫醒的那类人。

AIOps（AI + IT Operations）：用人工智能处理监控告警、定位故障根因的技术方向。简单说，就是让AI替代人工盯着系统跑。

AIOps能力及应用场景

AIOps应用场景演进策略

AIOps关联团队关系图

MTTR（Mean Time To Resolve，平均修复时间）：从发现故障到修复完毕的平均耗时，越短越好。

根因分析（RCA，Root Cause Analysis）：不只找"哪里坏了"，而是找"为什么坏"——是代码问题、数据库问题，还是上游服务拖垮了下游？

近些年根因分析相关研究

行业内各公司在根因分析上的实践和分享

告警疲劳：系统每天产生几万条告警，大部分是噪音，真正的故障信号被淹没，工程师久而久之开始麻木。

Trace链路（调用链路）：一次用户请求经过多个服务的完整路径记录，出了故障用来追溯"哪一段出了问题"。

一条结构线，先说清楚三者关系

谁在做决策？

人全程操作，AI只是工具 → AI辅助

AI处理子任务，人把控方向 → 多智能体协作

AI全程主导执行，人只设目标 → AI原生

这三者不是同一条升级路线上的三个站。它们是三种不同的系统架构，决定了不同的风险分布和利益格局。

第一层：AI辅助——工作流不变，人还是瓶颈

AI加速每一个单步动作，但工作流骨架原封不动。工程师出了故障还是要自己跳转监控平台、日志系统、部署记录，手动关联所有信号，最后做出判断。

认知负担，一分没少。

运维领域发展历程

行业产品AIOps能力分析

美团（Horae系统，来源：美团技术团队官方公开文章）

美团服务运维部从告警管理切入AIOps实践，开发了故障发现系统Horae，核心解决"告警风暴"问题——海量指标涌入时，系统自动过滤噪音、收敛告警，减少无效呼叫。时序数据分类准确率达到95%以上。

这是典型的AI辅助形态：AI嵌入了原有流程的若干节点，但工程师还在操作每一个后续环节。

2024年针对约4800名开发者的随机对照试验显示，Copilot用户每周合并请求数量增加约26%，经验较少的开发者收益更大。但另一项针对约800名开发者的观察性研究显示，PR合并量无明显提升，且Copilot用户的PR中bug密度上升了41%。

这个结论值得停下来想：如果AI加速了代码生成，而bug密度同步上升，那么谁来处理这些bug引发的生产故障？还是那些工程师。AI辅助在编码端的收益，可能正在运维端产生新的成本。

第二层：多智能体协作——拆开任务，专业智能体并行处理

这里需要先解释一个结构性问题：为什么一个AI处理不了所有事？

处理一次线上故障，需要同时分析数据库连接池（数据库处理请求的资源池，资源耗尽就像收费站只剩一个窗口）状态、上游服务响应时间、最近的代码部署记录、安全日志异常。这四件事要求截然不同的推理策略。

单个AI顺序处理：查完日志再查指标，再查部署记录。更危险的是，第一步方向判断错了，后面全部跟着走偏，没有其他路径纠偏。

多智能体的核心不是"更多AI"，而是并行假设测试：多个专业智能体同时从不同方向逼近根因，互不等待，互相校验。

小红书AIOps现状

故障定位整体方案

图4.3 核心场景调用拓扑生成