第二次实习总结

本文最后更新于：12 小时前

本文记录自己的第二段实习经历。

2022.7 - 2023.6

时隔三年再一次做实习复盘，希望能做得更好。

职位

基础平台研发实习生

这次实习时长一年，中途有过短暂的休息，还有一段时间的放养，总体成果并不算多，但很充实，回想过来还是有不少值得总结回顾的地方，于是做此复盘。

本次复盘有一个追寻的步骤准则：

  1. 回顾经历（STAR 法则）
  2. 结果评估（亮点与不足）
  3. 分析原因（主观 / 客观）
  4. 总结经验（如何改进，有没有其他前辈的方案可以借鉴）

项目内容复盘

除了这些所谓的项目，这次实习其实给我留了蛮充足的时间进行学习，团队内文档建设非常的丰富，有针对新人介绍整体架构的视频，还有对业界竞品架构详细剖析的文档，除此之外各个模块基本也都有详细的文档展示，非常有助于成长学习。

Task 1 快速入门 demo

1. 回顾经历

任务背景：实习的产品是一个 Serverless 产品，虽然有免运维 + 低成本的好处，但是有迁移成本，很多客户没有迁移改造的能力和动力，所以需要一些 Quick Start 案例帮助用户。

目标：两周内开发3个场景的 demo。

行动：第一次使用 Serverless 产品，所以先尝试体验别的 Quick Start demo，感受产品的功能，之后照葫芦画瓢写案例。

结果：耗费三周产出 3 个 demo 及详细的部署文档。

2. 结果评估

功能性：达标。

时间：超时一周。

3. 分析原因
  • 对各语言环境不熟悉，还有运行环境依赖不熟悉。
    • nodejs，花费了大量时间调试异步接口。
    • go，由于依赖 cgo 得装支持 C 跨平台编译的工具链以交叉编译。参考
  • 第一次接触云环境，对于 VPC 等概念都不熟悉，导致开发的 bug 较多。
  • （客观）中期有需求变化，前期解决问题定义不准确带来了工作量（修改量）的提升。
4. 总结经验

最后的文档产出上可以提前将共同点抽出来，可能会更高效点。

需求定义应该更明确，防止返工现象。

Task 2 摸索一个可以做的问题

1. 回顾经历

任务背景：作为偏研究的实习生，导师还是希望我能在整体业务背景下找出自己觉得有意思的可以解决的问题去做，相比于被 assign 一个任务，会更锻炼发现问题、定义问题的能力。不过由于自己也是 Serverless 领域的小白，探索起来还是比较吃力。

我自己首先找了许多论文综述，其中【…】总结的最好，在这里我最感兴趣的有两个模块，一个是关于如何降低冷启动率的问题，一个是关于如何做实例调度以提高资源利用率的问题。由于实例调度上一个博士实习生做了一些尝试，也发了一篇 CCF-B，并且正好组内有一些 Web 项目想要更高的服务质量（延迟），所以开始探索降低冷启动率的问题。

确定好选题后，就进一步就综述中的论文开始研究。并针对目前的架构中可能调整的位置做了分析，并向导师提出了一个 idea。一开始没啥回应但在后续 Web 场景中也有同事提出了相同的探索方向，当然大家并不知道怎么深入做下去，但大家能有同样的想法让我觉得我没白探索。可惜后来有其他项目需要人手，就暂时没继续摸索这个问题了。

发现问题 -> 定义问题 -> 调研 -> 方案选型 -> MVP -> 解决问题 -> 消灭问题

2. 结果评估

在 30 天内小小入门一个领域，并提出一个能产生共鸣做的问题，产出一份论文调研报告。我个人感觉结果还不错，以后面临相对问题应该可以更熟练一些，时间可以更短一些，不过这要看领域的复杂度了，就事论事。

3. 分析原因

时间较长的原因：

  • 研究生期间没有规范的论文阅读训练。
  • 对 Serverless 领域涉猎几乎为 0。
  • 没有每周及时反馈问题，应尽快反馈，提高沟通频率。
4. 总结经验

总结一下我认为初步进入一个研究领域的方法论：

通读业界优秀的综述文章 -> 精读感兴趣的部分 -> 挑选该方向论文学习。

Task 3 控制台参数工具

1. 回顾经历

任务背景：在一次大项目中缺人手，需要抽调我去辅助开发其中的自动推荐参数的工具，这个问题简单说就是根据用户压测的 metrics 去推荐配置。

第一次参与要上线的项目，大致走了以下几步：

  1. 先定义什么是用户希望的配置。（成本 or 性能，这里面的 tradeoff 把控）
  2. 如何得到这样的配置？（采集 metrics 的频率、如何计算？）
  3. 优化：怎样鲁棒 & 高效 & 精准得得到配置（不同 workload 的场景覆盖测试）
  4. 各种 BugFix…
2. 结果评估

功能性：基本符合要求，我自己认为精准度还有提升空间。

性能：基本符合要求，算法时间消耗还可以进一步优化，预期稳定性也可以进一步提高。

时间：基本符合预期，后期奇怪 Bug 解决花费的时间偏多。

3. 分析原因

  • 自己信息检索能力不够，没能快速找到一个 MVP 效仿。

  • 没有有经验的同事，一切都是自己探索，缺少一定的方向性指导。

  • 依旧是寻求反馈的频率低了，导致中间走错过方向。

4. 总结经验

我认为高效的解决问题的路径：看到一个问题先定义好问题的输入、输出、约束，在生产方案前将 Evaluation 确定好，然后立刻去海量搜集可能的解决方案，讨论对比后立刻出一版 MVP 继续讨论，最后确定结果再详细实施，并优化细节。

Task 4 动态参数调整

1. 回顾经历

任务背景：控制台自动推荐参数是一个一次性的工具，但用户的请求 Payload、代码可能都会有变动，如何做到实时感知变化并调整就是一个需要解决的问题了。

调研了非常多的方案，一开始甚至去想自适应限流好不好用，这里自己犯了一个巨大的错误，就是没有想明白那些 RPC 框架自适应限流算法适用的场景。这点没想清楚导致做了一些没必要的尝试，浪费了一些时间。

后来确定方案后，这次是导师提供帮助及讨论最多的一个时期（也因为换座位和导师坐在一起了～），有很多的思考碰撞，非常棒。构造了真实的负载测试，也发现很多场景我们的产品性能和我预期都不太一致，在这里花费了相当多的时间。但这次沟通反馈非常频繁，体验很好。

2. 结果评估

功能性：基本符合要求，精准度还有提升空间。

性能：基本符合要求。

时间：远超预期，第一次直接修改核心组件中间开发的 debug 时长远超我的想象了…（主要还是源于对组件的不了解）

3. 分析原因

  • 在多场景 workload 测试过程中发生了非常多意想不到的性能预期不一致的问题（如高 QPS 下的实例数激增 / latency 暴涨等），对于这些问题的探究解决花费了大量的时间导致总体耗时远超预期。

  • 自己对于自己的代码总是会质疑写得是不是最高效的，非常想知道别人写我的功能代码会怎么写…这也是这次实习中一个比较大的遗憾（被 review 的次数较少），间接导致了开发周期的拉长。

4. 总结经验

最后一个项目在做的时候已经大概有一个套路可循了，至于如何更好得解决，说实话我也不知道…在这段开发中最大要反思的就是不要轻易承诺一个开发的周期，实在太丢人了…

自己的反思 & 别人的建议

反思

  1. 没有从大框架切入，在前期快速了解各个组件的作用。 理应在了解大框架后，比如从一个 createContainer 链路快速梳理整条路径，而这个梳理我是在入职三个多月才开始干，前面花了太多时间纠结小细节了。

  2. 早睡早起，经常睡眠不足导致状态不佳，千万不能报复性熬夜。

  3. 问题定义和如何解决从一开始就是不佳的会导致工作量的提升。规划任务时一定得先有一个想做成什么样的效果预期，并将预期和大家对齐。

  4. debug 能力不足。分析日志的能力有欠缺。 【最好先重现问题】

  5. ⚠️ 及时沟通，纠正方向性问题，及时调整。【你遇到的问题别人可能也遇到，甚至早有思考】

  6. 如果不能确定自己时间管理是否完美，不要给别人轻易承诺 deadline。

  7. 问问题：

    • 问问题时先把现象说明白，再谈自己的思路【不要上来就推测】。

    • 小问题先直接看代码。【避免问较笨的问题】

  8. 成功的标准是什么？做成功的事？【我在这个团队好像并没有觉得大家有什么非常有成就感的事】

导师话语录

  • “我们的 Evaluation 是什么？”，发现问题开始准备想方案时，要先想清楚评价指标，定义好评价指标才好做方案的选型。
  • “脑子里一定得有 benchmark 的标准“，不能忘记相对于 benchmark 的变化，其实这也是时刻记得 Evaluation 的变体。
  • 先做一个钉子将自己所负责的领域打深，做到别人有这个模块的问题都会先想到你去解决。然后再慢慢拓宽自己的管理面。
  • 建立个人品牌很重要。找机会展现自己的能力。

别人的语录

本部门

  • 最快的成长就是 mentor 带着你讨论方案的选择，讨论其中的 tradeoff。

  • 先定义终态，再拆解小问题（近期几个小目标 + 远期一个大目标）。 代码开发是从上而下写的，正确性验证才是从下而上写的。

  • 标准化、可复制化（而非定制化）的解决方案是最关键的，易于推广并吸引更多的客户。

  • 做搭格子的人而非爬梯子的人，争取做一个新方向的 owner。

  • 和别人解释时觉得有点困难时就举个例子。

非本部门

  • 一天一小PR（问题拆解）
  • 主动跟mentor提出要多久升薪的期待
  • 读大部的巨作 + 系统化的学习
  • 工作最好有指标提升的量化数据（TPS提高10%~20%）
  • 每个月产出一个技术博客
  • 及时复盘总结

观察别的同事

  • 回答问题时能精准的先报出 X 种原因 / 方案，这其实就是 think twice 的表现，在回答前脑海中就已经有一个回答的大体框架。
  • 有明确目标，知道要干什么事情的时候，6、7点钟就会自然醒起来做事。
  • 多沉淀文档，空闲时多在自己范围内的其他文档下留言，在有能力的情况下开始表现自己。
  • 会议纪要每一步想法的变更、其动机都详细的记录。
  • 晚上有空闲时留出一些时间学习，吃点草。

未来

TODO

感悟与记录

本博客所有文章除特别声明外，均采用 CC BY-SA 4.0 协议 ，转载请注明出处！