线上偶发 P99 抖动，你第一反应是抓包还是翻应用日志？

【背景】 做了三年网络侧，最近几次帮后端同事排障，发现一个反复出现的分歧：同一个接口 P99 从 50ms 抖到 800ms，应用团队默认"先翻日志、看 GC、看线程池"，网络团队默认"先 tcpdump、看重传、看 RTT"。两边都觉得自己先动一步更合理，但实际定位到根因时，经常是"其实另一头先看到线索"。

【常见分歧 / 几种做法】 我总结下来社区里大致有四种流派：

1. 应用优先派：trace 链路 + 应用日志 + GC log 先看，网络是"排除法最后一步"。理由：绝大多数慢是代码 / 配置 / 资源问题，网络抖动是小概率。
2. 网络优先派：先看 TCP 重传率、RTT 分布、SYN 丢包率，确认链路干净再怀疑应用。理由：网络问题最隐蔽，日志里往往只看到"等 socket 返回"，看不到为什么。
3. 并行双轨派：应用侧和网络侧同时开抓，事后对齐时间戳。理由：偶发问题窗口极短（几百 ms），串行排查容易错过现场。
4. 指标先行派：不急着抓包也不急着翻日志，先看 Prometheus / Zabbix 里的 RTT、重传、连接数、CPU steal 等趋势图，确认"抖动"到底是真网络问题还是统计假象（比如长尾被采样稀释）。

【我的倾向与理由】 我个人偏向 4 → 2 的顺序：

• 第一步永远看指标趋势图。我见过至少两次"抖动"其实是监控采样窗口把一次 2s 的慢查询摊到 1min 窗口里造成的 P99 毛刺，根本不是网络问题。先确认"抖动"是真实的、可复现的，再花抓包的时间。
• 第二步，如果指标确认有 RTT 尖刺或重传突增，我直接 tcpdump + ss -ti 看连接级重传，同时让应用侧把 trace 里对应时间窗口的 span 导出来。两边时间戳对齐后，基本 10 分钟内能分清是"包丢了"还是"应用没发 / 没收"。
• 我坚持网络优先的第二步，是因为 TCP 重传是客观证据——它不依赖应用框架的日志级别、不依赖 trace 采样率、不依赖 GC 日志是否开启。应用侧的"慢"可能是结果，网络侧的"重传"更可能是原因（当然也可能是结果，比如对端 buffer 满导致 RST，这时反过来又是应用问题）。

但我也承认，纯网络侧有个盲区：应用层超时 ≠ 网络超时。比如 HikariCP 等连接 3s 超时，日志里记的是 SQLTransientConnectionException，但根因可能是数据库端连接池耗尽，跟网络完全无关。这种 case 网络抓包抓了个寂寞。

【想听大家聊聊】

1. 你们团队排障时的"第一动作"是什么？有没有因为先看了错误的一边，浪费 30 分钟以上的真实案例？
2. 偶发 P99 抖动，你们一般怎么定义"偶发"？是 1% 的请求慢 10 倍，还是 0.1% 的请求慢 100 倍？这个定义直接影响采样策略——全量抓包不现实，1% 采样又可能恰好漏掉。
3. 有没有人做过"网络侧 + 应用侧"的统一时间线工具？比如把 tcpdump 事件和 trace span 画在同一个时间轴上，而不是各看各的 log 文件。
4. 一个偏实践的问题：你们生产环境 tcpdump 是常驻抓包（环形 buffer），还是出问题后手动开？常驻抓包对磁盘 I/O 和 CPU 的影响你们怎么评估的？

欢迎贴你们团队的排障 SOP 或者踩坑记录，我比较想收集"第一动作选错了"的案例，比教科书式的流程讨论有用得多。