排班只是 On-call 的开始

On-call 是一个从欧美技术圈传来的词，中文里没有完全对应的说法，最接近的是“值班”或“待命”。但做过的人都知道，它远不止“排个班、接个电话”那么简单。一套像样的 On-call 体系，是从监控告警产生的那一刻起，到工程师认领、处理、复盘为止的一整条流水线。任何一个环节做得糙，整条链路的体验都会塌掉。

下面这张图把这条流水线的关键环节都画了出来。这篇文章不打算逐个给你念定义（网上的定义已经够多了），而是想沿着这张图，把每个环节为什么需要、做到什么程度合适、哪里容易踩坑讲清楚。

告警集成：先把所有告警收到一处

On-call 的第一步，是把散落在各个监控工具里的告警收敛到一个平台上处理。绝大多数监控系统都支持 Webhook，所以一个 On-call 平台只要针对不同来源做接口适配、提供对应的 Webhook，用户的接入成本就最低。

有些不那么开放的系统只会发邮件，连 Webhook 都没有。这时候如果平台能收下这些邮件、解析正文，把它也变成结构化告警，就是一种兜底手段。取舍点：邮件解析天然脆弱，对方稍微改一下模板就可能失效，所以它是兜底，不是首选。能走 Webhook 就别走邮件。

标签增强：告警字段越富，处理越快

很多监控工具发出来的告警是“光秃秃”的，只有机器名、监控项、阈值这么几个字段。工程师半夜被叫醒，盯着这么几个字，根本判断不了影响面。

如果平台能对接外部元数据（比如 CMDB），在告警进来时把字段补全（这台机器属于哪个业务、哪个环境、谁负责），那么这些补出来的标签既可以驱动更自动化的分发，也能让工程师一眼看出严重程度。基线：值得增强的，是那些能直接影响“该不该叫醒人、该叫谁”的字段。为了好看而堆一堆没人看的标签，只是增加噪音。

聚合降噪：把 N 条压成有限几条

这是 On-call 产品最核心的能力之一。一次大规模故障可能同时触发成百上千条告警，如果逐条通知，工程师的手机会被打爆，反而拖慢了处理。聚合降噪的目标，是把同时触发的一批相似告警归并成有限的几个故障（incident），只以 incident 为粒度通知。

聚合可以基于规则，也可以基于语义相似度，而且可以跨数据源：来源于 Zabbix 的告警和来源于 Prometheus 的告警，只要“相似”就能并到一起。除了大规模实例告警，那种“一会触发、一会恢复、一会又触发”的抖动告警，也是典型的可收敛场景，可以用相同标签把它们收敛成一个 incident，大幅降低频率。

告警抑制：用得克制，别重度依赖

抑制和降噪不是一回事。降噪是把相似的告警合并；抑制是引入“某种依赖关系”：高级别告警抑制低级别告警，或者底层基础设施告警抑制上层模块告警。比如机房断网了，就没必要再为这个机房里每个服务单独报警。

抑制听起来很美，但这里有个坑：这些依赖关系维护成本很高，而且不容易解释。一旦某条该响的告警被一条抑制规则悄悄吃掉，排查起来非常痛苦。所以抑制适合用在少数边界清晰、依赖稳定的场景，不建议在大规模场景里重度依赖。能用聚合解决的，就别上抑制。

排班：别让整个团队被反复打断

排班的目的，是避免整个团队被告警反复打断，同时保证任何时刻都有合适的人在线。On-call 确实能让工程师成长，但它琐碎、又经常起夜，长期连轴转身体会垮，所以必须轮值。

设计排班时，有几个绕不开的维度：

• 公平性：确保每个人分配均衡，避免某个人总是在周末或节假日值班。
• 灵活性：允许提前或临时换班，应对请假、休假等场景。
• 轮换周期：按小时、天、周、月轮换都行，取决于业务节奏。
• 角色：通常分主值班和备值班。主值班是第一响应人；主值班过载或没及时响应时，问题升级给备值班。
• 交接通知：轮换交接时要有清晰的通知机制，可以提前 N 分钟通知下一班，也可以每天固定时间播报一次。

顺带说一句成本账：愿意 On-call 的工程师不是没有，毕竟可能换来双倍工资或调休。但要是全员 On-call，公司补贴成本就受不了了。所以排班轮值也是一种省钱的办法：参与的人变少，公司付出的成本自然变少。

认领、升级、协同：让每条告警都有归属

认领：理论上每一条告警都应该被认领。反过来推一句，如果一条告警发出来没人认领，也没造成任何后果，那它本就是无意义的，根本不该发。通常用 MTTA（平均认领时间） 来量化认领的效率。

升级与转派：针对不同等级的告警提前画好升级路线，能显著降低值班人的心理压力。升级可以手动，也可以自动。比如某条告警超过 30 分钟既没人处理、也没恢复，就自动升级给主管或备份人员，确保问题最终有人兜底。

这里值得展开讲一种成熟的分层响应模式，很多需要 7×24 支持的团队都在用：

做法上，给 L1/L2/L3 各建一张值班表，再在分派策略里设三个环节，每个环节绑定对应的值班表。这样“先叫谁、叫不动再叫谁”就自动跑起来了，不用人去半夜手动拉人。

协同：处理过程中随时可以把相关人拉进来。关键是拉人时要准确及时地通知到对方，并把处理过程和时间线完整保留下来，让后加入的人能快速看懂全貌，而不是反复问“现在到哪一步了”。

通知：触达体验决定一切

再好的告警，发不到对的人手上、对方点不动，都等于零。海外团队大量用 Slack，它几乎成了协同领域的“操作系统”；国内则是企业微信、飞书、钉钉三足鼎立。这些 IM 都支持开发内置应用，能在 IM 卡片里直接认领、关闭、转派、处理告警，是提升 On-call 体验的关键。

半夜告警响了，但你一看就知道这条短期内不用动手。如果能掏出手机在 IM 里点几下处理掉，就不用爬起来开电脑。这一个细节，对幸福感的提升是实打实的。

数据统计：无数据，不治理

把全公司的告警都收到一个平台之后，最大的红利是能按维度做统计。告警压缩率、MTTA、MTTR、认领比例、告警数量，是衡量 On-call 效率的关键指标；按业务、团队、个人去切分，就能定位薄弱点。

更实际的一个用途是治理告警规则本身：哪些规则在频繁触发，往往说明规则本身不合理，既浪费了电话短信费用，又让员工不开心，服务稳定性还没见改善。这类规则该改的改、该删的删。

比工具更重要的：让告警值得被叫醒

上面这些环节，都是在“告警已经产生”之后做文章。但最划算的降噪发生在告警产生之前，也就是从源头治理告警规则：

• 每条告警都应该是 actionable 的：即对应一个明确的止损动作或 SOP。如果一条告警发出来只是个“提醒”，不需要任何人做任何事，那它八成是多余的。实在怕漏掉大事，就让它自动建一张 ticket，定期扫一眼，别打电话、发短信。
• 对结果类指标告警，而不是对原因类指标告警：对外提供 HTTP 服务，接口成功率和延迟是结果类指标，最该关注；CPU 利用率这类是原因类指标，放进大盘可观测即可。原因类指标有问题、结果类没问题，说明还没影响业务，不必半夜叫醒人。

很多团队的告警之所以越堆越多，是因为每次故障复盘第一个问题都是“告警全不全”，员工为了不挨怼，宁可多加规则也不愿少加。长此以往攒出一大堆有用没用的规则，新人来了受不了又走，对团队是慢性损耗。

On-call 的好坏，一半靠产品，一半靠认知。如果一线工程师很痛苦，而管理层根本没注意到，沟通起来就是鸡同鸭讲。把它认真对待，有时候比加薪更能提升团队的幸福感。

Flashduty 把上面这张图里的每个环节都做成了能力：多源告警集成、聚合降噪、排班升级、IM 双向触达和数据看板。如果你正在搭或重做 On-call 体系，可以从这里开始：Flashduty。