凌晨一点二十，电话响。我接起来，对面是值班开发，语气很急：线上系统崩了，全站 502，你们运维是不是改了什么？

我脑袋还懵着，下意识先自证清白：我今天没动过任何生产配置。他说那怎么突然就崩了？

我爬起来登录，先看时间线。系统是 00:57 开始报 502 的，我翻了下自己的操作记录——最近一次动生产是三天前加了个防火墙规则，跟今天完全没关系。然后我查了开发那边的发布记录，好家伙，00:55，他们刚发了个版本。

我截图发群里：你们 00:55 发版，00:57 开始 502，这个时间线你们自己看看。

群里安静了十几秒。然后那个开发说：我们那个版本就改了个前端样式，不可能影响后端。

我说行，那我查。查了半天，最后发现是他们新版本的前端调了一个新的接口，那个接口在他们测试环境有，生产环境没同步部署，所以一上线，前端疯狂请求这个不存在的接口，后端网关直接被打爆。

我什么都没改，但那一小时我一直在被质疑。

这事干多了我就习惯了。后来我总结出一个规律：线上出问题，第一时间先别急着辩解，也别急着甩锅，先把时间线拉出来。谁在故障前动了什么，日志里都有。时间线摆出来，比吵十句都管用。

当然，我也见过反过来的。有一次确实是我们运维的锅——机房割接，我同事把一根光纤插错端口，导致一个网段全断。那次客户打电话来，我第一句就是：是我们这边的问题，正在恢复。客户反而没怎么发火，说：行，你们处理，处理完跟我说一声。

你主动认,人家反而不揪着不放;你一上来就"不是我",人家只会更怀疑你。

还有一次更有意思。系统慢,开发说是数据库的问题,让我们调优。我上去看了半天,数据库各项指标都正常,最后发现是他们有个接口没做分页,一次把全表查出来。我跟开发说,这个 SQL 你们自己优化下吧,开发不吭声了。

后来我们定了个规矩:线上事故,先恢复,再定位,最后才是追责。追责那一步,不是找谁背锅,是把流程漏洞补上。这个规矩定了之后,半夜吵架的次数明显少了。

其实干运维这么多年,我早就不在乎锅不锅的了。我在乎的是,出事了能不能第一时间把系统拉起来。锅可以背,系统不能一直挂着。