别再被“关联性背锅”了：基于因果推断做根因定位，到底靠不靠谱？

兄弟们，今天咱说点狠的——运维圈最容易掉坑的概念：相关性 ≠ 因果性。
你在监控大盘上看到 CPU 飙升的时候磁盘 I/O 也抖了，你第一反应是什么？

“这俩有关系！CPU 拉高肯定导致 I/O 抖动！”

但很可能真相是：

• CPU 和 I/O 都被 upstream 的一个垃圾 SQL 干废了
• 你却把脏锅甩给了 CPU
• 最后业务老板一通电话骂运维：“怎么 CPU 又炸了你不扩容？！”

这就是相关性害人。
今天我们换一个视角——基于因果推断（Causal Inference）的根因定位。

先说结论：
因果推断不是银弹，但比纯相关分析更靠谱，也更接近真实世界。
尤其是 AIOps、分布式链路、SLO 体系下，它简直就是心理按摩神器。

一、为什么“相关”是个坑？

因为相关性太廉价了。

随便举例：

气温越高，冰淇淋销量越大
溺水死亡人数也越高

这俩指标相关度接近 0.9，你能说：

“冰淇淋导致溺水”吗？

要这么拍脑袋，得送你去参加奇葩说。

运维圈也一样：

• Latency 高的时候 QPS 也升
• A 服务抖时 B 服务也炸
• 垃圾回收一触发，响应时间飞天

这些都叫现象伴随
并不是因果链路。

所以光靠 Pearson correlation、Spearman、互信息这些统计相关性工具做根因定位，和占卜半斤八两。

二、什么叫因果推断？

简单一句话：

因果推断关心的是干预后的结果，而不是观察到的共付现象。

Pearl 的因果三层结构是：

• 关联层（ Association）：变量之间“看上去相关”
• 干预层（ Intervention）：如果我动它，结果会变吗？
• 反事实层（ Counterfactual）：如果当时不动它，会怎样？

真正运维要解决的恰恰是第二层：

哪个变量值得干预？

例如：

• CPU 并不导致延迟，是延迟触发了线程堆积、CPU 才升
• 内存飙升只是结果，真正原因是内存泄漏
• 下游爆了，导致你上游的重试堆积

这不是一句 correlation 能解释的。

三、用代码演示：相关欺骗 vs 因果识别

假设我们模拟一个运维故障：

• 是 数据库超时 导致 服务延迟
• 延迟升导致 CPU 升
• 所以 CPU 与延迟高度相关，却不是因

我们造个数据：

import numpy as np
import pandas as pd
from sklearn.linear_model import LinearRegression

np.random.seed(42)

db_timeout = np.random.binomial(1, 0.3, 1000)  # 根因
latency = db_timeout * 50 + np.random.normal(5, 2, 1000)
cpu = latency * 0.3 + np.random.normal(2, 1, 1000)

df = pd.DataFrame({"timeout": db_timeout, "latency": latency, "cpu": cpu})
print(df.corr())

你会看到：

• latency 与 cpu 相关性极高（>0.9）
• timeout 与 cpu 低一些

但真正原因是 timeout，不是 latency。

如果只看相关性，我们会怪 latency。
这就是典型的运维误判。

四、因果推断怎么玩？

① 用 DAG 表达依赖关系

比如：

DB Timeout --> Latency --> CPU

这类图可以用 networkx 或 causal-learn 构建。

② 用干预检验（do-calculus）

如果我强行拉高 CPU，延迟会变吗？不会。
但我触发 DB timeout，延迟瞬间飙。

这才叫因果影响力。

很多自动根因定位系统（阿里、京东、微软）都玩这个。

③ 用打分做引用

评分指标通常包括：

• 吸收力（descendant effect）
• 出口阻塞（bottleneck effect）
• 干预敏感度
• 影响传播路径

一句话：
谁的动能最大，谁就是元凶。

五、回到实战场景：APM 中因果定位怎么落地？

✔ 分布式追踪是地图

你得知道：

• 谁调用谁
• 谁阻塞谁
• 谁扇区传播

OpenTelemetry、Jaeger 就是因果网络的观察器。

✔ 指标依赖树是植发梳子

比如 SLI：

Latency = Queue Delay + Service Time
Queue Delay = concurrency/worker
Service Time = DB IO + CPU cost

你知道各个节点之间的公式，这叫结构方程模型。
它能告诉你：

latency 的增长到底来自哪个组件的贡献？

这比相关性强多了。

✔ 故障复盘靠反事实分析

反事实就是：

“如果当时我限制一下重试，会不会没爆？”

这对容量规划、熔断策略极其重要。

六、说点实话：因果推断不是万能药

我给你几点大实话：

✘ 没有足够观测数据，因果推断是白搭

垃圾数据只能算命，不是推断。

✘ 没有结构知识，你推不出 DAG

全靠 AI 猜 DAG，只会猜出屎。

✘ 干预成本太高

你敢在生产上随便想实验参数？
大概率会被开除。

所以因果推断要落地，三个条件缺一不可：

1. 观测数据足够丰富
2. 系统依赖能表达
3. 允许小规模实验（AB、压测）

七、到底比相关性更可靠吗？

我这么说吧：
相关性像问：你俩天天一起出现，是不是搞对象？
因果推断像问：你俩去办证了吗？是不是结婚了？

• 相关：只是观察
• 因果：是证明

所以根因定位不是“看起来像”，而是“证据链闭环”。

是不是比相关性更靠谱？
是。
但要能落地，还得看业务实际情况。

八、我对因果的态度：谨慎但支持

我接触过三类团队：

1. 迷信因果 ——觉得它无所不能
2. 拒绝因果 ——觉得玄乎
3. 合理使用 ——把它当理性工具

我劝你做第三类。

它不是魔法，但：

• 帮你沉淀依赖结构
• 帮你做灰度决策
• 帮你强化 SLO 和容量治理

它让定位根因变得更稳、更有逻辑、也更有安全感。

九、最后一句话：别把锅甩错了

很多运维事故不是技术问题，而是：

• 决策基于错觉
• 认知基于相关
• 行动基于猜测