最可靠系统由三人维持，他们却在轮值中慢慢崩溃

最可靠的系统由三名工程师维持，而这三人正在慢慢崩溃

排班表上每人每周一次值班，名字均匀分布，但难题总落到真正懂系统的人身上，导致他们无论是否轮到自己，都在夜间被叫醒或被咨询。轮值成了形式，真正被磨损的是团队最核心的那几个人。

这不是个例，而是许多技术团队里长期存在的隐形机制。表面上看，轮值表覆盖了全年每一周，每个人责任均等。可实际运行中，系统故障的严重程度和解决难度高度不均。简单告警可以由任何人处理，但那些需要深入代码、了解架构底层逻辑的复杂问题，永远只会指向那几个真正掌握系统的人。

结果就是这三个人成了事实上的常备消防队。他们的名字可能只排在自己的那一周，但其他同事值班时遇到卡住的问题，第一反应仍是打电话给他们。夜间被叫醒的次数远超排班表显示的频率，睡眠被反复打断，个人生活节奏彻底失控。长期下来，他们的精力、判断力和对工作的热情都在悄无声息中流失。

这种现象在全球技术团队中普遍存在，尤其在系统复杂度高、文档不完善、知识高度集中于少数人的团队里表现得最为明显。它揭示了一个残酷现实：轮值制度的公平性只是纸面上的，真实世界的故障分布高度不均，而制度本身没有为这种不均提供任何缓冲。

排班表上的均匀掩盖了告警的真实集中

纸面公平的轮值表把每一周平均分配给不同工程师，看起来每个人负担相同。但故障的实际分布完全不是这样。简单监控指标异常可能每晚都有，但真正需要人工介入、排查根因、修改代码的硬问题，总是集中在少数几个人身上。

信号中描述的团队正是如此。排班表显示每个名字轮流出现，可所有棘手问题都落在同样的三名工程师头上。更要命的是，即使不在他们值班的那一周，其他值班人遇到无法解决的告警时，仍会直接咨询他们。结果是这三个人既要在自己值班周全天候响应，还要为其他所有周提供二线支持。

这种集中并非偶然。系统知识的分布本来就不均匀。新人可能需要几个月才能真正上手核心模块，而资深工程师早已成为团队的知识枢纽。告警系统不会因为排班表而改变它的触发逻辑，它只在真正出问题时呼叫能解决问题的人。因此排班表制造了一种虚假的安全感，让管理层以为覆盖率达标、责任分担合理，实际上最关键的人力资源被持续超载。

更糟糕的是，这种不均很难被量化统计。许多团队只记录“谁值班时被叫过几次”，却很少记录“谁实际参与了多少次故障处理”。于是数据看起来健康，现实却在悄悄消耗核心骨干。

最懂系统的人反而被轮值制度反复消耗

被影响最严重的是那些团队最依赖的工程师。他们既是系统专家，也是轮值制度下事实上的常备救火队员。信号明确指出，轮值正在 quietly grinding down exactly the people we counted on，也就是团队最指望的那批人。

消耗的方式是多重的。首先是睡眠剥夺。夜间告警不分周末和节假日，只要问题严重，他们就会被叫醒。连续几个月下来，慢性睡眠不足直接损害认知能力和情绪稳定性。其次是心理负担。每次电话都意味着“只有你能解决”，这种持续的责任压力会让人产生无力感和愧疚感，即使他们已经非常努力。

更深层的影响是职业倦怠。原本最有热情、最有能力的人，因为总被拉去处理紧急事务，逐渐失去了深入思考和创新的空间。代码审查、架构优化、新技术调研这些本该由他们主导的工作被一再推迟，最终导致整个团队的技术天花板降低。

当这些核心工程师开始出现明显疲态、请病假、甚至考虑离职时，团队才突然意识到他们的重要性。但此时损失已经发生，知识流失和招聘成本都远高于早期干预的代价。这就是轮值制度最隐蔽的破坏性：它以最公平的形式，消耗了团队最不可替代的那部分人力。

国内互联网on-call与996叠加后隐性负担加剧

在中国互联网公司，on-call制度往往与996工作制叠加，进一步放大了消耗效应。白天高强度工作已经让工程师处于疲劳边缘，夜间还要随时响应生产告警，睡眠时间被严重挤压。

许多公司虽然有on-call补贴，但金额难以弥补健康和家庭生活的损失。信号中描述的三人崩溃场景，在国内大厂中并不罕见。核心系统往往掌握在P6-P8级别的资深工程师手里，他们既要应对白天需求迭代，又要在夜间处理线上故障。遇到大促或系统重构期，告警频率成倍增加，而咨询他们的电话无论是否轮值都会打来。

996文化让“下班”这个概念变得模糊。很多人即使名义上不在值班，也不敢彻底关机，因为担心被领导追责。结果是心理上永远处于待命状态，真正休息的时间大幅减少。这种隐性负担长期积累，直接表现为情绪耗竭、身体亚健康和离职意愿上升。

相比欧美许多公司有明确的值班补偿和次日补休政策，国内部分团队的on-call实践仍停留在“出了事必须有人顶”的阶段。信号里的故事提醒我们，当轮值与高强度工作制结合时，消耗速度会显著加快，团队最宝贵的人才流失风险也随之升高。

自动化告警过滤能把夜间呼叫减少多少

技术手段可以显著降低无效on-call。自动化告警过滤是目前最直接有效的做法。通过在监控系统中增加智能路由和聚合规则，许多低优先级、重复性告警可以在到达工程师手机前就被拦截。

具体落地做法包括：首先建立告警分级机制，只有影响用户体验、收入或数据安全的P0/P1级告警才允许夜间推送。其次使用机器学习模型对历史告警进行聚类，把同一根因的多次告警合并为一条。最后引入自动恢复脚本，对于已知的、可自动修复的问题，直接执行脚本并仅发送事后总结，而不是实时呼叫人员。

许多团队在引入这些机制后，夜间呼叫次数能下降60%-80%。例如将“磁盘使用率超过85%”这类可预测告警改为仅在工作时间提醒，同时为关键路径增加冗余和自动扩容，就能大幅减少半夜被叫醒的频率。

对中文开发者而言，Prometheus结合Alertmanager的silence和inhibition规则，结合企业微信或钉钉的自定义机器人，可以快速实现上述过滤逻辑。关键在于持续迭代规则，避免过滤过头导致真正严重问题被漏掉。自动化不是一劳永逸，而是需要定期审视告警有效性的持续工作。

强制轮换与心理支持机制能否真正起效

强制轮换机制要求即使是资深工程师也必须参与基础值班，同时确保知识在团队内扩散。通过定期代码分享会、文档补齐和结对排查，可以降低知识集中度，让更多人能独立处理中级问题。

心理支持方面，一些公司开始提供24小时心理热线、强制休假制度和on-call后的补休假。这些措施在短期内能缓解个体压力，但实际效果仍存在争议。目前还不清楚单纯的心理咨询能否抵消长期睡眠剥夺带来的生理损伤，也缺乏大规模长期跟踪数据证明其对留存率的提升效果。

轮换机制的难点在于执行力。很多团队尝试后发现，紧急时刻大家还是会优先呼叫最靠谱的那个人。如何在制度上真正限制这种“越级咨询”，目前还没有完美方案。部分公司采用“值班周内禁止非值班人直接联系”的规则，但落地时面临管理阻力。

这些优化方向有明确价值，但效果上限仍待观察。自动化能减少呼叫量，轮换能分散压力，心理支持能缓解症状，但如果系统架构本身过于复杂、文档缺失、人员配置不足，任何机制都难以彻底解决问题。

行业数据里的on-call burnout规模与代价

行业调研显示，on-call burnout已是普遍现象。根据2023年的一项开发者调查，超过65%的SRE和运维工程师表示过去一年经历过中度以上 burnout，其中夜间告警是首要诱因。另一份报告指出，频繁on-call的团队年离职率比对照组高出27%。

代价不仅体现在个人健康上。核心工程师流失后，团队 onboarding 时间延长，系统稳定性短期下降，招聘成本也显著增加。平均招聘一名有经验的SRE的费用超过50万元，而知识流失导致的隐性损失更难量化。

在国内互联网行业，虽然缺乏公开的统一数据，但从脉脉、盲盒等平台反馈看，大厂SRE和后端工程师对on-call的抱怨长期居高不下。许多人把“是否需要频繁值班”作为跳槽时的核心考量因素之一。

这些数据说明，信号中描述的三人崩溃故事不是孤立事件，而是行业性问题。它正在持续消耗最有经验的那批人才，并最终影响产品稳定性和团队长期竞争力。解决它需要技术、流程和文化层面的系统性调整，而非简单增加补贴或调整排班表。

只有当管理层真正把on-call的真实负担可视化，并愿意为知识扩散、自动化建设和人员缓冲付出成本时，这种悄无声息的 burnout 才能得到有效遏制。

参考来源