事情本身不复杂，线索都在日志里。SLB 开了基于 cookie 的会话保持，把后端从两台扩到六台，新机器 CPU 一直是零，只有老用户重连才偶尔落上去，活动流量上不去。
第一反应是「没有配置保持失效后的重试与降级」，验证下来不成立。
真正麻烦的地方在于，几个原因的现象几乎一样。会话保持超时设成十二小时，老会话一直绑在旧机。少数情况下是cookie 种在客户端，浏览器不重开会话就一直有效。
另外，灰度扩容时没做连接预热和权重调整。
上来先看各后端的活动连接分布
ss -tan state established | awk '{print $4}' | cut -d: -f1 | sort | uniq -c然后把会话保持超时缩到三十分钟
curl -s http://slb.console/api/lb/lb-xxx | python -m json.tool | grep -i sticky接着确认后端健康检查都在通过
curl -s -o /dev/null -w '%{http_code}\n' http://10.0.1.10/healthz滚动重启让会话重新分配
systemctl restart app && sleep 30改完先别撤，确认这几项。六台后端的连接数在半小时内趋于平均，新机器 CPU 接近其他实例，用户没有被强制登出。
容易忽略的是，会话保持和水平扩容天然冲突，能把会话放 Redis 就别用粘性会话；必须粘的时候把超时设短。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。