成事：技术人最大的问题就是情怀化

Sep 28, 2022

成事：技术人最大的问题就是情怀化-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

成事：技术人最大的问题就是情怀化

2022-09-28 毕玄来自北京

《超级访谈：对话毕玄》

课程介绍



讲述：正霖，叶芊

时长19:52大小18.14M



你好，我是叶芊。
　
从今天开始，“高手锦囊”板块的 5 场专题研讨即将展开，我们会从毕玄的具体工作经历出发，在“个人成事、方向选择、团队带领、做事文化、架构修炼”这 5 个方面，希望能总结出可供借鉴的分析思路和实操方法。
　
毕竟对于这样一位技术敏感度如此之高的大佬，仿佛总是能提前站在下一个技术风口上，他是如何分析技术方向的，又是如何在一次次技术浪潮中求得自己和团队发展的，如果能总结出这种方法论，相信对你一定有很大帮助。
　
今天我们先来对 HSF 做复盘，毕竟第一次总是印象深刻，对于第一个真正自己从 0 做的访问量巨大且核心的系统，又出了大故障，他总结了哪些成事方法呢？
　
极客时间：复盘一下你进淘宝做 HSF 的过程，这是你做的第一个专业性要求高的系统，之前所有人都讲做一个网站，访问量从 200 万到 1 个亿是不一样的，但没有人知道到底哪里不一样。经历过上线故障之后，你觉得大量级的系统到底是什么不一样？
毕玄：这一次之后我就懂了，量级其实不重要，重要的是要求。一个要求非常高的系统跟其他系统的差别是什么。
要求非常高的系统，核心是对整个系统的所有环节，你都要非常非常清楚。因为这是概率问题，你以前可能认为十万分之一的问题不会出现，但在一个大型系统里，它是必然会出现的。所以写一个小系统是容易的，写一个超大系统因为所有的概率问题都会爆发，对工程师的要求就变得非常非常高。
以前流行一篇文章，你在浏览器敲了一个回车发生了什么？这个问题其实挑战很大，说实话，到现在也没有多少人能非常好地回答出这个问题，因为背后有非常多链条。
你必须非常清楚你负责的那个部分从头到尾所有代码的细节，后来阿里对基础工程类的人都有这个要求，不能说我用了一个三方开源的东西，它出了故障，所以问题是它的，那当然不是，对我们来讲，都是你的故障。
在这个阶段，对工程师的要求已经完全不一样了，不是说你写完一个功能就拉倒，是你要能把代码维持着，这个挑战就非常非常大了。
极客时间：维持代码的成本，在开发之初也要考虑清楚。
毕玄：对。一个要在生产环境跑很多年的系统，未来怎么可持续地发展，在设计阶段是非常重要的。如果你做一个系统，面对 1 个用户和面对 1000 万个用户，只跑一个星期和可能要跑 10 年，都有很大差别的。这就是我最后交付的成本。
硬件也是一样，软硬件其实最终体现就是价格。我们看硬件，有些保修期很短，有些很长，有些寿命很长，有些寿命很短，决定了它背后的选择是差别很大的。当然，软件可能还做不到像硬件一样这么直接的映射，但差不多也是这个概念。
极客时间：所以为了保障对代码的掌握程度，大厂一般都自己写？
毕玄：如果过多用别人的东西，你是很难清楚掌握的，最好全部自己写，在出问题的关键时候，你可以迅速反应。当然你也不可能说一切都自己写，肯定会用到一些开源，所以我们会要求，你如果用任何开源的东西，对这个东西的所有代码也必须非常清楚，否则，在大规模系统里你一定会栽跟头。所以对大规模系统来讲，技术选型是很不一样的，包括对团队的要求也是。
很多开源的东西，大家觉得外面很火，阿里为什么不引入？其实很简单，引入进来，阿里又没有一个专业的团队来维护，那最好不要引入，你还不如自己写算了。这样代价肯定是也有，但对公司来讲可以接受。这个就是认知。
　
极客时间：我们继续一个系统的技术要求这个话题聊，如果说量级不是核心重要的，那对开发者来说，是什么导致了系统的高要求？
毕玄：其实本质是业务，你看现在的几个网站，业务要求的差别非常大，也奠定了他们背后技术难题的差别非常大，我后来接触了一些要求更高的公司对这一点的感受更强烈。
淘宝你说以前要求高，当然也高，但是说实话还没那么高，因为淘宝出完一个故障，如果几分钟后能恢复，交易量是能恢复的，会冲高然后恢复。所以淘宝说实话出一次故障也就这样，能发生什么？所以出了再处理是可以的，如果还能快速处理，大家就觉得你很牛了。
但像饿了么这种外卖公司，很大的挑战是他的系统在 11 点 12 点的时候不能出故障，关键是不能出，压根不能，这就不一样了，跟我们出之后再弥补差很多。
极客时间：因为外卖的业务竞争太激烈了？
毕玄：对，很简单你想，我饿了么跟美团打的这么辛苦，可能因为你们技术团队 11 点出一次故障，业务份额瞬间就变了，那还怎么玩，因为用户一定要点外卖，饿了么不能点，就会去美团点。包括当年滴滴跟快的的战争，快的背后是我们，当时我去快的呆了一段时间，处理各种问题，也是为了能让它更稳定，腾讯也派了大量工程师去滴滴。
这个时候技术真的是关键，因为谁稳定，就决定了用户会倾向谁，当然钱的补贴很重要，但技术也很重要。所以这个阶段，稳定性，已经是这些公司的核心能力了，本身就已经成为业务了。
这种对工程师的挑战非常非常大，因为一个不能出故障的系统是很难做的，但是如果说能接受出故障，给我 1-5 分钟的恢复时间，这两个系统的设计会有很大差别，因为出故障以后我可以想各种办法，但那个不能，我也很难回答。
所以我们做其他系统就会越来越明白，有些系统其实不像大家想象的那么简单。当时还有个段子，因为淘宝做的比较好，12306 总出问题，大家都说淘宝双十一都没事，把他交给淘宝不就行了吗？但你如果仔细了解一下，会发现这些系统其实不一样的。
极客时间：什么不一样，可以展开讲讲吗？
毕玄：12306 这种是涉及民生类型的，像饿了么也可以认为涉及民生，包括共享单车都是，银行、金融这种就更不用说了。
到民生这种，挑战是挺复杂的，12306 交给淘宝也不好解决，因为它和淘宝最大的区别是库存。淘宝的库存是静态的，买一个商品有多少库存，减 1 就好了，比方说我能卖 1000 件，那我减就行，虽然是高并发但也没什么，排队就好了。但你看 12306 最复杂的就是库存。
因为买一张火车票，从 A 站到 B 站中间有很多种可能性，是一个动态算库存的过程，但库存这个东西压力是最大的，还要动态算，淘宝都没想过这个问题该怎么解决，因为淘宝在库存上也很痛苦，但那也只是单品。
极客时间：所以和大家想的不一样，民生相关的系统，像 12306、银行，看着业务很简单，但背后是不能出问题。
毕玄：对，包括以前我们觉得金融行业落后，像银行，你看看你们，做个变更简直了怎么这么难？后来我们懂了，如果我们是你们，估计也会变得那么严格，因为影响面是不一样的，银行只要哪一天钱取不出来，可能会立刻引发社会动荡，你说你是技术故障，别人可能都不信。
淘宝说实话并没有影响民生，而且商业竞争还不到出了问题用户就去另一个的程度。像外卖、打车太明显了，某天你份额异常飙升，基本是因为你的竞争对手挂了，根本就不是你业务做得多好。
现在，软件的核心系统对工程师的要求在直线上升，说实话新一代的互联网工程师是比我们更难的，因为我们有时间去成长，他们其实没有，上来就是必须做到这样。我们是出了无数次故障，然后慢慢学会的，知道每个地方是什么原因，但他们就真的太难了，因为没有机会。
　
　
极客时间：你说新一代互联网工程师更难，为什么会产生这个差别？和以前相比，你觉得现在这一代工程师面对的新问题是什么？
毕玄：现在软件的要求跟以前的软件有很多差别，以前 AWS 取了一个名字，我们觉得很土，但后来觉得这名字也还不错，AWS 给现在的软件取了一个新的定义，叫 Modern Application。
如果大家去看以前的软件，一是相对来讲功能比较单一化，不会太复杂，现在大家要做的软件上来复杂度就比较高，软件要链接的东西更多。以前是我只实现一个功能，现在你看到的可能只是一个功能，但背后其实是 N 多功能叠加起来的，都是一个很复杂的公式，所以软件复杂度就很高。比如说外卖，背后涉及的链条非常长，软件写起来就很复杂的，不像以前我们很简单，这就是时代发展。
第二，以前的软件都是有成长期的，因为成长期很长，它对稳定性、可用性的要求不会那么高，以前大家不能用，也能接受，不能用就不能用，我可以换人工。但现在不一样了。
现在软件的成长周期太短了，在中国你从 0 做到 1000 万用户，以前要很多年，现在可能是几个月的事，这就完蛋了，淘宝当时能花一年来搞架构演进，现在的公司哪有这个时间，没等搞完他就倒闭了；而且这种倒闭就太冤了，我本来发展得很好，因为我发展得太好，用户量太大，系统撑不住，所以挂了，这简直了，发展不好挂了也就算了。
但现在技术侧就会面临这个问题，你的成长时间非常短，商业竞争非常激烈。当年不是这样的，淘宝起来的时候有竞对吗？自从把 eBay 踢出去，至少在那几年是没有竞争对手的，所以，稳定性等等都不重要，把业务、功能各种都做好就行了。
极客时间：所以还是回归到了业务、商业层面，当时如果淘宝有竞争对手，对业务和技术的态度会不一样？
毕玄：我觉得很多都会不一样。但是现在中国不是这样了，现在你做了 A，只要能起来一点点，你可能会发现中国瞬间诞生了 100 家做 A 的公司，那你要求的技术门槛就直接拔高了。
说白了就是利润空间的问题，一个行业只要开始赚钱，在中国绝对会卷到死。在海外这点会好很多，因为海外看你已经赚了那么多钱，那我还是不要做这个行业了，他会觉得我的机会很少。但中国不会这么看，中国会觉得，哇！他那么赚钱，我也可以做。
极客时间：不同时代的软件，以前就看业务，现在还要求技术门槛。
毕玄：以前技术真的不是核心，对业务来讲，说实话一点都不重要。
淘宝最早根本不认为技术有什么重要的，反正能用钱解决的，我全部用钱解决，技术最好不要干，最好全部是写业务代码做需求的。不要说我有一个团队是不做业务的，全部在研究什么基础技术，那完蛋了，因为这就是养人，而且这种人通常又比较贵，养一帮这种人都是成本。但现在不行。
现在很多公司上来如果技术没有达到一定的分数线，可能业务都没机会做，就已经挂了。因为中国用户被训练出来了，对体验的要求非常高，中国用户点一下恨不得立刻下一页，如果还多要转几下，他就放弃了，太卷了，但海外不会。这些背后全是巨大的投入，不管是人员、还是 IT 成本。
这就是现代，后来我们很认可 AWS 讲要跟原来区分开，当然它也是告诉你，为什么现在很多公司，尤其是初创还没有那么稳定的公司，应该用云，其实就是分数线。因为你用，至少一开始就一定达到了分数线，然后你可以更专注在业务上。但以前不存在这个问题。
极客时间：系统的技术要求变高，之前和现代的界限，是什么时候开始的呢？
毕玄：中国我觉得就是移动起来。在 PC 时代，你看竞争其实不是很激烈，那个时候互联网还没爆发，没让大家觉得做这行有多赚钱。当然还有更赚钱的，当然也不能做。然后，大家突然间发现做互联网是最赚钱的，中国肯定卷死，这是中国最痛苦的地方。
极客时间：移动互联网起来的时候，大家都觉得怎么着做个 5 年 10 年的，但没有想到这么快，客户端没几年就发展到饱和了。
毕玄：因为 PC 就很多年。
极客时间：为什么移动时代会发展得这么快？
毕玄：我觉得跟中国手机发展的比较好有关系，然后网络条件比较好，国外其实是因为网络太差，你想在印度点一下那么慢，那还是不要用了，手机也差。但中国这些基础设施太好了，基础设施真的是关键，基础设施越好，上面就越会爆发无数的可能。
　
极客时间：关于 HSF 前面聊了这么多，主要是超大系统对程序员开发能力上的要求，在具体的技术选型上，之前你也在很多文章中反思用 OSGi 是非常错误的决定。
毕玄：对是的。
极客时间：现在你再去做 HSF 的技术选型会有不同吗？
毕玄：不会，我觉得还是错的。这是我后来总结的，技术的人最大的问题是太情怀化。
我以前选择 OSGi 最大的出发点是什么？就是情怀。因为所有人都知道我出名是因为 OSGi，很多人在我来了淘宝以后都问我：淘宝用 OSGi 吗？我说没用，这个对我这种技术人还是有点伤害。因为支付宝也用 OSGi，我跟阿玺他们都很熟，他们用，我不用，他们又经常找我问问题，后来我就觉得那不行，淘宝也得用。这就是情怀，纯粹是情怀。
很多技术人做一个决定，其实他的出发点就是不对的，他的出发点就是情怀。
极客时间：但大家可能会举 Linux 的例子，很多做了最伟大技术的人，可能就是出于情怀。
毕玄：但我觉得在公司的层面，肯定是不能那么干的。所有的公司都是一家商业公司，那商业公司里做的所有事情，确实应该要对这家公司意味着什么。
所以关键是反思选择把原来的东西改造成基于 OSGi 的，对当时这家公司来讲，对客户、用户来讲，意味着什么？到底有没有帮助？是不是一个很好的长期发展选择？如果他的问题，你其实没有任何解决作用，那还不如以前，因为新方案一定会带来很多新的问题。
很多技术人，做决定最大的问题就是情怀太美了。比如说很多架构师 Leader 他为什么做这件事，可能就是技术上觉得这个东西看着不爽，想把它改的更完美一点。技术人确实有这样的癖好，因为技术这玩意确实可以很完美化，我觉得这个架构看起来不好看，这个代码看起来可以写的更好。
极客时间：但是从商业上看，把代码、架构改得更好看这些都是成本。
毕玄：对，商业是一个妥协的问题，事实上，一个平台要做好，架构师最大的挑战就是做平衡。所以在阿里我们面试很多 P8 升 P9 的架构师，问的核心话题都是你在这一轮架构设计里面做过什么选择和平衡，这才是最难的，而不是你做了什么很好看的玩意，一个看起来很完美的架构，最后有可能对公司是极大的伤害。
极客时间：这是业务上的考虑，是不是也有团队上的？因为后来听说你要做别的业务，但 HSF 这个项目用的技术栈又是 OSGi，所以想托给其他人负责维护非常难？
毕玄：是的，这个肯定有影响。因为你对整个团队的要求变高了，这很痛苦的，未来团队的招人等等都是大问题，包括团队的人出去以后，他们其实也会各种担心。
后来我跟很多人聊，包括有技术情怀的，他觉得有个语言特别好，用这个可以写一个更好的、性能更高的东西，对这家公司会有很大帮助。这个出发点看起来没错，因为出发点是对工作业务有帮助。
但这里没有考虑到一个问题，如果你离开了那个团队，这玩意谁能搞定？如果没有你在，就没人能接，那就是你给公司挖了一个坑，然后公司还不能把你怎么样，这不就是坑公司？
所以很多时候讨论语言选择是一个最无聊的话题，因为语言的选择，事实上不是单一爱好的问题，是我站在公司整个层面上，包括人才储备上，做的综合判断，不是说我觉得这门语言多牛，这不重要，每门语言都有自己很适合的地方，否则它为什么活着呢？
极客时间：你这么重视对公司、团队方面的考虑和权衡，在技术人里不是太常见，你是怎么意识到这一点的？是你在后面的项目经历里慢慢体会的？
毕玄：这一点其实是我后面一个老板对我的影响，七公，就现在淘特的负责人。
那一年我被提名 P8P9 的晋升，写完 PPT 他帮我看了一下，然后他说你这个 PPT 最大的问题就是没有讲清楚你做这个事情的意义是什么，就是技术的出发点。
他说我技术层面当然没有问题，都讲的很好，但越高级别的人，越需要回答的问题是你为什么要干这件事情，而不是你怎么干这件事情，以及怎么解决里面各种各样的技术难题，这些是偏执行层面的，当然也需要，因为一家公司肯定有很多技术上非常难的事情需要人解决，但是更需要的是，有人去思考这家公司到底要做什么？为什么要做这件事？这是最大挑战。
他那次跟我聊了之后，我一定程度上开窍了，后来我所有的技术规划都是以这为出发点。很多技术的人可能很难接受这个，但这就是你走向成熟化的必然。因为我们也能看到有些技术很神的，可能有纯粹的技术立项，这种确实很好，但关键是在中国的生存环境比较困难。
　
水友讨论区到这里今天的讨论就暂时结束了。理解了毕玄做选择的出发点，我们再回看之前他的所有转岗决定，背后的理由是清晰且一致的。
在一个要求非常高的系统，你的敌人叫做墨菲定律，开发者需要具备更高的代码掌握程度，而且现代系统，因为业务复杂度和商业竞争度在不断提升，对开发者的要求也越来越高。
但对技术人来说，最致命的障碍常常并不因为外界，而是因为自己，在技术选型上，想清楚你的出发点是最重要的，一名成熟的技术人需要从对公司、对客户 / 用户，以及对团队的各角度，想清楚自己做事的意义是什么。这是毕玄做事且能成事的底层逻辑。
不知道你对今天讨论的哪个部分感兴趣，我还是列了几个讨论的话题：
AWS 说的 Modern Application，作为身处其中的开发者，你有哪些感受呢？回顾自己做过的系统，要求是什么样的？你觉得挑战是什么？
毕玄做事，他认为重要的是想清楚对公司 / 客户 / 用户来讲到底有没有帮助，是不是一个很好的长期发展选择。你做事的出发点是什么呢？关于技术人的情怀问题，你见过哪些坑？你有给团队 / 公司挖过坑吗？
欢迎留言交流，聊聊自己当年（或者现在）炫技的那些事。
下一讲我们聊一聊到底该如何思考技术演进方向，下一讲见。
拓展阅读之前毕玄有自曝过自己因为技术情怀犯过一些错误：
技术人员的情结
我在系统设计上犯过的 14 个错

分享给需要的人，Ta购买本课程，你将得18元

生成海报并分享

赞 9

提建议

开篇词｜这一次，我们来采访毕玄

方向：技术演进，到底该怎么思考未来？

 写留言

精选留言(9)

leslie
2022-10-04 来自江西
"情怀"：可能就像某个行业做久了换个行业会特别不适应节奏，做事情会按照过去的节奏。金融运维做久了，换到互联网时还会去追求稳定为核心，而导致效率、产出偏低，其实不少互联网公司只要求关键时间段稳定就行了，当你再次回归金融时你会觉得这一切的节奏很OK。 "越高级别的人，越需要回答的问题是你为什么要干这件事情，而不是你怎么干这件事情":这句话倒是感悟很深，级别接近不会去问，级别越高越关注核心的why?
7
熊悟空的凶
2022-10-01 来自北京
不是你写的代码用了那么多技术，而是你写的代码有多稳定
4
JianXu
2022-10-07 来自浙江
如果不能量化衡量业务价值，基本上就是没有想清楚。而我现在碰到的难点是：基础性投入如何衡量业务价值？或者短期看不出来。
作者回复: 很多基础性投入也需要做一定的业务价值的映射，我还是相信一定是可以映射的，只是有些确实会周期很长，周期很长的我还是比较建议能有一个短期的里程碑，也许这个里程碑不能直接映射到业务价值的结果，但应该至少可以有能力提升等的说法，举个简单例子：当年做调度的时候，因为周期也很长，不可能在一年，两年对整个公司的成本真的产生明显的影响，这个阶段我们更多的会讲在某个局部呈现出的能力提升，而这个能力提升到一定阶段铺开后，就会真正的转化为业务价值。
2
术子米德
2022-10-28 来自浙江
🤔☕️🤔☕️🤔 【R】小概率事件，在大型系统里，就会变成必然事件。当系统从跑1个月，变成需要持续跑10年，当一个系统只有100个用户，变成容纳1000万个用户，这不是两套不同的系统，而是两个不同的物种的差别。【.I.】我算个技术人嘛？也算也不算。当我听安排，喊我干啥就干啥，也就是仅做实现的时候，我觉得我不是技术人，顶多算个技工。当我遇到问题，分析问题找出其中约束，基于约束设计出方案，实现出来的东西像个玩意儿，当时满意感十足，虽然过些时候回看又觉得不太行，这时我觉得自己就算个技术人。不过，这似乎没情怀啥事情。所以，所谓的技术人员情怀，到底是在沿途无意接触到的观念，还是从自己内心长出来的信念，对此我还没有答案。我更倾向于，这是沿途拾得的小礼物，某段时间挂在嘴边说道，只有在实践中去尝试，情怀遇现实后，抖落下来种子，能够在内心长出自己对于技术的信念。用技术做产品，能够让更多人参与进来，给更多技术人机会去发展探索新东西，就是我现在的技术信念。【.I.】假设我离开公司，我负责的部分移交给谁？这样的问题，看似有点消极，实际很务实，甚至我到觉得，必须要有这样积极的问题。或者，换种问法，假设我晋升或换岗，我是否已经培养好接手的小伙伴。突破后传承，才能有真的延续，也真的能够让更多小伙伴遇到机会。【Q】对于喊我干啥就干啥的技术人，如何能够棒喝他们，必须去想干啥背后的为啥，必须突破躲在窝里等活来的认知，否则不惑之年，被裁后再猛然不惑，就真的来不及，对于这样的情况，老师是否有经验和方法，把这些躲着的心态给棒喝醒来？ ——by 术子米德@2022.10.28
展开
作者回复: 感觉是有些难的，也许可以尝试的是平时问这些人群一些问题，带动思考。
共 2 条评论
1
Jolyne
2022-10-27 来自四川
和做人一样，所谓明明白白、清清楚楚
1
heloong
2022-10-20 来自浙江
技术选型考虑更多从公司层面考虑其实很重要，我发现好多人往往喜欢从自己成长角度考虑，然后选新的热点技术，公司技术管理也一般，容易给后来人留下烂摊子
1
novoer
2022-11-26 来自福建
为什么干这件事很重要
秦穆之
2022-10-20 来自上海
这几年也感受到在面向业务的团队里，稳定性是最主要的指标。当我刚开始入门的时候，带我老哥给的要求只是按时完成需求。当我开始独立负责一小块业务时，老大给的要求是保质保量完成需求，并能抗住突发流量（心里要有一个尺度，具体的刻度自己拿捏）。当我代表我们团队参与到一个大的活动业务模块时，老大给了一个很简单的要求：在极限情况下，整个链路可以出问题，但是瓶颈不能出在你这一环。业务侧出问题，轻则客诉，重则资损，再严重点就可嗯出重大舆情了。
展开
Ryan Feng
2022-10-08 来自北京
所谓modern application应该是天然融合了高可用，易扩展，易于运维（cicd）等现代应用特性，使得应用在未来的更新迭代中保持更长久的生命周期和相对低廉的维护成本，保持可持续发展。

