这个坑值得记一笔。为了跑完八万条 URL，巡检脚本开了 50 个并发，每天上午十点源站 CPU 直接打满，用户访问开始出现 502，告警比巡检报告先到。
这类报错背后常见的原因有几处，逐个排除就行。脚本没有限速，所有请求在同一分钟内发出；巡检和业务高峰重叠，没有错峰；失败重试没有退避，异常时请求量翻倍。
动手时先把并发降到 5 并加间隔
xargs -P 5 -I{} curl -s -o /dev/null -w '%{http_code} {}\n' {}给重试加指数退避
curl --retry 2 --retry-delay 5 -sI https://www.example.com/p/1再往下把巡检挪到凌晨低峰
crontab -l | grep check_urls末了观察巡检时段的源站负载
sar -u 1 10同一份数据我导出了两份，一份留底，一份拿来试。
这类问题以前遇到过，但这次的触发条件和上次不一样。
怎么算真的好了，看的是同一批现象。并发降到 5 后巡检时段 CPU 峰值不超过 25%，用户在上午不再遇到 502，巡检本身也能完整跑完。
巡检脚本是访问者不是管理员，给它限速和错峰，比事后解释故障省事得多。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。