最近跟一个朋友（化名张三）吃饭，三哥想离职，约我喝酒，说自己天天 On-call，出门都背着电脑，连续一年了，快崩溃了。
我问：你们组就你一个人吗？为啥只有你 On-call？
三哥一脸苦涩：我们组算上老板一共四个人，老板说另外俩人不靠谱，不让他们值班，还给我画饼，说 On-call 能锻炼技术。结果到了年底，我绩效普通，那俩安心写代码的反倒比我高。心里真不是滋味，不想干了。
显然，三哥这是遇人不淑。还有一种情况同样让人窝火。老板说咱们要推行 DevOps 文化，「You build it, you run it, you monitor it」，于是名义上全员 On-call。可现实是，老实人时时刻刻扛着电脑，不老实的人出了问题从不搭理。一追问，理由永远管够：我睡着了、刚好没信号、正在洗澡。最后的结局是，一个组里人不少，只有那个老实人累到极限，离职走人，老板再招个新人，继续这个循环。
这是典型的双输：
- 对那个老实人：长期憋屈，最终离职；
- 对团队：明眼人都看得出管理水平低、人员流动大、系统稳定性差。
这正应了那句话：
一切问题，最后都是管理问题。
当然，把锅一股脑甩给管理、甩给文化、甩给老板个人，对解决眼下的问题通常没什么帮助。所以我们不妨实际一点，看看作为一线、二线的 leader 到底该怎么做。如果你是一线干活的同学，至少可以拿这些观点跟你的直线 leader 聊聊。实在不行，把这篇文章转到群里，盼着老板能看到。
怎么做 On-call，才不至于把人逼走
一、排班轮流干，别让一个人扛
这活儿确实没人愿意一直干，那就排班、轮流、团队共担。中国人讲「不患寡而患不均」，关键是公平。弄一张排班表，把所有人都排进去，再把临时调班、节假日值班这些都考虑进来。
纯靠 Excel 维护一开始还行，时间一长就很费劲：换班通知靠人吼，临时调班一改全乱。这种事交给专门的工具更省心，PagerDuty、OpsGenie、Flashduty 这类产品都内置了排班能力，自动轮转、换班通知、临时调班、节假日排班都支持，能把排班管理的负担降下来。
二、值班的人要有奖励
本周我值班，日薪翻倍，热情一下就上来了。海外不少公司就是这么做的：On-call 有专门的奖金，或者额外的调休。这样大家才愿意轮着来，而不是像三哥那样，一年没休过一次假。
公司当然要为此付出一点成本，但换来的是响应效率、系统稳定性，以及员工的幸福感。这账，但凡精明的老板都算得过来。
三、奖之外也要有罚，但前提是先有奖
奖惩分明、公平公正，才是长久之计。只罚不奖肯定不行，那不叫管理，叫压榨。
反过来，如果值班的人故意不接电话、不处理告警，最终酿成事故，那也得有相应的代价，比如影响绩效、影响奖金，严重的甚至要承担更重的后果。制度要立得住、要服众，否则大家心里不服，强压也落不了地。
万一真出现告警长时间没人处理的情况，系统应该能自动升级，升给备班同事，或者直接升给 leader，保证每一条告警最终都有人兜底。这就要求告警分发平台支持升级机制。PagerDuty、OpsGenie、Flashduty 都有这套能力，告警不会因为一个人掉链子就被漏掉。
四、值班发现的隐患要高优处理
值班的同学如果发现了稳定性隐患，要及时上会讨论，确定优先级，尽快修掉。系统越来越稳，告警越来越少，值班的人自然越来越轻松，这是一个正向循环。最怕的是隐患一直挂着没人管，告警一遍遍响，把人活活磨没了耐心。
五、告警要有统一收敛、降噪的平台
一次网络故障，咔咔咔上千条告警电话打过来，值班手机直接被打爆，连正常通话都做不到，这时候人是会暴躁的。
这就需要告警平台能做统一收敛和降噪：把同一个根因引发的告警合并成一条，把不重要的告警压下去。一般的监控系统专注在数据采集、存储、可视化和告警生成上，对告警之后的收敛、降噪、分发、升级支持得并不好。多数团队没必要从头造一套，成熟产品能把人力留给规则治理和稳定性改造。
六、值班要有完备的 SOP
处理告警时人往往精神紧绷，最容易出错。这时候一份完备的 SOP 就很关键：遇到什么情况、该怎么一步步处理，写清楚。这既能提高处理效率，也能降低操作出错的概率。
如果能把 SOP 里的逻辑进一步固化成脚本，那就更好了，告警触发时自动执行，不需要人半夜爬起来敲命令。这也是为什么夜莺会做告警自愈这个功能。
每个新模块上线前，都应该先备齐几样基本功：
- 梳理 SLI 指标，并配置好告警规则；
- 写好 SOP 手册，并对团队做培训；
- 指定紧急联系人，一般是模块负责人。如果这个负责人不想被频繁打扰，那就更得把 SLI 和 SOP 做扎实，否则就是自己给自己找罪受。
这些坑你中了几条
上面是「该怎么做」，下面换个角度，把这些年见过的 On-call 反模式列一列。你不妨对照着看看，自己团队中了几条。
告警分级混乱，全都不敢怠慢
配规则的时候没认真斟酌级别，最后所有告警一锅粥，每条都不敢忽视，于是高优先级的问题被淹没，低优先级的问题反倒占用了大量精力。
建议把级别收敛到 P1、P2、P3 三档就够了。级别太多，配规则时心智负担重，大家会草草选一个，反而让分级更乱：
- P1：最严重，通常影响了用户的核心主流程，必须立即处理，用电话、短信这类打扰性强的方式通知；
- P2：影响非核心功能，或者不尽快处理就可能演变成故障，用短信、IM 这类中等打扰的方式通知；
- P3：通常不影响用户使用，但有潜在风险（比如拖一周可能就出事），不必立即处理，每天下班前统一看一遍即可，用邮件这种弱打扰渠道甚至不通知都行。
过度依赖个人经验，没有标准流程
故障处理全凭某几位资深成员的直觉，经验靠口口相传。一旦团队成员有变动，问题就来了。而且脑子里的东西在紧急情况下最容易因为紧张而出错。
应对的办法，是把经验沉淀成详细的 SOP，让新人也能照着快速上手。光写还不够，还得定期演练给 SOP「保鲜」。长时间不维护的 SOP 很可能早就过时了，演练时发现问题及时修正，保证它始终管用。
故障复盘走过场
问题解决完就翻篇，不复盘，导致同样的坑反复踩；或者复盘太随意，头痛医头、脚痛医脚。
复盘可以连续追问几个 Why 来加深度，但也别钻牛角尖。很多问题追到最后都会落到组织和文化上，那不是一线团队能立刻解决的。更重要的是举一反三：优秀工程师和普通工程师的一大差距，就在于能不能从一个故障推及一类问题。
On-call 压力分配不均
名义上全队接告警，实际上是某个老实人接了大部分，这正是三哥故事的核心。压力压在少数人身上，倦怠、离职都是迟早的事。
除了前面说的公平轮值和补偿，还要设置主备 On-call 机制，避免单点压力过大。
这里也给新人提个醒：别太抗拒 On-call。以我的经验，值班是个人成长很好的方式。但值班时如果要动手操作，新人一定要先得到老人的指导，别瞎操作，否则容易把小事搞成大事。最好走一道简单的审批，按流程来，出了问题也分得清责任。
忽视工具和自动化建设
故障处理全靠手动，效率低又容易错。尤其是一些老人，习惯了手动那一套，懒得学新工具、懒得搭自动化。
该投入就得投入：建好监控、告警和自动化工具，把手动操作减下来，比如用脚本快速回滚服务、切换集群。止损工具是经验的沉淀，比一份只能用来读的 SOP 手册更可靠。
沟通和升级机制缺位
故障一来，信息传递不畅：该拉进来的人没及时拉进来，业务方和 leader 没及时知会，处理过程中的进展也没人对外同步，结果就是响应延迟、资源调配混乱。
要建立清晰的沟通流程（比如 War Room 机制）和升级路径，确保信息能快速触达相关人员，并按严重程度及时升级。Google SRE 那本书里专门讲过：故障时对外沟通是很关键的一环，往往由专人负责。有人指挥统筹，有人负责处理，有人负责沟通，多人协作，才不至于乱成一团。
别等最好用的人离开
希望各位 leader 认真对待 On-call，别等把老实人逼走了才追悔莫及。先把一张公平的轮值表、一条明确的补偿规则、一条升级路径和一个统一的告警收敛入口立起来，就能挡住最糟糕的局面：一个人替整个团队扛到离职。Flashduty 可以把排班、奖惩、升级、收敛和 SOP 串进同一条 On-call 流程。
