别让 On-call 累垮最负责的人

On-call 最常见的失败，是最负责的人替整个团队值班，直到离职。避免这种结局，无须大规模改组。四项基础就能挡住最坏的局面：

• 一张公平的轮值表。
• 一条明确的补偿规则。
• 一条自动升级路径。
• 一个统一的告警收敛入口。

下面先讲一个真实的例子，再逐条说明做法，最后列出六个常见反模式。

一个值班一年后离职的工程师

张三（化名）连续一年每天 On-call，出门都要带着电脑。他所在的组算上主管共四人。主管认为另外两人不可靠，不让他们值班，并告诉张三值班能锻炼技术。年底，张三的绩效只是普通，两位专心写代码的同事反而更高。张三因此决定离职。

另一种情况同样常见。主管宣布推行 DevOps 文化，“You build it, you run it, you monitor it”，于是名义上全员 On-call。实际上，负责的人时刻带着电脑，其他人出了问题从不响应。追问时理由总是现成的：睡着了、没信号、在洗澡。最终，组里人不少，却只有那位负责的人累到离职。主管再招新人，循环继续。

这是双输的结局：

• 对那位负责的人：长期委屈，最终离职。
• 对团队：管理水平低、人员流动大、系统稳定性差，外人都看得出来。

把问题都归给管理、文化或主管个人，对眼前的局面帮助有限。一线和二线主管仍有可以动用的手段。一线工程师也可以拿下面的做法，与直属主管讨论。

让 On-call 公平且可持续的六项做法

一、排班轮流，由团队共同承担

没人愿意一直值班，因此要排班、轮换、团队共担。关键在于公平。用一张排班表把所有人排进去，并提前考虑临时调班和节假日值班。

用 Excel 维护排班，起初可行，时间长了就很费力。换班通知靠人提醒，一次临时调班就会打乱整张表。Flashduty On-call、PagerDuty、OpsGenie 等产品都内置排班能力。自动轮换、换班通知、临时调班和节假日排班都能支持，排班管理的负担随之减轻。

二、为值班人员提供补偿

值班当周日薪翻倍，值班人员的积极性会明显提高。有的公司为 On-call 设立专门的奖金，或提供额外调休。有了补偿，大家才愿意轮流值班。张三一年没休过一次假，正是缺少补偿的结果。

公司需要为此付出成本。换来的是更快的响应、更稳定的系统，以及工程师更高的满意度。

三、先有奖励，再谈问责

奖惩分明、公平公正，制度才能长久。只有处罚、没有奖励，就成了压榨。

反过来，值班人员若故意拒接电话、放任告警，最终引发事故，也要承担相应后果。后果可以是影响绩效、影响奖金，严重时承担更重的责任。制度必须让人信服，否则无法落地。

告警长时间无人处理时，系统应自动升级给备班同事或直接主管。这样每条告警最终都有人负责。这要求告警分发平台支持升级机制。PagerDuty、OpsGenie 和 Flashduty 都提供这项能力，单个人的疏漏不会让告警被遗漏。

四、优先处理值班中发现的隐患

值班人员发现稳定性隐患后，应及时提交讨论、确定优先级并尽快修复。系统越稳定，告警越少，值班也越轻松，这是一个正向循环。最糟的情况是隐患长期无人处理，同一条告警反复响起，消耗值班人员的耐心。

五、用统一平台收敛和降噪告警

一次网络故障可能触发上千通告警电话。值班手机被打满，连正常通话都无法接通。

这时需要告警平台统一收敛和降噪。同一根因引发的告警合并为一条，不重要的告警被压下去。一般的监控系统专注于数据采集、存储、可视化和告警生成。告警产生之后的收敛、降噪、分发和升级，往往不是它们的强项。多数团队无须从头自建，成熟产品可以把人力留给规则治理和稳定性改造。

六、为值班准备完备的 SOP

处理告警时，人往往精神紧绷，最容易出错。一份完备的标准操作流程（SOP）能写清楚每种情况的处理步骤。它既能提高处理效率，也能降低误操作的概率。

如果能把 SOP 的逻辑固化为脚本，在告警触发时自动执行，效果更好。值班人员无须半夜起床敲命令。夜莺开发告警自愈功能，正是出于这个原因。

每个新模块上线前，应先完成三项准备：

• 梳理服务等级指标（SLI），并配置好告警规则。
• 编写 SOP 手册，并对团队进行培训。
• 指定紧急联系人，一般是模块负责人。负责人如果不希望被频繁打扰，更要把 SLI 和 SOP 做扎实。

六个常见的 On-call 反模式

下面列出多年来常见的 On-call 反模式，可以对照检查团队的现状。

告警分级混乱，所有告警都不敢忽视

配置规则时没有认真斟酌级别，所有告警混在一起。每条都不敢忽视，高优先级问题被淹没，低优先级问题却占用了大量精力。

建议把级别收敛为 P1、P2、P3 三档。级别太多，配置时心智负担重，大家会草率选择，分级反而更乱：

依赖个人经验，缺少标准流程

故障处理全凭几位资深成员的直觉，经验靠口口相传。成员一旦变动，问题就会暴露。而且紧急情况下，只存在于脑中的经验最容易因紧张而出错。

应对方法是把经验沉淀为详细的 SOP，让新人也能照着上手。SOP 还需要定期演练来保持有效。长期不维护的 SOP 很可能已经过时，演练中发现问题要及时修正。

故障复盘流于形式

问题解决后直接翻篇，不做复盘，同样的问题反复出现。或者复盘过于随意，只处理表面症状。

复盘可以连续追问几个“为什么”来加深分析，但不必追到极致。很多问题追到最后都会落到组织和文化上，一线团队无法立即解决。更重要的是举一反三。优秀工程师与普通工程师的一大差距，在于能否从一个故障推及一类问题。

On-call 压力分配不均

名义上全队接告警，实际上一位负责的人接了大部分，这正是张三的处境。压力集中在少数人身上，倦怠和离职只是时间问题。

除了公平轮值和补偿，还应设置主备 On-call 机制，避免单点压力过大。

新人也不必抗拒 On-call，值班是很好的成长方式。但值班时需要动手操作，新人应先得到资深同事的指导，避免把小问题变成大问题。最好设置一道简单的审批，按流程操作，出了问题也能分清责任。

忽视工具和自动化建设

故障处理全靠手动，效率低且容易出错。一些资深成员习惯了手动操作，不愿学习新工具，也不愿建设自动化。

该投入的地方要投入：建好监控、告警和自动化工具，减少手动操作。例如，用脚本快速回滚服务或切换集群。止损工具是经验的沉淀，比只能阅读的 SOP 手册更可靠。

沟通和升级机制缺失

故障发生时信息传递不畅。该拉进来的人没有及时加入，业务方和主管没有及时知会，处理进展也无人同步。结果是响应延迟、资源调配混乱。

团队需要清晰的沟通流程（例如作战室机制）和升级路径。信息要快速触达相关人员，并按严重程度及时升级。Google SRE 一书专门讨论过：故障期间的对外沟通很关键，通常由专人负责。有人指挥统筹，有人负责处理，有人负责沟通，多人协作才不会陷入混乱。

在最负责的人离开之前行动

主管应认真对待 On-call，不要等到最负责的人离职才后悔。先建立文首的四项基础：轮值表、补偿规则、升级路径和告警收敛入口。Flashduty On-call 可以把其中的排班、升级和告警收敛串进同一条 On-call 流程。