-->

技术领导力实战笔记_103_大咖对话_|_谭待:架构的本质是折中

你好,本周做客大咖对话的嘉宾是百度搜索首席架构师兼区块链实验室主任谭泰。

他的主要研究领域在分布式系统搜索引擎和区块链是百度BBC代理计算和matrix私有云的主要设计者两获百度最高奖,主持设计了百度新一代搜索架构,在时效性和计算规模上实现了大幅提升,同时也主导了极速搜索、全站、HTTPS等百度搜索的一系列重大革新。

即刻时间问,您现在身兼百度搜索首席架构师和区块链实验室主任,这两个不同角色之间的差异大吗?您如何调整自己,适应不同的要求呢?谭代回答,在百度搜索这边,我作为首席架构师是一个IC的角色,也就是独立贡献者。

百度跟很多互联网公司不一样,百度的技术序列是不带人的,即使要推进项目用的也是非职权管理的方式,更多的会依靠技术人自身的影响力,而不会涉及到具体业务相关的管理。

而在区块链实验室这边呢,我作为主任就要承担很多业务相关的管理工作,我需要在这两个角色之间互相切换,而不同角色的要求是不一样的。

作为技术负责人,虽然也会有非职权管理的场景,但更多的是需要把个人的聪明才智发挥出来,找到关键点,把事情给解决掉,体现出你的技术价值。

同时,在宏观方面,还要着眼整体技术方向的演进,以及技术梯队的培养等工作。

而作为管理成份,简单来说,就不能像原来那么挑活了。

原来作为技术leader,我可以只看最关键的事情,剩下的反正有经理帮着兜底儿,如人员问题、预算问题,等我都可以不去管。

但现在作为一个业务的管理者,我变成了那个兜底儿的人,需要把很多精力分到一些,看上去非常繁琐。

但对整个部门发展非常关键的事情上,比如上面提到的人员,招聘、预算制定等。

除此之外呢,最大的挑战是思维方式的改变。

在搜索这边,我依旧保持之前的思路和做事方式,保持对技术的判断力,找出技术的最优解,发挥技术的最大价值。

但在区块链实验室这边,我反而需要主动克制自己对技术的感觉,不要过多的参与到一些非常细节的技术讨论和判断中。

甚至有时候我有更好的想法也要忍住,不能直接提出来,而是要慢慢引导团队,或者让他们自己去尝试。

主要原因在于,一方面,我作为业务管理者,过多的参与技术方案的制定,对整个技术团队的成长并不是一件好事儿。

另一方面,作为管理者,我需要将更多的时间和精力分配到整体的业务和战略上,以及对内对外向上向下的各种协同合作中。

总的来说,我现在也不算是从技术转向管理,而是同时保留了这两种角色有点人格分裂的感觉,但也是非常有意思的挑战。

即刻时间问,回顾一下您的职业生涯对您影响最深的事情是什么呢?谭丹回答,这么多年下来,感触深刻的事情还蛮多的。

我分享一个至今仍对我产生影响的事情吧。

二零零七年我进入百度开始实习,加入了一个主攻云计算方向的团队。

当时这个团队聚集了百度最优秀的人,公司也给了非常大的支持。

一方面,一毕业就加入一个,可以说是当时全国最优秀的团队,得到了很多牛人的指导,这对个人的成长非常有帮助。

最关键的是在这个过程中,养成了很好的技术素养和做事方式,对我的职业生涯起到了奠基性的作用。

另一方面,这个项目后来失败了,他有着最优秀的团队,做的也是云计算这样符合技术趋势的事情。

但他最后却失败了。

可以说,如果他成功了,那他对我的触动还没有这么大我时常回顾他的失败原因。

其中最大的一个原因是他没有吻合产品的发展步调,这是一个技术性项目,但它最终是要服务于某一个业务和产品的。

然而这个项目在设计之初就和产品的步调脱节了,它的发展计划没有很好的吻合产品的发展计划。

所以虽然它的技术很出色,取得的成果也不错,但产品等不了,他出成果出方案,最终就用了其他方案。

对于这个项目来说,他就是失败了。

大家都知道技术要结合业务和产品的发展,但老话说的好,知易行难,知道归知道,要做到知行合一是一件很难的事情。

很多技术人在执行过程中会不自觉的追求最前沿的技术,会很自然的从自己的角度出发思考问题,而忘了考虑产品的需求与步调,最终导致两者脱节。

这件事情对我的影响很深,一方面他帮我培养了非常好的技术素养,让我懂得在做技术规划的时候要往前看、往远看。

另一方面,他也提醒我,你可以站得很高,看得很远,但你的每一步落地都必须要接地气儿。

踩中业务方的节奏,即刻时间问您从事架构相关工作多年,在您看来,架构的本质是什么呢?谭丹回答,架构的本质是折中。

作为架构师,你拥有的是有限的资源,如人力资源、机器资源等。

但你面对的是没有上限的需求,如工期的需求、稳定性的需求等。

所以需要在不同的层面做出折中的选择,你不可能做出一个完美的解决方案,必然要牺牲一些东西来达成另一些需求。

所以从宏观的整体架构设计和安排,到最终每个功能点的实现都是折中的。

比如我过去设计方案的时候,会做不同的milestar,选择不同的future list,这是一种广泛的折中。

再具体点说,你做方案的时候,不管是用空间换时间,还是用时间换空间,都是一种折中。

展开来讲,首先作为架构师,要明确你设计系统最终还是为了产品和业务。

所以你要了解产品和业务的需求,并做出相应的预判。

比如预判这个产品三年以后会是什么样的,这样你设计的系统就有足够的预留空间和生命周期。

在百度我们设计系统的时候,一般会去看业务三年以后的情况,这样做出来的系统至少在三年内能比较好的支撑业务发展。

另外,硬件基础设施一直在迭代,三年后,很可能就发展到一个新的阶段。

这时就可以根据新的业务情况和硬件条件重构系统,也能借此机会让团队更好的熟悉原来的系统。

其次,作为架构师,在设计系统的时候,一定要找到关键点,折中不是平庸,而是为了更好的在某些关键点上突出,为此可以在别的地方做出牺牲。

我小时候,父亲给我讲了一个故事,至今印象深刻。

二十世纪初期,美国福特公司的一台电机出现故障,很多人花了两三个月都修不好,在束手无策的情况下,请来了专家斯坦门茨。

斯坦门茨在电机旁边仔细观察,又计算了两天后,就用粉笔在电机的外壳上画了一条线,说打开电机在这条线往里的线圈减少十六圈,结果证明问题果真出在这里,这个故事给我的感触很深。

作为架构师,你一定要成为那个划线的人一个架构,会涉及方方面面,不可能全都很好的估计。

所以你需要找到那条线,找到问题的关键,并将其解决,这才是最能体现架构师价值的地方。

举个例子,我做过的极速搜索项目,这个项目目标是把搜索平均速度提高两倍。

我之前一直负责搜索中的底层分布式的系统,分布式系统里的很多折中是怎么把时间和空间进行互换之后,我接手极速搜索项目,之前大家做速度优化,普遍的思路是看哪个地方慢就优化那个地方。

我没有这样的惯性思维,而是想着分布式系统里的那种空间换时间的做法,能不能应用到速度优化上来。

最后,我的方法是系统提前预测用户的搜索目标,并实时抓取。

当用户点击搜索时,就把搜索结果瞬间展现出来。

这么做必然会消耗更多的资源,但却能极大提升搜索速度。

基本可以把搜索请求时间缩短至原来的百分之十。

可以说用空间换时间,就是我画的非常漂亮的一条线。

本期大咖对话到此结束,如果你有想跟嘉宾交流的话题,欢迎在留言区回复,感谢你的收听,我们下期再见。