kubectl scale deploy api --replicas=4 hey -z 60s -q 30 -c 20 http://api.internal/health kubectl rollout status deploy/api
下游恢复后 30 秒内入口 QPS 从 800 冲到 3600，客户端重试队列和积压的定时任务一起涌进来，刚恢复的服务 CPU 到 100%，两分钟后再次不可用。先别急着动参数，把报错原文和时间点记下来，顺序反了容易白折腾。
原因不复杂，故障期间客户端一直在重试，积压的请求在恢复瞬间集中释放。服务刚启动，连接池和本地缓存都是冷的，处理能力只有稳态的一半。
「恢复流量突增」排查到最后往往是很小的一处差异，前面那些复杂猜测可以先放一放。备份不是备了就行，恢复一次才算数，很多备份文件打开才发现是空的。
处理上按这个顺序：恢复时先把入口流量限到稳态的 30% 再逐步放开；客户端重试加最大次数和总时长 别无限排队；启动后先跑预热 把热点 key 和连接池填满；积压任务按比例放行 不要一次性全放。
改完只确认一件事：恢复过程入口 QPS 曲线是斜坡上升，CPU 峰值不超过 70%，不再出现二次不可用。