🍌云2年 --- 总结我学到了什么

楼主在亚麻云工作2年多了，快跑路了。写这篇帖子对这两年的经历做个回顾，总结下我学到了那些SDE、backend的技术技能，与同行们分享交流一下。
总的来说在亚麻云还是学到了很多的！虽然很累 :(
(如果我写的不妥，有泄露什么内部消息，麻烦告诉我一声，我好修改。。。）

技术栈
我主要是负责开发某个内部的service，提供APIs给上游的、其他内部的services使用，用来读取或是修改我们组下游的数据库里的内容。

我们组的service的技术栈总结如下：
* 下游services包括：key-value database; 类似Blob storage service; Auth service; Metric service; Log storage service.
* 我们的service框架：亚麻内部service framework; RPC. HTTP (在host上有另外一个程序来decrypt HTTPs to HTTP).
* Service discovery: (1) DNS, or (2) DNS and a service to return server IPs
* Testing: (1) unit test; (2) integration test; (3) load test; (4) integration test which runs at all times.
* Deployment: 内部CICD的pipeline to deploy to all AWS regions.
* Monitoring: 主要metrics是API latency; availability; Host CPU/Memory/Disk.
* Logging: Service log with information of every API request; Application log for service start/shutdown info, warnings, errors, and stacktrace.

工作经历
接下来记录下我这两年都干了啥，每个阶段都学到了些什么。

第一年工作经历
按月来划分：

• 1~5: 开发API和Integration test. 学习了Java, dependency injection, unit test, integration test; 亚麻的Java编译和包管理。读了Effective Java和Head first design，在前辈的code review下，感觉写漂亮代码的能力得到了许多提升！
• 6~8: 做API load test. 学习了如何使用pipeline；如何配置我们的service、然后部署到pipeline的某组hosts上；学习了我们service是如何产生logs的，都使用了哪些logs管理工具；部署的时候我们的service以及相关程序是如何被启动的。期间写了我的第一个design doc，来解决压力测试时我们service遇到的问题。
• 6~8: F**king new region build， 而且还是部署我们的service第一次到政府的regions。每次出了错，我都看不到error，要和有政府权限的engineer沟通，特别烦。 这段经历中我又进一步学习了pipeline的设置（例如deployment time window; what metric to trigger rollback deployment; other deployment settings). 同时学习了我们的service都需要哪些resources（e.g.部署环境; HTTPs所需要的证书；DNS and Load Balancer等等). 此外，由于政府engineers特别忙、老是不理我，我还得到了一个BQ经历 --- 当对方组不理我时，我可以escalate给我的manager :)
• 9~10: 给我们的AWS service的public APIs写integration test。这算是我第一次从用户的角度了解我们的AWS产品。
• 11~13: 给我们的AWS service的WebServer的代码做refactoring。听上去很高大上，其实就是把code和classes移来移去。我写了几个design doc。还算是一段有帮助的经历。
  

第二年工作经历：
* 2~4, 7~8: 做了一个让我们的service能scale up、接受更多QPS的项目，用client-side load balancing取代server-side load balancer. 感触颇多... 一开始预计2~3个月就能做好部署所需的活儿，结果花了5个月才真正做完，之后部署又花了更多的时间。这是我第一次自己负责一个中等的项目，项目由于各种误算、阻碍，不断延期，我好几次得尴尬的告诉老板说我做不完。这算是宝贵的成长经历以及BQ经历吧- -| !!! 在技术方面，这期间我对我们组service是如何运作的、如何部署的又了更深的了解。
* 4: 开发了一个内部的command-line工具
* 5~6: 开发了些代码，让客户方便call我们的service
* 9~Now: (a) 做了好多ops活儿；(b) 之前scale up的项目有蛮多followup tasks；(c) 给我们的service和一些refactoring项目写docs，以及也写了一些修修补补的代码。
. 1point 3acres
总结
感觉这偏总结帖写的有些冗长了...

稍微做个总结：
在亚麻云这两年，还是学到了很多东西的。如果让我开发一个新的internal service, 应该没啥大问题、流程我都比较了解了，应该能比我的第一个项目做的更好。
但如果是让我开发一个external facing service, 这方面经验还比较欠缺。在领导力方面，我也才刚刚够格SDE2。

另外还想谈谈我没能学到的知识，比较遗憾：
(1)没有机会使用 SQL数据库，message queue, lock service等等其他分部署系统里的组成部分。没有机会使用native AWS。
(2)我们的service不存储数据、不用考虑concurrency、consistency的问题，感觉数据库的核心技术没法学到。

最后，想说下我为啥要跑路了。。。一是对组里的技术熟悉以后，就觉得没意思了；二是太累了，不知道是不是亚麻的原因；三是 写业务逻辑写腻了，做ops做累了，感觉没啥意思。
准备去给手机写c++ library了。有点害怕这可能是职业规划上的倒退。不过还是去试试看吧，希望比现在的工作有趣.... 如果各位朋友有啥建议，写谢谢各位了。

以上。O(∩_∩)O各位看官















补充内容 (2022-04-04 14:10 +8:00):
再说几点oncall(ops)的感悟。。。

我觉得吧，
好的oncall/ops tasks:
* 发生在白天
* 能学到新知识，e.g.了解其他service，或者更好的掌握自己的service
* 解决我们自己的service的bug。反思为什么会出现这个bug
* 改进我们自己的service，减小oncall load.
* 某些严重的sev2, 有机会旁听managers,senior甚至principle engineers开会。要是自己能插上话，就更好了

坏的oncall/ops tasks （这个占了大多数）:
* 晚上或者周末的page
* 手动的、机械性的活儿：(a) 跑xxx指令； (b) 找failure的logs; (c) 手动更换bad host;
    - 改进方法： 自动化；改进指令；改进UI. （得向自己老板提要求priorite它；或者给其他组提feature request, 虽然常常不会有回应)
* 明明和我们组负责的service不相关，却assign给我们组负责。
* 给前人开发的service做 region build --- 很可能doc不全 + resource synthesis的代码不全，很是头疼。
* Solve library version upgrade failures
* 另外，做一些dependency/tool migration也算是ops活儿吧 --- 就是照着migration guide依葫芦画瓢，没啥意思。。。
* 我们自己service的false alarm或者flaky alarm，浪费debug时间。 (请尽快解决它们！)

最后，除了技能意外，我还从oncall学到了厚着脸皮在半夜page别人的能力（大误）。
希望世间没有night page.

附注：我总结了一下我oncall遇到的各种各样的问题🚨，写了个bug sheet的帖子: https://www.1point3acres.com/bbs/thread-878659-1-1.html
多谢各位看官阅读👻

补充内容 (2022-04-09 07:48 +8:00):
======================================================

除了技术栈/Oncall以外，最后我再试图总结下非技能方面的感悟吧：

---------

项目规划
我做的升职项目延误了蛮久的。
* 导致延误的原因包括: (a) 在design阶段有些任务没有深入分析，低估了项目的复杂度，导致延期。 (b)没有留足足够的buffer应对bug和意外的项目阻碍。(c) 没有考虑其他ops任务、突发任务、甚至是休假对项目预期时间的影响。
* 解决办法：(a)花费更长的时间在design上。(b)(c)感觉比较难。作为engineer我需要尽量说服老板给自己加更多的 buffer time；而老板的立场则是为了提高产出，会质疑员工要求的extra buffer是真的还是想摸鱼。如果没有老板，我应该会把所有任务估算的耗时加起来x2当成预期的总耗时吧。（题外话：以前本科做一些电子/机械方面的设计，感觉更是需要x3预期耗时).
另外一点感悟，如果想在组里干长久，最好别burn out、健康要紧。老老实实和老板说我做不完，让他多给点日期。我感觉我是老加班，导致心累、想换组。（如果老板很不通情达理、push的很紧，那还是少加班多刷题吧...)

---------

Push back其他组的请求
大概两种情况吧
1. 列举利弊后，这个request不合理，那就自然的回绝了。注意，是要有理有据的“甩锅”。这可能需要对我们组的技术、业务、定位比较熟悉。
2. 分析一通后，发现这确实该由我们组来做，但是我们组没有时间呀！我们组有更重要的任务。这时候就只能婉言告诉对方，我们很忙，小任务的话我们尽量抽空试一试；大任务的请找我们的老板详谈。
幸运的是我作为SDE 1or2, 遇到难的问题，我可以说I'm not sure...然后请老板和senior来决定。

---------

提高在会议里的visibility
* 一是提高自己的技术能力吧。有干货才能提出好问题、好建议。怎么做到呢？(a) 会议上多多听senior的发言；(b) 有时间仔细研读下自己service的design doc和road map, 以及上下游service的system arch。(c) 如果比较闲或者比较上进的话，可以和老板、senior说，我也想当senior、我想去多旁听旁听会议。
* 二是大胆的问、大胆的说吧。（其实我做的不太行。。。有些时候有想法、问题，但还是闷在肚子里了）给建议不一定要是对的、不一定要propose solution。提出质疑、提出concern也是很棒的feedback.
* 三是.....如果会议里没有大佬，都是和我平辈或者经验更少的人，那他们可能就没给啥建议或者给的很菜的建议。这时候我自然就有义...

补充内容 (2022-04-09 07:49 +8:00):
务发言，自然而然就有visibility了。

其他的 等想到了再写。。。。

给楼主点赞，能感觉到一步一个脚印学习到了很多AWS的东西，前途无量！

匿名者 发表于 2022-4-3 10:47
Lz能说说怎么在亚麻survive，怎么看经理是不是好经理啊？ 我是New hired刚进亚麻

survivie的话，我当初就好好干活就survive了。。。应该有其他人写的帖子写的更详细

我理解的好老板 ：
* engineer遇到blocker, 老板会想办法帮助他；
* engineer项目延期，老板应该是分析为什么延期、帮助engineer下一次做的更好，而不是质问engineer，逼他加班，之类的；
* 帮engineer做点职业规划，给engineer想要的项目、resource
* 和其他组开会的时候，尽量把烫手的山芋甩给其他组，把好活拦给自己组

哪天等我离职了，我也想开个贴记录一下我非典型的亚麻生活，应该和99%的麻厂员工不一样吧hhh亚麻真的太大了，太多样了

lz拿到某核心组经验，不亏！羡慕能写c++内核的

给lz点赞！

很棒，鼓个掌

跟楼主正好反过来，我是先写了两年c++ library，然后跑去写service业务逻辑

匿名用户 发表于 2022-04-02 11:05:49
跟楼主正好反过来，我是先写了两年c++ library，然后跑去写service业务逻辑

层主能谈谈为什么换方向吗？

匿名用户 发表于 2022-04-02 11:32:52
客三消 我建议留在后端

能说说理由吗？
. ----我最近跳槽也多少有些感觉到，后端开发需求多，每个大公司都需要web/app service，职业上感觉很稳健

感谢lz分享，写底层未必是后退，厚积薄发，积累的经验都是有价值的