Oncall/ops 到底能学到东西吗？还是纯粹浪费时间？

Lz 混的比较惨，这可能是最惨的亚马逊经历，这是一个全是烙印的坑组，一个成熟infra/产品组？

Lz 当年毕业加入亚麻aws 某个core service 组做sde1（做分布式存储）

组里的service比较成熟，用户量很大，都是外面的大公司客户以及亚麻内部比如retail什么的
   
组里全是oncall / ops，一周起码要60个sev2，而且周末还要做metric callout，看哪个api什么时候有latency spike， packet loss， high error rate主要原因也就是hot key，customer driving traffic，  bad node这样

需要查大量的log看看出什么事儿了。

唯一写的代码，还是改组里的业务逻辑然后帮助减少sev2的数量，也算是一个小feature吧。但也是围绕着oncall来的。

基本上天天就是处理ticket，然后mcm deployment，查logs。

做这些确实把ops弄的很6，aws那一套包括cloudformation做的很6。


组里的架构涉及kinesis, S3, Dynamodb, EC2, SQS, ELB 什么的，做ops的时候也确实能把组里的架构从系统设计层面/high level看的很熟悉，知道组里service分布式系统怎么设计的，整个流程是什么，end to end。其实不然的话没法做ops，因为出了ticket你要快速定位哪里，然后怎么解决。


天天做的事情比如：改ec2的CFN让我们组更省钱，或者onboard新的load balancer使得性能更好。要不就是写码自动化我们每天的ops，比如customer cut sev3 ticket要求加capacity，我们要做一系列check然后再approve，我做的就是写码自动化这个过程。

主要是烙印经理对我基本就是hire to fire，所以大的涉及组里架构的项目，确实也没让我参与，天天就让我ops。入职一周年整的时候被pip，然后终于有时间刷题了，花了半年跳槽去了 meta e4 一个产品组 backend。


现在在产品组呆了快一年了，产品组里面其实就是不停的改业务逻辑，也用不到分布式/系统设计这些，基本就是面向对象/编程语言这些东西。Oncall任务也不重，虽然deadline很紧，但是不用半夜起床，没有亚麻oncall intensive。其实wlb好了不少。

我其实刷题不错的，lc 刷了 1000道，而且全是medium/hard，也比较喜欢写程序。系统设计那几本书也都看了。

回想起我的亚麻经历，我不断的反思，当年刚进去的时候真的是有力气用不上，一直处于懵逼的状态。一个是亚麻基本不给时间rampup另一个是因为cs科班只学怎么写程序，没教过ops是什么。

但是感觉写业务逻辑容易很多，虽然我现在组里业务逻辑很复杂，各种class交织在一起。Fb的代码质量不咋地，而且没有文档。但是还是比亚麻容易我觉得。

我觉得产品组L4/SDE2这个级别从开发的角度来讲也不是很难，只要花几个月搞清楚组里现成的代码库怎么写的。几个主要的file/class之间的关系，e2e data flow，以及high level/system level组里的service如何架构的。最后是熟悉公司的开发/deploy工具。这样加feature的时候能独立lead project ，不用问别人。基本就行了？


我也确实想问问地里的大佬，我这一年多亚麻经历是不是白费了，对我以后做swe有用吗？其实当时出来面试的时候，我都讲不出来什么，因为什么project都没做，基本都是ops。我一般只能是把组里的系统设计讲一遍，replication / partition如何实现的，service提供的具体的产品功能是什么。但是这些也都不是我写的feature/service。当时要不是meta大放水，我可能就要去面sre / devops了lol

补充内容 (2022-07-26 00:17 +8:00):
我组里人都是野鸡学校毕业的印度人。不像现在的产品组，同事都是美国名校本科，中国人都是清北复交。我觉得ops就是垃圾工作，如果技术含量高，指定这群垃圾烙印做不了。但是我的烙印同事确实吃苦耐劳，troubleshooting做的确实不错。

补充内容 (2022-07-26 01:04 +8:00):
很多人回复说ops也有用，对理解分布式有好处。但是思来想去还是去新组比较好，sde是来build新东西的，不是维护现有service的。虽然维护工作也对build better service有帮助吧。

当然有用。一直觉得公司里管SRE的都是大神lol。很多都是以前做过多年backend觉得写业务逻辑无聊的转sre的。我觉得这年头把devops/sre和以前的sysadmin混为一谈是很可笑的说法。我干了很多年backend也做过fullstack，一个感觉就是investigation的难度往往大于development。在现有屎山上做improvement比从头建新的东西要难。做Migration往往比new integration要难。我自己在做oncall/ops相关的工作时也收获很大。当然这部分往往趣味性低，成就感不强，也不太好在简历上吹水，所以很多人更喜欢做后端或者fullstack.不过我是觉得大部分人做的feature也学不到什么东西就是了，学会调API，数据库多用用，差不多也就这些。


补充内容 (2022-07-25 11:16 +8:00):
其实大家都明白去做分布式系统的实现是很多码农最高追求，但是整个美国这么多公司真正去做这些infra实现的码农总数有超过一千人么.....如果哪个junior能毕业两三年就能去直接参与k8s, kafka, cassandra这些系统的核心模块的Implementation我觉得那真是撞大运了。绝大多数如果真的想去做这些东西那么从ops开始着手是很自然的状态，毕竟这类开源/不开源的infra迭代速度和产品是没法比的，需要的直接往上堆代码的人不需要太多。所以真的想从事这方面的内容我觉得也只能从ops先开始做，然后看看后面发展能不能去参与实现。

补充内容 (2022-07-26 02:47 +8:00):
再补充一个，大家在美国打拼不易，一会这家裁员一会那家hiring freeze. 今天你碰到门槛了明天我遭遇挫折了，希望还是尽量别存在那种鄙视链比较好。今天干devops的是垃圾明天做前端的low， 今天你搞ML的高大上明天你做data engineer的没前途...大家都是从高考,GRE/TOEFL等等一路杀穿过来的，说实话美国科技行业90%的码农工作你都可以在半年到一年内理解并掌握。真没啥必要一会看不上这个一会看不上那个。本来打拼就够累的了，自己人还搞鄙视链就真没必要了。

你也说了做ops能让你了解整个系统，框架和各个部件。那为什么你不可以进一步思考他们为什么要这样设计？可不可以改进？

做ops，只写修ops的feature确实没啥用。但这段时光真正的价值在于你能近距离接触一个超大traffic的customer service，知道具体细节怎么实现的。等你面试的时候，你就可以吹系统设计可以这样这样做，因为业界最屌的AWS就是这么做的。这种经历是绝大多数公司提供不了的，因为AWS traffic就是大。大公司的经历优势就在于你可以观察猪怎么跑的，跳槽以后就用这些经验去教别家的猪跑。

匿名用户 发表于 2022-7-24 14:58
“做很多ops，对自己组里的架构很熟悉，出了sev2能很快解决，并且知道怎么改进系统消除这些sev2。”

...

对，是的。

有一个backend的开发项目肯定比只有分布式的ops经验强。

但是目前市场上，分布式的开发经验 远比 普通backend的开发经验稀缺，而分布式的ops经验是获取分布式开发经验的必经之路。

所以楼主去年面meta 1.5YOE（其实是一年的sre ops经验）面上meta swe E4?

回到正题
sre的经验对于未来做swe肯定是有用的，毕竟大部分swe（尤其是infra方向的swe）也要应对ops问题
但是对你来说，边际价值（Marginal utility）会慢慢下降，因为一直做ops无法升职也对跳槽无用。
————————————————————————————————

楼主想问的问题可能是这个？
如果自己当时在aws core service里幸存到现在，并涉足了一些大的涉及组里分布式架构的项目，是不是比现在在产品组（不针对meta）写业务逻辑要更有优势？
对，我觉得是。swe劳动力市场里，能熟练写业务逻辑的人实在太多太多了，而且供应增加的速度很快。大部分new grad/junior都能干。
但是涉及分布式架构的项目，没有大量的ops经验和扎实的分布式系统功底，是很难开展的。
这个供需关系其实也反映在TC和升职难度上了。

gongchen 发表于 2022-7-24 17:20
所以楼主去年面meta 1.5YOE（其实是一年的sre ops经验）面上meta swe E4?

回到正题

亚麻之前还有一年200人小公司经验，拿到meta也是运气好

我觉得我那一年真是把这辈子的ops都做了，好在现在不做ops了

匿名用户 发表于 2022-7-24 14:24
亚麻之前还有一年200人小公司经验，拿到meta也是运气好

我觉得我那一年真是把这辈子的ops都做了，好在 ...

okok 2.5yoe拿meta e4也正常

更新了我的上面的回复
分布式系统的ops不是完全没价值的。这些ops是成为distributed system engineer的必要条件，但不是充分条件。

gongchen 发表于 2022-7-24 17:20
所以楼主去年面meta 1.5YOE（其实是一年的sre ops经验）面上meta swe E4?

回到正题

“做很多ops，对自己组里的架构很熟悉，出了sev2能很快解决，并且知道怎么改进系统消除这些sev2。”

这些当然对自己组里有用，但是跳槽出去别家有多认可这些经验就不好说了。

跳槽的时候人家总是让我deep dive一个project，但是我从来没有加过feature，压根就没做过project，这个就很难办了。

sponge_key 发表于 2022-7-24 17:38
当然有用。一直觉得公司里管SRE的都是大神lol。很多都是以前做过多年backend觉得写业务逻辑无聊的转sre的。 ...

前辈说的我很赞同，当时有一个latency spike经理让我做investigation，我整整996了3周，最后没找出root cause。这精力换做产品组都写出10个CL了lol。

我觉得ops/investigation，特别是oncall一个不是自己开发的系统比开发难多了。但是做了之后简历上没得写，跳槽外面似乎不认可。还是看写了什么大 feature，launch，impact。除了azure/aws/gcp可能需要这类skills

但是大家都在说远离ops，远离云服务。我觉得我确实还是去了一个坑组。


可能从0到1开发一个大型分布式系统的经验很值钱，但是天天维护做运维真的是都没资格做开发

SRE能学到东西但是如果服务不是你开发的那事倍功半，而且心理/精神压力大，成果不明显，不利于身心健康。

eureka7 发表于 2022-07-24 15:29:29
SRE能学到东西但是如果服务不是你开发的那事倍功半，而且心理/精神压力大，成果不明显，不利于身心健康。

哈哈哈 压力确实很大 凌晨几点的西雅图我都见过

但是onboarding就给三个月，现在做cloud的很少有人能oncall自己写的service吧。都是现成的service

我自己做的那点逻辑如果有ticket，我自己确实解决起来很顺手