AWS Aurora组工作情况介绍

小伙伴们大家好！最近刚转组成功，h1b transfer也被approve了，一切算是尘埃落定了，有时间安心码字了，下面我给大家介绍一下AWS下面Aurora组的一些情况。NOTE：一切观点仅代表我个人观点，我会做到尽量客观，但如有冒犯请多见谅！
先介绍下Aurora：Aurora是RDS下面的一个产品，简而言之就是一个新的db engine，感兴趣的话可以看下aws doc，这个产品能比其他传统engine速度快，也更稳定，之前只支持mysql，近两年支持了postgresql，最近正在开发MS的sql server。Aurora是公认的AWS下面发展最快的组。在内部资料上也能观察出来，发展确实很快。DB Instance数量呈指数增长，从0-->1w和1w-->2w时间明显缩短。这个产品也非常盈利，入职之前曾经玩了玩，自己建了一个instance，一个月后收到500刀的账单。。。。自己内部的aws账号为了做test在prod上建instance忘了删除一个月花费几千刀也是很正常的事情（我知道这不frugal🙈）。看了下整个permission list，RDS大概有3000sde，Aurora大概有700+。


再介绍下我的背景：去年六月NG校招，被随机分到Aurora下面的Aurora-postgresql（以下用APG代替）的control-plane team（以下简称cp）。说是postgresql，但其实我们和Aurora-Mysql（以下简称AMS）是共同开发的，我们很多东西也是共用的，也经常共同开发feature，只不过我们美国team开发APG稍微多一些，AMS主要在温哥华。整个Aurora的核心，至少cp是在加拿大而不是在美国。这个帖子主要是站在cp的角度去介绍这个组。

然后介绍下组里的人员组成。在入职之前曾查了一下有没有关于aurora的介绍，但只查到这个org的含印率很高。确实，感觉整个Aurora印度人比例占了百分之70。我们组在我们几个中国new hire入职之前只有mgr是白人，其他都是印度人。入职之前看了很多关于这方面的帖子很担心，但！！！我们组的印度人真的都很好，很耐心、helpful，跟我想象中的印度人完完全全不一样，甚至我的印度mentor还鼓励我们办绿卡，跟我们聊买房，我转组除了我的几个中国同事，最舍不得的就是他！！！他真的超级好！！！手把手的教我debug，兢兢业业，帮我setup环境，甚至我在deploy东西他还帮我build一个pipeline出来。总之我想说，不是所有的印度人都是跟我们站在对立面的，希望大家遇到的印度人都像我的组员一样！！

下面就是我转组的几个原因了，也是我对这个组不满意的地方，吐槽负能量居多，again，如有冒犯请多见谅！！

1. ops重：RDS是一个非常成熟的产品了，现在maintance居多，feature开发较少，这就导致了新人分不到好的project，甚至分不到project。第一年入职的新人都是在搞operation的东西。比如我，我在转组之前细细回味了一下我入职的一年，基本没写过feature code，都是在deploy，release东西。甚至写的MCM（亚麻内部文档，类似于傻瓜操作指南，把你要deploy的步骤记载下来，如果你不在了/出问题的时候不在，能及时rollback/continue）比我写的CR要多，而且AWS现在已经有22个region了，可能三四个region就要deploy一整天，再加上block day/bake time，一个mcm可能需要跑两周。这个时间你要时刻注意你的deploy是不是break了某些东西，导致每天除了这个mcm干不了别的事情，根本没时间开发feature，每天很枯燥的跑一跑mcm一天就过去了。不仅是我们cp team，engine和storage team也是一样，转组之前跟几个中国人聊了一聊，大家第一年干的事情基本大同小异，但是熬过了一年多就会渐渐接手feature task了，所以需要有取舍要不要在这里熬一年。

2. Oncall重：作为一个customer facing且非常盈利的产品，Auror这个产品的oncall load非常重。我们组的oncall rotaion和别的组不一样，我们是八小时循环制，不是传统的一个人oncall一周，也不是一天，是白天八小时，大概10天轮一次（最近有改动下面提及）。我曾天真地问过mgr为什么我们组的oncall这么奇怪，mgr笑着说 如果一个人oncall一周，他会用接下来的一周休息，后来真正primary oncall了我才知道mgr是什么意思。我们Aurora在世界各地都有组，主要是北美（每天10am-6pm） 印度（6pm-2am） 都柏林（2am-10am），平均我们oncall的八小时会有25张sev2 tt，一般一天会有70张左右。根本就处理不完sev2，更不用说sev3之类的，在queue里几个月是常有的事。TAM非常不愿意来找我们，因为有时候sev2都没时间处理，pending了好几天/好几个月，which made customer very unhappy。。。。基本oncall的八小时是从早忙到晚。最近我们把都柏林的组挪出了rotation+印度疫情严重，我们北美又加了两小时，现在是6am-4pm 北美， 4pm-12am北美，12am-6am印度。。。基本oncall一天完事大家都会休个comp off休息调整一下。。。。而且除了oncall，我们还有qa oncall（一周），这个主要是处理pre-prod的环境问题，code deploy到prod之前会在preprod上测试，每天晚上会跑几千个test，qa oncall的任务就是确保code change不会break这些test，如果发现break了就要dive deep是哪里出问题了，是要fix还是rollback。tertiary oncall（两周），这个是今年新搞出来的，主要是修一些long-term存在的问题/customer facing的紧急问题。曾经有一个月，我连续oncall了三周，这是我想转组的直接导火索，根本没时间focus on自己的project。。。。

3. Cross-team communication频繁。作为一个产品，需要有多个component协同配合，aurora也不例外，最主要的就是三部分engine, cp, storage。这三个部分属cp最卑微，是给那两个component擦屁股的，这两个component只要出问题了就来ping我们让我们去debug帮忙解决问题，他们的问题永远highest priority，我们需要放下手头所有事情帮他们debug，过分的是，如果几个小时没回复他们，他们就会向上escalate给我的mgr甚至skip mgr。我曾经跟mgr反应过这个问题，他也就是打太极，安慰我，从来没想过帮我解决问题，这也是我想走的主要原因之一。之前我以为是我太矫情，后来发现组里大部分人都对其他team有意见。。。。但其实说实话别的team也没办法，大家都是相互依存的，这是产品性质决定的。。。如果不喜欢这种氛围的话不来/转组是最明智的选择。

4. 人员流动频繁。这个不是我转组的原因，只是一个现象，从我入职以来，已经有20+ l6+的人离开aurora了，其中不乏aurora的创始人团队核心成员。很多都是一手把aurora带起来的开山鼻祖。不知道high level的人是怎么看待这个产品的。


说了这么多不好的地方，再来说一说Aurora好的方面

1. 发展快。这个是毋庸置疑的，公认是aws发展最快的组。近两年一直在扩招，常年让我们内推，open job实在是太多了，跟别的组比我们是他们的几倍甚至几十倍，which means 缺人 == 不会pip，我走的时候我手头那个pj是今年要GA的，我们组有14个人但mgr愣是找不到人handover，因为大家都有其他task/pj/oncall需要做。去年我入职的时候，我们组算上intern来了8个新人。。。。今年据说还要扩招，想上岸的小伙伴可以试一试呀，不确保是好组但是个上岸的好机会，因为缺人所以bar不是很高。

2. 适合摸鱼，如上所示，每天需要run mcm，这东西更像是体力活而不是脑力活，每天盯着这东西一天就过去了。。。非常适合摸鱼，每天五点就去遛狗了（逃）

3. 组里有钱。Aurora是真的有钱，每周五team lunch给我们报销饭费，我每次都点50刀左右的东西让公司报销。。。遇到节日也会给我们发doordash的giftcard。内部aws账户日常2k刀/mo，system account粗略算下来一个月几十万甚至几百万，VPC limit 从default的5个扩展到50000个。。。。

4. 组里很多大佬。因为这个产品很新，有一批开山鼻祖。那帮人是真的很强，跟他们能学到很多东西。看他们写的code有时候很震撼，不管是design还是code style都是非常值得学习的，经常感叹什么时候能赶得上他们哈哈哈。

5. 很多大客户，比如三星，autodesk，airbnb，不管干了什么写在简历里面都会很好看。


总之，我作为一个ng彩鸡，在组里呆的不是很开心，就有了想走的念头最后也如愿以偿。如果是大佬的话应该在这个组呆着会很舒服，跟我一起入职的一个return intern感觉他就呆的很舒服，上了一艘好船，pj 很好scope很大。有时候会想是不是熬过了这段时间再坚持一下就会好，但已经做了选择就不后悔了！

上面就是对aurora的一些切身体会，希望能帮到地里的小伙伴。最近internal transfer成功了，如果有需要的小伙伴留言呀，我再开一贴讲一下internal transfer的流程。有问题随时在下面留言，我会尽我所能回复的，如果想到什么也会在下面补充。求一波米呀！！！

8小时25张sev2……你们没有考虑过root cause么

缺人就没有pip就是你太天真了

作为aurora的大客户，scaling真是垃圾的一逼。各种bug和不稳定，导致我司损失了几千万甚至上亿刀

楼主写得很实诚，ams engine组的表示赞一个。现在ops确实太重了，没那么exciting了，不过组在亚麻内部绝对是好组

感谢分享！

匿名者 发表于 2021-5-19 15:10
. Χ缺人就没有pip就是你太天真了

这个组pip确实在亚麻是少有的罕见，我之前aws组连hv都不放过，这个组知道的几个国人ni的case都没事儿

伊萨卡的布丁 发表于 2021-05-19 00:14:47
这个组pip确实在亚麻是少有的罕见，我之前aws组连hv都不放过，这个组知道的几个国人ni的case都没事儿

这个取决于有多少pip名额...换句话说你的表现不重要，有多少人表现比你差很重要

匿名者 发表于 2021-5-19 15:10
缺人就没有pip就是你太天真了

可能是我表述的不够准确。我想表达的意思是，因为缺人，而且东西多，培养人的成本比较高，向我们这种入职一年勉强能独立行走的一般只要好好干被搞的几率会小很多，至少招人的周期/成本都比把我们赶走要长/高

Shubin_ren 发表于 2021-5-19 15:16
8小时25张sev2……你们没有考虑过root cause么

有挺多都是customer不当操作导致的，最近那个两周的oncall也是fucus on这些RCA，但Aurora因为产品发展快，很多feature都不会在preprod上完全测试就去了prod，导致会有源源不断的新bug。。。感觉我们是用customer去test哈哈哈

楼主方便透漏最后transfer去哪个组了吗？