职业规划思考

最近开始找新工作了，但要找什么样的工作呢？还是有点点迷茫，仿佛回到了 2019。

2023 年版本

思考了几天，思绪仍然混乱，这是“写博客”的信号。写博客是我目前最好的沉思方法。 19 年因为这个问题写了这篇博客，当时说“技术深度不够”，这个问题今天仍然存在。 至于“兴趣爱好在哪”这个问题，现在倒是觉得很多东西都足够有趣，更多是结合现实看。

目前纠结的点主要是在数据库测试和数据库开发这两个方向。对于数据库测试方向， 过去有四年工作的经验，有一些“测试+分布式+数据库”的积累，基本套路还算清晰， 就是对未来成长路线有些不清楚。而对于数据库开发，只是潜意识觉得自己对它更感兴趣， 但可以做什么，以及入行需要什么技能，还是挺不清晰的。

为了避免“做什么错什么”的尴尬境地，还是要把解决思路给弄弄清楚

• 工作哪三要素对我来说最重要？
• 把自己的担忧清清楚楚的写明白，这个“迷茫”的问题是不是就能解决了？
  • 比如对“测试”这个岗位的担忧到底是什么？
  • “开发”的哪个点让我觉得它很有趣？
• 看有哪些数据库测试或开发的岗位，看看其中有哪些能投的？
  • 注：做这个事情，帮助不大。因为看完之后，我发现研发岗都不太好投， 数据库测试的岗位都可以投投试试。

工作最重要的三要素

自己对一段工作，最看重的三点是什么？ 从这个角度来判断自己想要什么工作：

1. 事情：能涨知识，且有可持续性。判断依据是这个领域 1,3,5,10 年会有递增的积累。
   • 为什么？这样自己有成长，随之而来会有成就感，可替代性也没那么强。
   • 具体一点：这个领域的专家能让我心生敬佩。
2. 团队：小伙伴有个人追求。不要：事事打太极；事事得过且过；无沟通交流。
   • 为什么？这样方能开心的工作，能互相学习和成长。
3. 工作时长：9-5-5 是理想型，10-8-5 接近底线。
   • 为什么？迎着夕阳下班是最幸福的事情之一。回家只想躺我是拒绝的。
4. 为什么没有提到薪资？目前生活对薪资的要求还不高。

上面的几件事还是偏理论，来点实际的例子：

• ✔ 如果一段工作结束之后，能结交几个趣味相投的小伙伴，想必是非常美好的。 对应就是希望团队小伙伴是友善的，如果有共同兴趣和三观则完美。
• ✖ 工作内容一直是在解决同质的问题，比如把 A,B,C,D… 产品化。 但如果是把 A 产品化进行持续优化，则不算同质。
• ✔ 团队能偶尔一起吃饭，能偶尔有说有笑。
• ✖ 团队一年到头没见过面，团队鸦雀无声。
• ✔ 可以在解决问题的时候获得成就感。工作内容不是可有可无的。
• ✖ 每天担心自己将来一天会被裁，而且找不到新工作。
• 后面想到再补充吧！

对测试岗位的担忧到底是什么？

对测试岗位的担忧其实有很大一部分是来“互联网行业普遍认为测试是一个技术性不强的岗位”， 是一个可替代性较强的岗位。我有不少小伙伴也这样觉得。虽然我知道测试事情要做好， 难度比开发可能还要高，但我自己潜意识也基本认同这个观点。为啥呢？

开发技能对比：开发 vs 测开

直观感受是：如果我把自己看作一个 TiDB 测试开发，那我的开发技能是不如 TiDB 开发。 那到底开发技能哪里不如他们？

以 TiKV 存储研发为例，他们基本都熟悉存储的典型数据结构算法；RocksDB 的运行机制； 都对 Raft/Paxos 算法有基本的认识；对并发编程也有一些经验；熟悉 c++/rust 编写； 往往其中某一两个点会比较精通。那回头看自己，自己对这前面这些理论其实也了解， 但和熟悉还是有一点差距。也就是说，我认为的_不如_， 其实在于这个领域的知识掌握度不如他们，并且我没有哪一个点非常精通。 （这里总他们他们的，还挺不礼貌的，毕竟我很多小伙伴都属于“他们”的范畴 :尬笑:）

测开测开，还有测试技能呢？感受明显的一个点是他们对测试（如系统测试）的要素了解不够， 也就不知道如何设计一个自动化测试框架。测开其实也算是一个领域，就像分布式存储一样。 那这个领域有哪些知识点？我有没有哪一个很精通呢？以系统测试框架为例，知识点有这些： 系统测试用例的常见模式；常见的测试框架以及它们的优劣； 环境/资源隔离；资源调度；oauth 服务；流量回放等。我精通第一个？

测开和开发岗位的共同点在于，都是掌握一个领域知识，然后需要在某几个点精通。 要想全部精通，都需要多年积累。两者差异在主要还是在于领域知识上。 前者（storage），偏底层一些，参考资料基本是论文或开源系统源码。 后者大都参考现有产品或框架，后者偏应用。前者单个知识点的复杂度， 会更高一些。比如小白学 RocksDB 和测试框架所花的时间，我相信前者要多一些。

另外一个差异是产品品质要求。类似存储这样的产品，它的用户是实实在在有高性能、 高可用性的要求的，也就是这些知识点是实实在在要用上的。比如性能，往往就体现在并发编程、 和对操作系统的理解基础之上。而对于测试框架这样的产品，我的经验告诉我， 它的用户往往是相对宽容的。用户遇到问题可能也只会在心里吐槽，这东西怎么这么难用， 然后用户心理又想，“又不是不能用”，就这样吧。后者对性能要求一般基本没有， 但易用性的要求往往会更高一些。

总结一下，类似数据库开发这样的岗位，我认为这样的工作本身就会 push 你成为一个精通的家伙， 在这样的背景下，团队人才密度可能会比较高。而对于测试开发，精通和入门差异也是非常大的， 是满足我自己说的三点要素的。不过要达到精通的水准，个体一定要沉得下心来， 因为环境可能比纯开发要差些。换个角度说，它挑战可能更大。

测试技能

前面只聊了开发技能，如果把测试技能的因素也考虑在里面呢？

抛开对产品的理解，测试有哪些领域知识？之前合作的同事中有测试技能让我特别佩服的。 我尝试结合自己经验，分析下ta的知识领域。

• 测试理念与测试活动：熟练知道开发流程各个阶段干什么测试活动，每个活动用到什么方法。 比如需求分析评审；测试计划与策略；测试方案设计；可测性需求；缺陷分析与管理；质量度量。
• 测试用例设计：知道遇到不同类型的 bug 该进行什么样的测试活动，以及测试用方法。
• 测试综合素质：细心，不放过小问题，沟通能力强。比如对一个产品原理的求知欲； 对问题的持续追踪能力；推动开发解决问题的能力。这些素质也是有前面硬核知识作为基础的。

回过头想想，在之前测试团队，有牛逼的性能专家，也有让大伙佩服的测试专家， 也有 leadership 很好的老板。也就是说，这个岗位完全有潜力满足我对工作的要求。

测开专家应该长啥样？

一句话描述它：对数据库测试的一个垂直领域很熟悉：比如稳定性，性能，正确性。 知道这个领域常用的测试技术，并且对测试理念与测试活动有基本了解。 拆解成具体能力的话，我认为测开要精通的内容（程度划分：了解 -> 熟悉 -> 精通）

1. （精通）稳定性 / 性能 / 正确性的领域知识。
   1. 稳定性：比如 raft 算法，选主的坑，日志复制的坑？？？
   2. 正确性：比如事务；一致性（一致性的测试负载）。
   3. 性能：好像每一层都有。
2. （精通）测试用例编写框架的设计。见识更多的测试框架，有丰富的 API 设计经验。
3. （熟悉）提升分布式产品可测性的常见手段和实现技术。
4. （熟悉）测试理念与测试活动。目前只是处于了解阶段，细节不熟悉。
5. （熟悉）产品领域知识。目前只是处于了解阶段，细节不熟悉。
6. （熟悉）所需编程技能：C/C++ / 并发编程。

偏基础设施的测开要精通的内容（和基础设施专家或许已经比较像了）

1. 测试用例编写框架的设计。见识更多的测试框架，有丰富的 API 设计经验。 2. 资源隔离的技术方案。资源隔离对于工程效率或者测开太常见了，docker 的原理细节、IO 隔离等？ 3. 资源/用例编排与调度技术。 4. 熟悉这个领域常见测试方法与技术实现原理：如流量录制与回放。 5. 混沌工程。 6. Linux 内核。 6. 所需编程技能：Golang，docker（原理级），K8s？

哪个工作能培养这样的专家？

以之前的工作经验来看，可测性这项工作基本是依赖开发来负责具体实现，测试可以提出需求或者建议。 类似性能、正确性等领域知识，是测试和开发配合一起完成。在这种背景下，测试基本不需要改动产品代码， 也就是较难产生上面所说的偏测试的测开专家。但怎么说，这个和团队人员的技能树确实也有较大关系。

这里一个困境我了解到的研发和测试团队都很难培养这样一种专家，但它们都有潜力。

所以，担忧是啥？

测试、测开、开发这三个领域我目前都沾边，最合适自己的领域则是“分布式数据库测试开发”。 因为这些领域知识，我都具备一些。但担忧在于，怎样才能成为这个领域的专家呢？

我担忧未来的工作不能促使自己达成目标，因为还没有看到已有的某个团队完成了这样的事情。 而如果换成研发，我可能会觉得把那些论文看完，把那些代码在生产项目上撸一遍， 大概也就能成为专家了吧。前路清晰，可控性较强。而测开则是挑战无限，若隐若现。

开发真的很吸引我吗？

写了上述章节后，我觉得这个问题似乎没那么重要了。不写了。 简单来说，确实挺吸引的。因为行业成熟，人才密度够，可预期性较强。

找啥工作？做啥准备？

测开可以，但要详细了解团队的目标和我的想象的差异。 开发也挺好，但怎么入门是一个重要的问题。

1. 把测开都面一遍，找一个最符合要求。
2. 把存储也都投一投，看看有没有能入门的。
3. 还有一些东西，两者都有用：刷点 leetcode；并发编程；C/C++ 技能。

2019 年版本

我之前做过 工程效率、运维开发 两个岗位，这两个方向似乎都和 DevOps 挂钩， 我也没有深入对比过这几个岗位的差别。但自己最近一年都感觉这个方向， 是要求工程师有一定的技术广度（从前端到运维），但是对深度要求不高， 感觉一不小心就会被变成一个只会写 CRUD 的工程师。

但我自己（似乎）还是希望在一个方向有比较深入一点的研究，于是就在想一个问题： 自己的兴趣爱好到底是什么？可以匹配到哪个岗位？

想了两三天，也没啥结果，只能先整理一下自己知道的一些工作和岗位。

SRE vs DevOps

推荐文章：https://juejin.im/post/5b95448cf265da0aa41e4e6c

比较认同：DevOps 是一种文化，SRE 则是一种具体的岗位。但在需求的推动下， DevOps 演变成一个岗位。另外，个人感觉 DevOps 和敏捷开发这个概念也是兮兮相关的。

其中，提到的工作内容区别也挺有意思。

DevOps	SRE
设定应用生命管理周期制度，扭转流程	制定 SLA 服务标准
开发、管理 开发工程师 /QA 工程师使用 开发平台系统	开发、选型、管理 各类中间件
开发、管理 发布系统	开发、管理 分布式监控系统
开发、选型、管理 监控、报警系统	开发、管理 分布式追踪系统
开发、管理 权限系统	开发、管理 性能监控、探测系统（dtrace、火焰图）
开发、选型、管理 CMBD	开发、选型、培训 性能调优工具
管理变更	管理变更
管理故障	管理故障

关于“工程效率”这个岗位

几种理解

搜集了几中对工程效率的看法，下面是一种理解：

2023-05-18：重看这段文字的时候，感觉这个相当于啥都没说嘛…但仔细琢磨 （出于对当初自己的信任），似乎还是讲到了核心点：让业务可以全心全意的做自己的事情。 这本质的逻辑或许是：它认为效率提升不是业务开发自己的事情，而是可以剥离开来的。

Productivity Engineering aims to reduce cognitive load so that engineers can devote the majority of their attention to delivering business value.

https://medium.com/@ProdEngSV/productivity-engineering-4aff8b560d0b

翻阅一些资料，找到 Google 对工程效率的一些看法。下面是 Google 对这个岗位发展前景的看法：

You will learn about testable and maintainable systems as well as sustainable engineering practices. You will also develop your communication, collaboration, and leadership skills. What you do with these skills will be up to you!

2023-05-18: 我当下确实感觉工程效率这类工作需要较强的“协作/领导/管理”能力。 在 PingCAP 工作经历让我觉得，测试也类似，经常需要和产品、开发沟通。为什么呢？ 因为我直观感觉，开发其实是一个非常明确具体的工种，开发流程当下也是比较明确的。 而测试则依赖公司测试流程的完善程度，而（我感觉）测试流程完善且合理的公司不多。

怎样判断是否真正提高了效率？

Google Engineering Productivity (data-driven): You believe that unless you can quantify or measure something, you probably can’t improve it

2023-05-18: 想起前几天一个面试官问我你做的测试框架提升了多少效率？回想一下， 当时回答的不太好，我觉得下面这段话可能还没有深入我心。当然这段话，有技术人表示不同意。

这句话是职场管理者们说的话，因为他们他们的行为被公司的财务报表绑架了，他们无时无刻都要算投入产出， 这句话直接导致了KPI管理……这句话挺臭名昭著的 [ref][kpi-measure-improve]。如果你相信的这句话， 你将永远无法得到成长……我觉得应该这么说：如果你没见过什么是好的，你将永远无法成长……

– https://twitter.com/haoel/status/1657249109034827777

工程效率、运维开发和研发效能

我理解“运维开发”则是：早期的运维开发就是将运维自动化，当时应该还没有 CI/CD 这些东西， 但后来大家都渐渐接收了 DevOps 这个文化，这个岗位渐渐演变成 DevOps 开发工程师。

我理解“研发效能”则是：DevOps 关注的中心是应用（服务），流程是从开发到发布到运维： Dev -> Delivery -> Ops 研发效能关注的中心是项目，流程是从立项到开发到上线： Project -> Dev -> Delivery。