图文：夜班运维的一晚，告警响了三次

这一晚我从二十一点四十接班，到早上六点交班。八小时二十分钟，告警响了三次，两次需要动手，一次只是看着。

我想把这一晚拆成画面写下来。不是为了说明夜班有多辛苦，而是想说清楚一件事：夜里的三次告警，往往不是三个问题，而是同一件事在不同时间露出的三张脸。

一、二十一点四十：接班

1.1 画面：交接只用了三分钟

监控大屏在值班室东侧墙上，两块屏，左边是全局拓扑，右边是告警流。前一个班的人站起来，把椅子推给我，说三句话：缓存集群有一台在重启，别管；晚上十一点有个批量任务，跑完会有一条磁盘告警，别管；其他没事。

他把一张交接单推过来，上面三行手写。我签了名字和时间，他走了。整个过程三分钟。

1.2 旁白：交接单上没写的部分

交接单只有三行，但值班的人脑子里装的东西更多。哪台机器前几天换过网卡，哪个接口白天调过超时参数，哪个客户这几天在做数据迁移。这些都没写下来，因为写下来太长。

夜班的难点不在技术，在于你要用三分钟接住另一个人八小时的上下文。接不住的部分，会在凌晨以告警的形式回来找你。

1.3 当时的判断：今晚不会安静

我看了一眼日历，今晚有两件事：二十三点整的批量对账，和凌晨两点的一个索引重建。两件事都会大量读写磁盘，而磁盘的写入延迟这两天本来就在边缘。

我在交接单背面写了一行：磁盘延迟若超过阈值，先看是不是批量任务。写完贴在显示器边框上。这个动作后来救了我一次。

二、二十二点五十：告警一，写入延迟

2.1 画面：一条黄线爬上去

告警流里跳出一条黄色：某数据库节点写入延迟超过两百毫秒，持续三分钟。同时拓扑图上那个节点的边框变成黄色，慢慢闪。

我点开曲线，看到延迟从四十毫秒开始爬，爬了六分钟，然后停在两百二。同一时间，磁盘队列深度从二涨到十一。没有报错，没有超时，只是在变慢。

2.2 旁白：这类告警很容易被划掉

黄色告警在夜班里的处境很尴尬。它不像红色那样必须马上处理，也不像蓝色那样可以随手关掉。多数时候它自己会回落，于是人养成一个习惯：先看一眼，觉得没事，划掉。

我那天没有划掉，因为二十分钟后就是批量对账。如果延迟在对账期间继续爬，对账任务会拖长，拖长就会和凌晨的索引重建撞上。这两件事一起压磁盘，后果不是慢，是卡死。

2.3 当时的判断：先降一半，不做根因

我做了两件事：把对账任务的并发从八降到四，把索引重建往后推一小时。没有去查根因，因为夜里查根因的代价太高，而这件事有明确的缓解手段。

延迟在对账开始后维持在两百六，没有继续涨。对账跑完是二十三点五十八，比平时多了十九分钟。这个结果可以接受。

后来复盘，根因是一块盘的写缓存策略被白天的变更改回了默认值。这件事在夜里查不出来，因为需要翻白天的变更记录，而变更记录在另一个系统里，需要另一个权限。

三、零点二十：告警二，连接池

3.1 画面：红色的数字停在九十八

零点二十，告警流跳红：应用连接池使用率百分之九十八，持续两分钟。这次不是黄色，是红色，声音也响了一下。

我打开应用面板，活跃连接九十八，空闲二，等待队列十七。同时数据库侧的连接数是三百二十，接近上限。两条曲线几乎同时抬起来。

3.2 旁白：连接池告警的三种常见原因

连接池打满，通常是三种原因：慢查询把连接占住、连接泄漏没有归还、流量突然上涨。三种原因的处置完全不同，前两种要动代码或配置，后一种要扩容。

判断的方法很土：看慢查询日志有没有新增，看连接的平均持有时间有没有变长，看入口流量有没有跳变。三个指标里，平均持有时间更能说明问题，因为它把“占着不放”和“来得多”区分开了。

3.3 当时的判断：先限流，再定位

平均持有时间从三十毫秒涨到一千二百毫秒，说明是连接被占住，不是流量涨。我先把两个非核心接口的限流阈值降到三成，把连接让出来。

三分钟后连接数回到六十，等待队列清零。然后我去翻慢查询，发现一条统计语句在零点之后开始走全表，因为统计任务刚跑完，表的统计信息过期了。

这件事的处理顺序值得记一下：先恢复，再定位。夜里反过来的代价很大，你可能在定位的二十分钟里让整个应用不可用。

四、三点零五：告警三，备份失败

4.1 画面：一条灰色的记录

三点零五的告警不是红色也不是黄色，是灰色：备份任务失败，退出码一。这条告警没有声音，只在列表里多了一行。

我点进去看日志，失败原因是磁盘空间不足。备份目录只剩十二个G，而这个库的全量备份需要三十个G。

4.2 旁白：不响的告警更麻烦

三次告警里，这一条很容易被忽略，因为它不响。夜里人已经醒了两次，第三次看到一条灰色的记录，反应会慢半拍。

但它的影响周期长。备份失败意味着这一天的恢复点是前一天，如果白天出事，丢的是一整天。前两次告警影响的是几十分钟的性能，这一次影响的是数据安全的上限。

4.3 当时的判断：清旧备份，重跑，加监控

我先看了备份目录，里面有十四份历史备份，保留策略写的是保留七份，但清理脚本三个月前失效了，没人发现。我删掉七份，腾出五十八个G，重跑备份。

重跑用了四十七分钟，成功。然后我加了一条监控：备份目录使用率超过七成就告警。这条规则很简单，但它能防住同一类问题第二次发生。

五、五点四十：天亮之前

5.1 画面：交接单多了三行

五点四十，我在交接单上补了三行：写入延迟的根因待查，缓存策略已被白天变更改回；统计语句需要加索引或者改写；备份清理脚本失效，已手工处理，需要修脚本。

三行字，对应三次告警。写完的时候窗外已经泛白，值班室的空调还在响。

5.2 旁白：三次告警，一件事

白天复盘的时候，我们把三次告警摆在一起看，发现它们指向同一个东西：变更没有闭环。

白天的变更改了磁盘缓存策略，没有同步到值班的人；统计任务上线时没有评估统计信息过期的影响；备份清理脚本在三个月前的一次迁移里失效，没人验证。三件事都不是夜班造成的，但都在夜里结算。

5.3 当时的判断：夜班该做的事

夜班的价值不是修问题，是让业务活到天亮。这个定位一旦清楚，很多选择就变了：先缓解再定位，先恢复再复盘，先保住数据再谈性能。

至于根因，那是白天的事。夜里查根因，查出来的概率低，代价高，而且很容易在疲惫的时候做出错误判断。把根因留给清醒的人，是对系统更负责的做法。

5.4 后来改的三件事

其一，变更要留值班可见的备注。

所有会影响磁盘、连接、备份的变更，在日历上必须勾一个“值班关注”，勾了之后会自动出现在当晚的交接单里。这一条推行起来不难，因为成本只是多点一个勾。

其二，灰色告警也要有声音。

我们把“任务失败”这类灰色告警单独配了一个短提示音，音量不大，但能听见。规则是只对失败类生效，不对信息类生效，避免夜里被无意义的声音吵醒。

其三，交接单加一栏待验证。

交接单原来只有“已处理”和“待处理”，后来加了“待验证”：昨晚做的缓解动作，白天要有人确认是否真的解决了。这一栏让很多临时的绕过手段没有变成长期状态。

常见问题

问：夜班遇到黄色告警，什么情况下必须处理？

答：看它后面有没有排着别的动作。如果二十分钟内有批量任务、有备份、有发布，那这条黄色就要处理，因为它会在关键时间点放大。如果后面一整晚都是空的，可以先观察，把判断写进交接单，交给白天的人。

问：连接池打满，先限流还是先查慢查询？

答：先限流。限流是可逆的、影响面清楚的动作，能在几分钟内把连接让出来。查慢查询需要时间，而连接池满的时候，业务已经在报错了。顺序是先让业务恢复，再去找那条语句。

问：备份失败为什么容易被漏掉？

答：因为它通常不影响当下。业务在跑，页面在开，只有未来的恢复能力被削弱了，而这种削弱在当天看不见。解决办法是把它从“任务告警”提升为“数据安全告警”，单独一路通知，并且要求当班必须有人签字确认。

问：夜班交接单写多少内容合适？

答：三到五行，每行一件事，写清当前状态和下一步动作。写多了没人看，写少了接不住。我自己的习惯是每行不超过二十个字，超过就说明这件事还没想清楚。