AIOps 根因诊断：先建立证据链，再让模型给结论
一、AIOps 不是把告警丢给模型猜答案
AIOps 根因诊断的价值，不是让模型看几行日志后直接宣布“数据库慢了”，而是把指标、日志、Trace、发布记录和拓扑关系组织成可验证证据链。运维排障最怕流畅但无证据的结论。一个线上事故通常同时出现 CPU 升高、接口变慢、队列积压和告警风暴，真正的问题是这些信号谁是原因，谁是结果。
可靠的 AIOps 系统应先做数据归一化。指标要有服务、实例、集群、机房和时间窗口标签；日志要能关联 requestId 或 traceId；发布记录要能映射到服务版本；拓扑要知道调用依赖和基础设施位置。没有这些基础，模型只能做文字总结，无法支撑生产决策。
二、诊断链路：从异常窗口到根因候选
flowchart TD A[告警触发] --> B[确定异常时间窗口] B --> C[聚合指标与日志] C --> D[关联发布与拓扑] D --> E[AI 生成根因候选] E --> F[证据校验] F --> G[处置建议]AIOps 的核心环节是缩小搜索空间。先找异常开始时间，再看同一窗口内是否有发布、配置变更、流量突增、依赖故障或资源水位变化。模型适合把这些线索整理成排查顺序，但不能跳过证据验证。比如“缓存命中率下降导致数据库压力升高”必须同时看到缓存命中率下降、数据库 QPS 上升、接口延迟同步变化。
三、证据结构：根因候选必须带引用
下面是一个简化的根因候选结构。重点是每个结论都要能追溯证据。
from dataclasses import dataclass from typing import list @dataclass class Evidence: source: str metric: str value: str time_range: str @dataclass class RootCauseCandidate: summary: str confidence: float evidences: list[Evidence] def validate_candidate(candidate: RootCauseCandidate) -> None: if candidate.confidence < 0 or candidate.confidence > 1: raise ValueError("confidence must be between 0 and 1") if not candidate.evidences: raise ValueError("root cause candidate must include evidence")生产系统里，证据还要包含查询链接、日志样本和监控面板地址。排障人员看到候选结论后，应能一键打开上下文，而不是重新去各个平台搜索。AIOps 做得好，会让人少做重复检索；做得不好，只会多一个需要验证的聊天窗口。
四、落地边界：自动化建议不能直接替代处置审批
根因诊断和自动处置要分阶段建设。第一阶段只做只读分析，输出异常时间线、影响范围和根因候选；第二阶段接入工单或值班系统，让负责人确认建议；第三阶段才考虑低风险动作自动化，比如重启无状态副本、摘除异常实例、暂停非核心任务。高风险动作如切主、扩容数据库、回滚核心服务，必须有审批和回滚路径。
评估 AIOps 质量也不能只看“命中根因”。还要看平均定位时间是否下降、误报是否减少、建议是否可执行、证据是否完整、处置后指标是否恢复。很多系统演示时很漂亮，真正值班时却因为上下文不全而无法使用。运维场景里，信任来自一次次可复盘的正确判断。
数据质量是上限。指标缺标签、日志采样过度、Trace 丢失、发布时间不准，都会让模型判断失真。AIOps 不是替代可观测性建设，而是建立在可观测性之上的智能分析层。基础数据越干净，模型越像值班助手；基础数据越混乱，模型越像会说话的噪声放大器。
生产落地补充：从能跑到可维护
从生产落地角度看，这类方案不能只停留在主流程。更关键的是把输入校验、失败分支、资源上限和回滚路径提前写清楚。主流程通常容易在演示环境里跑通，真正暴露问题的是异常输入、依赖抖动、并发放大和权限边界。一篇技术方案如果没有解释这些约束，读者很难判断它能否放进真实系统。
评估时建议先定义三类指标：正确性指标、稳定性指标和成本指标。正确性指标回答结果是否可信，稳定性指标回答失败时是否可控，成本指标回答持续运行是否划算。三类指标要同时进入验收清单，不能只用平均耗时或单次成功率证明方案有效。
五、总结
AIOps 根因诊断应围绕证据链、时间线、拓扑关系和人工可验证结论展开。模型可以加速异常聚合和候选排序，但生产处置仍要依赖清晰证据、风险分级和可回滚流程。
