回馈地里，聊一聊在亚马逊云的oncall经历

背景：过去4年在亚马逊云2个组待过，都是oncall相对比较重的组，为什么oncall比较重还呆了这么久，一是职业发展考虑，二是身份限制。上个月楼主跳槽了
首先要说，亚马逊云绝大部分组的oncall强度都没有接下来描述的大。

第一个组的oncall设置：
第一类oncall，一级oncall，二级oncall，三级oncall，之所以这么设置是因为经常会出现一些文档无法cover的问题，就像你做的服务是安全认证，但真正核心的安全漏洞算法需要更专业的人去处理，这个更专业的同事在这里扮演二级oncall的角色。因为这个oncall强度非常大，我们是3周一轮，一次一天，只有白天8个小时。另外16个小时由欧洲和澳洲组cover，保证没有人晚上oncall。以前是24小时的，但后来强度特别大你不能让人24小时不睡觉吧。强度大什么概念，8个小时平均是10-15个2级，某些2级需要排查10多种情况，几个小时就过去了。如果一级忙不过来，二级必须上手帮忙。因为业务和code base的原因，组里的ticket数量是降不下来的。这个组的第二类oncall是QA，就是专注整合测试的，因为产品特别复杂和成熟，整合测试比较多，在代码上线的不同阶段/环境都有相应的整合测试，你的工作任务就是排查测试问题，并修改相应的代码。因为高员工流失率，测试代码是有各种bug的。这个oncall大概两个月轮转一次，一次一周。
第一个组oncall遇到的极端情况：
第一种oncall和第二种oncall重叠。节假日oncall二级oncall放假没有额外支持。在第一种oncall时身体不适但没有人愿意换的。某一次20多个二级，自己大概处理了10个，剩下的都是队友帮助的
第一个组oncall接触的人：
企业级premium support（他们有业绩需要，极为push，往往非SDE出身不太清楚oncall的强度）；同组队友（有可能什么修改，什么新的feature，什么test branch之类的）；姐妹组员工经理等；内部客户（一般来说是SDE，交流起来共同语言多）

第二个组的oncall设置：
只有一类oncall，一级oncall，这个和大部分亚马逊云的设置类似。24小时，虽然在组里的ops review中设置ticket级别尽力不让凌晨被叫醒，但实际操作中大概平均两周会有那么一次晚上被叫醒。因为流量比较大，上游客户比较多，压力还是很大的。当然，强度和第一个组比小巫见大巫。虽然没有二级（skip明确要求不要二级，说一级都能搞定），但经常会出现sr的帮助new grad的情况
第二个组oncall遇到的极端情况：
. 1point3acres没什么特别的极端情况，无非是一两天都没解决比较严重的availability问题，写个COE啥的比较常见（3个月一次）
第二个组oncall接触的人：
全是内部客户，上下游姐妹组。

先说一些积极的东西，不少人关注在oncall中能学到了什么：

• 和不同人优雅撕逼的能力，这里不是推卸责任，而是在遇到一个问题时hold every party accountable，有些客户着急会升级给我们经理，这时候要能解释清楚情况，即时汇报进度。简单说就是沟通能力
• 技术上的提高。主要是在高流量，变化的流量模式下，系统的瓶颈暴漏。很多时候瓶颈会cascade，这时候排查问题不仅仅需要扎实的知识（比如总有那么一个cache host流量那么大，这很可能是hot partition问题），还需要经验（那么多metric，都查一遍抓不住重点）。
• 由一些ops上出现的问题，更深层次的理解架构和开发，比如我们在migrate新的产品时，就避开了之前会产生的很多ops问题。
  

不积极的东西后面再补充，如果有人感兴趣看这个帖子的话。

为了和主贴区分开，占一层楼提醒大家选组，如果oncall是一个大的concern的话：
- 如果能看到组内的数据，还是可以的，idtools能看到这个组每周的oncall pain，tt或者t.corp能看到ticket基础数据，还有其他一些工具能看到趋势什么的
- 有时候组员会兼职oncall，如果你们组很轻松，有可能你会被调到相关组兼职oncall，所以只看现在组的数据不能完全说明什么
- 如果不想强度大，硬核组像rds，s3，dynamodb这种大概率可能要避开，但可能也失去了宝贵的成长机会。
- 简单的筛选标准，流量小的一般来说oncall比较轻松。流量小不见得不重要，取决于这个组的发展阶段。比如有些IOT组很重要，但oncall就是过家家
- 有时候即便ticket不多，但经理要求比较高的，强度也不见得小。有些经理被其他组推过来一个COE，写一个也得掉几根头发。楼主写过5个COE，review尤其是bar raiser的review比oncall本身痛苦

望舒 发表于 2021-06-03 16:59:27
不是做cloud的所以不是很懂为什么会有这么多on call issue。请问一般都是什么issue每天会发生那么多？是因为代码质量差吗 还是一般都是资源调度的问题

根据我接触云这么多年来看，很多时候并不是云本身问题，而是客户自身问题。但是云平台其中一项重要的服务就是为客户大包大揽，所以很多时候需要云供应商去给客户做运维：客户自己把数据库数据搞丢了一个p1来了让你恢复数据，客户自己message queue堵塞了一个p1让你帮他debug，客户自己弄的airflow dag有各种各样的bug也是要你来看。当这些问题超出support的能力的时候就要escalate到swe或sre去。

我们公司现在就是aws的大客户，我们的support case主要由sre或security去提交。但是我在的项目极度依赖s3，所以也经常会跟aws support打交道。很多时候我们的case就会被技术支持给到swe，这时候oncall的就被page了。

当然也有很多时候是资源调度啥的问题，我们公司类似这方面问题是由sre分担，swe不用管这方面的oncall，但是亚麻怎么操作就不清楚了。

看上去你们on-call还好啦。都是白天。
我们sev 3就会收到午夜凶铃。一次一个星期，两个月一轮。on-call的一周，基本上至少三天被叫醒。
最近老板又出幺蛾子，列出了30个重要客户。他们只要有任何事，sev 2， 24*7解决。

不是做cloud的所以不是很懂为什么会有这么多on call issue。请问一般都是什么issue每天会发生那么多？是因为代码质量差吗 还是一般都是资源调度的问题😮

求大米啊，有什么问题不涉及隐私的都会一一回答

第一个组oncall遇到的极端情况 和 第一个组oncall接触的人 写了两次，是typo吧？

第一个组怎么和我原来的组这么像。。。。一次八小时，三级oncall，一次十多张tt。。。。要不是澳洲我真以为咱们是同一个组了哈哈哈，给lz加米了！

        很有用的信息,  Thanks

楼主最后去哪了？

干货，持续关注！！！终于看到一个没有pip的亚麻贴了 ：）