每次 OnCall 过后都掉一层皮

[111qqz]

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

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

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

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

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

[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 在美国名声都臭了，找不到人了，开始祸害国内的同胞了