分布式系统排查实战：从现象到根因的收缩法

1. 分布式系统排查，难的不是命令而是思路

分布式系统问题排查这件事，我从最早的单体应用运维一路做到现在管着几十个微服务、上百个实例的集群，最大的感受是：真正让人抓狂的从来不是你记不住某个命令，而是你根本不知道该从哪一层下手。一台机器上的问题，你 top、free、iostat 三板斧下去基本就有感觉了；但换成分布式系统，一个用户下单失败，可能牵扯到网关、鉴权、订单、库存、支付、消息队列、缓存、数据库七八个组件，中间还隔着网络、容器编排、服务发现，你能看到的现象只有一个"偶发超时"，剩下的全是黑盒。

这篇文章我想聊的就是这套实战思路——怎么从一个模糊的现象出发，一步步把问题范围收缩到某个具体的组件、某个具体的参数，最后定位到根因。同时我也会把几个容易踩坑但又特别高频的场景讲透，比如有线网络卡顿这类底层问题怎么排查，通过远程通道接入 Linux 服务器做现场诊断时有哪些讲究，以及在云计算环境下做分布式排查跟自建机房有哪些不一样的地方。适合已经有一定 Linux 和网络基础、正在负责线上系统稳定性的运维、后端和 SRE 同学看，也适合那些刚接手分布式项目、遇到问题就只会重启的开发者。

我得先说一句可能有点反直觉的话：分布式排查的核心能力不是"排"，而是"缩"。你要在最短时间内，用一个又一个证据把"可能是任何地方"变成"大概率是这里"。下面我从方法论开始，一层层往外铺。

2. 排查之前必须先建立的三张底图

很多同学一遇到报警就直奔服务器敲命令，敲了半天发现连这个服务部署在哪几台机器上都不清楚，这就属于典型的"没有底图就开船"。我个人的习惯是，任何一次正式排查之前，先在脑子里（或者纸上）把三张图调出来。

2.1 服务拓扑图：谁调用了谁

分布式系统的调用关系往往比我们记忆中的复杂得多。你以为订单服务只调库存，实际上它还异步发消息给积分、通知、风控，这些下游又各自回调。所以第一件事是把当前故障链路相关的调用拓扑画出来，标清楚同步调用和异步调用、强依赖和弱依赖。

我一般用两个办法快速还原拓扑：一是看链路追踪系统里的服务依赖图（如果你们接了的话），二是直接翻配置文件里的注册中心和下游地址列表。这里有个细节，静态配置里的依赖清单往往是过时的，真正准确的是运行时抓出来的调用关系。我踩过一次坑，按照老文档去查一个已经不存在的下游，白白浪费了半小时。

拓扑图的价值在于，当某个接口报超时时，你能立刻列出"这条链路上有哪几个可能的故障点"，而不是无头苍蝇一样去猜。

2.2 资源与指标图：正常长什么样

第二张图是基线。分布式排查里最容易被忽略的一点是：你得知道"正常"是什么样子。某个接口平时 P99 就是 800ms，那它跑到 900ms 根本不算异常；反过来，一个平时 5ms 的接口突然变成 50ms，哪怕绝对值很小也值得警惕。

所以我会提前把关键指标的正常区间记下来：各服务的 QPS、响应时间分布、线程池活跃数、连接池占用、GC 频率、内存水位、磁盘 IO 利用率。这些数据从监控系统里一拉就有，但关键在于你要能一眼看出哪个指标偏离了它的日常形态，而不是盯着一个孤立的数字发呆。

提示：别只看平均值。分布式系统的故障常常藏在尾延迟里，平均值被大量正常请求一平均就看不出来了。P95、P99、P999 才是你的主战场。

2.3 变更时间线：最近动了什么

第三张图其实是条时间线。我敢说线上百分之七八十的故障都和最近的某次变更有关——发版、扩缩容、配置调整、证书更新、网络策略变更、依赖升级。所以排查第一动作应该是问一句："最近两小时、这两天，系统动过什么？"

把变更记录和故障开始时间对齐，如果高度吻合，那基本方向就有了。哪怕不完全吻合，也能帮你排除掉一大批无关变量。我见过很多次，大家吭哧吭哧查了半天底层网络，最后发现是前一晚有人改了个连接池上限没走评审。

这三张图准备齐了，你才算真正站在了排查的起跑线上。

3. 从现象到定位：一套可复用的收缩法

有了底图，接下来就是系统性收缩。我把它总结成"四问法"，每一问都在把范围往小里逼。

3.1 第一问：影响面有多大

先别急着看技术细节，先看影响范围。是全量用户都受影响，还是只有某个地域、某个版本、某类设备？是持续性的还是脉冲式的？是所有接口都慢，还是只有某几个接口？

影响面的形状往往直接指向根因类型。举个例子：如果只有某个可用区的实例出问题，那大概率是那一侧的网络或宿主机故障；如果是集群里所有实例同时变慢，那更可能是共享依赖——数据库、缓存、注册中心出毛病了；如果是脉冲式的、每隔几分钟抖一下，那要重点怀疑定时任务、缓存刷新、GC 或者连接池的周期性行为。

这一步不需要任何高深工具，把监控大盘上的曲线形状看仔细就行，但恰恰是最多人跳过的一步。

3.2 第二问：是资源瓶颈还是逻辑问题

确定影响面之后，下一个岔路口是：这个慢，是资源不够，还是逻辑有问题？

区分方法很直接——看资源指标。如果故障期间 CPU 打满、内存溢出、磁盘 IO 饱和、带宽跑满，那就是资源瓶颈，方向是扩容或者优化资源使用。如果资源指标很平稳，CPU 才 20%、内存充足、网络也没满，但请求就是慢，那问题多半在逻辑层面：锁竞争、线程池排队、连接池不够、下游阻塞、序列化耗时、慢查询。

我遇到过最典型的一次是接口超时，所有机器资源都很闲，最后查出来是某个共享连接池的最大连接数配得太小，请求全堵在获取连接那一步。资源监控一点异常都没有，但瓶颈实实在在存在。

3.3 第三问：问题在链路的哪一跳

如果是逻辑问题，那就得靠链路追踪把一次请求拆成若干段，看每一段的耗时。一个请求从网关进来，经过鉴权、业务处理、查缓存、查数据库、调用下游、返回，每一跳都有耗时。你把这些耗时按顺序排开，哪一段突然变长，问题就在哪一段附近。

这里有个经验：不要只看最慢的那一跳，要看耗时增量的分布。有时候是某一跳从 2ms 涨到 500ms，很明显；但有时候是每一跳都均匀地多了 3ms，累加起来就超时了，这时候问题往往出在更底层——比如系统调用、网络往返、或者时间同步。

3.4 第四问：改一个变量能不能复现或缓解

前面三问如果还没定位，就到动手环节了。在可控范围内改一个变量——把某台机器摘掉、把某个下游切走、把某个配置调大、重启某个组件——然后看现象有没有变化。每次只改一个变量，这是铁律，否则你永远不知道是哪个改动起了作用。

如果摘掉某台机器后问题消失，说明问题集中在那台机器上；如果切走某个下游后响应恢复正常，那故障点就在那个下游；如果改什么都是老样子，那可能问题在更外层，或者是个复合故障。

这套四问法不依赖任何特定工具，但它能保证你的排查是收敛的，而不是发散乱撞。

4. 有线网络卡顿：最容易被甩锅也最该被认真对待的一类问题

只要系统变慢，第一个被怀疑的往往是网络。"是不是网络又卡了？"这句话我在无数个故障群里见过。但说实话，真正的网络层问题其实不多，多数是应用层把自己拖慢了。不过这不代表网络排查可以糊弄，恰恰相反，你得有本事用证据把网络排除掉，或者把网络问题坐实。

4.1 卡顿的几种典型形态先分清

"卡顿"这个词太笼统了，先给现象分类：

• 时延高但不大丢包：请求都很慢，但没有明显报错。这种多半是链路拥塞、路由绕行或者队列积压。
• 丢包引发重传：TCP 层不断重传，表现为毛刺、超时、连接不稳定。这通常是链路质量差、网卡或交换机端口有问题。
• 连接建立慢：新建连接特别慢，但连接建好后正常。这往往和 DNS 解析、握手过程、SYN 队列有关。
• 间歇性大面积不通：一会儿好一会儿坏。要怀疑链路抖动、双工模式不匹配、广播风暴。

分清楚是哪一种，排查方向完全不同。

4.2 我常用的排查顺序

拿到一台嫌疑机器，我会按这个顺序过一遍：

第一步，看网卡本身的状态。用ethtool看协商速率和双工模式。我踩过一个大坑，有台机器的网卡因为网线老化，速率从千兆降到了百兆，双工还协商成了半双工，结果一整批请求慢得离谱。这种问题在监控上几乎看不出来，只有看网卡状态才发现。

# 查看网卡协商速率、双工模式、链路状态 ethtool eth0 # 查看网卡收发包统计，重点看 errors、dropped、overruns ip -s link show eth0

第二步，看丢包和重传。用netstat -s或者ss -s看 TCP 重传、校验和错误等全局统计的增量。注意是增量，不是累计值——累计值大不代表现在有问题。

# 每隔一秒采样一次 TCP 相关统计 watch -n 1 'netstat -s | grep -iE "retrans|error|timeout"'

第三步，看实时连接状态。ss -ant能列出所有 TCP 连接状态。如果看到大量SYN-SENT，说明连接建不起来（对端不通或丢包）；大量CLOSE-WAIT说明应用没正确关闭连接；大量TIME-WAIT是正常现象但数量异常高时要关注端口耗尽。

第四步，用抓包坐实。前面几步都只是怀疑，tcpdump才是最终判决。抓一段流量，重点看有没有重传、有没有乱序、握手耗时多少。这一步稍微进阶，但一旦你掌握了，排查效率会有质的飞跃。

# 抓取指定端口上跟某个对端的交互，存文件后分析（不要直接打到终端刷屏） tcpdump -i eth0 -w /tmp/cap.pcap 'host 10.0.0.5 and port 8080'

注意：抓包文件可能很大，抓的时候一定加过滤条件，抓完及时清理。生产环境上长时间无过滤抓包，很容易把磁盘写满，反而制造新故障。

4.3 一个排查心得

网络问题最忌讳的是上来就怀疑网络。我的习惯是反过来：先假设网络是好的，用证据证明应用层有问题；只有当应用层排查到"卡在发送/接收这一步"时，才转向网络排查。这样能避免大量无效的抓包和瞎猜。

另外，同一机房内的服务调用尽量走内网地址，跨机房、跨区域调用要格外关注时延和带宽。很多"网络卡顿"的根因，其实是某个配置误把内网调用写成了公网地址，白白绕了一大圈。

5. 通过远程通道接入 Linux 做现场诊断的注意事项

很多线上服务器你不能直接物理接触，得通过跳板机或者统一的接入通道连过去排查。这个过程本身也是个技术活，弄不好会造成二次伤害。

5.1 接入前的准备

我不会一上去就敲命令，而是先想清楚要看什么。列个清单：要看进程状态、线程栈、内存分布、磁盘 IO、网络连接、最近日志。带着问题上去，效率比漫无目的地逛高一倍。

接入时有个基本原则：能用只读命令就别用写命令，能用采样就别用全量。线上环境的首要目标是别把正在挣扎的系统压垮。

# 看进程的资源占用，按 CPU 或内存排序 top -o %CPU # 采样一分钟的进程级 IO，比一次性快照更能看出趋势 pidstat -d 1 60 # 抓一份线程栈，连续抓几次可以看出哪段代码在卡 jstack <pid> > /tmp/stack1.txt

5.2 会话与操作留痕

正规的接入通道一般会有会话审计，你敲的每一条命令都会被记录。这不是为了监视你，而是故障复盘时能还原"当时到底做了什么"。我强烈建议你自己也养成留痕的习惯——把关键命令的输出重定向到临时文件，排查完再统一分析，同时记录自己每一步的假设和结论。

这样做的好处是：万一一次排查没定位，下次换班的人能接着你的思路走，而不是从头再来一遍。

5.3 常见踩坑点

• 别在高负载机器上跑全量扫描类命令。比如对整个大目录做grep、对整个磁盘做find，这些操作本身会吃掉大量 IO，让本来就很脆弱的系统雪上加霜。
• 注意权限边界。很多生产账号是受限的，你看到的进程信息、打开的连接可能不完整。如果发现关键信息缺失，先确认是不是权限问题，别急着下结论。
• 留意时区。跳板机、目标服务器、日志系统、监控系统如果时区不一致，对齐时间线时能把人逼疯。排查前先统一确认各处的时区设置。
• 断开连接前留个清白。临时文件该删的删，该改的配置改回去，别给下一班的人留坑。

6. 云计算环境下分布式排查的特殊性

云上跑分布式系统和自建机房有一个本质区别：你失去了一部分对底层资源的可见性和控制权。物理机时代，网络不通你可以去机房换根网线、看交换机指示灯；到了云上，很多东西变成了"黑盒"，排查方法也得跟着变。

6.1 那些云上特有的"玄学"问题

可用区之间的时延。同一地域不同可用区之间的网络时延虽然不高，但相比同机架内的机器还是有差距。如果你的服务对时延敏感，又恰好把相互依赖的组件部署在了不同可用区，那日常就能感受到抖动。排查时先确认各组件的部署分布。

共享资源的邻居效应。云主机底层可能存在资源争抢，你的实例资源监控看着正常，但实际性能就是上不去。这种情况比较隐蔽，通常表现为"莫名其妙的性能波动"，且和你的业务负载没有强相关。

弹性伸缩带来的实例漂移。云上经常做自动扩缩容，实例会不断新建、销毁。如果排查时你抓的 IP 或实例 ID 是几分钟前的，可能那个实例早就不存在了。所以云上排查要养成习惯：先拉一份当前的实例列表，再基于最新列表定位。

网络策略和安全组的隐藏限制。容器编排和云平台常常有额外的网络策略层，一个连接不通，可能是安全组没放行，也可能是网络策略拦了，还可能是服务网格在做流量劫持。排查时要按层确认，别只盯着防火墙。

6.2 云上排查的发力点

在云环境里，我更多依赖平台提供的可观测能力。日志服务、指标监控、链路追踪、事件中心这四样基本能覆盖大部分场景。尤其是"事件中心"这一类产品特别容易被忽略——扩容失败、健康检查异常、实例被驱逐这类事情，往往在那里有明确记录，比你自己一层层查起来快得多。

另外，镜像和启动脚本也是云上的高频故障点。一个实例老起不来、起来就挂，很多时候是启动脚本里的某个依赖没准备好，或者镜像里少了个关键配置。排查这类问题时，把实例的启动日志完整拉出来看，比在应用日志里大海捞针高效得多。

7. 典型故障案例与排查实录

光讲方法论有点干，我挑两个真实感比较强的案例，把上面的思路串一遍。

7.1 案例一：集群整体响应变慢，但资源都很闲

现象是某天下午开始，核心接口的 P99 从 200ms 涨到了 1.5 秒，影响面是全量的。看资源监控，CPU、内存、磁盘、网络全都很平稳。

按收缩法走：影响面是全量 → 排除单机故障，指向共享依赖。接着看链路追踪，发现耗时集中在"查缓存"这一跳。再看缓存集群的监控，发现它的 CPU 不高，但网络连接数和命令处理队列长度在缓慢上升。

顺着连接数这个线索查到应用侧，发现有个新上线的定时任务，会周期性创建大量短连接去访问缓存，连接关闭不及时，逐渐把连接池占住了。根因是一个没做好连接复用的任务。资源层面毫无异常，但共享的连接池被打爆了。

这个案例的教训是："资源闲"不等于"没瓶颈"，共享的连接、队列、锁都可能是隐性瓶颈。

7.2 案例二：间歇性的接口毛刺

某个服务每隔十几分钟抖一下，毛刺持续一两秒，其他时候完全正常。这种问题最难查，因为它不可复现。

我先把时间线拉出来，发现毛刺的间隔和某个日志切割、缓存批量刷新的周期很接近。继续深挖，确定是缓存预热任务在批量回源，瞬间打满下游数据库的连接。数据库连接被占住的那一两秒，其他请求全卡住了。

解决方式其实很简单，把批量预热改成小批量、限速地慢慢灌进去。但找到根因花了大半天，因为它藏在"周期性行为"里，静态看指标根本看不出来。

这个案例的心得是：面对脉冲式、间歇性的问题，一定要去对齐"周期性行为"的时间线——定时任务、日志轮转、缓存刷新、批量同步、GC 周期，列出来挨个排除。

8. 常见问题速查与避坑清单

最后整理一份我平时用得最多的速查表，排查时对着过一遍，能省不少来回。

再补几条我个人踩出来的经验，都是常规文档里不太会写的：

第一，排查过程中随手记录。写下你的每个假设、验证结果、下一步计划。人在高压下特别容易绕圈，记录能帮你保持清醒，也方便交接。

第二，改配置之前先想好怎么回滚。哪怕只是调大一个参数，也要记住原值。我见过因为改配置没记录，最后连回滚都不知道回滚到哪的。

第三，分清楚"临时缓解"和"彻底修复"。重启、摘节点、切流量都是缓解手段，能帮你争取时间，但一定要在恢复后找到根因，否则同样的问题还会准时上门。

第四，别迷信"重启大法"。重启能让现场消失，但它也把唯一的证据销毁了。能在重启前抓的信息尽量抓，尤其是线程栈、连接状态、临时文件这类重启就没了的东西。

说到底，分布式系统排查这件事，工具和命令只是表层，真正拉开差距的是你有没有一套稳定的、收敛的思路，以及你在压力下能不能保持冷静、有条理地一步步验证。这套东西没有捷径，都是在一次次真实故障里磨出来的。多复盘、多记录、把每次故障都变成一次认知升级，几次之后你会发现，那些曾经让你手足无措的"玄学问题"，其实都有它清晰的因果链。