AIOps 根因定位相关性很多因果链只有一条AIOps 做告警降噪容易做根因定位难。因为系统里相关信号太多CPU 升高、错误率上升、延迟变大、队列堆积、下游超时。它们可能同时出现但不代表都是根因。根因定位最怕把“同时发生”当成“导致发生”。靠谱的 AIOps 根因定位需要拓扑、时序、变更和因果约束一起看。只靠大模型总结告警文本最多是写事故小作文。一、先建立服务拓扑图flowchart TD A[Web] -- B[API Gateway] B -- C[Order Service] C -- D[Payment Service] C -- E[Inventory Service] D -- F[Bank Adapter] E -- G[Redis] E -- H[Database]没有拓扑就不知道影响是从哪里扩散的。一个上游服务错误率上升可能是它自己坏了也可能是下游依赖慢了。拓扑能给定位方向加边界。二、时间顺序比指标相似更重要根因通常先于现象出现。比如数据库慢查询先升高然后库存服务延迟升高再到订单接口错误率上升。如果只看同一分钟的相关性很容易把订单服务误判为根因。SELECT service, metric, first_abnormal_at FROM anomaly_events WHERE incident_id inc-0703 ORDER BY first_abnormal_at ASC;时间顺序不能单独定案但它能排除很多不合理解释。后出现的现象不应该被轻易当成前面故障的根因。三、变更事件要进入定位链路线上事故很大比例和变更有关发布、配置、扩容、证书、限流规则、依赖升级。AIOps 如果不接入变更系统就会错过最强信号。evidence_sources: metrics: prometheus logs: loki traces: tempo topology: service_catalog changes: - deploy_event - config_change - feature_flag - autoscaling_event变更不是一定有罪但它必须被审问。尤其是故障窗口前后 30 分钟的变更要自动进入候选根因列表。四、输出要给证据链不要只给结论一个可用的根因定位结果应该长这样候选根因、证据、反证、影响范围、建议动作。只有一句“疑似 Redis 问题”基本等于没说。{ root_candidate: inventory redis latency spike, confidence: 0.78, evidence: [ Redis p99 latency first abnormal at 10:02, Inventory service timeout increased at 10:04, Order API error rate increased at 10:06 ], next_action: switch inventory cache to fallback cluster }证据链越清楚值班同学越敢执行动作。AIOps 的目标是缩短判断时间不是替人拍脑袋。五、总结AIOps 根因定位要从相关性走向因果链。服务拓扑给边界时间顺序给方向变更事件给强信号证据链给执行信心。大模型可以负责总结和解释但底层证据必须来自真实观测数据。相关性很多因果链通常只有一条别把热闹的告警列表当成根因。