毕玄谈技术成长之路

引言：

本期话题就是整理自“内部技术沙龙SmartCode--之毕玄《技术成长之路》”，内容包括如何提升技术基本能力、如何做好架构师角色、如何做好技术Leader这样的角色；正文不仅对本次分享进行了梳理，还把大家关注的QA也放在了文末，希望这篇文章能够给你带来一定的启发。

1. 分享嘉宾介绍 - 毕玄

2. 技术成长之路

总结来讲，不管往哪个技术方向走，都不存在好坏的说法；对于所有技术人员来讲，适合自己就是最重要的。但无论未来成为专业技术人才、架构师、技术leader，又或者是做业务、创业等，作为技术人最基本的是提升专业技术能力，技术的功底始终是必须的。

3. 提升专业技术能力

3.1 深度掌握所做的事情涉及的技术/业务

写一段代码可run的代码不难，但写一段无论如何都可以稳定run的代码却非常难。

对于所有的程序员来讲，最重要的是掌握正在做的事情所涉及的技术或者业务（背后的逻辑），这不一定是公司的要求，而是每个人对自己的要求。

• HSF的故事：HSF体量非常大，如果不掌握背后逻辑就很容易出问题。

毕玄 02 年毕业，07 年加入阿里，工作 5 年后接触 HSF 时，发现自己对技术的掌握并没有那么深刻。当时中间件团队的很多人在加入淘宝前没做过大规模系统（日天访问量 100 w+，甚至上亿）；由于没有经验，根本没法想象会出现的故障。

HSF 第一个版本上线阿里淘宝的后台系统（为客服小二服务），HSF服务调用量日均 100w 左右；初始上线时没出现问题，小看了高并发的系统的难度；遂决定上线至最重要的交易中心。整个系统发布完毕后半夜出现了异常，体现在淘宝打开页面变慢，于是花了 1 整天定位问题，到当天晚上淘宝页面出现打不开的问题，只好暂时下线 HSF。

回滚掉后立马就恢复正常，最后排查定位到问题是由于依赖Jboss远程通讯默认的超时时间是60 s；当超时时间特别长，后端有处理慢的请求时，处理的线程池会慢慢被耗满，导致越来越慢。因此，我们总结出对于像 HSF 如此高并发的系统，这个地方必须自己写才能够完全掌握在自己手里。

HSF上线引发的问题让毕玄真正理解了理论（《高并发Java》等相关书籍）背后的实践以及高并发系统与其他系统的区别；最大的区别在于是否真正了解代码运行逻辑，写代码过程中会调用大量三方API，而是否真正了解调用后所带来的效果是非常重要的，就如同做运维的同学必须清楚了解敲下的每行命令的效果。

后来，要求中间件团队写基础代码及业务写核心代码清楚了解所引用部分的含义，阿里也不允许随便引入三方的开源。

• 方法：阅读源码，自己模拟写对比最好的

任何代码语言所调用的 API 、类库等所有的源码都是开放的；深刻理解写代码时所引用的背后逻辑的方法即是进一步地去看源码，在出现故障时的帮助更甚。

第二个重要方法是模拟去写代码。在每个领域，开源都会有非常精华的部分。比如学习通信的代码，可以基于 Java 最原生的 NIO API 按照自身理解写一个通信框架，再与 Netty 的代码相对比。

3.2 提升解决问题的能力

每家公司或多或少都会有一些传奇人物 —— 出现问题解决不了脑海里就浮现出的程序员，解决问题对于综合能力的要求非常高，他们则被认为是这家公司里技术能力特别强、写代码特别好的代表。

• 淘宝消防队的故事

有一次出现了比较大的故障，发生半小时后技术老大了解是谁在处理故障，结果没有人在处理故障。

这时候出现了一个非常神奇的组织 —— 淘宝消防队，有一个运维同学牵头将一帮喜欢处理问题的人聚在一起建群，群里的人就叫做消防队，客服出问题时可以告知消防队，就会有人去定位问题并解决。毕玄就是消防队中的一员，好几年一直在处理各种各样的问题，随着处理问题的数量变多，处理问题的能力大幅上升；同时在阿里最传奇的技术人物多隆身上不断学习解问题的方法。

解问题与写代码的区别在于考察综合能力，很多人处理不了问题不一定是能力不够，而是对工具的知识累积不足，了解后慢慢就熟练了。

• 方法：尽可能多主动参与解决问题，加强对运行原理的理解和掌握。

解决问题的能力比掌握背后原理对技术的理解更难一点，需要去创造机会让自己能参与解决问题。同时，在很多公司更偏向恶性循环，通常是某几个人解决问题能力特别强，慢慢问题都被他们解决了，他们积累的技能越来越强，其他人可能解决问题的机会就越来越少；大家可以多主动地去参与解决问题，哪怕是与之没有关系，至少可以了解情况。

监控团队以及运维团队通常会整理好过去出现过的故障，大家可以翻看故障归因，对未来解决问题可能有所帮助。

解决问题所有的基础都是对整个运行原理的了解和掌握程度，有了基础后尽可能多去参与解决各种各样的问题。

3.3 鲁棒性高的设计和代码

最优秀的程序员一定是在前面两个基础上做到设计以及代码鲁棒性非常高，这就是优秀程序员与普通程序员的最大差别。

检验程序员的功底就可以阅读代码，鲁棒性非常高的代码无论放在哪里、在任何情况下，基本能做到预判的输出。

• 1999年价值3亿💲的火星气候探测者号故障的故事

有一个探测者号发射到火星上，降落时坠毁。故障发生在 1999 年，造成超过三个亿美金的损失；由于火星气候探测设计需要花很长时间，损失是金钱与时间双因素。

故障原因是代码由美国和英国团队合作，有段 API 由英国团队提供，美国团队使用。计算降落冲力时， API 里没有单位，只有数字，两边团队就单位问题造成了误解，计算错误导致下降烧毁。

故障可以映射至程序员日常工作，当你去调另一个团队写的 API，很多时候可能会默认按自己想法理解参数，未仔细查看文档。

• 方法：基于解决问题的能力，做具备鲁棒性的设计，以及写鲁棒性的代码。

对于很多程序员来讲，会觉得写代码能正常跑就好，不用花很多精力提高鲁棒性；这就是程序员对自己的要求，而却是优秀的程序员最能体现能力的地方；一方面是解决问题的能力，另一方面是写的代码几乎不出问题，即写防御性的代码。

3.4 总结

未来无论从事什么样的技术岗位，专业技术能力都是技术人员的基础，有了这些基础以后才有可能在某个岗位上做得好、被认可。这种能力一旦有所提升，会变成技能沉淀，不大会忘记。

在任何角色上所做的所有判断，都来源于对技术的理解，而专业技术能力就是对技术的理解。

4. 成为领域专业技术人才

4.1 深入领域知识，且知道领域的天花板

专业技术能力提升到一定程度会面临选择的问题，也就是到底应该往什么样的方向去走。

• 对应的领域在学术界/工程界的天花板的情况，深入掌握领域的技术。

第一选择是最简单的选择，即成为领域专业技术人才，核心是往更深处走；特征是对非常垂直的小领域有浓厚兴趣，可以挖得非常深。

如果往专业技术领域走，最重要的是一定要非常深入领域对应的知识（比如 IO 、语言、编译器、内存管理......等等领域），要对此专业领域里所有的细节、知识都清楚了解。

很重要的是要明白领域的天花板在哪里，否则你认为的领域创新可能早在多年前被别人“捷足先登”。

而学术界与工程界的天花板有所不同，学术界通常比较超前，但是否能在工程界落地有待考虑；而需要打探清楚工程界的天花板在哪里。

• 方法：各类顶级大会，进一步深入掌握相应的技术。

最重要的方法是顶级大会，每个领域都会有公认的顶级大会，最重要的技术突破都会在顶级大会上出现。

比如，操作系统领域发生过革命性演进的内容几乎都是发布在 OSDI 和 SOSP 的论文。只用研究每年大会的论文，就可以大概知道领域的天花板在哪。

4.2 实战，有“小”作品

第一步了解天花板在哪里，第二个就是实战。专业领域的人不仅是在领域内维护、解决问题，更重要的是做出创新，做出更有价值的东西。

• 技术群体是一个作品说话的群体

对技术人员来讲，是用作品说话的。没有人关心在公司是多高的级别/多大的leader，而是更关注过去做过什么，为公司贡献过什么。

如果是某个语言的作者找工作，简历上只写「我写了 Python」这一句话可能比任何语言都更有说服力。

对技术群体来讲，从长期的职业生涯来看，是否能做出作品比一切都重要。

• 方法：在公司内做出对公司有价值的作品的基础上，通过开源社区/顶级大会建立影响力，进入“圈子”。

思考对公司的价值到底是什么，往深处发展的人做对公司有价值的东西，通过开源的社区去建立自己的影响力，通过顶级大会进到专业性人才圈子里；圈子则是指大家做过同等重量级的东西并互相认可。

4.3 创新，改变，“大”作品

做更大的创新、更大的改变；把作品的范围拓宽，不仅仅对小特性改进，而是对很大的特性改进。

相对来讲，大多数人不适合往深处走，重要的是看个人兴趣。往深处走是非常孤独和寂寞的过程，要在一个领域研究非常多年才能有积累与巨变；通常需要很好的平台，需要很好场景真正落地创新。

• 基于对领域的发展的深刻认知，及对未来的判断，做出创新和改变，推进领域的发展，例如JVM的Warmup，内核QoS。

阿里JVM团队有很多东西可以做，但在当时认为，如果做好 Warmup 会对整个公司有很大的价值；同时在这个领域对业界是非常大的贡献。业界之前针对这个问题未有优解，阿里做了 Warmup 后在整个 JVM 出圈。

• 方法：基于历史的分析，基于好的场景的落地。

比如开源，提交了很多小的 patch ，对整个社区并没有太大创新性的贡献。阿里以前的策略未在开源投入过多资源，应该在某些集中领域做更大的创新、对社区影响更大。

比如内核，由于存在离线混部的诉求，内核欠缺的能力是按 QoS 来做资源/ CPU /内存的调度，操作系统领域并没有好的解决方法。在阿里有需要场景的情况下，可以在这个领域继续去做以及对整个社区产生非常大的影响。

5. 成为架构师

架构师适合更多的人，很多人都会做架构师这个「角色」。多数公司不会有架构师的「title」/「岗位」，更多的是「角色」，比如项目所需要的架构师。

5.1 拓宽知识面，且知道要解决的问题的天花板

与成为专业技术人才相比，成为架构师最大的区别是广度。知识面需要拓宽得非常广，面对复杂度的问题；很难说某个点非常难解决，多是综合在一起变为非常难的问题。

做架构师最重要的是将知识面拓宽，同时明白其天花板。

天花板对于技术人所有角色都是最重要的，它决定了对技术的判断，以及技术的未来走向。

• 知识面拓宽到系统涉及的方方面面: 基于时间/资源等的权衡、系统运行结构、可扩展性/可运维性等等。

毕玄曾经做容器时，上线前发现没有考虑到网络、不同机房以及存储层面的问题。写代码只用考虑用代码实现需求，而做架构师需要考虑多个程序员一起写出来的组装程序如何确保正常运行。这对知识面要求非常高，包括考虑生产环境部署时的结构。

架构师需要处理的更复杂问题是权衡 —— 架构为什么一定这样设计？其中考虑的是在做架构的过程所做的权衡，面临的非确定性问题而是选择问题；这种时候多看“杂”书其实会有帮助。

在设计系统时，由于代码上线后可能会在生产环境运行多年，架构师就要考虑未来拓展性及可运维性，考虑的问题可能涉及到未来十年系统的不断发展。

• 对应的要解决的问题在学术界/工程界的天花板的情况

架构师通常来讲是解决相对复杂的问题，无论是业务需求或技术需求的复杂度都会非常高。面临问题时，先不要着急想自己如何去解题，而是可以针对问题进行深入了解。

阿里07-08做单体应用到分布式架构改造时，外部有一些可参考的做法，以及一些公开的分布式架构的分享还是对当时的架构师有一定的启发和帮助的。后续做异地多活时，痛点在学术界/工程界都没有最佳案例参考，对我们就有所挑战，需要自己琢磨。再发展到容器化，在离线混部方向自己做容器与 Doc 最大的差距是无镜像将环境标准化，回顾过程总结出如果当时对这个领域有更多了解，选择可能会不一样。

面对要解的问题，可以先仔细探寻解题这条路前面是否已经有人走过，通过各种途径了解其他人的案例，一定要知道学术界/工程界在面对这类问题时的处理方式。解法并不是要天花板一模一样，每家公司背后的业务、工程、节奏以及环境不同，但可以据此自定义特色节奏。

毕玄做容器的例子：

做容器时最开始是特别高效的，由于虚拟化及容器方向无概念，完全按自己的想法做；做到一半时发现世界上存在「 Linux Container 」，原来前面的折腾都是白干，因为解法早已存在。

总结：架构师需注意学术界/工程界天花板情况，会影响技术选型；如果出现问题，所有人的努力都是没有任何意义的。

毕玄做异地多活的例子：

对于做异地多活的架构师来讲，最重要的是知道做系统必须守住的底线是什么，且这个底线是所有参与者都达成清楚一致、在写代码及进行子系统设计时都充分坚守的；否则，系统组装起来一定与预估有所差距。

重点非常重要，阿里对于异地多活最高要求是数据准确性的保护，贯穿所有的系统设计。

总结：系统设计原则最重要的是体现架构师对系统里最核心模块的理解。对于架构师来讲，只有完全理解需求，才能转化成技术问题。

5.2 实战，有“小”作品

前面是架构师基本的技能，架构师需要发展得越来越好。

对架构师来讲，通常很难做出对公司有非常大价值、对业务发展有更大的帮助的事情；解决一个点难以促进公司整体发展，而是解了很多问题后，组装出的方案对公司产生价值。因此，影响比较大的项目都涉及总架构师、很多子架构师，很多专业人士去解决对应领域的问题。

分工上不会要求做操作系统、语言级人员仔细思考要做什么，而是由架构师根据公司发展来思考与判断现阶段需做的最重要的事情。

除了具备架构师基本技能，想要发展得越来越好需要思考以上问题。在公司架构师都需要做过有影响力的小作品，才有可能获得去做很大系统架构师的机会。于公司而言，架构师的培养体系也需要有一定的方法论。

5.3 创新，改变，“大”作品

如果架构师想产出非常大的作品，对未来的看法非常重要，而了解天花板才有可能做创新；在当前场景下，只有认为历史方案都不佳，才能有可能再次创新。

参考阿里，在过去很多年在技术领域保有良好形象，是因为在历史上阿里不停地做创新；从最早做单体到分布式，到服务框架、消息、数据库中间件等，在中国的体系里都属于大的创新。

6. 成为技术leader

技术人中非常重要的角色是技术leader。很多公司或许由技术 leader 兼任架构师，但如果是非常高级别的技术 leader 是无法兼职架构师的，因为涉及领域非常多，与其他角色最大的不同是涉及到业务与人。

技术 leader 同时需要有技术基础，对技术的走向做判断，并做出技术规划。而技术 leader 要花更多时间在业务 —— 思考团队方向并不断调整；在人 —— 整个班子的建设、团队运转、成员的状况与发展；甚至未来走向其他管理岗位。

6.1 深入理解业务，根据业务面临的挑战/规划制定相应的技术规划

技术 leader 对能力的要求与其他角色差别非常大，需要承接的工作更“乱”也更“杂”。

对于技术 leader 来讲，最重要且必须的是深入理解业务；了解公司业务的具体情况，尤其是正面对的业务方。这里的误区是帮助业务方做判断，无需代替业务方做决策，而是理解业务，了解所支持的业务现面对的主要市场竞争，清楚业务团队面对挑战的规划。

• 从业务到技术的映射的责任一定要承接好，一定要具备天花板的认知

技术 leader需根据业务方的规划转化成技术的规划，及「业务转化成技术」这一步。而如何将业务面对挑战的规划转化成技术规划以帮助业务更好地发展，是非常重要的思考过程。做技术规划涉及解决问题，那对天花板的认知也就必须具备。

• 做好权衡取舍，切忌什么都要

一个团队年度要做的事情非常多，而需要根据实际情况决定什么做、什么不做；最害怕的是什么都要，因为所有事情背后都意味着资源的投入；因此，对技术 leader 来讲，做权衡取舍是最大的挑战。

不做选择是安全的，做决定后就有出问题的风险；但作为 leader 应该敢于去承担风险。leader 与员工最大的区别是决定了方向；如果方向错了，其他的努力都是白费。

因此，如果做了技术 leader ，不管愿不愿意，都应该去尝试且接受，做好这个位置的本职。如果实在不能接受，可以回归到做专业技术人或架构师等等。

6.2 根据技术规划，搭建相应的班子

对技术 leader 来讲，除了做技术规划，搭班子也非常重要。规划是第一步，技术规划是第一波挑战，规划做完后如何组建团队是更难的挑战。

• 对人的判断/识别/招聘

机器是听话的，写什么样的代码就怎样运行；跟人打交道是非常复杂的；因此，技术 leader 根据团队规划选人就是核心，选人标准基于对团队里的人的了解，意味着要花非常多的时间在人的身上，需要了解整个团队；这也基于对人判断的前提，涉及如何识别人、招聘人、吸引人。而是否能成功搭起班子是规划落地的重要环节。

6.3 团队的高效/有成长的运转

最重要的最后一点是所带领的团队是否高效运转，对团队的成员来讲是否有成长。

• 团队的运转是否高效，和组织设计，系统架构等通常都相关

对于公司来讲，团队高效运转的核心与公司组织架构息息相关，涉及团队之间的协作问题。如果认为减少协作更好，那团队可能形成自闭环；如果认为分工协作更好，对整个公司目前这个业务发展是更好，那则需要考虑协作中的各种因素。

对技术 leader 来讲，日常中的重要关注就是整个团队的运转情况。

系统架构对团队设计非常关键，从单体到分布式的案例。

阿里要解决的问题是规模增长、无限水平伸缩。而Google考虑的是公司规模变大时团队高效并行研发的问题。对几百人的团队来讲，如果不是分布式系统，团队协作很难；淘宝 07 年研发团队仅有 100+ 人时协作问题已显。

• 团队成员是否有成长，过去的一年团队有多少人觉得是值得写在简历的一年

回顾全年，过去一年经历是否值得写进简历？

对于工作多年的人，不会将每一年都写进简历，而是选择对整个职业生涯发展加分的部分。而团队成员是否有成长最重要的就看过去一年做的事情是否值得写进简历。

离开公司后，会想干什么？

这个问题反映出对未来走的路线的想法，也是向技术 leader 提出个人诉求的一种方式。技术 leader 设计整体规划时，可以适当考虑每个人的需求，对每个人的成长都会有很大帮助。

7. 分享赠言

专业的技术人与架构师是解决技术问题，在技术上持续发展。但不管最终走向了哪个角色，都挺好，兴趣是驱动做好事情的重点。大家应该根据自己的情况来仔细思考并决定未来走向。

8. Q&A

• 如何把握技术的深度和广度平衡？

Answer：取决于怎么理解深度和广度；多数人不是往深处发展的方向，更多的人都是往广的方向在走；平衡取决于什么叫往深处发展，什么叫往广发展。

• 怎样提升自己的技术影响力，是否有重要的时间节点？

Answer：故意打造影响力就走偏了，所谓影响力的基础都是作品，在作品的基础上进行打造。开源社区以及各种顶级大会是最典型影响力的展现，大会的级别与层次导致了产生影响力的不同。而这些的前提是作品以及作品对业界的影响程度。

• 业务研发如何利用开源代码加深技术深度？

Answer：如果对技术侧更感兴趣，可以选一个最感兴趣的领域翻看源码；在简单阅读后，尝试自己写类似的东西；写完以后与开源的或公司正在用的做对比，这样就可以逐步提升技术能力。现在开源界有很多可以参考的资料，这样的方法论是有效的。

• 如何利用零散的知识构建自己的知识架构？

Answer：比较建议先有更大的帽子或划分，划分后先探索感兴趣的领域的顶级大会，在顶级大会里可以看到最先进的产品、文章、论文、PPT等。

• 针对能力冰山模型，水面之上（专业技能）可以通过过往工作经验考察；水面之下（成长性、意志力、价值观等）只能通过大的挑战/重大项目展现。越关键的岗位越考察水面之下的点，识人、招聘、面试上是否有好的方法和经验？

Answer：面试时间短，几十分钟就要迅速对人做判断，判断水面之下的部分挺难的。有意思的话题是如果一个班子里最核心有 5 人，他们分别可以到什么级别？这取决于技术 leader 对技术规划的理解。外部招聘更看重过往作品、过去成绩以及实现过程。

• 如何看待做技术与转管理之间代码能力与管理局限的矛盾点？

Answer：技术人走向技术 leader 最大的关卡在于是否能真正接受技术 leader 的位置。写代码是硬核技能，可以赖以为生；而技术 leader 偏于软技能，可能会让程序员心里虚、认为难以找工作。

这才是很多技术人迈向技术 leader 的心理难关，也导致许多技术 leader 花很多时间写代码；但如果需要带很大团队规模，不建议写代码；而是要在方向、班子建设、团队运转上花非常多的精力和时间；如果接受不了，就不要带团队。

至于管理，发展空间非常大，带领多人去做好事情难度非常大，未来的延展性非常大。管理型leader多依赖于班子，可以吸引人、讲好业务的故事、组建优秀的班子，保证业务发展及团队飞速运转，是高岗位的人/公司需要的一种人才。

• 关于创新，容器研发的过程中，发现别的公司有更好的设计思路，于是采取了跟随策略；那如何看待原创性创新？

Answer：不能盲目原创性创新，如果对比目前的方案不是革命性的进步，通常建议还是拥抱现有，做小幅度创新演进就好，因为技术始终是有迭代周期的存在的。