P99 抖动时"网络侧还是应用侧背锅"：你们有没有一套可复现的客观归因流程？

背景

做了 8 年网络工程，我最高频出现的场景不是"链路断了"，而是这种：应用侧同学说"接口 P99 抖了"，我抓包看 TCP 层一切正常，对方说"我们慢"，我说"网络没问题"——然后两边扯皮，复盘时谁也没法定责。 社区里 #90 聊过"网络从基础设施变成故障放大器"，但大家更多讨论的是"观测做到哪一层"，而"观测数据怎么落成一次客观的归因判定"这条链，我觉得被绕过去了。

常见的几种做法（我观察到的分歧）

• 做法 A（看指标拍脑袋）：拉一下网卡丢包率、ping 一下、带宽没跑满，就说"网络没问题"。问题在于——这些指标全绿时，照样可能是 TCP RTO 退避、rx_ring 溢出、bufferbloat 排队延迟（#584、#761、#523 都讲过），应用侧 P99 照样抖。
• 做法 B（全抓包）：出问题就 tcpdump 抓一大段再慢慢看。问题是抖动是间歇的，抓包窗口经常没覆盖到，而且抓包本身可能改变时序（观测者效应）。
• 做法 C（各看各的）：应用侧看 GC、连接池、下游 RTT；网络侧看链路、队列、重传。两边数据都对，但没人把它们对齐到同一个时间轴上比。

我的倾向与理由

我倾向把"归因"当成一个可复现的流程，而不是一次性的排查动作，核心是三件事：

1. 统一时间轴：抖动那一刻，把应用侧（GC 暂停、连接池等待、下游 RTT）和网络侧（重传、RTO、rx_missed、队列深度 RTT 漂移）打在同一时间戳上对齐。抖动是毫秒级的，错位 1 秒都对不上。
2. 先排除"网络侧自证清白"的硬判据：ss -ti 看 retrans/rto、ethtool -S 看 rx_missed_errors、sar -n DEV 看丢包、tc -s qdisc 看队列排队时间——这几个能给出"网络侧此刻有没有异常"的客观证据，而不是 ping。
3. 留一份可复现的采集脚本，抖动时一键跑，输出对齐好的时间轴，让"谁背锅"变成看数据而不是吵架。

想听大家聊聊

• 你们团队真有一套这样的归因流程吗？还是每次都是现场发挥？
• 在你们的环境里，"网络侧自证清白"最靠谱的一两个指标是哪些？
• 跨机房 / 公网专线 / 云内 VPC 三种场景，你们的判据和工具链有什么差别？
• 你们有没有遇到过"网络侧指标全绿、但应用侧 P99 确实抖"、最后查出根因在别处的案例？是怎么定责的？

欢迎贴你们可复现的采集命令、脚本、判据，越具体越好。