Uber技术leader谈架构、团队与自我转型的14条核心准则

Q：你已经参与构建过能支撑海量用户的系统，要实现这种大规模的成功，通常需要哪些要素？

Sendil：成功的关键是在架构设计时把基础打牢。铺地基的时候放慢脚步，搞清楚你在建什么，理解系统的关键性、存在的问题，以及如何交付成果。一旦路铺好了，就能以高质量快速执行，真正实现指数级增长。交付之后还要去看用户的反馈，了解用户如何使用系统，也要清楚自己做了哪些权衡取舍。有了这几样东西，你就能收集数据，越来越深入地理解自己做出的权衡以及它的结果。你学得越多，反馈循环越短，就越容易理解系统，跑得也就越快。

Q：为了更快上线、试水市场、看看有没有用户用，在基础架构上做出妥协，值得吗？

Sendil：这取决于在解决什么问题。比如我现在正在负责的项目，一开始我先做了个POC，要求团队先把范围缩小，看提出的方案能不能解决实际问题。如果发现确实存在问题，而该方案在这个小的范围内解决了问题，那就OK。这时候就可以加快速度，也可以走一些捷径。因为我知道影响面会更小，所以可以先上线一个版本，从中学到东西，并且拿到数据。

Sendil：从上线的版本中，除了拿到数据，还会获得经验。将拿到的数据和经验进行比较，据此做出决策。一旦完成这一步，接下来要做的就是扩展系统，比如从几千几千用户扩展到几百万用户。

一旦拓展，就要考虑预算、SLO、SLA，并根据第一轮获得的反馈机制来指导决策。把这些数据和反馈结合起来，构建出一个架构，支撑你在接下来的时间里更快地推进。在推进的同时，还得确保交付的内容能产生有意义的实际影响。所以，把问题拆解成小块，按那个循环反复迭代，会有很大帮助。

Q：在某些组织里，你没法用这种方式上线，一边盯着架构，一边为下一个数量级的规模做重构。是否应该预先为某个未来的大规模做架构设计？还是说这种思路本身就不一定对？

Sendil：权衡确实很重要。不同类型的系统差异很大，就像我现在负责重构Uber某条核心路径，我不能贸然做大幅改动，如果引发故障，对业务影响会很大。所以在有些系统里你必须改动遗留的部分。

在这种情况下，我的做法是：想象一座围墙花园，把一个功能圈起来，外面加两道哨卡，让数据以事件形式进出。通过这种方式，我可以映射出功能、映射出数据流、映射出漏斗。这样我就能理解数据怎么穿过系统，以及输出了什么结果。这样更有信心“花园”里做改动了。从一个微小的改动开始，先尝试调整那一小块，再一步步推进。

所有事情没办法同时进行，所以必须先理清路径，一步步来。这样就能明确了自己想改什么，也把第一步的范围限定得很小，这种思路给了我很大的信心。同时，我得到的反馈循环越短，就越能积累可信的证据。按照这两点，我就能很从容地完成迁移，逐步推进产品的演进。

Q：拆分问题也是一种需要掌握的技能。经验不足的人遇到这种情况，是不是很容易出问题？

Sendil：从我的角度来看，最大的不同在于清晰度。它才是真正的分水岭，而不是资历多深，把事情说清楚是核心能力。比如现在正在做什么以及为什么要做。做什么和为什么这两点非常重要。一旦给出了这种清晰的说明，事情就容易多了。无论经验多少，只要明确知道自己在解决什么问题、打算怎么解决，整个团队的协作都会高效很多。

Q：特别是在从零开始的场景下，决策过程会非常有意思，尤其当我们在谈论为大规模设计的时候。大家往往各执己见，而要让他们达成一致，确实需要目标明确、方向清晰。

Sendil：人通常会用过去的经验来套眼前的场景，当面对一张白纸时，经常带着一种惯性思维来解决问题。作为管理者最重要的职责之一就是帮他们摆脱那种惯性，用更新、更宏观的视角去看待问题。他们是在一张全新的图纸上开始，而这个新场景跟他们以前解决的旧问题不一样，结合他们的长处和成长空间来优化会很有帮助。

这也是我看待系统和架构设计的方式：先想清楚我们要做什么、为什么做，然后去解决它，但前提是先把预设的假设放到一边。你可能以前解决过千万级用户的问题，但现在我们要解决的可能只是几千用户的问题，那就先往那个方向去优化。你可以参考之前的经验，但在真正推导方案的时候，还是具体问题具体分析，然后再往前推进。

Q：那你有没有发现资深工程师和初入职场的人之间存在差异？前者经验丰富，但他们的固有假设有时会把决策带偏；后者经验不足，反而有时像一张白纸。

Sendil：两种情况我都见过。初入职场的人通常很有热情，想把所有好的原则都付诸实践。但在一个已经有约束条件的系统里，你不可能把所有好的想法都落地。这时候经验就很重要了，因为经验丰富的人会带着整体视角来看问题，有些人能很快适应和调整，有些人则比较困难。适应能力非常重要，以及在给定的约束和限制下，如何思考并做出改变。这往往能区分出这是不是一个优秀的团队。

Q：当讨论开发速度和上线节奏时，用MVP上线去试水、获取使用数据、再迭代的策略本身是聪明的。从你构建基础架构的角度来看，哪些东西是可以妥协的，哪些是绝对不可以妥协的？

Sendil：比如系统延迟指标，我暂时可以接受一个近似的数值，也可以在一些可以轻易逆转的决策上妥协，也就是无需大量成本就能撤回的决定。我倾向于先做决定，推进上线，得到用户反馈之后继续迭代。特别是在探索全新领域时，我们需要大量数据，而只有上线之后才能真正了解系统。

我的优化思路是先提升交付速度，同时清楚我们在做哪些假设，并把它们记录在案。这样以后出现问题，我们还能回过头来审视并修正那些假设。核心策略就是：缩短反馈循环，理解系统，理解用户，然后持续迭代。

Q：很多人会把POC直接当作基础，然后继续往上搭建。但因为早期做了那些权衡，这种基础在真正要长期运行的时候往往并不稳固，这本身就是一个挑战。有些组织和工程师明白，POC是用来试水的，如果真看好这个方向，就需要投入更好的基础架构。但那些没意识到这一点的人，后续随着系统复杂性增加，就会陷入麻烦。在规模扩展的过程中，你看到团队通常是怎么应对复杂性的？

Sendil：进入生产阶段后，要明确假设和结果，把数据反馈回系统。随着复杂性增长，需要把现有架构拿出来，和团队一起梳理扩展时的优化目标：是延迟、用户量还是影响力？能否接受用户等待？针对这些约束做扩展，就能获得更短的反馈循环和更可靠的数据，再投入生产验证，获得更多信息。持续验证假设、形成反馈循环，是高效团队的标志。当这种循环成为文化，管理者就能聚焦下一层目标或者解决下一层复杂性。

我也常看到事情在这个方向上出问题：有人做了一个POC，就直接发布了，但你要弄清楚的是：你的价值点在哪里？正在解决的复杂性到底是什么？这时就回到清晰度这个问题上。如果不能清楚地说明你在解决什么，事情就会变得复杂得多。

Q：你希望谁来推动假设这件事情？是某个级别的资深工程师还是整个团队一起承担？

Sendil：责任感很重要。每个人都要对自己交付到生产环境的东西负起责任，这是整个团队共同承担的。如果我工作没做好，你有责任指出来。这就是我希望建立的团队文化，每个人都应该有责任感。一旦你把责任限定为某个资深工程师的职责，那明天其他工程师就会把责任推给他，这是不对的。

如果资深工程师没写，那高级工程师应该推动；如果谁都不写，那经理就应该推动，或者由经理自己承担这件事。一个系统要想运转良好，我们需要一份操作手册，而这本手册里应该包含所有的假设。大家要去建立这些假设并写下来。任何向生产环境推送代码的人，都有责任去记录并验证这些假设。

Q：问题在于，如果没有人去做，那就真的没有人会去做。但如果大家都能把这件事放在心上，那就可以通过行为来引导。而且，你的行为并不代表你这个人本身，你可以把这两者分开来看。有时候我们也可能以为自己做得对，但实际上那未必是正确的方式。

Sendil：在项目推进过程中，我的角色并不是去处理日常琐事，而是构建一个框架，并把这个框架交给团队去执行。这个框架是开放式的，比如在负责一个项目时，应该关注哪些方面？需要做哪些事情？该如何推进？这是一套让团队自己去思考和执行的体系。

这份文档在团队内部是开放且持续更新的，任何人都可以随时补充他们认为对团队最有利的内容。我们为项目的每个阶段都整理了一套检查清单和经验教训，用这份文档作为操作手册，团队中任何人都可以参照它来推进项目。这让工作内容更清晰，同时也让大家更安心。有了这种清晰度，我们就能并行推进多个项目，打造出一支高效团队。

这也是我思维转变发生的地方：不再亲自处理每一个设计决策，而是思考如何把它变成一个框架，帮助团队按照这个框架运作。在每个项目结束时，我们都会做一次复盘，对照项目清单和各项待办事项，根据实际情况调整相关内容。从每个项目中学到的东西都会被纳入这个流程，这对我们来说非常有效。

Q：见证高效团队的成长会带给你成就感，还是你更享受作为其中的一员？

Sendil：两种我都想要。每一个我从零开始搭建的团队，我都在观察团队文化的变化。最近我越来越专注于打造一个不仅交付结果，还能互相质疑、提出不同意见的团队。这是我想要的那种文化，也是我现在重点发力的方向。

Q：当涉及到用户实际使用应用的延迟体验，以及为了优化延迟所要付出的工程成本时，你是如何应对的？

Sendil：延迟这个指标在行业里被过度看重了。有些场景下，如果想确保合规性之类的因素，比如展示给用户的信息必须准确，那就算需要多花点时间也没问题，总比把错误信息展示给用户要好。这其实就是强一致性和最终一致性之间的权衡。

比如在支付领域，数据必须绝对准确，因为这直接关系到用户信任。如果你展示的数据是错的，信任就没了。所以我的优化思路是：如果延迟较高，我宁愿先不展示数据，只要最终给出正确的结果就行。在用户体验层面，我会考虑如何预取或预加载这些数据，怎么确保当用户滚动到屏幕特定位置时数据已经准备好了。

其实有很多场景可以进行预取，确保数据在正确的时间点可用。所以你可以运用这些思路，根据现有的用例来做优化。我本身有web背景，预加载和预取是加速JavaScript网站最有效的方式之一。当我还是一名工程师时，我对微基准测试和微优化非常痴迷。所以优化这类问题的方式是：分块加载数据，按需预取和预加载。

从这个角度来看，延迟对我来说意味着：在当前的上下文里，我要获取正确的数据集，然后通过不同的展示方式或加载方式来优化它。

Q：一开始我们聊了构建系统时成功的要素，那你觉得哪些做法注定会失败？或者说，有哪些常见的坑是应该避开的？

Sendil：最大的问题恰恰是清晰度不够。如果团队不清楚解决的是什么，为什么要解决，事情就会变得复杂很多。团队成员可能看不出我作为管理者或其他人正在犯的错，只会盲目跟从。当没有理解“为什么”时，整个工程流程也会变得教条化。所以，讲清楚“为什么”，并确保大家正确理解它，比很多其他事情都重要。另一个容易导致失败的因素是，有些工程师对某些模式和框架抱有非常强烈的执念。不管解决什么问题，都非要套用某个特定的模式。

我记得在上一家公司，有一个日历功能的代码库，是个Web日历，整份代码用Scala写的，而且是纯函数式风格。我刚去的时候，没人敢碰那份代码。它确实能跑，但就是动不了，谁都改不了。公司也清楚这个情况。那段代码是用纯单子风格的Scala写的，写得很优雅，非常函数式，但偏偏搞得特别复杂。我们花了两年半才把它完全替换掉，换完之后大家才敢安心做改动。所以我觉得，那种“只按自己熟悉的方式做，不管适不适合当前问题”的习惯，最后往往会闹出很多问题。我会尽量避免这些做法。

我会试着在问题出现之前多想一步：这个优化怎么做，还有哪些信息我能提前掌握。作为管理者，我比团队多接触一些信息，也更有机会看清整体情况。我每周或每两周会跟团队成员聊一次，了解他们在做什么、卡点在哪。这让我在跟团队沟通时更有底气，也能更清楚地把方向讲明白。比如我会告诉他们：“这是我们要解决的问题。我知道某种做法以前行得通，但别照搬，再想想有没有更适合现在的方式。”

随着你带团队的时间变长，会慢慢意识到：你的职责不是去抠每一个设计细节、把每个方案都调成最优解。要学会让团队有犯错的空间，然后从错误里学到东西。这才是管理者真正应该优化的方向。

Q：当团队遇到这种问题时，成员应该怎么应对？比如有人坚持用Scala，说“我擅长这个，我觉得这样能更快”，但可能并不适合当前场景，只是基于个人经验的偏好。在这样的情况下，团队其他人应该怎么做才能找到更合适的方案？

Sendil：关键在于提出正确的问题，厘清你正在解决什么问题、如何解决，以及这个问题的生命周期有多长。我们只是为短期解决，比如只为了这个POC，还是要长期维护？在某些情况下，你也可能面临一个团队精通Go语言，而组织本身也在特定场景下使用Go，这时候也不能脱离现实去硬推另一种方案。

你可以基于现有条件去优化，找到适合当下场景的方式。但如果你的解决方案确实需要安全性和并发处理能力，而不只是高性能的并发系统，那你还是应该回到那个方向上，建议团队往那走，团队也应该能给出相应的建议。这才是理想的工作方式。

Q：我从一线工程师转向负责产品的过程中，经常和工程师们有意见分歧。那时候我经常想：我该阻止他们这么做，还是放手让他们自己去学？他们可能会失败，也可能会成功。那我该不该阻止，还是干脆让他们自己去试错？

Sendil：每当遇到那种非常坚持己见、想要按自己方向推进的人时，我都会想到这一点。他们确实很擅长那个方向，也清楚预期结果，如果按那个方向走，往往能做出很好的成绩。

但对我来说，关键还是在设计阶段：你要先把护栏设好，把路铺好，然后让团队在这条路上跑。如果你在造汽车，就铺公路；如果你在造航天器，就得按它的飞行轨迹来设计路径。先把约束条件定下来，这些约束可以是动态的、随时可调的，但先假定它们是当前的边界，然后往这个方向走。这样做既能加快速度，也能保证质量，因为团队是在限定范围内工作。大家清楚该做什么，路径也更清晰。

做决策之前，得先停下来想一想。有些决策是不可逆的，比如Rust和Go的选择。你一旦选了一个方向，就很难回头，除非重写整份代码。所以面对这类决策时，必须停下来看清情况。

我的角色是在战略层面去推动，理解当前发生了什么，然后想清楚能提供什么帮助。有些时候，你有足够的空间让团队犯错，然后从错误中学习。有些时候则没有。这取决于具体情境，基于这些再做决策。

Q：目前你已经是工程经理，所以手写代码的操作会更少，在走这条职业道路的时候，你考虑了哪些因素？

Sendil：当我第一次成为工程经理时，我跟当时的经理说：我没办法停止写代码，不管怎样我都会继续写。但随着管理的团队越来越大，我能亲自写的代码量也越来越少。那时候我才意识到，这其实是一份完全不同的工作。我之前以为做经理只是高级工程师的延伸，但实际情况是，当工程师时积累的那些经验和习惯，在新岗位上完全用不上，我几乎得从头学起。

在高级工程师的阶段，我的任务是给出方案、推动落地。但到了经理这个位置，我的目标不再是直接给出答案，而是确保团队能自己找到正确的方向。我当然有决策权，但我不想经常用，这跟以前很不一样。我开始琢磨：现在的情况到底是怎么回事？我该怎么推动改变？我该怎么用一种不那么直接的方式去引导团队？

Q：是的，你拥有决策权。

Sendil：但现在我不能那样做了，我必须越来越务实。这是最大的变化。我以前积累的那些肌肉记忆，现在完全派不上用场了。

Q：你对那种肌肉记忆应该很有信心吧？

Sendil：如果是以前，我可能会直接往某个方向去解决。但现在我不能直接下结论，因为团队里的人都很优秀，他们懂的比我多。所以如果出现偏差，我本能的做法不是把它归为“错误”，而是通过提问来引导。我会问他们更多问题，问得多了，大多数时候我都能理解他们的思路，然后退一步，从领导层的角度去想：这确实是个不错的方案。

但这也取决于具体情境。在开口之前，我得先问自己一遍。这方面我做得还不够好，还在学。每次开会前我都提醒自己：别直接给方案，帮他们找到方案。这个提醒对我帮助很大。对我来说，这是最大也最难的一次转变。

Sendil：管理者有培养他人的义务，但管理岗位的晋升结构本身是有限的。在某些地方，只有等上面的人走了，下面的人才能往上走。这意味着，作为经理，你的成长不再取决于“完成了X和Y”，而是看你是否愿意在可能牺牲个人晋升速度的前提下，去成就别人。

你愿意这么做吗？很多非常有抱负、希望在短时间内快速成长的人，在做管理时都会面临一个选择：是否接受自己的成长在某个阶段会慢下来，为的是让别人先上去。这不是说管理等于职业生涯的终结，而是说在特定阶段，你的成长确实会以团队成长为先。如果你在看到别人进步时也能感到满足，愿意把时间投入到培养他人上，那就是一个信号：你可能会成为一个很好的管理者。

我当初选择做管理，就是因为团队里有一个人，技术非常出色，但沟通上有问题。我帮他做了大量沟通训练，一起开会、起草内容，后来他晋升为资深工程师。那一刻，我比自己晋升还要高兴。那件事让我确认：这就是我应该走的路。

一旦你成为管理者，你得到的认可会急剧减少。你做的每一件事，都需要很长时间才能看到回报。哪怕只是取消一个30分钟的会议，别人也可能很久才意识到它的价值。而作为工程师，你部署一个新版本，结果几乎马上就能看到。

另一方面，管理者做出的每一个决策，几乎都会遇到反对意见，真正的认可反而很少。所以你得做好准备：脸皮要厚一点，清楚自己做的事不会马上见效，也不会像从前一样及时获得反馈。