每次 OnCall 过后都掉一层皮

[111qqz]

组里人少，每过一个半月就要 OnCall 一周。一年 OnCall 7-8 次，也就是将近两个月的时间在 OnCall.

每天基本早上十点到晚上十一点，在查一个问题的时候又有其他问题出现。很多都是线上问题，非常紧急。 问题不响应或者每过 12 小时没有解决，就告警电话一直打。

OnCall 5 天之后，基本得睡个 12+个小时整个人才缓过来。 早上醒来又全是没有接到的告警电话

下周估计也要花几天解决这周遗留的问题。

有木有做 SRE 的大佬，想问问这种高强度的 OnCall 是如何调节身体和精神压力的？ 如何做到同时处理七八个问题，做到快速的 context switch 的？

oncall 是 24 小时，但是转到研发这边的问题基本都是白天处理了。前面有 SRE 同学帮忙顶着，基本每周在 200 单左右，他们可以过滤掉 80%

[infinityv]

我这一个月 oncall 一周，7x24 ，告警电话两分钟之内没接到直接升级，五分钟内必须人工介入处理。好受点了吧……

[111qqz]

@infinityv #1 😂老哥我不是来比惨，是想问这个要怎么调节

[learningman]

切不了，人不是计算机，存不了 context 的。命要紧。。。

[kkfnui]

你们 oncall 做的是啥工作呢？

重启服务？给硬件升级？或者服务有 bug 要修复？

为啥问题这么多呢

[dayeye2006199]

坚持拖到下一位 oncall 的来接盘

[111qqz]

@kkfnui #4 有几种吧。1.用法咨询，基本不花时间也不花精力
2. 模型上线失败，原因可能有很多种，要一个一个去排查，每种都要花些时间
3. 失败率突增 /毛刺，SRE 会先查一些普遍的原因，之后会转到我们这边。 这种可能一两天也找不到原因...
4. 用户请求服务报错。 这里面原因也种类特别多，最头疼的是用户代码写的有问题，可能需要看模型的结构，或者用户的代码。 这种基本要连续半天的时间来排查，但是中间会被很多次 2/3 这种线上问题打断。
5. 用户打分对不齐。 这种就更花精力了，一个 case 查一周都是有可能的。 原因种类虽然不多，但是一般会依赖用户配合来排查。 但是我们的用户基本都是做算法的同学，很多做不到 /不愿意 辅助我们排查。
6. 我们依赖很多第三方的基础设施，这些基础设施偶尔会出问题。

[ryd994]

能干多少干多少，接不到的就不接。你们 oncall 没有 escalating queue 的吗？你接不到就让老板接。
你说的几种情况：
1. 用法咨询：写 wiki
2. 上线失败：上线期间安排专人另外 oncall 。因为上线时间是可控的，没必要依赖正常的 oncall
3. 非紧急问题安排新人去解决。反正不急，顺便给新人学习了。
4. 同样写 wiki 。你们组不是 customer facing 吧？写好基础的 troubleshoot 流程，交给客服人员处理
5. 你不帮我我也不帮你。他都不急你急什么？发邮件给老板，这是 long investigation ，让老板另外安排人
6. 让客服组去 follow up 。ticket 转给对应的问题组，交接完毕就可以走了。如果问题修完了还有其他问题，客服组会再来找你的。


总的来说，oncall 忙不过来永远是老板的问题，永远是流程的问题。你就是一打工的，尽力而为，不必紧张。

[ericgui]

you need a new job

[d5]

非常赞同#7 楼老哥的说法，尤其是最后一句话，这怕不是流程的问题。另外既然存在 on-call 场景，你们不能靠其他时区的同事嘛？

[Biggoldfish]

一个半月 oncall 一次加一，还好我们组 customer facing 的 feature 不多，大多数 internal issue 都不紧急或可以当作不紧急，很少工作时间之外被 page 。但即便如此那一周也琐事缠身很少能正常写代码，周末也不太敢去信号不好的地方。下一份工作还是尽量找 oncall 少一点的（

[leimao]

AWS 的兄弟是吗

[ericbize]

为什么白天 oncall 都会这样！

多招人

我以为楼主说的是 晚上 oncall

[marffin]

不知道你们对于 oncall 的要求是什么，我们这边的要求就是 triage 找到问题即可，至于是不是你来解决问题那不一定，因为你可能不是最熟悉这块问题的人。遇到不熟悉的问题，把正确的人叫起来就行。另外，半夜里修问题对生产系统作改动是很危险的，脑子不清醒加上没有人 review ，很可能按下葫芦起了瓢，甚至造成更多的问题。所以只要不是十万火急非常严重的事情，我们都更倾向于 ack ，建个 incident ，然后留到白天工作时间处理。

[111qqz]

@ryd994 #7 感谢老哥的回复。 我这里说的用户是指其他业务部门的研发同事。1. 用法咨询我们一直有 wiki 的其实，但是 wiki 内容太多了，得看个一两天。目前的做法是还是要接单子，然后帮用户分析他的需要是什么，再帮他路由到对应的 wiki 条目。 2. 我们是推荐场景，线上有上千个服务，模型上线基本时半个小时-40 分钟一次。 尤其有很多对实时性敏感的场景(比如新闻推荐), 模型上线失败对业务效果影响非常大。
3. 失败率这个还算比较紧急，因为会影响我们整个部门的考核。
4. 这个我们也尝试过，比如训练任务经常出现的一个问题是 OOM ，有其他同事写了一个特别详细的“OOM 问题排查指引”。 但是发现由于用户基本都是算法研究同学，他们对这些系统 /工程 一些的问题基本看了 wiki 也不知道如何排查。对内存 /cpu 这些的理解和普通人差不太多。

5. 这个问题的痛点主要是，我们缺少一些"自证清白"的途径。 我们负责的部分基本属于整个调用链的最下游，所以需要排除上游的这些问题。 如果拒不配合到也好说，最担心的是遇到过用户一口咬定"模型训练代码，数据都没有修改过，突然服务就报错了"。 可能最后查了一周，发现用户的模型代码都变了，于是问用户，结果被回答"我以为这两种模型结构是等价的，不算修改"😅

6. 我们木有客服组，其他设施出了问题大部分是研发在和他们对接。

老板其实也知道单子多，也一直在想办法降低数量。 好在老板不太会给额外的压力，就是 OnCall 下来确实头痛得不行

[111qqz]

@ericbize #12 寒冬了，招聘都锁了。人数多了确实能好不少😂

[111qqz]

@Biggoldfish #10 学弟现在在哪家来着。 我们其实不算直接 customer facing , 但是因为是推荐场景，服务有问题就直接影响算法效果。 感觉做 infra 的话去哪里都少不了 oncall

[chenxytw]

“组里人少”，我觉得这即是原因之一也是你应该选择的解决方案了.jpg

[111qqz]

@d5 #9 研发 on-call 基本只有白天，而且我也不是外企哈哈哈，木有其他时区的同事

[111qqz]

@marffin #13 我们这边的要求是，如果能明确是某个人写的代码的问题，那么可以交给那个同学来处理。 但是时间主要就花在定位问题上了。对于问题的定位，我们这边一般是哪周出现的问题，那一周 oncall 的同学跟到底。 然后我这边其实已经都是白天了，基本没有晚上处理的情况. 但是单子还是处理不过来

[rrfeng]

oncall 太多就是系统设计的垃圾，没得洗。包括本身稳定性问题，还有很多产品上的问题（这个很容易被忽视）
另外充分的反馈改进是必须的，不然永远不会变好。

[Biggoldfish]

@111qqz 翻出多年不用的 QQ 私聊了哈哈

[ryd994]

@111qqz 1. 这不应该 oncall 做。邮件沟通转给对应组员即可

2.那就更应该安排专人负责。或者设计一套自动修整系统，解决一些小问题。

3. 那也分紧急不紧急。能用两天时间就说明没那么经济。oncall 第一任务是生产环境的 outage ，其次才是失败率。失败率剩下的不还是可用率嘛。真要是重要的问题，那也是老板负责，你有什么压力。

4. 那也是需要另外安排人做。我们组这种事情都是转给 pm 去解决的。因为 dev 控制不了用户爱怎么用。pm 却很需要了解用户需要什么功能。让 dev 做这个非常没效率。如果老板认识不到他的 dev 在干 support 和 pm 的活，那说明老板的工作没有做好。

5. 这就更是老板和 pm 的锅了啊。和其他组件如何交接，这是最初立项时就要商量好的事情。
缺 log ，缺工具，导致 Dev 浪费时间在 oncall 上，那就应该开发工具，保证下次遇到同类问题可以快速定位和控制影响。如果你有类似的想法，应该及时和老板反馈，商量如何解决同类问题。你看，visibility 这不就来了嘛。

oncall 的任务不是彻底解决问题，而是定位问题和恢复服务。这考的是产品整体架构，不是单人的技术水平。如果你们出了大事还没法恢复，你老板就完蛋了。

6. 和下游用户对接，这就是 tpm 的工作……

总之，oncall 事多是正常的，但是你没必要有压力。尽力而为就行了。

[OliveGlaze]

学好英文早点润了。

看了 OP 的博客，感觉刷了那么多题最后干的活和民工似的，有点为楼主感到惋惜，在腾讯算法岗干了这么久早点去另谋高就吧。

[yzbythesea]

同做 infra ，7x24 oncall ，大概 7 天中有 3 ，4 天晚上要被 page 叫醒，一周大概 60 个 page 。

结束了休一天假；有一个 secondary 来处理不紧急的事；遇上复杂的及时找组里懂的人帮忙

[ZSeptember]

所以，到底为什么这么多问题。
如果是业务方的问题，为什么是你 on call 。
业务方为什么会写出那么多问题

[111qqz]

@ryd994 #22 老哥说的都非常有道理。 我老板还是靠谱的，也在想办法解决。 但是一个是人力原因，一个是技术债实在太多了，公司各种古老的技术架构也在慢慢更新。 我尽力而为吧

[111qqz]

@OliveGlaze #23 如果是做 infra,哪里都逃不过 oncall 的，国外也一样😂

[111qqz]

@ZSeptember #25 1. 技术债太多了。
2. 业务方不知道是自己的问题呀，我们是调用链的下游。
3. 我觉得主要是业务招人完全不考察这方面，基本只看发了什么 paper, 所以很多业务是基本不会写代码的，问题就特别多了。

[xmumiffy]

我还以为你这 on call 是正班下班后再来个 12 小时，结果是每天工作 12 小时么 那和正常上班也没什么差别吧

[wa007]

@111qqz 模型上线失败、请求出错。
服务这么不稳定的么

[wangshushu]

字节？

[patrickyoung]

@111qqz #14 流程 系统 Wiki 分布 用户引导都有问题。我是做 DFIR 的乙方，24h oncall 都是正常的，但是几乎很少遇到这样的情况，一年到头就一两次。

[OliveGlaze]

@111qqz 是，但润走之后继续做 infra 的话，起码「每天基本早上十点到晚上十一点」出现的概率比你现在小很多了[看戏]

[msg7086]

12x7 ，一个月轮到一次，精神（闹钟）压力大不过我们单子少，很多和我们无关但是转给我们的单子会有别人走 run book wiki 带掉，只有少数会掉到我们头上，所以我感觉还行，扛过去就好。不过组里也有个小哥觉得受不了的，下周一直接请假休息一天。

[YaakovZiv]

我在华为外包工作过，华为是三个 8 小时都有人，主备那种。研发有主备两个人。每个运维都会有专用问题手册，现场按照手册排查一遍就能解决超过 70%的问题，剩下 30%奇怪的问题，远程热线也能一小时内处理完。如果是十分紧急问题，会单独拉作战室。
同时处理多个问题，第一个问题处理到 30%时，需要等待进程或者其他人员介入。第二个问题接入，开始处理第二个问题。从第一个问题接入开始，就做详细记录，会有严格的表格要求记录的信息，随时换人上都能接手处理，不至于换个人就要重新了解一遍问题。

[tuding]

7x24 oncall 时间久了身体会拖垮

[461da73c]

每周 200 多 case 的系统还能上线？
是没有测试吗，要求也太低了，报一下公司，避免踩坑，lz 还是尽快跑路吧。

[AltairT]

@infinityv 电脑不可能随时在身边啊，难道配了那种带 SIM 卡的迷你 PC?

[NCZkevin]

社科的同学？最惨的是做框架的组，看见他们的 oncall 强度都害怕，每天群里各种乱七八糟的问题。想优化 oncall 只能逼着研发尽量自己去解决问题，别有事没事就来找 oncall,特别是很多共性的问题，一定要写好文档，放在群公告里。

[Lonenso]

推荐阅读 凤凰项目

[Mirage09]

@yzbythesea 60 个 page...AWS 么...

[yzbythesea]

@Mirage09 不是在 aws ，但是应该 infra 都差不多这个水平

[levelworm]

@Lonenso 这个看的我乐死了。我估计楼主公司没凤凰项目里那么垃圾，不过肯定也是有问题。
话说下下周去新公司做 BI Infra ，估计也要乐死了。。。

[hallDrawnel]

on call 是真的可怕

[tairan2006]

换工作

[wangyzj]

没有
身体早晚不行，不要搞 24 小时有业务的
你还会经常遇到不讲理的
你还得装孙子
最后 SRE 也不是你这样的 oncall

[111qqz]

@xmumiffy #29 差别还挺大的，正常上班的话吃饭，午休都不紧不慢，节奏自己可以把控。OnCall 就完全不一样了...

[111qqz]

@wa007 #30 是呀。请求出错大部分倒不是服务的问题，而是用户代码的问题(比如请求了计算图中不存在的 tensor) 但是模型上线失败确实是组件的问题。我们依赖的两个外部存储会出问题，平均一周两三次吧。 以前次数更多一些

[111qqz]

@OliveGlaze #33 哈哈哈哈那确实

[111qqz]

@461da73c #37 是啊，线上跑了几年了。 其实已经上线不去修改的服务也不会出问题，出问题的大部分都是新服务，比如想用某个新功能但是没配置对或者新功能有 bug. 是没有测试的，测试全都被砍掉做测试开发了。 服务质量交给开发通过写单元测试，接口测试自己保证。 测试左移算是一个大趋势吧(虽然有利有弊

[111qqz]

@NCZkevin #39 巧了，我们确实是做框架的组.... 快手的框架组也这样嘛，害怕

[111qqz]

@wangyzj #46 我们部门的 SRE 比我强度还大很多...ToC 的公司基本都是 24 小时有业务吧😂

[111qqz]

@Lonenso #40 感谢，我去看看，增加一些工作的信心(x

[111qqz]

@461da73c #37 公司是绿色软件家。不过看其他楼层的回复，字节，快手估计也差不多这个样子...

[segama201901]

@ryd994 how to 的问题建议写 Q&A 。如果 OA 能有机器人辅助更好。wiki 基本没人会看。

[Hasal]

@ericgui 赞同该做法，跑路是最佳解决办法。

[southwolf]

听起来是不小的项目, 上线了临时发现这么多问题? 上线前没有完整联调测试过的吗? 没有预发布 /pre-prod 环境? 全靠人肉排查解决问题? 这个不是你们 SRE 的问题啊, 是流程管理的问题.
找老板提, 去怼算法 /研发去, 怼不过就换组或者跑路吧.

[111qqz]

@southwolf #57 上线前肯定是测试过的。但是有些部分是没办法完全测试到的，比如一个很大的变量就是模型。每个服务的模型都是不是一样的，我们一般只能挑有代表的几个模型测一测，没办法做到全覆盖。还有很多问题的根源在于权限不收敛，线上环境可以被同部门的其他同学随意变动(比如扩缩容，放量，将一个错误的模型上线到某个服务上)。 权限控制这部分就要跨部门了，我们也只能等人家的排期，转眼也等了快一年了(

[ericgui]

卧槽，amazon 在美国名声都臭了，找不到人了，开始祸害国内的同胞了