别再被“关联性背锅”了：基于因果推断做根因定位，到底靠不靠谱？
兄弟们，今天咱说点狠的——运维圈最容易掉坑的概念：相关性 ≠ 因果性。
你在监控大盘上看到 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，只会猜出屎。
✘ 干预成本太高
你敢在生产上随便想实验参数？
大概率会被开除。
所以因果推断要落地，三个条件缺一不可：
- 观测数据足够丰富
- 系统依赖能表达
- 允许小规模实验（AB、压测）
七、到底比相关性更可靠吗？
我这么说吧：
相关性像问：你俩天天一起出现，是不是搞对象？
因果推断像问：你俩去办证了吗？是不是结婚了？
- 相关：只是观察
- 因果：是证明
所以根因定位不是“看起来像”，而是“证据链闭环”。
是不是比相关性更靠谱？
是。
但要能落地，还得看业务实际情况。
八、我对因果的态度：谨慎但支持
我接触过三类团队：
- 迷信因果 ——觉得它无所不能
- 拒绝因果 ——觉得玄乎
- 合理使用 ——把它当理性工具
我劝你做第三类。
它不是魔法，但：
- 帮你沉淀依赖结构
- 帮你做灰度决策
- 帮你强化 SLO 和容量治理
它让定位根因变得更稳、更有逻辑、也更有安全感。
九、最后一句话：别把锅甩错了
很多运维事故不是技术问题，而是：
- 决策基于错觉
- 认知基于相关
- 行动基于猜测
