业务是否受影响取决于应用延迟敏感度和重试机制；HTTP API通常容忍100ms内抖动，而实时音视频、高频交易或Redis主从同步在10ms抖动下就可能超时。
网络抖动到底多大才算影响业务
业务是否受影响，不取决于抖动绝对值，而取决于应用对延迟敏感度和重试机制。HTTP API 通常容忍 100ms 内抖动，而实时音视频、高频交易或 Redis 主从同步可能在 10ms 抖动下就出现超时或连接重置。
关键判断依据是：你的服务是否设置了 connect_timeout、read_timeout，以及下游依赖（如数据库、缓存）的超时阈值。例如，若用 curl 调用一个设了 --max-time 2 的接口，而网络抖动导致某次 RTT 突增至 2100ms，就会直接失败。
怎么用 ping 和 mtr 快速定位抖动来源
ping 只能看端到端，但抖动可能发生在中间某跳；mtr 是更有效的诊断工具，它结合了 traceroute 和持续 ping 的能力。
- 运行
mtr -r -c 100 -i 0.2 example.com（100 次探测，间隔 200ms），重点关注「Loss%」和「Avg」列突变的跳数 - 如果第 5 跳开始延迟骤增且方差大（
Jitter列明显高于前后跳），大概率是该节点出口拥塞或 QoS 限速 - 注意对比
mtr --tcp -P 6379 redis-host和普通 ICMP 结果——有些防火墙会优先丢弃 ICMP，而放行 TCP，此时必须用 TCP 模式测真实业务路径
业务日志里怎么识别抖动引发的异常
抖动本身不会直接报错，但会放大下游不稳定。常见线索包括：
