用根因分析本体构建自治 AIOps 平台
为什么大多数 AIOps 停在「告警根因展示」，而走不到「自动闭环」。本文拆解本体建模这一步的关键取舍。
智能运维的难点从来不卡在「检测出异常」——时序异常检测、日志异常检测这些算法早就成熟了。 真正卡住落地的，是从告警走到处置的那一段：告警告诉你哪里坏了，但没告诉你该做什么。
问题的本质是语义缺失
传统 AIOps 平台的根因分析，本质上在做指标空间的关联：
- 链路 A 的时序异常
- 设备 B 的日志出现新错误码
- 配置中心 C 在 14:03 被修改
把这些关联起来，输出一个「根因」列表。但这本质上是相关性，不是因果性。 它不知道「配置被改」和「链路异常」之间，存在一条业务上真实存在的依赖关系。
相关性告诉你「它们一起发生了」，因果性才能告诉你「先动哪个能止血」。
本体建模解决的就是这层语义
我的做法是把运维领域的知识显式建模成一张本体图：
class FaultEvent:
"""一次故障事件"""
occurred_at: datetime
symptom: Symptom # 症状层：用户/业务看到的表现
impact_scope: set[Entity] # 影响面
class RootCause:
"""根因假设"""
entity: Entity # 实体层：设备、配置、版本
mechanism: Mechanism # 机制层：为什么会导致该症状
confidence: float
evidence: list[Evidence] # 证据链关键在于三层解耦：症状 → 实体 → 机制。 大模型在这一层的作用不是「替代算法」，而是把非结构化的运维上下文（日志、变更记录、工单） 映射到本体中的实体上，这是规则和传统算法都做不到的。
关键取舍
| 方案 | 覆盖率 | 可解释性 | 建设成本 |
|---|---|---|---|
| 纯规则 | 低 | 高 | 高 |
| 纯大模型 | 高 | 低 | 中 |
| 本体 + 大模型 | 中高 | 高 | 高 |
结论是：本体建设的前期投入很重，但没有捷径。 一旦本体立起来，后面接多大的模型、换多快的推理，成本都是线性的； 反过来，本体没立就直接上大模型，得到的只是一个「说得通但不敢用」的回答。
自治的最后一公里
有了本体和根因假设，自治闭环才成为可能：
- 症状检测（算法）
- 本体映射（大模型）
- 根因排序（算法 + 知识）
- 处置建议生成（大模型 + 模板约束）
- 执行与验证（受控动作，带回滚）
第 5 步是分水岭。没有回滚机制，前面四步做得再好都不敢放开自动执行。