Pager 没响却听见警报？Oncall 工程师的睡眠与焦虑指南

作为要值班的工程师，下面这些场景大概都不陌生：pager 没响，脑海里却隐约听到警报，拿起手机才发现只是错觉；半夜被叫醒后直接进客户会议，脑袋还没清醒就被要求回答问题；下班后想安静放空五分钟，结果脑子比工作时还停不下来；值班早就结束了，却还是会无意识地点开那些没处理完的调查。

刚开始我以为这些反应只是个人韧性不够，或者已经 burnout 了。后来把相关文献翻过一轮才发现，这些反应在临床和职业健康研究里都有名字、有研究，也有对策。本文是我整理的阅读和实践笔记，把值班相关现象、研究证据，以及可以马上开始做的个人对策放在一起。

如果这些内容能对 SRE、软件工程师、TSE / Customer Support、DevOps、平台工程师，或者任何要扛 pager 的角色有帮助，那就很好。oncall 焦虑从来不是纯粹的个人问题，所以我会先谈结构性问题，例如 alert design 和轮值设计，再回到个人层面能做的事。

TL;DR：如果你只想先做三件事

如果只能先做三件事，优先顺序如下：

• 先检查 alert 设计：如果一轮 oncall 超过 2 个真正需要处理的 incident，或者大量 alert 根本不需要 action，问题优先在系统设计，不在个人韧性。
• 建立 wake-up protocol：半夜被 page 之后不要直接坐到电脑前。先用水、冷水、光、动作把 sleep inertia 降到最低，必要时再用咖啡因。
• 把值班周当成 60% 到 70% 工作量：不要安排深度工作、重要面试或高风险决策，把 standby 当成工作状态，而不是失败的休假。

后面的章节会展开这三件事的研究依据、机制解释和具体做法。

mindmap
  root(("Oncall 工程师<br>身心生存指南"))
    为什么这么累<br>机制与名称
      Phantom Vibration<br>幻觉震动
      Hypervigilance<br>过度警觉
      Operant Conditioning<br>操作制约
    结构先于个人
      每轮班最多 2 个 incident
      警报分级与调校
      单地 8 人或双地各 6 人
      Runbook 维护与更新
    睡眠是底线
      Sleep Inertia<br>刚醒时认知下降
      Wake-up Protocol<br>水 冷水 光 动作
      就寝规律控制在 ±1 小时
      睡前 60-90 分钟收尾
    Standby 是隐形劳动
      待命本身就在工作
      Attention Residue<br>注意力残留
      Ready-to-resume Plan
      只在响的时候反应
    Oncall 周的节奏
      规划 60-70% 工作量
      低认知负担活动
      Page 后争取 5 分钟缓冲
      极低门槛成就清单
    不同角色的痛点
      SWE 或 Platform Engineer<br>深度工作被打断
      SRE 或 DevOps<br>警报量加跨团队协作
      Customer 或 TSE<br>客户情绪加广产品线
    何时找专业协助
      恐慌发作或解离
      持续失眠或幻听
      用酒精药物缓解
      CBT 或 EMDR 治疗

Oncall 焦虑有名字，也有研究依据

我值 oncall 的时候，常常会莫名焦虑，甚至会自我怀疑：“为什么别人 oncall 都还好，只有我这么焦虑？”和主管、同事聊过几次之后，我整理出几个可能的原因：

• 对不确定性感到焦虑
• 担心遇到未知的技术问题或事故时，不知道该怎么处理
• 怕把事情搞砸

这些心理因素会带来一连串生理反应。比如说，值班时段明明很安静，我有时却会莫名觉得手机在震动、听到警报声或消息提示音，进而引发紧张和焦虑。但这些反应不是个人韧性不足，而是大脑对长期、不可预测的警报信号做出的合理适应。

有些心态调整也许能缓解焦虑：

• Pager 响起时，没有人期待你当下就把根因彻底解决；重点是先止血，或找人一起止血。
• 先想清楚：就算 Pager 响了、或者问题暂时解不出来，最坏会发生什么。把最坏情境具体化之后，通常就没那么可怕。
• 别人急，但我不急。我需要比周围的人更平静，才能把问题解决。

另外，先弄清楚这些反应的名称和文献证据，是处理它们的第一步。当你知道“幻听 alert”这件事有很多同行也会经历，自我责备通常就会少很多。

Phantom vibration syndrome（幻觉震动症候群）

Rothberg 等人 2010 年发表在 BMJ 的横断面调查估计，大约 68% 的医护人员经历过幻觉震动（Rothberg et al., 2010, BMJ ¹）。Lin 等人 2013 年发表在 PLOS ONE 的研究也指出：他们追踪了 74 位医学院实习生，实习开始时已经有 78.1% 经历 phantom vibration、27.4% 经历 phantom ringing；到了实习第三个月，比例分别升到 95.9% 和 84.9%，第六个月仍维持在 93.2% 和 87.7%。在这项研究里，焦虑和抑郁分数虽然也在实习期间同步上升，但作者特别指出，幻觉震动和铃声的盛行率变化不能简单解释为焦虑或抑郁的直接结果，而更像是高压环境下常见的知觉适应现象（Lin et al., 2013, PLOS ONE ²）。Chen 等人 2014 年的横断面研究进一步发现，幻觉震动症候群和职业倦怠存在独立关联，可能是工作压力的早期指标，而不只是焦虑或抑郁的副产物（Chen et al., 2014 ³）。

当大脑被训练成“任何震动或铃声都可能是紧急警报”，信号检测阈值就会被拉低，衣服摩擦、心跳、冷气声这类噪音都可能被误判为警报。值班结束后还在听幻觉警报，不是神经质，而是大脑的检测模型还没回到原来的校准状态。

Hypervigilance（过度警觉）

我离开 AWS 之后，现在听到 Amazon Pager 的声音还是会被吓到；相比之下，Google 的警报声温和得多。这不是在比品牌，只是想举一个直观的例子：警报声音的设计，会直接塑造神经系统的反应。当警报声音尖锐、急促、音量又大时，大脑会把它当成危险信号；久而久之就形成制约反应。之后只要听到接近的频率或节奏，甚至只是手机通知音、电梯声，交感神经就会先被启动，心跳加快、肌肉紧绷、呼吸变浅。反过来说，如果警报被设计成“能辨识但不会吓人”，再配合分级机制和合理的噪音控制，身体就不容易被反复训练成长期的过度警觉状态。

Hypervigilance 是 PTSD 的核心症状之一，但它不需要创伤事件也能被诱发。Oncall 环境本身就具备训练过度警觉的所有条件：触发不可预测、风险高、睡眠被打断或片段化、缺少明确的下班边界。

Dettmers 等人 2016 年在 Journal of Occupational Health Psychology 发表的研究做了一件很关键的事：他们比较了员工在“非工作时间需要保持可用”和“不需要保持可用”两种日子。结果显示，光是 extended availability（延伸可用性）本身就会限制恢复经验，并和隔天早上的情绪变化以及皮质醇 (Cortisol) 变化有关（Dettmers et al., 2016 ⁴）。Ziebertz 等人的大型调查研究也指出，与其说 oncall 的负担只取决于时数，不如说“不确定性带来的压力”、“待命期间无法放松”和“活动受限”更能解释疲劳、工作家庭干扰与主观表现困难（Ziebertz et al., 2015 ⁵）。

换句话说，神经系统并不会很好地区分 standby 和 on duty。这也解释了为什么我多次在 oncall 期间尝试闭眼冥想，反而更焦虑：平时我们会用工作、会议、滑手机这些外部刺激去盖过内部的警戒信号，一旦坐下来闭眼，背景里的 hypervigilance 就会浮到意识层面，就像耳鸣的人在安静房间里会觉得耳鸣最大声。

Operant conditioning（操作制约）

Pager 声音、Slack ping、手机震动，早就被杏仁核学习成高强度的条件刺激。即使 oncall 结束，这条“信号 -> 焦虑”的反射回路还在，只能等大脑慢慢把这个联结淡化，心理学上叫 extinction，也就是消退反应。所以很多人值班结束后几天，还是会习惯性检查手机；条件反射不会因为轮班结束就立刻消失。

结构性问题优先：先检查 alert 设计

oncall 焦虑很多时候不是个人韧性问题，而是 alert 设计的问题。如果工作环境的结构已经让人快要崩溃，再多个人技巧也只是把崩溃时间往后拖而已。

Expect to handle no more than two events per on-call shift (e.g., per 12 hours): it takes time to respond to and fix outages, start the postmortem, and file the resulting bugs. More frequent events may degrade the quality of response, and suggest that something is wrong with (at least one of) the system’s design, monitoring sensitivity, and response to postmortem bugs. — Google SRE Book, Service Best Practices

也就是说，一轮班最多两个 incident，是 Google 认为仍然“可学习、可恢复”的上限。超过这个量，工程师就没办法好好分析，也很难写出像样的 postmortem，最后只会越来越疲惫。Google 同时建议单地 oncall 团队至少 8 人；如果 on-call 不超过 25% 工时，这样的规模刚好可以支撑 primary/secondary 双轮值。若是跨地理区域的 follow-the-sun 轮值，每地至少 6 人，总数至少 12 人，才能避免长期夜班 page。

业界真实情况通常离这个标准很远。我自己的经验是，如果一个轮班收到超过 5 个需要实际处理的 alert、超过 30% 的 alert 不需要任何后续动作、同一个服务一天内反复触发（flap）多次、runbook 不存在或已经过期，或者少于 5 个工程师分担 24/7 轮值，那么重点应该优先放在改善 alert 设计，而不是个人技巧。这些是团队层级的问题，在团队回顾会或 postmortem 上提出、推动 alert 调校、争取人力，比一个人硬撑健康得多。

睡眠是 oncall 的底线

如果 oncall 时间横跨半夜，对睡眠的破坏不只是“半夜被叫醒”，它同时破坏三件事：被叫醒当下的认知能力、整个 oncall 周期的睡眠规律性，以及 oncall 结束后的再次入睡能力。

Sleep inertia：被叫醒进会议时别期待自己还能保持理智

Sleep inertia（睡眠惰性）指的是醒来后一段时间内，认知能力和反应速度暂时下降的状态。多数人的晨间 sleep inertia 会持续 15 到 30 分钟，严重时甚至可达数小时（Hilditch & McHill, 2019, Nature and Science of Sleep ⁶）。

最戏剧化的研究是 Wertz 等人 2006 年发表在 JAMA 的论文。他们直接比较“刚睡醒”和“已经持续清醒”状态下的认知表现，结论非常反直觉：刚睡醒那段时间的认知损伤，可能比长时间清醒造成的疲劳还严重（Wertz et al., 2006, JAMA ⁷）。更糟的是，Scheer 等人 2008 年的研究发现，在生理夜间（biological night）被叫醒时，sleep inertia 的强度最大（Scheer et al., 2008, J Biol Rhythms ⁸）。这正是 oncall 半夜 page 你进客户会议的场景。

换句话说，你不是不够专业，而是在明显受损、接近酒精影响的认知状态下被要求工作。半夜表现不好不只是个人问题，也有明确的生理基础。

Wake-up protocol：先把刚醒前几分钟的混乱和决策负担降到最低

这个流程适用于两种情况：oncall 早班起床，以及半夜被 page 之后必须立刻进入客户会议或做关键决策。如果只是半夜被叫醒确认警报、处理完还会回去睡，那就只做下面的物理唤醒步骤（水、冷水、光、动作、呼吸），跳过咖啡那一段，否则会影响后续睡眠。

我们无法控制被呼叫的时间点，但可以控制环境。比如前一晚先把环境准备好：床边放一杯水，起床第一件事就喝完；起床时立刻开灯，因为“光”是最强的唤醒信号；把 oncall 衣服放在椅子上，省去穿什么的决策成本。这些都是在降低“刚醒后的决策负担”，因为刚醒的大脑本来就不适合做决策。

被叫醒之后：

• 先把那杯水喝完，脱水会放大 sleep inertia
• 用冷水洗脸 30 秒，这可能触发哺乳动物潜水反射（mammalian dive reflex），帮助降低生理唤醒和焦虑。目前没有很强的证据证明它能直接缩短 sleep inertia，但主观上多数人都会觉得清醒一点
• 如果天已经亮了，走到窗边看 30 到 60 秒的天光；即使阴天，户外照度也比室内高 10 到 100 倍
• 整个流程大约 3 到 4 分钟，比直接坐到电脑前清醒度好很多

关于咖啡因摄入，只有在“确定不会再回去睡”的场景才喝，也就是 oncall 早班起床，或者天快亮时被 page 进客户会议。坊间常听到“起床先别立刻喝咖啡，会和皮质醇高峰冲突，也容易产生耐受性”这种说法，但目前研究证据其实很薄弱。皮质醇觉醒反应的个体差异很大，咖啡因耐受性和摄入时间点之间的因果关系也还没有定论。实务上，更安全的做法是先把物理唤醒（水、冷水、光、动作）做完，等身体真正开始醒、需要进一步提神时再喝，而不是把咖啡当作开机键。如果是半夜被 page 起床处理 incident，结束后还要回去睡，就不应该喝咖啡影响睡眠。

睡眠规律比睡眠时长更重要

很多人以为睡眠就是“够不够长”。但 Windred 等人 2024 年发表在 SLEEP 期刊、使用 UK Biobank 超过 60,000 名受试者的大型研究有一个反直觉发现：睡眠规律性比睡眠时长更能预测死亡风险（Windred et al., 2024, SLEEP ⁹）。具体数字上，相较于规律性最差的五分位族群，最规律的族群全因死亡率风险低 20% 到 48%、癌症死亡率低 16% 到 39%、心血管代谢死亡率低 22% 到 57%，而且这个效应强于总睡眠时长的影响。

对 oncall 工程师来说，这个发现的含义很直接：oncall 排班可能很难改，但你可以把就寝时间当作主要控制变量。我的做法是先决定起床时间，再反推上床时间，公式很简单：

就寝时间 = oncall 开始时间 - (60 分钟收尾 + 8 小时睡眠 + 15 分钟入睡延迟)

例如：

• 8:00 AM 开始 oncall 的话，22:30 上床
• 6:00 AM 开始 oncall 的话，20:45 上床
• 9:00 AM 开始 oncall 的话，23:30 上床

关键不是“几点睡”，而是把 oncall 周和非 oncall 周的就寝时间差异控制在 1 小时以内。最常见的误区是 oncall 一结束就熬夜“补偿自己”，这通常会把规律性破坏得比 oncall 周期间还严重，等于前面的努力白费。周末就寝时间和工作日差异控制在 1 小时以内也是同样的道理，social jet lag 对代谢、心血管和认知的负面影响有明显的剂量反应关系。

睡前 60 到 90 分钟的收尾时段，我会做几件事：停止工作和 Slack，让大脑从交感神经切回副交感神经；调暗灯光，帮助褪黑激素（melatonin）自然分泌；不滑手机，因为蓝光加焦虑内容是双重打击；不喝酒，因为酒精会破坏 REM 睡眠，对 oncall 焦虑尤其致命；房间温度维持在 18 到 20°C，因为核心体温下降本身就是入睡信号。这些听起来都很常识，但 oncall 期间越焦虑越容易偷懒不做，反而把睡眠搞得更糟。

Oncall 期间的可持续节奏

我经常会因为在 oncall 期间想“放松”，结果又因为放松不下来而对自己生气，接着觉得时间过去却一事无成，焦虑就加倍了。尤其是周末必须待命、不敢乱跑时，那种心情特别明显。但 standby 本身就是一种有效的工作状态，不要试图把它过成休假。

待命 = 隐形劳动

你的身体其实一整天都在工作：皮质醇偏高、注意力放在“Pager 会不会响”上、决策能力被留给可能发生的事故。但这种劳动没有 code commit、没有 ticket close、也没有可以发 IG 的照片，所以大脑找不到证据证明这一天有做事。

Attention residue（注意力残留）

Leroy 2009 年发表在 Organizational Behavior and Human Decision Processes 的研究提出了“注意力残留（attention residue）”的概念：当你从任务 A 切换到任务 B 时，部分注意力仍会停留在 A 上，尤其是 A 还没完成，或者没有明确收尾点的时候。这个残留会在统计上显著降低你在任务 B 上的认知表现（Leroy, 2009, OBHDP ¹⁰）。

（补充：原始研究只证明了“有显著下降”，并没有量化成“脑力剩一半”这种直观比例；后者只是流行写法的简化。）

Oncall 是 attention residue 的极端情境：A（随时可能来的 page）永远不会真正关闭，所以你做的每件“私人时间”都带着残留。看书记不住、追剧没剧情、和朋友发消息心不在焉，不是你不专心，而是大脑的注意力被预留在一个永远开着的任务上。这个延伸是我自己对 oncall 情境的解读，不是 Leroy 原始实验的结论。

后来 Leroy 和 Glomb（2018）在 Organization Science 提出 ready-to-resume plan 作为对策：被打断时，花一两分钟写下“我做到哪一步、下一步要做什么”，明确的书面收尾能让大脑相信任务不会丢失，从而更干净地切换到下一件事（Leroy & Glomb, 2018, Organization Science ¹¹）。放到 oncall 场景里，每次处理完一个 incident、准备回到原本活动前，花一分钟记下“incident 编号、当前状态、下一步观察什么条件、什么情况会再次被叫”，会比直接放下手机去做家务或看书轻松得多。

我自己会用的策略

可以尝试用认知行为治疗法（Cognitive Behavioral Therapy，简称 CBT）去反转对值班的看法。比如在心态上把周六 6AM 到 6PM 直接画成“工作时间”；6PM 之后才是你的周末。这样你不会用“正常周末”的标准去评价它，也就不容易觉得自己失败了。一个被工作占用的日子，本来就不太会长得像自由的日子。

Oncall 期间我也会给自己一个极低门槛的成就清单：

• 走路 15 分钟，不要离家太远
• 读完一章书 / 一篇文章
• 煮一杯像样的咖啡，或者拍一张照片
• 写三行日记

每天勾一项就算数，给大脑留下可观测的证据：今天确实有发生事情。没有这个锚点，standby 状态很容易把整天吞掉，心理上也很容易觉得自己什么都没做。

我会把值班周当成 60% 到 70% 工作量的一周来规划：不排需要深度讨论的会议、不排需要长时间专注的深度工作、不学新技术、不安排面试，保留缓冲时间来应付频繁的 context switch。相比照常排 100% 然后因为 incident 一直崩溃，这种做法可持续得多。

至于 oncall 期间怎么度过 standby 时间，重点是用“低认知负担活动”代替纯放松。对处于过度警觉状态的人来说，冥想通常会在前期放大焦虑，因为它会逼你注意内在讯号。改成让大脑有 70% 被占住、还留 30% 可以接 page 的活动会轻松很多，例如散步（户外更好）、做饭洗碗整理房间、拼图这类简单手工、听 podcast 而不是纯音乐，让大脑有东西抓着就不会放空乱想。这些活动的共同特征是有节奏、有反馈、决策负担低。

另一个常见坏习惯是每 5 分钟检查一次 dashboard 或 Slack，这是强迫式的反复确认，会强化焦虑回路。原则很简单：只在响的时候反应。如果你不信任自己的 alert 系统，那是 alert 设计的问题，回到前面那一段，不是靠更频繁的人工检查就能解决的。

被 page 进会议前，先争取 5 分钟缓冲

Oncall 通常会设置对应的 Response SLO。在这个机制下，如果在一定时间内没有回应，就会继续升级。不论是 incident channel、客户会议，还是主管把案子升级给你，除非是火烧眉毛的 P0 等级事件需要直接加入，否则都应该善用 SLO 的设计，给自己保留缓冲时间来完成反应。也就是说，我在接到 Pager 并完成 Ack 之后，可以：

• 先上个洗手间、倒杯水，再回到键盘前
• 先稍微收尾手边的事，或者简单记一下目前进度
• 如果是熟悉的服务，顺手看一下最近一次相似 incident 的 postmortem 或对应 runbook，把“上次怎么处理”重新放进工作记忆

我也常提醒自己：别人急，但我不急。我需要比周围的人更平静，才能把问题解决。如果有人一直在催，可以试着这样沟通：

Give me 5 minutes to spin up - I’ll join with context.

如果是半夜被叫醒，这 5 分钟多少能降低 sleep inertia 的伤害，并建立最低限度的状况掌握。带着背景晚到 5 分钟，远比什么都不知道却准时加入好得多。

不同角色的补充建议

不同 oncall 角色面对的痛点不太一样，下面针对几种典型角色补充一些建议。

Software Engineer 或 Platform Engineer

主要的 oncall 痛点是深度工作被打断，但 incident 频率不一定高。比较有效的做法是值班周完全不排专注时段或重要的 PR review；standby 期间挑小任务做，例如 code review、写文档、处理技术债、学习新东西。你也可以利用 oncall 的空档去改善自己 service 的 alert 和 runbook，这对下一轮 oncall 的同事也是直接的帮助。

SRE 或 DevOps

主要痛点是警报量加上跨团队协作。如果团队愿意采用 Google SRE 的“每轮班最多 2 个 incident”原则来校正 alert 设计，就能有效减少不必要的 toil。每次 oncall 结束做一次个人回顾，问自己哪些 alert 是噪音、哪些 runbook 该补。blameless postmortem 文化是最有效的长期减压工具。让 incident 变成学习，而不是创伤，工作就会轻很多。

Customer Engineer 或 Technical Solution Engineer

这类角色比较特殊，尤其在面对企业级或重点客户时更是如此。这个角色的挑战在于：你不只是要解决问题，还要管理客户情绪；产品线范围太广，不可能每一块都非常熟；客户往往期待立即回应。

这时候可以把这个角色定义成 incident commander，而不是 SME。这类客户 oncall 的工作是搞清楚问题的影响范围、降低客户焦虑、找到对的人、并维持固定的沟通频率。“我不知道”是合理的回答，只要后面接着“但我会找到知道的人”。对客户的标准话术可以是：

I’m not the SME for this specific component, but I’m pulling in [team] now. In the meantime, let me confirm the impact so we can prioritize correctly.

这句话的好处是：诚实说明自己不熟，建立信任；给出下一步，降低焦虑；把话题重新导向你能掌控的范围。另外，非 oncall 时间建立个人 runbook 对 TSE 角色特别重要：每次遇到不熟的产品，花 15 分钟记下它是做什么的（一句话）、常见的失效模式（3 个）、该找谁（team / Slack channel / on-call rotation）、dashboard 在哪。两三个 oncall 周期积累下来，你会有一份比官方 runbook 更实用的个人速查表。

何时该找专业协助

虽然 oncall 焦虑在某个范围内是合理的职业适应，但下面这些信号出现时，请寻求专业医疗建议：

• oncall 结束后 1 到 2 周仍然无法放松，或者停不下来检查 Slack
• 开始害怕下一次 oncall，而不只是单纯不喜欢
• 影响到工作之外的人际关系、兴趣或食欲
• 出现恐慌发作，比如突然心跳加快、呼吸困难、觉得自己快死了
• 用酒精、药物或暴饮暴食来缓解
• 出现解离、挥之不去的侵入性念头，或者入睡前的幻觉警报

这些状态不一定等于正式的 PTSD 诊断，但在临床语言里，已经可以用 hypervigilance、occupational stress、睡眠障碍、焦虑反应，甚至创伤相关症状来理解。对于 PTSD 或创伤相关症状，trauma-focused CBT 和 EMDR 都是常见且有证据基础的治疗选项。实际需要几次治疗，仍然取决于症状严重度和个人背景。英国 Royal College of Psychiatrists 也提到，PTSD 的心理治疗常见安排大约是 8 到 12 次，但复杂情况可能需要更久。最重要的是不要拖到“我快崩溃”才去看；越早接触专业协助，效果通常越好，成本也往往更低。这不是脆弱，而是职业伤害，就像 RSI 是长期打字的职业伤害，hypervigilance 是长期 oncall 的职业伤害。

结语

Oncall 是现代分布式系统必要的税，但这个税可以、也应该被设计得可持续。如果只能做三件事：这周先盘点 alerts，把不需要立即处理的关掉声音，或者改成视觉提示；下次 oncall 严格执行 wake-up protocol（水 -> 冷水 -> 光 -> 动作 -> 呼吸）；长期把就寝时间规律性控制在 ±1 小时内。

幻觉警报、被叫醒时无法决策、standby 时无法放松，这些都是有研究、有名称、有对策的生理反应，不是个人韧性问题。结构性层面，也就是 alert 调校、轮值设计、blameless culture，是团队的责任；个人层面，也就是睡眠、营养、运动和心理工具，是你能掌控的部分。两者缺一不可。

每个人的工作环境、生理节奏和团队文化都不一样，这篇整理也不一定每一条都适合每个人。重点是先理解这些反应背后的机制，再反复试验适合自己情境的工具。

参考资料