Oncall 的中文解释是「待命的、随叫随到的」，《SRE：Google运维解密》对 oncall 是这样解释的，
on-call 轮值是很多运维和研发团队的重要职责，目标是保障服务的可靠性和可用性
on-call 轮值制度是 Google SRE 团队的指导思想，它保障了一个可持续的运维工作环境
对于 ToD（面向开发者提供服务）的业务来说，很多公司都借鉴了 Google SRE 的 oncall 方式，团队会分配一定的人力资源，7 * 24 小时提供咨询服务（值班）。
这对开发者用户而言，确实是一件好事，有任何问题都会有专业人员帮忙解答。但长期来看，oncall 制度却容易带来一些不易察觉的问题。
oncall 数量跟服务质量的关系不大：服务质量好，踊跃提问；服务质量不好，则会大量投诉
oncall 会降低咨询的门槛：我们越加强 oncall 响应效率，低质量的问题就会增多
oncall 会占用整个团队的时间：很多 oncall 不是值班人员一个人能解决的
那么如何才能「理性的」看待 oncall 呢？ToD 团队应该如何提供更好的开发者服务呢？
解决问题 vs 消灭问题
通过人工咨询来保障问题被解决，应该视为一种降级方案，而不应该是常规的方案。
在接到 oncall 咨询的时候，值班人员不能只站在「解决问题」的角度看待 oncall，还要站在「消灭问题」的角度来看。什么是「消灭问题」呢？那就是要考虑：为什么会有人向我们提出这个问题，他们自己为什么解决不了。
ToD 业务的用户都是开发者，他们本身都具备很高的技术素养。「为什么非要借助 oncall 来解决问题，而无法自己排查解决」，这是一个值得深思的问题，它会影响我们应对 oncall 的思路和方式。
我们发现大部分 oncall 问题，之所以被提出来，是因为开发者们由于「信息壁垒」排查不下去了，没办法知道「到底发生了什么」，那就只能来提问了。如果 ToD 团队没有意识到这些，只解决单一开发者的提问，那就不能从根本上「消灭问题」，只能算是暂时「解决」了某个疑问。
「消灭问题」的办法之一，就是让开发者们知道他们想知道的信息。这句话说来简单，实则很难。因为值班人员很容易在被咨询的过程中，陷入满足感之中 ——「我知道你不知道的东西，我很强」。这是人性的弱点，需要修订「满足/补偿机制」才能解开循环。
另外一个原因在于「知识的诅咒」，它是一种认知偏差，意思是懂得某项知识的人，无法理解不了解这些知识的人的处境。这个「习惯」需要经常性的练习向其他人讲解知识，才能解除。
总之，值班人员要「消灭问题」。想一想如何让开发者们不用提 oncall 也能自己解决问题，如何让他们获取想知道的信息，如何避免自己陷入「我很懂」的满足感之中，如何规避「知识的诅咒」。
服务关系 vs 协作关系
ToD 团队确实是向开发者提供服务的，但是这种服务却是与面向「老百姓」提供的服务，有很大的不同。假如有一个老百姓去营业厅办理业务，营业员让老百姓自己来操作电脑，我们肯定会认为这是一件十分不合理的事情。我们会想，既然老百姓自己能操作，那要他营业员干什么？
ToD 团队在应对 oncall 时，也容易陷入以上这种考虑之中。如果开发者们能自己做，那要我做什么？然而对于 ToD 业务而言，这样考虑是不妥当的。我们需要重新考虑 ToD 团队与开发者之间的「边界」，因为 ToD 团队的用户是开发，也会写代码。那么为什么某些代码、软件功能 必须由 ToD 团队来提供呢？这里面的考量是什么？
我想这要从整个大部门的「效能」层面考虑才行，ToD 团队存在的意义之一，就在于能使得整个大部门的成本降低、产能提高。如果 ToD 团队只解决单一开发者/团队 的问题，或者仅仅解决自己的问题，这对大部门的效能增益而言，简直是负向的。所以 ToD 团队必须有能力识别通用问题，有能力一次性解决大规模的问题，这样 ToD 团队的存在才是有价值的，才能划算。
因此，与其说 ToD 团队是提供服务的，倒不如说 ToD 团队是与开发者们一起协作的。ToD 团队需要提供一定的开发性，让开发者们可以有效的参与进来，不要什么东西都自己研究。首先，自己研究出来的东西，很容易背离实际，好似空中楼阁一样难以被其他开发者们认可。其次，我们不能等研究出来之后，再考虑推广，而是应该先考虑需求和落地场景。乔布斯有一次在讨论产品和技术时提到，必须从用户体验入手，然后再回头开发技术。而不是从技术入手，然后再试着搞清楚，应该把东西卖到哪里。
总之，ToD 团队与开发者用户之间，应当从一开始就建立起协作关系。有问题大家一起解决，有哪些事项是我（ToD 团队）可以帮到你（开发者/团队）的。这不是一个 甲方/乙方 的关系，不是我有一个功能你帮我实现，而是这里有一个问题，来商议如何采用 ROI 更高的方式来解决。
结语
回到 oncall 事情本身，oncall 是 ToD 团队与开发者们建立联系的一个很重要的桥梁。使 ToD 团队的成员，可以直接深入到开发一线了解问题出在哪里，了解他们的真实痛点是什么，帮助他们解决问题。
但仅仅是解决问题还不够，ToD 团队还要为「开发者们无法自己解决问题」来买单，否则开发者们会认为，虽然 ToD 团队提供了一些功能，还不如别要这些功能更好，因为它阻碍了正常的一线开发流程。
7 * 24 小时的 oncall 会占用 ToD 团队很多时间，紧张感会让大家误以为只有更好的 oncall 态度才能「更上一层楼」。但其实态度是一方面，ToD 团队的价值则是更重要的一个方面。它是涉及到 ToD 团队应不应当存在的「生死存亡」的问题。