1. 现象：业务慢，但传统告警并不红
周五晚高峰，华东区多家门店反馈收银页面打开慢、会员查询卡顿。监控大盘上没有明显断网告警，出口带宽也没有打满，链路丢包率在1%以内。值班群里的第一反应是“业务端是不是卡了”，但同一时间应用服务器指标基本正常。
这类问题的难点在于：用户体感很差，但常规红线指标不一定触发。
2. 第一轮排查为什么会卡住
第一轮排查我们按常见顺序做了三件事：
-
看带宽利用率
-
看链路丢包率
-
看网关CPU和内存
这三项都没有异常峰值，导致排查一度停在“现象存在、证据不足”的状态。事后看，这一步的问题是把“网络质量”简化成了“是否丢包”，忽略了延迟抖动和重传的组合影响。
当班后来补了三条命令，才把“慢但不断”的证据拉出来，下面这组可直接复用：
# 1) 看链路路径与每跳抖动
mtr -rwzc 100 core-api.example.com
# 2) 看DNS解析耗时与应答来源
dig core-api.example.com @127.0.0.1 +stats
dig core-api.example.com @223.5.5.5 +stats
# 3) 看TCP重传概况（Linux）
ss -s
netstat -s | grep -i retrans
我们当时的判断标准很简单：如果丢包低但 mtr 的后几跳抖动明显抬升，同时 dig 本地DNS慢于公共DNS，就优先排查出口路径和DNS转发链路。
3. 关键证据：RTT抖动和TCP重传同时抬升
第二轮我们把采样粒度从5分钟拉到30秒，并按门店分组抓取三类数据：
-
到总部核心服务的RTT P95
-
TCP重传率
-
DNS解析耗时
结果很快出现：问题时段内，RTT P95从40ms上升到220ms，TCP重传率从0.3%升到3.8%，DNS解析耗时在部分门店达到400ms以上。虽然丢包仍不高，但“高抖动+重传+慢解析”已经足够把页面响应拖慢。
为了让团队后续不用手工翻图，我们把这三项做成了固定查询（Prometheus示例）：
# RTT P95（按门店）
histogram_quantile(0.95,
sum by (le, store_id) (
rate(probe_http_duration_seconds_bucket{job="store_probe"}[5m])
)
)
# TCP重传率（按门店主机）
sum by (store_id) (rate(node_netstat_Tcp_RetransSegs[5m]))
/
sum by (store_id) (rate(node_netstat_Tcp_OutSegs[5m]))
# DNS查询P95（按门店）
histogram_quantile(0.95,
sum by (le, store_id) (
rate(dns_request_duration_seconds_bucket{job="store_dns"}[5m])
)
)
4. 定位根因：策略路由和DNS路径叠加
继续对比正常门店和异常门店后，发现两点差异：
-
异常门店流量被策略路由到跨区出口
-
异常门店优先使用了跨区DNS转发链路
晚高峰时跨区链路负载波动，导致RTT抖动扩大；DNS解析路径变长又增加首包等待时间。两者叠加后，业务就出现“能用但明显慢”的状态。
5. 修复动作：先止血，再做结构修复
我们把修复拆成两层：
短期止血：
-
将受影响门店切回本地优先出口
-
强制DNS优先本地递归
-
对关键域名启用短时缓存策略
结构修复：
-
调整策略路由匹配条件，避免误入跨区路径
-
为跨区链路单独设置延迟抖动告警
-
将DNS解析时延纳入门店巡检项
修复后次日同时间段复测，RTT P95回落到60ms以内，重传率回到0.6%以下。
下面给两段当时用的“可替换模板”，不同设备厂商语法会有差异，但思路一致。
策略路由示例（伪配置）：
# 业务网段优先本地出口，跨区链路仅做备选
policy-route 100
match source 10.21.0.0/16
match destination 0.0.0.0/0
set next-hop LOCAL_WAN priority 10
set backup-next-hop CROSS_REGION_WAN priority 100
track sla-probe core-api.example.com
本地DNS优先示例（dnsmasq）：
# 关键业务域名走本地递归，避免跨区转发
server=/corp.example.com/10.10.10.53
server=223.5.5.5
cache-size=10000
min-cache-ttl=60
no-resolv
6. 这次复盘沉淀的排障顺序
针对“慢但不断”的问题，建议固定这条顺序：
-
先确认影响范围：哪些门店、哪些业务、持续多久
-
再看质量指标：RTT分位数、抖动、重传，不只看丢包
-
再看路径差异：出口、路由、DNS解析链路
-
最后看资源指标：CPU、带宽、会话数
把顺序固定后，团队在压力场景下也不容易跑偏。
7. 最小阈值建议（可直接抄）
| 指标 | 触发条件（建议） | 处置动作 |
|---|---|---|
| RTT P95 | >= 150 ms，连续 3 min | 触发性能告警，优先排查路径抖动 |
| TCP 重传率 | >= 2%，连续 3 min | 检查链路质量与路由策略 |
| DNS 解析耗时 P95 | >= 200 ms，连续 5 min | 检查 DNS 转发路径与本地缓存 |
| 丢包率 | >= 3%，连续 2 min | 触发网络故障流程并升级值班 |
8. 结论
网络排障最怕“盯住一个指标”。对门店场景来说，业务慢很多时候是质量波动而不是彻底中断。把RTT、重传、DNS三组证据放进固定流程，能明显缩短定位时间，也更容易沉淀成团队可复制的排障方法。
