网络问题排查的思路和技巧

这一篇计划很久了还没有写，今天终于开始下笔了。

许久无从下笔的原因是，网络问题排查——哦不，应该说不光网络，基本所有的问题排查，都是这样——思路相比于技巧要重要很多。思路，简单来说就是几句话的事情：

• 依据事实猜测而不是全凭经验猜测；
• 验证测试，比如使用工具复现，或者实现一个最小化的 case；
• 提出 fix；
• 实施 fix；

核心就是一句话，「基于事实猜测」，如果实践起来，却不是那么容易。顺藤摸瓜的正确排查方法是需要大量的基础以及经验支撑的，并不是什么独门秘籍，可以让人瞬间开悟的东西。

但还是有一些规律可以遵循。

一般的问题定位，第一步是明确问题。很多人表达问题不清楚的，与这种人沟通很容易就陷入了 X Y 问题¹。所以无比问清楚：现在问题是什么，网络从哪里到哪里不通，预期的结果是什么。在非常复杂的网络环境下，需要收集必要的信息，比如有没有 overlay，有没有一些特殊的配置。可能问题的报告者也说不清，大部分情况需要自己收集信息。

第二步就是复现问题。如果问题没有办法复现，就很难解决。如果可以复现，基本就解决了 90% 了。我自己最怕的问题也是无法复现的问题，比如高流量的偶尔延迟高，复现的现象定义不明确，复现条件也不明确。有一些工具可以使用，比如 iperf，scapy，或者自己写一些程序²来复现。有人遇到问题直接去查有没有变更，去看监控，这就像无头苍蝇。从根本解决问题，第一步一定是复现，最后一步对应的，是确定之前复现的场景下问题已经解决了。当然了，如果是线上的故障，立即查找变更和监控是正确的，应该需要在不明确根因的情况下能够恢复故障的手段。

第三部就很简单了，根据现象，做合理的假设，测试，逐步排除错误的假设，剩下的就是正确的答案。

时间长了，每个人都会积累一些技巧。比如，在最近的上一篇博客中使用到的，找一个正常的机器，进行比较一下。积累也是一个比较重要的过程，我喜欢把有意思的 case 都记录下载，对我很有帮助。

我发现厉害的人（偶尔，我自己也是），在看相同的信息的时候可以得到更多的结论。比如看到同样一个网络问题，使用同样的工具查看，别人说是网络不通，高手通过 curl -v 看发现是网络可以连接，而服务器没有返回内容。就把问题进一步定位到了 7 层问题，可能是 LB，WAF，application 的问题，但不会是路由或者 TCP 的问题。再比如，看到同样一个 MTR，高手可以分析出来默认网关有没有问题，出机房有没有问题，是单设备的问题还是某一跳的问题。

这是一种很酷的能力：能够在有限的环境里面定位到根本问题。

又想起来一个例子，我们经常需要网工给我们配置路由，但是配置好了没有？我们无从得知，因为我们没有交换机的登录权限。遇到问题的时候，低手会直接去麻烦人家，问问这个路由配置好了没，人家说好了，也没有办法验证是不是真的好了。高手在麻烦人家之前必然会提供相应的证据，比如，使用 traceroute，目标为这个网段的任意一个 IP，能不能 ping 通并不重要，重要的是看网工配置的交换机有没有出现在 traceroute 里面。这样报告问题，无法甩锅，解决问题的速度也快。

就写到这里，有很多大道理讲，但是讲起来没有什么说服力。好在日常已经积累了很多问题排查的博客，写具体的例子还是比较有意思。读者可以关注一下我的这类文章。

对了，在 AI 时代，如今大部分问题 AI 如果有权限都可以排查出来了，我们人类排查问题的技能还有用吗？

当然是有的，排查问题，解决问题，再想怎么一劳永逸地解决问题，对最终的质量负责，还是需要人的。如果你把一个系统完全交给 AI，AI 来应对用户的问题和需求，这里面没有了人做 trade off，感觉过不久就会变成非常大的一坨屎吧。

不过这也是现在，说不定多段时间 AI 真的可以完全自主运行系统了。在那之前，我们还是好好享受技术带来的快乐和成就感吧。

1. https://zh.wikipedia.org/zh-sg/XY%E9%97%AE%E9%A2%98 ↩︎
2. 现在有了 AI，这样做已经非常方便了 ↩︎

---