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 根因定位要从相关性走向因果链。服务拓扑给边界，时间顺序给方向，变更事件给强信号，证据链给执行信心。

大模型可以负责总结和解释，但底层证据必须来自真实观测数据。相关性很多，因果链通常只有一条，别把热闹的告警列表当成根因。