线上偶发 5xx 且无发布关联，如何区分是 GC、Pod 抢占还是网络抖动？

【背景】 我们是一套 K8s 集群（ACK，1.27）+ Java 17 + Spring Boot 3 的服务，约 12 个副本，P99 目标 < 300ms，监控走 Prometheus + Grafana，链路用 SkyWalking。最近两个月陆续出现 5xx 尖刺：每次持续 20s–90s，QPS 不高（峰值 200 左右），事后看发布记录都跟故障时段错开 ≥ 30 分钟，所以基本排除"发版引入"。

【现象】

• 5xx 主要分布在 502/504，少量 500；
• 故障窗口内 GC 日志能看到 1–2 次 Full GC（每次 800ms–2s，G1）；
• K8s 事件里有零星 Evicted / Preempted，但时间并不完全重合；
• 同机房跨 AZ 的 p99 RT 在故障窗口内普遍抬升 40%–120%，但没有丢包告警；
• 客户端侧的 trace 显示 30% 的失败请求卡在"出口网关→服务"这一段，其余在"服务→下游 DB"。

【已尝试的排查】

1. 把 G1 换成 ZGC 灰度 20%，Full GC 次数降了但 5xx 没明显下降；
2. 给 pod 加了 requests/limits 收紧（CPU 500m→250m、Mem 512m→384m），驱逐事件减少，5xx 仍然有；
3. 在 Ingress 层加了 p99 告警 + 按 AZ 拆分 dashboard，能定位到"哪个 AZ 更糟"，但没法直接归因；
4. 拉了 4 周的 GC 日志做脚本统计，Full GC 与 5xx 的时间重合率只有 ~40%。

【期望得到的答案形态】

• 有没有一套可复现的判定顺序/清单，能在事后 30 分钟内把「GC 主导 / 抢占主导 / 网络抖动主导」三选一锁定？最好带具体要拉的 metric（PromQL 或日志字段）和阈值；
• 如果你们也在做类似归因，你们的「信号优先级」是怎么排的？哪些指标你们踩过坑、发现其实没用？
• 针对"跨 AZ RT 抬升但无丢包"这种情况，社区里有没有验证过的网络层探针方案（eBPF / 内核计数器 / 业务侧拨测）？

欢迎按"你的环境 + 你用的判定方法 + 一个真实案例"的形式回答，越具体越好，避免纯概念。