Oncall Routing 到底在考什么？把我整理到的思路拆一下

之前整理 OpenAI 面经的时候，oncall routing 这道出现频率不算低，前两天还有人在我的帖子下面问这道到底考什么。把我记下来的笔记发出来，大家有出入欢迎纠正。先说清楚，我没面过，这就是整理公开面经记的笔记。
题面大概长这样
系统会收到 alerts，每个 alert 属于某个 service，带 severity。要你把 alert 分给对的 oncall，该通知谁、通知不到怎么办，都要设计出来。形式有 coding 也有设计讨论，核心是同一套东西。
我拆下来的几个点
先定数据

• service 和 team 的映射：一个 alert 先要知道归哪个 team 管
• oncall schedule：每个 team 谁在值班，rotation 怎么排，时区怎么算
• alert 本身：service、severity、时间、内容

匹配逻辑

• 按 service 找到 team，再按当前时间找到正在值班的人
• severity 高的走更快的通道（直接打电话？），低的可以只发消息攒着

没人理怎么办

• 发出去之后一段时间没人 ack，就 escalate 到下一个人或者 backup
• 升级链要提前定好，不能临时现找

防打扰

• 同一个问题短时间内来一堆 alert，要能合并/dedup，不然 oncall 直接被刷爆
• 已经有人在处理了，后续相同的 alert 就不要重复通知全组

容易被追问的地方

• 值班的人请假或者交接中间有空档怎么办
• alert 风暴：一晚上来几百条，怎么分组、怎么排序
• 怎么记录谁处理过、处理了多久，后面复盘要用
• 跨时区 team 怎么交接

我的理解是这道题考的不是某个算法，而是你能不能把一个真实 oncall 系统里乱七八糟的情况都想全。写代码的话，schedule 查找和 escalation 这两块最容易写乱，建议先把数据结构定清楚再往下写。
面过这道的朋友欢迎补充，尤其是 coding 版本到底要求写到哪一步，我整理的时候这块信息最少。

coding版可以补一组竞态测试：同一incident的ack和升级timer换序各跑一遍，再把timer重复投递一次。状态变化时递增version，timer带上预期版本，只有状态仍为triggered且版本匹配，才原子更新升级级别并递增版本；ack先成功后旧timer应失效，重复timer也不能多升一级。通知重试和升级状态分开处理，别把状态更新成功当作通知一定送达。ack暂停升级，resolve才表示关闭；如果配置了ack超时，超时后还会恢复升级，PagerDuty文档也区分了这些行为：https://docs.pagerduty.com/incident-management/incidents/overview

dan_chun 发表于 2026-10-31 15:17:12
coding版可以补一组竞态测试：同一incident的ack和升级timer换序各跑一遍，再把timer重复投递一次。状态变化时递增version，timer

这个点确实是最容易漏的，ack 和 timer 换序那组我之前没想到这么细。你说的 timer 带预期版本我记下了，感觉是防重复升级最干净的做法。想多问一句：如果同一个 alert 的 timer 被重复投递，你会直接按 alert id + version 去重，还是让版本校验本身来挡掉就行？