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