线上出问题，我第一件事不是看日志

凌晨两点被叫起来处理告警，很多人的第一反应是打开日志平台，从最近十分钟开始翻。我以前也这样，翻到天亮，最后发现是某台机器的磁盘满了。

后来我改了顺序。

现在第一步是看「变了什么」。上次发版是什么时候、配置有没有人动过、有没有人扩缩容、云上有没有变更通知。这些信息在控制台和发布记录里都能查到，两三分钟能看完，但能排掉一大半可能性。真的，大部分故障不是系统自己坏的，是有人动了东西。

（当然也有例外，比如证书到期。这种属于「什么都没变但就是坏了」，我吃过一次亏，现在会顺手看一眼域名和证书的到期时间。）

第二步才是看监控的趋势，不是看当前的绝对值。CPU 80% 说明不了什么，但如果它十分钟前是 20%，那就是个信号。内存缓慢上涨比突然飙升更值得警惕，前者往往是泄漏，后者可能只是一波流量。

第三步看日志，而且我不从头看，从错误类型的统计看。哪个异常在几分钟内涨了几百倍，基本就是它了。单条日志的堆栈很唬人，但真正有用的是「哪一类错误突然变多了」。

有一次印象特别深。服务一直报超时，日志里全是数据库连接超时。当时所有人都往数据库查，查了半天数据库很健康。最后发现是我们自己的连接池配置在一次发布里被改小了，从 50 改成了 10。数据库没问题，是我们自己不给自己连接。

那次之后我加了个习惯：任何配置变更都要在发布说明里写清楚，哪怕只改了一个数字。因为出问题的时候，没人会记得三个月前那个「优化」改了什么。

还有一点，我现在会先把「怎么回滚」想清楚，再去定位根因。这个顺序听起来不专业，但线上讲的是先恢复再分析。回滚两分钟能解决的事，非要花两小时找根因，用户已经跑光了。

写得有点乱，但这就是我真实的顺序：先看变了什么，再看趋势，最后看日志；先能回滚，再去刨根。