On-call 倦怠的隐形加速器：团队心理安全感的三个断层
凌晨两点的两种剧本
同样的告警，同样的 P1 故障，为什么 A 团队的工程师在值班后需要整整三天才能恢复生产力，而 B 团队的工程师第二天上午就能正常参与代码评审？
这不是意志力或敬业度的差异。根据我在多家基础设施团队的观察，高 burnout 团队与韧性团队之间的"心理耗能比"往往达到 3:1 甚至更高。问题的根源不在于告警数量本身，而在于告警发生时，大脑所处的"心理生态位"。
断层一：模糊威胁 vs 清晰边界（不确定性税）
高 burnout 团队的特征：告警内容含糊（"服务异常"），影响范围不明， escalation 路径像迷宫。工程师长期处于**认知警觉（Hypervigilance）**状态——即使没有告警，潜意识也在扫描威胁。
心理学机制：不确定性会触发大脑的"威胁检测回路"，持续消耗前额叶皮层的葡萄糖储备。这种"不确定性税"让一次简单的重启操作背负了巨大的认知债务。
韧性 team's 设计：
- 告警即上下文：每条告警必须附带影响面评估（用户可见性 %）和上次相似事件的 Playbook 链接
- 降级开关的可见性：明确标注"何时可以等到早上处理"，给予工程师认知退出权
断层二：孤独问责 vs 分布式认知（社会缓冲带）
危险信号：当值班工程师说出"这台服务器只有我能救"时，团队已经滑向孤立性应激（Isolated Stress）。
高 burnout 陷阱："英雄文化"将值班责任原子化到个人。告警响起时，工程师感受到的是被审判的恐惧而非解决问题的兴奋。这种孤独感会放大皮质醇水平，且缺乏社会支持进行情绪调节。
韧性 team's 协议：
- 15 分钟规则：任何值班人员有权在 15 分钟内呼叫 backup，无需证明"我已经尽力了"
- Warm Handoff：交接班不是发消息，而是语音确认，确保"心理责任"的转移，而非仅仅是监控权限的转移
- 故障的集体所有权：Postmortem 使用"我们"而非"你"作为主语，区分"人的失误"与"系统脆弱性"
断层三：习得性无助 vs 代理感恢复（控制幻觉的终结）
最关键的断层：工程师是否相信"我能从根本上减少这类告警"？
当团队长期处于反应性救火（Reactive Firefighting）模式，工程师会发展出习得性无助（Learned Helplessness）——即使面对可修复的根因，也默认只能做临时止血。这种代理感（Agency）的丧失是 burnout 的核心加速器。
韧性 team's 机制：
- 每周 2 小时根因预算：强制要求值班人员将 20% 的值班时间用于永久性修复，而非仅仅关闭告警
- 噪声消灭游戏：每月统计"无需人工介入即可自愈的告警"，团队一起优化阈值，让工程师看到系统随自己意志改变
- 轮换的节律感：遵循 Ultradian Rhythm（超日节律），单次值班不超过 12 小时，确保 REM 睡眠周期的完整性，支持大脑对创伤性事件的记忆再巩固（Reconsolidation）
可操作的检查清单
如果你怀疑自己的团队正处于高 burnout 轨道，用以下三个问题快速诊断：
- 模糊性测试：新来的工程师能否在不询问老员工的情况下，判断当前告警是否需要立即 wake up CTO？
- 安全网测试：过去一个月，是否有值班工程师在未解决故障的情况下呼叫了 backup 且未受到任何隐性指责？
- 代理感测试：团队 OKR 中是否有与"减少 On-call 痛苦"直接相关的技术指标（如 MTTR 降低或自动化率提升）？
Burnout 是系统的反馈，不是个人的缺陷
那 3 倍的 burnout 速度差异，本质上是系统韧性的量化体现。当告警无法避免时，我们能设计的是告警发生时的权力结构——工程师是拥有资源与支持的"第一响应者"，还是独自面对混沌的"替罪羊"。
修复 On-call 体验不是加装更多监控，而是重建**心理安全感（Psychological Safety）**的技术底座。毕竟，最好的 on-call 轮换，是让工程师在深夜接到电话时，第一反应是"终于可以解决这个问题了"，而不是"为什么又是我"。