建立排查的坐标系：时间维度、空间维度、依赖维度

做故障排查这么多年，我最大的体会是什么？

很多人遇到问题就慌了。东看看日志，西查查配置，像无头苍蝇一样乱撞。结果呢？折腾半天，问题还在那。

为什么会这样？说白了，就是脑子里没有一张「地图」。

我习惯把排查问题比作「定位」。你想想看，要在地球上找一个点，需要什么？经度、纬度、海拔。三个坐标一确定，位置就锁死了。

故障排查也一样。我们需要建立自己的三维坐标系：时间维度、空间维度、依赖维度。

1. 时间维度：什么时候开始的？

时间维度，是排查问题的第一把钥匙。

我记得有一次线上告警，服务响应变慢。团队里的小伙子直接去看代码，看了两小时没看出名堂。我问他：「你看了最近一次的发布记录吗？」他愣住了。

这就是典型的「丢了时间轴」。

时间维度要关注三个关键点：

• 首次出现时间：问题是什么时候第一次出现的？精确到秒。
• 持续时长：是瞬时的，还是持续性的？
• 变化趋势：是越来越严重，还是时好时坏？

我一般会先问自己三个问题：

1. 这个问题是今天才有的，还是昨天就有了？
2. 最近有没有做过变更？发布、配置修改、扩容缩容？
3. 有没有周期性规律？比如每天下午三点准时出问题？

2. 空间维度：发生在哪里？

空间维度，说白了就是「问题在哪个节点上」。

一个请求从客户端发出，经过负载均衡、网关、多个微服务、缓存、数据库……链条很长。问题可能发生在任何一个环节。

空间维度要拆解成三个层次：

• 物理空间：哪台机器？哪个机房？哪个区域？
• 逻辑空间：哪个服务？哪个接口？哪个模块？
• 代码空间：哪个类？哪个方法？哪一行代码？

我曾经遇到过一个诡异的问题：同一个接口，A机器正常，B机器报错。查了半天，发现B机器的JDK版本和A机器不一样。这就是典型的「空间维度」没对齐。

3. 依赖维度：跟谁有关系？

依赖维度，是很多人容易忽略的。

现在的系统，没有一个是孤岛。你的服务依赖数据库、缓存、消息队列、第三方API……任何一个依赖出问题，都可能让你背锅。

依赖维度要梳理清楚：

• 强依赖 vs 弱依赖：哪些依赖挂了，你的服务就挂了？哪些可以降级？
• 内部依赖 vs 外部依赖：是公司内部的服务，还是第三方的？
• 同步依赖 vs 异步依赖：是实时调用的，还是消息队列异步的？

我记得有一次，用户反馈下单失败。我查了自己的服务，日志一切正常。后来发现是支付网关的超时时间设置得太短，导致偶发失败。这就是典型的「依赖维度」问题——问题不在你，但在你的依赖链上。

4. 如何用三维坐标定位问题？

好了，三个维度都讲完了。怎么用？

我总结了一个「三步定位法」：

1. 第一步：锁定时间窗口。先看监控，确定问题开始的时间点。看看那个时间点附近有没有变更。
2. 第二步：缩小空间范围。从全局到局部，一层层缩小。是全部用户都出问题，还是只有一部分？是所有接口都慢，还是某一个？
3. 第三步：排查依赖链。沿着调用链，检查每一个依赖的健康状态。看看有没有超时、报错、限流。

这三步走完，90%的问题都能定位到根因。

下面这张图，是我自己画的三维坐标系。每次排查问题，我都会在脑子里过一遍这张图。

5. 实战案例：一个真实的三维定位

讲个真实的案例吧。

有一次，用户反馈「订单列表加载慢」。我按照三维坐标系来排查：

• 时间维度：监控显示，从昨天下午3点开始，接口响应时间从50ms飙升到2s。那个时间点，刚好有一个新版本发布。
• 空间维度：不是所有用户都慢，只有「查看历史订单」这个接口慢。其他接口正常。说明问题在订单查询这个模块。
• 依赖维度：订单查询依赖订单数据库和缓存。检查发现，缓存命中率从95%降到了30%。

三个维度一交叉，问题就清楚了：新版本改动了缓存key的生成逻辑，导致缓存大量失效，请求都打到了数据库上。

修复方案很简单：回滚缓存key的改动。整个过程，从接到告警到定位根因，用了不到15分钟。

6. 总结一下

时间维度告诉你「什么时候开始的」，空间维度告诉你「发生在哪里」，依赖维度告诉你「跟谁有关系」。

三个维度一交叉，问题的位置就锁死了。

嗯，这就是排查问题的基本功。下一节，我们会深入讲每个维度的具体排查技巧。但今天这个坐标系，我希望你能先刻在脑子里。

可可精品资料库