每次 OnCall 过后都掉一层皮

[111qqz]

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

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

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

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

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

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