软体工程师该如何值班 (on-call)?

先前在 《软体工程师该如何做好监控 (monitoring)？》 文中，我们谈到了在监控时收到警报，负责值班 (on-call) 的团队成员要先确认问题，如果确认问题真的存在，接着就会着手处理。很多刚入行的工程师，可能对值班没有太多概念，或者比较资深的工程师，会想要去优化自己团队的值班流程。因此在这一篇，我们将来讨论如何做好值班这件事。

谁来负责值班?

在早些年，软体开发与维运一般是被拆开的，当开发团队开发完成后，就由维运团队接手维运。在那个年代，开发者多半不需用参与到值班的工作。然而，在近几年，这个现象有所改变。

会有这个转变的主要原因，是因为过去把开发与维运拆开的方式，两边分裂难以扩展。除此之外，开发者不用负责值班，会让开发者在写程式时缺乏「要让线上完好无意外」的意识，这状况在由开发者参与维运后，有了明显改善，所以业界就纷纷往这方向发展。

在英文有一句叫 You build it, you own it 的话，意思是指，自己开发的东西，就要负责到底，不是开发完就没自己的事。当自己要负责维运自己写的程式码，在写程式码时，自然会更小心，不然出包了不再是别人扛，而是自己要吞自己搞出的问题。

在开发者也参与维运后，业界逐渐出现几个软图ㄧ工程师 (SWE) 与网站可靠性工程师 (SRE) 的不同合作模式。先前 Increment 针对各大公司的调查 (连结)，有以下的协作模式：

• Google 的 SRE 仅负责运行、维护和值班最重要且稳定的服务 (如广告、Gmail 和搜寻)，而开发团队则承担其他非稳定、非关键服务的运维工作
• Airbnb 有与开发团队密切合作的 SRE，但 SRE 只专注于提高整个系统的可靠性。具体来说，开发者负责值班，SRE 协助开发团队导入维运的最佳实践
• Datadog 的 SRE 和开发者共同值班，每次值班都会有两个角色一起参与
• Amazon 则是极致的 You build it, you own it (据说是基于 ownership 这个领导力原则)，所以是开发者一路从开发负责到维运

开发者的轮班

在谈完开发者与 SRE 在值班的不同角色，接着来谈开发者在实际值班时，是如何轮班的。

在值班的轮班通常是以周为单位，每个人每次负责主要轮班一周，然后当副值班人一周，团队有多少人就是多久轮一次，例如团队有 12 个工程师，那会是每 12 周轮一次主值班。

担任主值班人时，当有某个异常出现，呼叫机 (pager) 第一个会打给你；如果主值班人没有响应，则会再打给副值班人。这种主副模式，可以确保不会找不到人 (当然可能两个人都没有响应，一般预设会是再打去总监级别的角色，但相信多数人不会想要自己该负责的东西，漏接然后被大老板接到，这种后果通常不会太好)。

好的轮班设计，应该要避免过度频繁轮班，否则团队成员会燃烧殆尽。因此，会推荐在面试时，跟用人主管聊多久轮一次班，以及该团队目前的值班状况，这会让你对未来实际加入团队后会发生什么事，能有更具体的理解

值班时被呼叫了该怎么办?

在对值班有整体性理解后，相信多数人有的下个问题是「如果真的在值班时被呼叫了，该怎么办?」。

许多公司都会有值班的相关指南与训练，举例来说，GitLab 就有公开自己的 On-call Handbook (连结) 以及值班时的检查清单 (连结)。如果你目前待的团队，还没有建立起相关的指南与训练，本文的最下方还有附上其他业界公开的指南可以参考。

往下我们会进一步来谈，在处理事故时推荐基本一定要有的原则与流程。

响应

当你在值班时收到通知，第一件做的事情是响应，一般值班相关的工具都会有一个 Ack (是 Acknowledge 的简写)，点下去后让相关人员知道你收到通知。为了确保 SLA 能被维持住，假如主值班人没有在一定时间内响应，就会往下去呼叫副值班人，然后再到团队主管，然后部门主管以此类推。当然，相信多数人不会想要惊动大主管，所以收到通知时，会马上按 Ack。

判断与同步

在响应后，需要进一步判断是否该异常警报真的是事故，判断完如果真的是事故后，要接着要跟组织的其他人同步状况。

一般出事故时，会有两个群组，一个是有所有人的群组，会由负责值班的人去更新事故处理状况 (下面会有模板可以让大家参考)，让组织的所有人都能被同步；另一个群组则是负责问题解决的人新开的群组，让跟相关问题的讨论能集中，如果有想了解细节的人再加入。

除了在公司内的同步，有时也会需要对外同步，让客户知道发生了什么事，以及目前处理状况如何。举例来说，先前 OpenAI 的 API 挂掉后，除了有状态页面，也会在推特等平台，即时更新，让使用 OpenAI API 的人知道何时问题得以被排除。

止损优先 (mitigation first)

在值班时，一个大原则是跟时间赛跑，如同在 《软体工程师该如何做好监控 (monitoring)？》 一文有提到，公司多半会有 SLA 的设定，如果超出承诺的时间，会要赔钱给客户；如果是直接面对使用者的，那可能每晚一秒钟修复问题，都在造成商业上的损失。

而要能够快速解决问题，需要先止损。业界有个词叫 mitigation first, invesigation later (先止损，后排查根因)，意思是先确保问题没有持续影响线上环境，事后再来详细调查问题的根本原因。举例来说，假如事故是因为某个刚上线的改动 (不论是新的程式码，或是配置的更动)，那第一时间要做的事，就是立马回滚 (rollback)。

止确保问题得到缓解，线上的使用者不再被影响后，再来谈讨根本原因，然后再去设计能解决根因的解决方案。这个顺序很重要，过去业界有太多悲剧，就是工程师试图想直接解决问题，导致一来过慢，二来可能在有时间压力下，反而越弄越糟。

阅读更多

如果你对于做好值班这件事感兴趣，欢迎加入 E+ 成长计划来阅读更深入的内容。在 E+ 的完整版当中，我们会进一步谈值班用的工具、第一时间要同步状态可以用什么模板、业界有哪些值得参考的值班规范、B2B 产品的值班可以如何优化等主题。

本文为 E+ 成长计划的深度内容，截取前三分之一开放免费阅读。欢迎加入 E+ 成长计划阅读完整版本 (点此了解 E+ 的详细介绍)