值班小抄：几次半夜被叫醒之后，我给自己写了一份「夜班手册」

第一次夜班：完全靠本能在瞎点

第一次夜班，是周六凌晨两点。电话响的时候，我甚至愣了三秒才反应过来「哦对，今天轮到我值班」。

打开电脑、连上 VPN、ssh 到服务器，一顿操作之后，我做了这些事：

• 先打开了最熟悉的服务日志，疯狂 tail -f。
• 发现没啥错误，又去看 Nginx 日志。
• 看到 5xx 确实在增加，于是凭直觉重启了两个服务。

那天运气好，问题确实缓解了。但第二天早会复盘的时候，老板问了我三个问题：

1. 你第一眼看的是什么指标？
2. 你怎么判断是重启可以解决，而不是扩容或者限流？
3. 如果你没接电话，后备值班的人能不能按你的操作复现一遍？

三个问题我一个也答不上来。

我开始给自己写「夜班手册」

那天之后，我做了一件很俗气但非常有用的事： 打开一个文档，标题写了四个字——「夜班手册」。

这个手册不是那种 20 页的 SOP，而是几条非常具体的「先后顺序」：

1. 先看哪个总览大盘。
2. 再看哪个服务的哪块子图。
3. 如果是 5xx 飙升，检查 A/B/C 三个地方。
4. 只能动哪些开关，哪些动了之后必须在群里说。

我自己的排查顺序

现在每次夜班，哪怕是被电话吵醒，我也会按这个顺序走：

1. 先看「用户感知」层

打开用户侧的监控大盘：PV、错误率、接口耗时。 先确认三件事：

• 是不是所有用户都受影响，还是某几个租户 / 某个地区？
• 问题是「完全不可用」还是「变慢」？
• 是新版本刚发完就出问题，还是随机时间点冒出来？

2. 再看「关键链路」

我们后来给几个关键接口单独做了 Panel：登录、下单、支付回调。 夜里出问题，80% 都在这几条线上。

每个 Panel 我都会看三个图：

• 请求量是不是有明显突刺？
• 错误率是不是只在某几个 status code 上涨？
• 95 线/99 线 RT 是不是突然抬头？

3. 最后才是机器资源

以前我一上来就看 CPU / 内存，现在会放到后面。 因为资源高并不等于出问题，有时候是活动正常量大。

但如果你看到「接口 RT 升高 + CPU 飙升 + 错误率上来」，那大概率就是要么扩容，要么限流，要么止血回滚了。

给自己定的「夜班红线」

为了防止半夜脑子糊掉乱操作，我给自己定了几条红线，写在手册最上面：

• 不能线上直接跑任何一条没在文档里出现过的 SQL。
• 不能同时重启超过 1 个核心服务。
• 不能在没人知情的情况下改配置，哪怕只是把阈值调高一点点。

这些红线听上去很保守，但半夜的时候，人是最容易高估自己判断力的。 有了这些红线，反而让我在「要不要动手」这件事上清醒很多。

为值班准备好的「快捷入口」

我还专门为夜班账号做了一套「一键直达」：

• 浏览器书签栏只保留了 5 个链接：值班大盘、错误告警列表、核心接口 Panel、报警规则配置、回滚操作文档。
• 终端里给常用的 ssh 和 kubectl 命令都配了 alias。
• 桌面上放了一个 txt，里面是所有「一看就知道是大事故」的报警关键字。

这样哪怕是被吵醒，手还在抖，基本也能在 1 分钟内把情况大致摸清，不至于在一堆图表里乱点。

对团队的要求：值班不是「一个人的战斗」

最后一点很现实：一个人再熟练，也扛不住一整条业务线的所有坑。 所以后面我们对值班有几个团队级的约定：

• 每次比较大的事故，第二天必须有简短 Postmortem，值班的人不背锅，大家一起复盘流程。
• 复盘里如果暴露出「只有某个人知道怎么搞」的点，必须写进公共文档。
• 新人上值班之前，至少跟老同学跟班 2 次，只看不操作。

这些约定并没有让事故数量立刻变少，但至少做到了两件事：

• 半夜出事的时候，不会再出现「谁都不敢动」的僵局。
• 白天大家更愿意为了「让值班好过一点」去补监控、补告警、补文档。

写在最后

我现在还是不喜欢被半夜叫醒，但至少不会再那么慌。 这篇其实就是把我的「夜班手册」从内部文档搬了一部分出来。

如果你也在轮值班，不妨给自己也写一份类似的小抄，不用复杂，哪怕就 10 条 checklist： 先看哪里、再看哪里、哪些能动、哪些命令坚决不能敲。 半夜的时候，你会很感谢那个白天帮你写小抄的自己。