别再用“重启大法”了：你重启的时候，可能把关键证据也一起清掉了
企微里业务同学一句话：“页面不报错，就是一直转圈。”
我第一眼看监控，CPU、内存都不夸张，错误率也没明显抬头。那个瞬间我脑子里就两个字：重启。
结果重启后确实顺了几分钟，然后就更惨了：堆积涨得飞快、成片的超时、告警开始轰炸。
复盘下来扎心的一点是：问题不一定是重启造成的，但本来可以查的线索被我们重启清掉了。
这篇我把当时的脑回路和一些重启前需要做的一些措施写出来。
这种事故最烦：
没大面积 5xx
监控面板上大部分指标图都挺稳定，不是“心电图”状态
但用户体验已经掉到地上
你就很容易陷入自我怀疑呀：到底是用户网不好？还是前端问题？还是那个后端队列卡死了？
我那会儿也犯了这个毛病：盯着“服务健康”看了 5 分钟，还是没能定位到用户具体卡在哪一步。
讲真，人是会偷懒的。你看到不明显的异常，又怕拖着拖着变大故障，自然而然就想“重启试试”：
清掉奇怪的状态
连接池重建
线程池回到初始状态
看起来一切重新开始
问题是：重启一旦执行，也同时一些关键线索也断了。
我把当晚的关键点尽量按时间线说清楚：
T+0（告知）：企微反馈“卡”，没报错。
T+5（误判）：我看监控面板“没炸”，觉得可能是偶发。
T+8（真实线索出现）：消息堆积开始抬头，但幅度不大，没触发告警。
T+12（我手一抖）：我重启了应用。
T+15（假恢复）：延迟短暂回落，企微里有人反馈说“好像好了”。
T+20（反噬开始）：堆积开始上涨，超时开始出现，告警开始变多...
那 3 分钟“好了”，现在回头看就是最迷惑人的：它让你以为重启有效，反而错过最该做的事——保留证据 + 定位根因。
在这种情况里，重启就不是简单的重启一个进程，它会触发一串连锁反应：
堆积在那儿：重启不会让堆积消失，只会让你暂时“看起来轻松”。
消费/处理节奏会变：重启后可能触发消费组调整、并发模型回到默认、瞬时吞吐变化。
回补/重试很容易失控：原始流量 + backlog回补 + 失败重试，叠起来就会造成流量短时间内迅速变大。
下游被打穿：你以为你在救自己的服务，实际上你在把压力甩给下游——等下游开始出问题，就更难收拾了。
一句话：重启的那一刻，系统状态被重置了，但系统负担没被重置。
这次让我最尴尬的点是：问题本身也许不是我重启造成的，但我把排障线索弄断了。
计数器归零：很多关键指标是counter，重启后归零，你再看趋势就像被切断。
实例身份变了：K8s pod 名变了，虚机进程号变了，原本盯的那个“有问题的实例”，重启后没法对齐。
现场信息没了：线程栈/运行时快照/连接池状态，这些东西最有价值的就是“故障发生时那一刻”。你重启完再抓，抓到的是恢复后的数据，没意义。
把异常窗口记下来：从几点到几点、哪个接口、哪个机房/集群。
截图/保存3张关键图：入口延迟（P95/P99）、堆积（lag/队列深度）、下游耗时/错误。
抓一份现场快照：线程栈/pprof/运行时信息，能抓就抓一份。
把重试/回补开关过一遍：能不能先降重试、开退避、关回补。
先止血再重启：限流/熔断/降级先顶住，不然重启就是“恢复出厂后继续挨打”。
只灰度重启一小部分：别头一热一下子全重启。
重启时间点记得留痕：后面复盘对齐曲线、对齐日志，全靠这个时间点。
最后说一句：不是说不能重启，而是不能在什么措施都没做的情况下就盲目重启。上面这七点也不是什么“流程规范”，就当成给自己兜底了。
新闻搜索
