2. 技术增长之路

　　综上所述，无论走哪个技术方向，都没有对错之分； 对于所有技术人员来说，适合自己的才是最重要的。 但无论你将来成为一名专业的技术人才、架构师、技术，还是做生意、创业等等，作为一个技术人最基本的就是提升自己的专业技术能力。 技术技能始终是必要的。

　　3、提高专业技术能力

　　3.1 对自己所做的事情涉及的技术/业务有深入的了解

　　写一段可以运行的代码并不难，但是写一段无论如何都能稳定运行的代码就很难了。

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

　　毕轩2002年毕业，2007年加入阿里巴巴，工作5年后接触HSF时，他发现自己对技术的掌握并没有那么深。 当时中间件团队很多人在加入淘宝之前从未做过大型系统（日访问量100w+，甚至上亿）； 由于缺乏经验，他们无法想象会发生什么故障。

　　HSF首个版本上线于阿里巴巴淘宝后台系统（服务客服服务员），日均HSF服务调用量约100万次。 刚上线的时候没有任何问题，高并发系统的难度被低估了； 因此决定将其推向最高级别。 重要的贸易中心。 整个系统发布后半夜出现异常，体现在淘宝页面打开缓慢。 于是花了一整天的时间才找到问题所在。 到当天晚上，淘宝页面打不开，HSF不得不暂时下线。

　　回滚后，立即恢复正常。 最终调查显示，问题是由于依赖Jboss远程通信造成的。 默认超时为 60 秒。 当超时特别长，后端处理请求较慢时，处理线程池会慢慢变慢。 它已经满了，导致它变得越来越慢。 因此，我们得出的结论是，对于HSF这样的高并发系统，这个地方必须要我们自己写，才能完全掌握在我们自己的手中。

　　HSF推出带来的问题让毕轩真正理解了理论背后的实践（《高并发Java》等相关书籍）以及高并发系统与其他系统的区别； 最大的区别在于是否真正理解代码运行逻辑，而在编写代码的过程中会调用大量的第三方API，真正理解调用的效果非常重要，就像学生做的那样运维必须清楚地了解输入的每一行命令的作用。

　　后来要求中间件团队写基础代码和业务核心代码，才能清楚地理解引用部分的含义。 阿里巴巴也不允许第三方随意引入开源。

　　任何代码语言调用的API、类库等所有源代码均开放； 写代码时深入理解背后逻辑的方法就是进一步看源码，这在出现故障时会更有帮助。

　　第二个重要方法是模拟编写代码。 在每个领域，开源都会有它最好的部分。 比如学习通信代码，可以根据自己对Java最原生的NIO API的理解，写一个通信框架，然后和Netty的代码进行对比。

　　3.2 提高解决问题的能力

　　每个公司或多或少都有一些传奇人物——当问题出现而无法解决时，他们就会浮现在脑海中。 解决问题对综合能力要求非常高，在这家公司被认为技术能力特别强。 ，特别擅长写代码的代表。

　　一旦发生比较大的故障。 事故发生半小时后，技术老总查出是谁在处理故障，但结果却无人处理。

　　这时，一个非常神奇的组织出现了——淘宝消防队。 一位运维同学带头召集了一群喜欢处理问题的人，组成了一个小组。 该小组的成员被称为“消防队”。 当出现问题时，可以通知客服，消防队会有专人定位问题并解决。 毕轩是消防队的一名队员。 多年来他一直在处理各种问题。 随着处理的问题数量增多，他处理问题的能力也显着增强。 同时，他还在阿里最传奇的技术人物多龙身上继续努力。 了解如何解决问题。

　　解决问题和写代码的区别在于考察综合能力。 很多人解决不了问题，并不一定是能力不足，而是对工具的知识积累不够。 了解之后，他们就逐渐熟练了。

　　解决问题的能力比掌握背后的原理、理解技术要难一点。 你需要为自己创造机会参与解决问题。 与此同时，许多公司往往倾向于恶性循环。 通常有少数人解决问题的能力特别强。 渐渐地，问题就被他们解决了。 随着自己积累的技能越来越强，其他人解决问题的机会也越来越多。 较少的; 每个人都可以主动参与解决问题，即使无关，至少也能了解情况。

　　监控团队和运维团队通常会整理过去发生过的故障。 可以看看故障归因，或许对以后解决问题有帮助。

　　解决问题的基础是对整个运行原理的理解和掌握。 一旦有了基础，你就可以参与解决尽可能多的问题。

　　3.3 稳健的设计和代码

　　最好的程序员必须基于前两个基础具有非常高的设计和代码稳健性。 这是优秀程序员和普通程序员最大的区别。

　　要测试程序员的技能，可以阅读代码。 鲁棒性非常高的代码，无论放在哪里、任何情况下，基本上都可以实现可预测的输出。

　　一个探测器被发射到火星并在着陆时坠毁。 1999年发生故障，造成损失超过3亿美元； 由于火星气候探测的设计需要很长时间，损失是金钱和时间的结合。

　　失败的原因是代码是美国和英国团队合作的，部分API是英国团队提供的，美国团队使用的。 在计算着陆动量时，API 中没有单位，只有数字。 双方团队对单位问题理解错误，计算错误导致下降烧毁。

　　故障可以映射到程序员的日常工作中。 当你调整其他团队编写的API时，你可能会默认按照自己的想法理解参数，而没有仔细查看文档。

　　对于很多程序员来说，感觉写代码就可以正常运行，不需要花费大量的精力来提高健壮性； 这是程序员对自己的要求，也是优秀程序员最能展现自己能力的地方； 一方面是解决问题的能力，另一方面是写出几乎没有问题的代码，即写防御性代码。

　　3.4 总结

　　无论将来从事何种技术岗位，专业技术能力是技术人员的基础。 有了这些基础，才能在某个岗位上做好工作，得到认可。 这种能力一旦提升，就会成为一种技能积累，不会被遗忘。

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

　　4、成为该领域的专业技术人才

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

　　当专业技术能力提升到一定程度的时候，你就会面临选择的问题，就是你该往哪个方向走。

　　第一个选择也是最简单的，就是成为该领域的专业技术人才。 核心是要深入； 特点是你对一个很垂直的小领域有浓厚的兴趣，能挖得很深。

　　如果进入专业技术领域，最重要的是对相应领域（如IO、语言、编译器、内存管理等）以及专业领域的所有细节有非常深入的了解。 ，知识理解清楚。

　　了解该领域的天花板在哪里非常重要，否则你认为的该领域的创新可能在很多年前就被别人“先到”了。

　　学术界和工程界的天花板是不同的。 学术界通常比较先进，但是否可以在工程界实施需要考虑； 有必要找出工程界的天花板在哪里。

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

　　例如，操作系统领域几乎所有革命性的发展都是在OSDI和SOSP上发表的论文。 只需研究每次年会的论文，就能大致知道该领域的天花板在哪里。

　　4.2 实战，有“小”作品

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

　　对于技术人员来说，他们的作品不言而喻。 没有人关心他们在公司的级别有多高、多大，而更关心他们过去做过什么、为公司做出过什么贡献。

　　如果某种语言的作家正在找工作，在简历中只写“我写的”可能比任何其他语言都更有说服力。

　　对于技术界来说，从长远的职业角度来看，能否产出作品比什么都重要。

　　想想这对公司来说有什么价值。 深度发展的人做对公司有价值的事情，通过开源社区建立自己的影响力，通过顶级会议进入专业人才圈子； 圆圈指的是所有人。 做了同等重要的事情并互相认可。

　　4.3 创新、变革、“大”工程

　　做出更大的创新和变革； 拓宽工作范围，不仅仅要改进小特征，还要改进大特征。

　　相对而言，大多数人都不适合深入。 重要的是看个人兴趣。 深入下去是一个非常孤独和孤独的过程。 一个领域需要多年的研究才能获得积累和巨大的改变； 真正实现创新通常需要一个好的平台和好的场景。

　　阿里巴巴JVM团队有很多事情要做，但当时认为如果做得好，对整个公司有很大的价值； 同时也会对该领域的行业做出非常大的贡献。 此前业界还没有针对这个问题的最优解决方案。 阿里巴巴做了之后，就爆发了整个JVM。

　　比如在开源中，提交了很多小补丁，对整个社区并没有做出太多的创新贡献。 阿里巴巴此前的策略并没有在开源方面投入太多资源。 要在某些集中的领域做出更大的创新，对社会产生更大的影响。

　　比如内核，由于离线共置的需求，缺乏根据QoS调度资源/CPU/内存的能力，操作系统领域也没有很好的解决方案。 如果阿里有需求的话，他可以继续在这个领域做下去，对整个社区产生非常大的影响。

　　5. 成为一名建筑师

　　架构师适合更多的人，很多人都会扮演架构师的“角色”。 大多数公司对架构师没有“头衔”/“职位”，更多的是“角色”，比如项目需要的架构师。

　　5.1 拓宽知识面，知道要解决问题的上限

　　与成为一名专业技术人才相比，成为一名架构师最大的区别在于广度。 知识需要非常广泛地拓宽并面临复杂性问题； 很难说某一点非常难解决，但可能会组合成一个非常困难的问题。

　　作为一名建筑师最重要的就是拓宽你的知识面，了解天花板。

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

　　毕轩在做容器的时候，发现上线之前没有考虑网络、不同机房、存储级别。 编写代码时，只需要考虑使用代码来实现需求，但作为架构师，需要考虑如何保证多个程序员编写的汇编程序的正常运行。 这需要大量的知识，包括在生产环境中部署时考虑结构。

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

　　在设计系统时，由于代码上线后可能会在生产环境中运行很多年，因此架构师必须考虑未来的可扩展性和可操作性。 考虑的问题可能涉及系统未来十年的持续发展。

　　架构师通常要解决比较复杂的问题，无论是业务需求还是技术需求，复杂度都会很高。 遇到问题的时候，不要先去考虑如何解决问题。 相反，你可以对问题有深入的了解。

　　阿里07-08在单体应用转型分布式架构的时候，有一些外部参考的实践，以及一些公共分布式架构的分享，对当时的架构师有启发和帮助。 当我们以后在多个地点工作时，痛点没有学术界/工程界最好的案例参考，这给我们带来了挑战，需要我们自己去解决。 再说说容器化，自己做容器和离线共置方向的Doc最大的区别就是环境的标准化，没有镜像。 审查过程得出的结论是，如果我当时对这个领域了解得更多，我的选择可能会有所不同。

　　当面对一个需要解决的问题时，可以先仔细探究一下是否有人已经走过了解决问题的道路。 通过各种渠道了解别人的案例。 请务必了解学术/工程界如何处理此类问题。 方式。 解决方案是不要有相同的上限。 每个公司背后的业务、工程、节奏、环境都不同，但可以相应定制特色节奏。

　　毕轩制作容器的例子：

　　做容器的时候，一开始效率很高。 由于我对虚拟化和容器方向没有概念，所以完全按照自己的想法去做。 半路上我发现了“Linux”的存在。 事实证明，之前的所有努力都白费了，因为解决方案已经存在了。 。

　　总结：架构师需要关注学术界/工程界的天花板情况，这会影响技术选型； 如果出了问题，大家的努力就没有意义了。

　　毕轩在不同地方做更多工作的例子：

　　对于在偏远地区工作的架构师来说，最重要的是知道构建系统时必须有的底线是什么，而这个底线是所有参与者在编写代码和设计时都达成明确一致并完全遵守的东西子系统。 ; 否则，系统组装肯定会与预估有所不同。

　　关键点非常重要。 阿里巴巴对远程多活的最高要求是数据准确性的保障，这一点贯穿于所有的系统设计。

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

　　5.2实战，有“小”作品

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

　　对于架构师来说，通常很难做对公司有很大价值、对业务发展更有帮助的事情； 解决某一点很难促进公司的整体发展，而是解决很多问题后组合而成的解决方案。 为公司创造价值。 所以，影响比较大的项目，会涉及到总建筑师、很多副建筑师、很多专业人员来解决相应领域的问题。

　　这种分工就不需要操作系统和语言层面的人员去仔细思考该做什么。 相反，架构师会根据公司的发展来思考和判断现阶段需要做的最重要的事情。

　　除了具备架构师的基本功之外，想要发展得越来越好，还需要思考以上问题。 公司里的架构师需要做过小而有影响力的工作，才有机会成为大型系统架构师。 对于企业来说，架构师的培训体系也需要一定的方法论。

　　5.3 创新、变革、“大”工程

　　如果一个建筑师想要制作出非常大的作品，他对未来的看法非常重要，只有了解天花板才能创新； 在目前的场景下，只有他认为历史的解决方案不好，他才能再次创新。

　　作为参考，阿里巴巴多年来在科技领域一直保持着良好的形象，因为阿里巴巴在历史上不断创新； 从最早的单体式到分布式，再到服务框架、消息传递、数据库中间件等，在中国的系统中都是很大的创新。

　　6. 科技化

　　技术人员中一个非常重要的角色就是技术。 很多公司可能有技术人员同时兼任架构师，但如果是技术含量很高的技术，他们是不可能兼职架构师的，因为涉及的领域实在是太多了，和其他角色最大的区别就是它涉及商业和人员。

　　技术还需要有技术基础，对技术方向做出判断，做出技术规划。 技术需要花更多的时间在业务上——思考团队的方向并不断调整； 以人为本——整个团队的建设、团队的运作、成员的地位和发展； 甚至未来会跳槽到其他管理职位。

　　6.1 深入了解业务，根据业务面临的挑战/计划制定相应的技术方案

　　技术的能力要求与其他角色有很大不同，需要承担的工作也更加“杂乱”和“复杂”。

　　对于技术来说，最重要、最必要的是对业务的深入了解； 了解公司业务的具体情况，特别是所面临的业务方。 这里的误区是为了帮助业务方做出判断。 不需要代表业务方做决策，而是要了解业务，了解所支持的业务目前面临的主要市场竞争情况，了解业务团队面对挑战的计划。

　　技术需要根据业务方的规划转化为技术规划，“业务转化为技术”这一步。 如何将业务挑战的计划转化为技术计划来帮助业务更好地发展，是一个非常重要的思考过程。 做技术规划涉及到解决问题，所以必须对上限有了解。

　　一个团队每年要做的事情很多，需要根据实际情况决定什么该做、什么不该做； 最怕的是凡事都要做，因为凡事的背后都意味着资源的投入； 因此，在技术方面，做好权衡是最大的挑战。

　　不做选择是安全的，但做出决定后就有出现问题的风险； 但你应该有足够的勇气去冒险。 与员工最大的区别是决定方向； 如果方向错了，其他一切努力都将付之东流。

　　所以，如果你是做技术的，不管你愿不愿意，你都应该尝试着接受，并做好这个岗位上的工作。 如果实在无法接受，可以重新做一名专业技术人员或者建筑师等。

　　6.2 根据技术方案组建相应团队

　　对于技术来说，除了技术规划之外，团队建设也很重要。 规划是第一步，技术规划是第一波挑战，规划完成后如何组建团队是更困难的挑战。

　　机器很听话，在你写代码的时候运行。 与人打交道是非常复杂的。 所以，技术的核心是根据团队规划来选人。 选择标准是基于了解团队中的人员，这意味着需要花费大量时间。 花更多的时间在人身上需要了解整个团队； 这也是基于判断人的前提，包括如何识别人、招募人、吸引人。 团队能否成功组建是规划和实施的重要一环。

　　6.3 团队高效/成长的运作

　　最后也是最重要的一点是你所带领的团队是否高效运作，团队成员是否有成长。

　　对于一个公司来说，团队高效运作的核心与公司的组织架构密切相关，涉及到团队之间的协作问题。 如果你认为减少协作更好，团队可能会形成一个自我闭环； 如果你认为分工更好，协作对整个公司当前的业务发展更好，那么你在协作时需要考虑各种因素。

　　对于技术来说，日常生活中一个重要的关注点就是整个团队的运作。

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

　　阿里巴巴要解决的问题是规模增长和无限水平扩展。 考虑的是公司规模变大时团队高效并行研发的问题。 对于一个几百人的团队来说，如果不是分布式系统，团队协作会很困难； 2007年，淘宝的研发团队只有100多人，协作问题凸显。

　　回顾这一整年，这一年的经历是否值得写进你的简历呢？

　　对于工作多年的人来说，他们不会每年都写在简历上，而是选择对整个职业发展加分的部分。 团队成员是否成长，最重要的是他们过去一年所做的事情是否值得写进简历。

　　离开公司后你想做什么？

　　这个问题反映了对未来道路的思考，也是对技术提出个人诉求的一种方式。 在做整体技术设计方案的时候，能够适当考虑大家的需求，这对于大家的成长会有很大的帮助。