1.
最近面试了一位来自某大厂的人。最后提问环节他问：
“听说微软WLB很好，那么你们要on-call吗？要的话，会经常夜里起来解决问题吗？”
他说，他负责的服务有时需要晚上处理on-call的问题，比较累，所以想了解在微软工作的情况。
这是一个很好的问题！人们都不喜欢7*24的on-call，很可能甚于996。虽然微软在WLB上的形象不错，但我觉得不少人还是担心需要on-call的工作是一个例外。
当时我简单实话实说回答：
很可能要on-call，但并不需要*经常*夜里起来这么辛苦。
需要不需要on-call要看具体项目。我在的团队里，多数是需要的，因为多数需要7*24的on-call来保证业务的SLA。如果夜里接到on-call的电话，肯定是要起来解决问题的。不过，从我的经验看，这应该谈不上“经常”这么辛苦的程度。
一般微软的oncall都实行DRI（Direct Response Individual）制，团队成员可以均摊on-call的压力。简单来说，就是轮班制，比如每人轮流值班一周，负责7*24小时处理团队内*所有*紧急的业务事故，而不是每一个成员7*24处理各自负责的服务或功能的on-call。
业务越是关键或者说on-call强度越大，DRI轮班的团队规模越大，有的一个季度甚至半年才轮班一次。如果跨国团队共同组建DRI，一天的DRI可能分成2-3段，由不同国家地区的团队负责，这样就没有夜里的on-call了。
如果每个人都需要为自己负责那点事on-call，哪怕出事频率不高，心里也难免绷着一根弦，睡也睡不踏实。日常项目工作也容易被突发事故所影响，要不耽误了项目工作，要不在处理完事故后加班熬夜赶项目。
而且，实现DRI制往往还会改善整体的工程质量。人们对自己的容忍度一般远高于（自认为的）别人对自己的容忍度。如果自己的服务每一两周出个on-call的小问题，处理起来不难，哪怕是夜里被on-call叫起，忍忍就习惯了；如果这交给每周的DRI处理，即使别人不吐槽，自己心理压力也很大，就更有动力改善自己的服务。
当DRI肯定是一个辛苦的事，所以我们会设法减轻不必要的压力并将其维持在一个可接受的程度。比如，我们一般不会安排重要紧急的项目工作给DRI。如果夜里被唤醒处理了事故，白天可以在家休息，一些on-call的工作也可以交给backup DRI。总之，当DRI的时候，一般不会过劳。
有些团队DRI强度大，一般会有事后激励措施，例如最常见的方式是给调休，比如公共假日的DRI之后能补休，哪怕那一天安全无事故。我春节值了两天DRI，平安，也得了两天DRI假。
总之，在微软大家都比较关爱自己的WLB，自然也会注意去不影响别人的WLB。虽然on-call不轻松，但态度正确总能想到办法让on-call不那么辛苦。
记得当时应该就是碎碎念地回答了这些内容。
要知道，做好on-call和维持WLB并没有什么冲突，而且两者相结合才能体现一个工程团队基本的专业能力和人文关怀。确保产品和服务的可靠性，固然是on-call的根本，但以牺牲人的身心健康为代价的方式注定不可持续。
如果on-call强度太大，我们要思考这多是技术架构和工程质量问题，还多是on-call组织管理问题。从我个人经验看，多数是前者；而且，它们始终需要依靠技术手段去解决。组织管理则多是维持on-call团队人员士气的*辅助*手段。
因此，改善on-call的根本手段还应该是持续地改善技术架构和工程质量。
如何做到这一点？我认为首先要做到的是从live site中学习，吸取经验教训。每一个重大的live site往往都揭露了技术架构和工程流程的重大缺陷。如果团队都不能从这血泪经历里吸取教训从而改善自身，那么也很难相信这个团队能从其他方面做好技术工作。这也是我之前分享的live site主题的那几篇文章想表达的主要观点之一。
Live Site First!
2.
看到这里，我想不少人会对上面那张截图里的问题感兴趣。
微软哪些开发职位不需要oncall的？
我不知道微软上海的情况，也不知道现在微软北京和苏州哪些具体的岗位不需要on-call。我只可以简单根据个人经历说说我的看法。
我最初在Bing Core Relevance主要做Experimentation，并不需要on-call。接着在Answer Development Experience主要做离线数据处理，也不需要on-call。后来做了些Task Completion和Conversational AI的incubation项目，也没on-call。后来到了Cortana才开始接触on-call，然后就一直on-call了。
一般来说，从事的工作越是容易造成大的商业影响，越是需要on-call。如果只是支撑内部团队且不需要7*24小时响应，或者做一些incubation的项目，自然不需要on-call。有的质量流程做得好，也几乎不怎么需要on-call，比如发布一个新训练的核心网页排序模型需要经过离线评估，半在线评估，在线的交叉测试和A/B测试，能导致重大影响的缺陷不可能在完全发布之前才暴露。
从程序员职业发展考虑，我个人不建议选择工作时去避开on-call。职业发展快慢很大程度取决于所做出的商业影响，而越是有重要商业影响的产品和服务越是追求高度可靠和快速响应，自然on-call更必不可缺。按未来发展的趋势，回避on-call只会越来越难。
同时，如之前说的，on-call并不一定会破坏WLB。没有足够技术和管理能力的时候才会。因此，与其回避on-call或抱怨on-call，直面并征服on-call才是终结它的正确方法。
HJ说：
需不需要 on-call，其实和我之前的一篇文章的答案很相似：
还是要看组看项目的！
就拿微软闵行来说，一些非 service 的项目组就不需要 on-call。比如：Teams DevX、Java Tooling、Spring Integration、Azure SDK、Data Scientist 团队等等。
然后，对于需要 on-call 的组，他们 on-call 的频率以及强度也各不相同，这个会和组员的人数、项目的复杂性、产品面向的用户群体等等都会有关系。
还有一些组，是中国和美国的工程师分别负责12小时的 on-call，这样就不会出现半夜起来的情况。
如果你不想 on-call，或者希望 on-call 的压力不那么大，在找我内推的时候，也可以告诉我。这样我可以推荐合适的组。
微软DevDiv热招继续！除了Dev和PM，还需要Data Engineering大佬！
End
HJ说
大厂内推 · 职业规划 · 业界资讯
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
