你好！

本周作客“大咖对话”的嘉宾是百度搜索首席架构师兼区块链实验室主任谭待。他的主要研究领域在分布式系统、搜索引擎和区块链，是百度 BVC 代理计算和 Matrix 私有云的主要设计者，两获百度最高奖。主持设计了百度新一代搜索架构，在时效性和计算规模上实现了大幅提升；同时也主导了极速搜索、全站 HTTPS 等百度搜索的一系列重大革新。

极客时间：您现在身兼百度搜索首席架构师和区块链实验室主任，这两个不同角色之间的差异大么？您如何调整自己适应不同的要求？

谭待：在百度搜索这边，我作为首席架构师，是一个 IC 的角色，也就是独立贡献者。百度跟很多互联网公司不一样，百度的技术序列是不带人的，即使要推进项目，用的也是非职权管理的方式，更多的会依靠技术人自身的影响力，而不会涉及到具体业务相关的管理。而在区块链实验室这边，我作为主任，就要承担很多业务相关的管理工作。

我需要在这两个角色之间互相切换，而不同角色的要求是不一样的。

作为技术负责人，虽然也会有非职权管理的场景，但更多的是需要把个人的聪明才智发挥出来，找到关键点，把事情给解决掉，体现出你的技术价值。同时在宏观方面，还要着眼整体技术方向的演进，以及技术梯队的培养等工作。

而作为管理身份，简单来说，就是不能像原来那么挑活了。原来作为技术 Leader，我可以只看最关键的事情，剩下的反正有经理帮着兜底，如人员问题、预算问题等，我都可以不去管。但现在作为一个业务的管理者，我变成了那个兜底的人，需要把很多精力分到一些看上去非常琐碎，但对整个部门发展非常关键的事情上，比如上面提到的人员招聘、预算制定等。

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

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

但在区块链实验室这边，我反而需要主动克制自己对技术的感觉，不要过多的参与到一些非常细节的技术讨论和判断中。甚至有时候我有更好的想法，也要忍住，不能直接提出来，而是要慢慢引导团队，或者让他们自己去尝试。

主要原因在于，一方面，我作为业务管理者过多的参与技术方案的制定，对整个技术团队的成长并不是一件好事；另一方面，作为管理者，我需要将更多的时间和精力分配到整体的业务和战略上，以及对内对外、向上向下的各种协同合作中。

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

极客时间：回顾一下您的职业生涯，对您影响最深的事情是什么？

谭待：这么多年下来，感触深刻的事情还蛮多的，我分享一个至今仍对我产生影响的事情吧。

2007 年，我进入百度开始实习，加入了一个主攻云计算方向的团队。当时这个团队聚集了百度最优秀的人，公司也给了非常大的支持。

一方面，一毕业就加入一个可以说是当时全国最优秀的团队，得到了很多牛人的指导，这对个人的成长非常有帮助，最关键的是在这个过程中养成了很好的技术素养和做事方式，对我的职业生涯起到了奠基性的作用。

另一方面，这个项目后来失败了，它有着最优秀的团队，做的也是云计算这样符合技术趋势的事情，但它最后却失败了。可以说，如果它成功了，那它对我的触动还没有这么大。

我时常回顾它的失败原因，其中最大的一个原因是，它没有吻合产品的发展步调。

这是一个技术型项目，但它最终是要服务于某一个业务和产品的。然而，这个项目在设计之初，就和产品的步调脱节了，它的发展计划没有很好的吻合产品的发展计划。所以，虽然它的技术很出色，取得的成果也不错，但产品等不了它出成果、出方案，最终就用了其他方案。对这个项目来说，它就是失败了。

大家都知道，技术要结合业务和产品的发展，但老话说的好，知易行难，知道归知道，要做到知行合一是一件很难的事情。很多技术人，在执行过程中，会不自觉的追求最前沿的技术，会很自然的从自己的角度出发思考问题，而忘了考虑产品的需求与步调，最终导致两者脱节。

这件事情对我的影响很深，一方面，它帮我培养了非常好的技术素养，让我懂得在做技术规划的时候，要往前看，往远看；另一方面，它也提醒我，你可以站的很高，看的很远，但你的每一步落地，都必须要接地气，踩中业务方的节奏。

极客时间：您从事架构相关工作多年，在您看来，架构的本质是什么？

谭待：架构的本质是折中，作为架构师，你拥有的是有限的资源，如人力资源、机器资源等，但你面对的是没有上限的需求，如工期的需求、稳定性的需求等，所以需要在不同的层面做出折中的选择。

你不可能做出一个完美的解决方案，必然要牺牲一些东西来达成另一些需求。所以，从宏观的整体架构设计和安排，到最终每个功能点的实现，都是折中的。

比如，我过去设计方案的时候，会做不同的 Milestone，选择不同的 Feature List，这是一种广泛的折中。再具体点说，你做方案的时候，不管是用空间换时间，还是用时间换空间，都是一种折中。

展开来讲，首先，作为架构师，要明确你设计系统最终还是为了产品和业务，所以，你要了解产品和业务的需求，并做出相应的预判，比如预判这个产品三年以后会是什么样的。这样，你设计的系统，就有足够的预留空间和生命周期。

在百度，我们设计系统的时候，一般会去看业务三年以后的情况，这样做出来的系统，至少在三年内能比较好的支撑业务发展。另外，硬件基础设施一直在迭代，三年后很可能就发展到一个新的阶段。这时就可以根据新的业务情况和硬件条件重构系统，也能借此机会让团队更好的熟悉原来的系统。

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

我父亲小时候给我讲了一个故事，至今印象深刻。20 世纪初期，美国福特公司的一台电机出现故障，很多人花了两三个月都修不好。在束手无策的情况下请来了专家斯坦门茨，斯坦门茨在电机旁边仔细观察，又计算了两天后，就用粉笔在电机的外壳上画了一条线，说：“打开电机，在这条线往里的线圈减少 16 圈。”结果证明，问题果真出在这里。

这个故事给我的感触很深，作为架构师，你一定要成为那个划线的人。一个架构会涉及方方面面，不可能全都很好的顾及，所以，你需要找到那条线，找到问题的关键，并将其解决，这才是最能体现架构师价值的地方。

举个例子，我做过的极速搜索项目，这个项目目标是把搜索平均速度提高两倍。我之前一直负责搜索中的底层分布式的系统，分布式系统里的很多折中是怎么把时间和空间进行互换。之后，我接手极速搜索项目。之前，大家做速度优化，普遍的思路是看哪个地方慢就优化那个地方。我没有这样的惯性思维，而是想着，分布式系统里的那种用空间换时间的做法能不能应用到速度优化上来。

最后我的方法是，系统提前预测用户的搜索目标并实时抓取，当用户点击搜索时，就把搜索结果瞬时展现出来。这么做必然会消耗更多的资源，但却能极大提升搜索速度，基本可以把搜索请求时间缩短至原来的 10%。

可以说，“用空间换时间”就是我划的非常漂亮的一条线。