从告警风暴到根因候选：AIOps 落地的四层技术拆解

一份行业调研里有组数字值得玩味：77% 的值班团队每天至少收到 10 条告警，但超过一半的组织认为其中真正可行动的不足三成。告警不是太少，而是太多、太碎、太缺上下文。本文沿着告警的生命周期，把 AI 在这个领域的能力拆成检测、收敛、诊断、处置四层，逐层讨论工程实现方式与已知边界。

一、告警为什么会失控

一次数据库故障，往往同时触发健康检查超时、连接池耗尽、依赖它的多个微服务报错、SLO burn rate 告警、负载均衡后端摘除——每条告警在技术上各自成立，但对值班的人而言，它们描述的是同一件事。

根源在于三处：

• 静态阈值与业务节律脱节。 CPU 超 80% 报警，在常规时段合理，在跑批窗口和发版后的抖动期就是持续的噪声。长期误报会系统性摧毁告警的信任度，最终演变成"看到就划走"。
• 去重解决不了关联。 字段哈希只能合并完全相同的告警，而压垮值班的是字段不同、根因相同的一串告警，它们来自不同系统、不同对象。
• 告警到达时不带上下文。 一条"支付服务 5xx 升高"，不包含近期变更记录、上下游依赖健康度、历史同类事故的处理经验。这些信息散落在指标、日志、链路、CMDB、工单系统里，排障时间大量消耗在找数据而非做判断上。

第一层：检测——动态基线工程

检测层的目标是回答"什么时候该报"。核心思路是用基于历史数据的动态基线替换固定阈值。

曲线自适应分类建模

不同形态的指标，最优算法不同。实践中可以先把指标按形态分为三类，再分别适配算法组合：

工程上还有两个关键点：

1. 无监督优先。 有监督模型需要持续标注和调优，运营成本极高；指标形态一旦变化，模型就过时。Nsigma（含一阶差分与不差分）、箱线图、EWMA、KDE、DBSCAN、孤立森林、LOF、OneClassSVM、同比/环比这一整套无监督体系，对形态变化更健壮。
2. 多算法投票。 建模阶段取过去约 14 天历史数据，用网格法搜索最优超参；检测时对每类曲线跑 2 种以上算法，按少数服从多数裁决，避免单一算法在特定形态上的系统性偏差。代价是计算量上升，需要评估采样频率与算法复杂度的平衡。

日志模板化

日志侧的动态机制是把日志拆成"常量"与"变量"：常量提取为事件模板，变量作为参数，完成非结构化文本到结构化数据的逆向解析。海量日志场景下，性能优化路径通常是：前缀树预过滤缩小搜索空间 → 倒排列表查找 → 循环查找 → 计算最长公共子序列（LCS）相似度取最高者。命中已有模式则更新参数边界，未命中则创建新模板加入全局模板库，实现模板库的动态演进。

这一层的边界很明确：动态基线只负责发现"偏离常态"，不解释为什么偏离。

第二层：收敛——五类降噪机制设计

收敛层回答"该看哪条"。仅靠字段去重远远不够，实践中需要五类机制配合：

同时做告警丰富：接入时通过插件清洗字段，联动 CMDB 补全对象的负责人、所属业务、位置等信息，让一条告警自带可派单的上下文。拓扑数据完备时，整体降噪达到 70% 以上是常见水平；没有 CMDB 支撑，依赖屏蔽退化为简单去重，压不到根因事件这一层。

降噪会不会把真故障一起降掉？依赖屏蔽与时间屏蔽都基于明确的关联关系和窗口配置，不是概率判断，风险可控。建议对核心监控项配置立即通知与无人响应时的循环通知兜底。

第三层：诊断——从现象到根因候选

这是"AI 到底有没有用"的分水岭，也是营销承诺与一线体验落差最大的地方。很多系统只在界面上加了大模型对话框，底层数据没打通，AI 只能做检索，做不了推断。诊断能力的前提是统一建模。

全栈观测对象对齐

• 为每个服务、实例分配唯一实体标识，指标关联到 ModelID + InstanceID，链路关联到 ServiceID + InstanceID；
• 把 CMDB 资源拓扑与 APM、eBPF 生成的调用拓扑按 IP、端口、MAC 等物理主键映射对齐；
• 通过时间戳把指标、调用、日志聚合到同一时间窗口；
• 最终映射为有向图：节点是系统组件，边是依赖或调用关系，边和节点上附加延迟、QPS、拓扑类型等属性。

没有这层对齐，AI 看到的是四堆互不相干的数据，所谓根因分析本质是在猜。

多智能体诊断架构

在此之上，可用多智能体（A2A）架构组织诊断流程：

流程走五步：接收故障对象并生成候选 → 多智能体并行调查 → 证据汇聚与交叉验证（时间对齐、传播方向验证、跨域一致性检查、反证）→ 证据不足时保守输出 Top-K 方向并标记缺失证据 → 证据充分时收敛输出。最终按分析结论、因果传播链、排障过程、处置建议四部分呈现。

能力可按三级演进：L1 用固定分析流程直接调观测数据；L2 引入领域模型提升效率；L3 引入 LLM 实现分析自动编排、数据解析与总结。

必须强调的边界：输出是"根因候选 + 证据链"，不是确定性判定。证据不足时明确标记缺失、保留人工介入，是设计上的取舍，也是判断一个系统是否诚实的信号。把 AI 结论当作可直接采信的唯一答案，是落地事故的重灾区。

第四层：处置与知识沉淀

诊断之后要闭环，否则 MTTR 不会真正下降。通用能力包括：

• 自愈处理：重启服务、清理日志、磁盘清理等场景按预置脚本自动执行，支持参数化，建议先跑通人工确认下的自动处置，再逐步放开权限；
• 流程对接：内置对接 ITSM 及第三方工单系统，支持按规则自动分派到人、组、值班人员；
• 多渠道通知：邮件、短信、企业 IM 机器人、值班大屏等；
• 知识库：运维经验向量化存储为私域语料，用于告警辅助分析与对话式排查——通用大模型解决不了特定系统特有的故障模式，经验必须能沉淀复用。私有化部署配合本地向量化可保证知识不出域，使用云端模型能力时需评估数据出域风险。

效果度量靠报表：有效告警总量、待响应/未关闭/已关闭数量，以及各人员的 MTTA、MTTR。

二、落地过程中的几个工程判断

1. 先建底座，再叠 AI。 统一建模、数据关联没做完之前，上任何 AI 都只是聊天机器人。
2. 算法必须能解释。 用的是什么算法、适配哪种曲线、建模周期多长、多算法如何裁决——答不上来或只说"自动学习"的，通常是阈值换了个名字。
3. 收敛优先于诊断。 告警量没压下来之前，诊断智能体处理的是噪声的平方。
4. 根因分析要有图谱。 没有 CMDB 与调用拓扑对齐的根因分析不可信。
5. 结论要按证据强度分级输出。 候选 + 证据 + 置信度，胜过每次一个看似确定的答案。
6. 小团队的价值首先是降门槛。 知识推荐、处置建议、对话式排查让经验不足的成员也能按路径推进，这比追求全自动更现实。

三、小结

AIOps 不是把大模型接进监控界面，而是一条完整的工程链路：动态基线解决"报什么"，五类降噪解决"看什么"，统一建模 + 多智能体解决"为什么"，工单自愈与知识沉淀解决"之后怎么办"。每一层都有明确的能力边界，接受"候选 + 证据链"而非"确定答案"，是这套体系能长期运转的前提。