网络抖动是个伪命题
"网络抖动"是工程师最常用的甩锅词。但 99% 的"抖动"都能被定位到具体的交换机、网卡、内核参数或应用代码。本文是一次 18 个月的"反甩锅"训练笔记。
我做过一件比较轴的事:用 18 个月时间,禁止团队在事故报告里用"网络抖动"这个词。每当有人写"网络抖动导致延迟升高",必须附上具体证据——哪个包、哪一跳、哪个时间点。结果:99% 的"抖动"都被定位到了具体原因。这件事让我相信,"网络抖动"在绝大多数场景下是个伪命题。
为什么"网络抖动"是甩锅词
"抖动"在工程师语境里常常意味着"我也不知道为什么,但希望它别再发生"。这种态度的问题在于:不定位真因,下次还会发生。我们的纪律是:每个"抖动"都要拆解成可观测的指标。
"网络抖动"是个抽象名词。具体的现象是:TCP 重传、ARP miss、NIC ring full、softirq 饥饿、conntrack 表满。把它们具体化,"抖动"就消失了。
排查工具箱
遇到"网络抖动",按这个顺序排查:
- tcpdump + wireshark:抓包看真实发生了什么。
- ss -i:看连接的 retrans、rtt、cwnd。
- nicstat / ethtool -S:看网卡的 drop、fifo、err。
- netstat -s:看协议栈各层计数。
- /proc/net/softnet_stat:看 softirq 是否丢包。
- conntrack -L:看连接跟踪表是否满。
- perf top:看 softirq、网络相关函数占比。
案例 1:原来不是网络,是 conntrack 表满
某次服务"网络抖动",表现为随机连接超时。tcpdump 看到包都正常发出,但回包进不来。最后定位到 nf_conntrack: table full, dropping packet。解决:
# 调大 conntrack 表
echo 1048576 > /proc/sys/net/netfilter/nf_conntrack_max
echo 60 > /proc/sys/net/netfilter/nf_conntrack_tcp_timeout_established
"网络抖动"的真相是:conntrack 表满后内核开始丢包。
案例 2:原来不是网络,是 NIC ring buffer 溢出
某次高 QPS 服务"网络抖动"。ethtool -S 看到 rx_fifo_errors 持续增长。原因:NIC ring buffer 太小,突发流量时溢出。解决:
ethtool -G eth0 rx 4096 tx 4096
"网络抖动"的真相是:网卡 ring buffer 满了,驱动层丢包。
案例 3:原来不是网络,是 ARP miss
某次跨机房"网络抖动"。抓包看到大量 ARP request。原因:ARP cache timeout 太短,跨机房 ARP 频繁过期。解决:调大 net.ipv4.neigh.default.gc_stale_time 与 ARP 永久条目。
案例 4:原来不是网络,是 softirq 饥饿
某次"网络抖动"出现在 K8s 节点上。排查发现某 CPU 100% softirq,其他 CPU 闲。原因:NIC IRQ 都绑在一个 CPU 上,RPS 没开。解决:开启 RPS + 调整 IRQ 亲和性。
案例 5:这次真的是网络
少数情况下,"网络抖动"真的是网络。我们的一个真实案例:跨机房延迟从 2ms 飙到 50ms,持续 10 秒。最后定位到运营商某条专线在某个时间点拥塞。证据:MTR 显示某一跳延迟飙升。这种"真的网络问题"反而是少数——大约 10%。
把"抖动"工程化
我们后来建了一套"网络健康度"看板,把"抖动"拆成 8 个指标:
- TCP 重传率
- NIC drop / fifo 错误
- softirq 丢包
- conntrack 表占用
- ARP cache 命中率
- 跨机房延迟 P99
- DNS 解析延迟
- 连接建立成功率
任何一个指标恶化都直接告警,附上具体值。从此"网络抖动"这个词不再出现在事故报告里——因为每次都能找到具体的指标。
反甩锅的文化价值
禁止"网络抖动"这个词,看起来是文字游戏,实质是文化。它要求工程师:
- 把抽象问题具体化。
- 把"运气问题"变成"工程问题"。
- 把"无法解决"变成"可以定位"。
18 个月后回看,团队的网络事故平均定位时间从 4 小时降到 30 分钟。这 30 分钟里,他们做了 18 个月前要 4 小时才能做的事——因为他们不再把"网络"当黑箱。
给团队的简短建议
- 把"网络抖动"列进禁用词。
- 每个网络问题都要有具体指标证据。
- 建立网络健康度看板,把抽象变具体。
- 把每次"抖动"的根因写进知识库。
"网络抖动"是个伪命题。99% 的"抖动"都有具体原因,剩下 1% 也能用工具定位。把这件事做成团队纪律,事故定位能力会质变。