关于 on-call 我知道的一切,一页讲完

On-call 不靠聪明,靠无聊的纪律。十年的传呼机、三大洲,还有一次在伊斯梅利亚的 cron 任务抽风事件之后,这是我真正递给新轮值搭档的短清单。它故意只有一页 — 要是超过一页,你写的就是凌晨三点没人会看的手册。

第一条:没人在看

凌晨三点,你不是在读,是在做模式匹配。假设你会冷静消化一整面文字的 runbook 是在写小说。我写过、留下来的页面只有三件事:一行症状、要跑的确切命令、接下来要查的确切东西。那种段落式解释的版本,六个月内就会被归档,因为真正出事时没人打开。

要是 runbook 里有”背景”小节,那是写给未来的你的,不是写给 on-call 时的你的。放到最底下。

在你动任何东西之前 — 在回滚之前、在扩容池之前、在踢掉一个节点之前 — 先在事故频道里发。两行:你看到什么 和 你准备做什么。就这些。

这看起来是摩擦。确实是摩擦。这是你这辈子给 on-call 加的最便宜的摩擦。它避免了三个工程师同时跑互相矛盾的命令、数据库四分钟内被重启两次的那种诊断。问我怎么知道。

顺序很重要。如果你的 dashboard 让这五件事不在两次点击之内,那就是你在忽视一个事故前问题。

过去一小时内我们有部署吗? 60% 的 page 是这个,你心里有数。先回滚, 再调试。调试优先-回滚后置是怎么搞出三小时故障 + 一个极其礼貌的 Slack 线程追问谁的 change 的典型剧本。
数据库还好吗? CPU、连接池饱和、复制延迟。数据库几乎总是请求路径里最慢的环节,一旦被你搞坏,恢复起来也最慢。
是只有一个 region / AZ / partition 吗? 如果看起来坏但只在 eu-central-1 坏,那修复多半在负载均衡层,不在你的代码里。
上游 API 变了吗? 供应商在工作日早上十点推破坏性变更,然后假装 changelog 里写过了。
流量形状变了吗? 某个集成上线了,你现在收到的请求是原来的 40 倍。在你开始重写服务之前,查一下源 IP 分布。

如果这五项里都没找到原因,慢下来。下一步永远是”慢慢读日志,从边缘往里读” — 不是”猜一下再重启”。

我第一次独自撑下一个 14 小时的事故、所有人鼓掌时,我以为这就是工作。第十次之后我才意识到,我一直在扛一个本该更早、叫醒更多人的系统。

你在当英雄而不是工程师的迹象:

这里面每一条都是事故后的 action item。“把 runbook 文档化”、“把 dashboard 挪到共享文件夹”、“在培训资料里加一节”。你的英雄主义是技术债。在你的轮值变成别人继承的创伤之前把它还清。

如果这篇只能带走一件事:传呼机响是因为系统会坏。系统会坏是因为工程本来就难。传呼机把你叫醒,不代表你更慢、更差、更不 senior。你是那个出现的人。

这里的反模式,是那种开口就问”这本来该谁接住?”的事故复盘。答案永远是 “系统” — CI、测试、告警、护栏、没问对问题的设计评审。“是谁”的问题是羞耻剧场,它让下一次事故更难,因为人们会为了不被点名而推迟呼叫。

全是无聊但会复利的:

我有一本个人的传呼机日志。 时间、页、最先查的东西、实际原因、要是当时知道会先查什么。每起事故五行。一年后,会浮现出官方事故复盘流程错过的模式。
我用有意识的确认来 silence,不用条件反射。 如果告警是错的,当晚就把告警修好。如果我 silence 了然后忘记,它会在凌晨四点再叫我一次,而且我活该。
我把”被呼但不是事故”当 bug 处理。 误报是 P0 运维问题,不是民俗税。如果你的团队把”为非事件醒来”视为常态,你的轮值就在慢慢崩溃。
交接我写下来。永远。 “没什么要汇报的”是一句话。“我忽略了 03:00 的 page,估计会自愈”是交接;“晚安”是弃置。

## 症状
<一句话,传呼机说的那个>

## 立即动作
<命令,或 dashboard 链接,或"升级给 X">

## 验证
<你怎么知道它生效了>

## 没生效时的下一步
<最多三条,有序>

## 背景
<其它一切 — 为什么、历史、链接>

如果一份 runbook 的前四节在一屏里放不下,它其实是两份 runbook 假装成一份。拆开。

你没法靠工程绕过睡眠不足。如果轮值每季度叫醒你不止一次,那是工程问题 — 不是个人韧性问题 — 你的工作是让系统变安静,不是让自己变硬。

我在跑一套 local-first 的 agent 控制面(Fulcrum),部分原因是我厌倦了看着团队一次次重新发明我十年前就写下来的事故响应习惯。传呼机不是敌人。敌人是那种把嘈杂的传呼机当成持有者性格特征的组织。