"分布式系统的实践知识，我大部分都是从值班中学来的！"

"如果没有亲自实践，你对AI的看法很可能完全错误。"

Marc Brooker是AWS副总裁兼杰出工程师。

实践，几乎贯穿了他整个职业生涯。他从应届毕业生做起，一步步晋升到现在的职位，参与过EC2、EBS、Lambda等多个核心服务的设计与演进，推动了Aurora DSQL的开发，目前正专注于为代理式AI构建基础设施。在近期一次深度对话中，Marc分享了他在AWS分布式系统和大规模基础设施领域的工作经验。本次对话内容涵盖：

一、寻找真正重要的方向

二、从3000多起云系统事后复盘汲取的技术经验

三、缓存的陷阱与亚稳态故障

四、人工智能将如何改变软件工程

五、AI时代给初级和资深工程师的建议

六、为什么工程师应该写作

七、专业能力与可见性的权衡

八、Marc欣赏的AWS工程师

九、给年轻时的自己的建议

AI时代，什么才是工程师真正重要的能力？这篇访谈或许能给出一个答案。

以下为本场访谈的中文编译。

一、寻找真正重要的方向

Q：你认为应该如何找到真正重要的方向？

Marc：把视野放宽一些，其实很多重要的东西都来自世界各地的客户。我花了很多时间与AWS客户会面，听他们聊，这是一个丰富的灵感来源。另一层面是看技术趋势。你可以看那些速度和性能指标，也可以看到多核和GPU的巨大爆发，存在自下而上的创新趋势，从中发现这些趋势又催生了多少新东西。再往大看，全球范围内有哪些大趋势？行业和整个世界在发生什么变化？正是这些变化带来了创造的机会，也带来了发现和定义问题的机会。

举一个具体的例子。2020年，我在Lambda团队跟很多客户聊过，他们当时对基于无服务器和容器构建应用非常感兴趣。那是巨大的转变，大家都觉得"我喜欢无服务器产品，我喜欢这种构建方式"。但数据世界，尤其是关系型数据，并不完全适合这个范式。这些关系型数据库还是非常依赖服务器的，功能很强大，但运维方式不一样。当时的客户让我意识到了一件很重要的事。所以我加入了Aurora团队，先做了Aurora Serverless，然后又做了SQL相关的工作。我们一直在数据库产品上大力投入，让它们更好地适应无服务器和容器工作负载。这是一个由客户推动的趋势。但与此同时，架构或其他因素也在驱动趋势：更快的网络、更快的计算、更快的连接。

现在数据库领域的一大技术趋势是，块存储正成为各种数据库默认的后端和持久层。围绕这一点，爆发很惊人。比如我们做Aurora DSQL，很大程度上就是学习并引领这个趋势。我们把20年前构建的S3作为新数据库底层的持久层，但它显然不具备在线数据库所需的低延迟和丰富接口。所以我们在上面构建了一个架构，更好地处理其它问题，而不用操心持久化。这正是我听到的客户反馈和技术趋势的完美碰撞。做一个市场领先的产品，如果没有这两方面的输入，几乎不可能实现。

Q：你说你曾经值班了15年。我听过很多资深工程师通过协商避免值班的故事，因为按单位时间算，值班可能被认为贡献不大。那您为什么值班那么久？

Marc：我关于如何构建分布式系统的大部分实践知识，都来自值班、分析以及深入理解那些事后复盘和COE。很多人刚毕业时计算机基础、编程和数学能力都很强，如果没有实际运行和理解系统这种接地气的知识，就缺了根基。值班是学习这些的最好途径之一，能看到系统真正怎么运行、怎么表现，客户怎么用，以及客户用出意外情况时会怎样。如何让系统对客户的非常规使用更有韧性？这几乎应该是值班的一个目标。如果你的团队成员值班只是重复关同一个工单，那就该做自动化了。

但真正值得让资深专家花时间的是：系统发生意外或不寻常状况时，深入复盘分析并把经验带回来。既要改进系统，也要在公司内外广泛分享。我们在AWS最有成效的机制之一，就是每周一次的大范围会议，AWS各处的工程师、各级领导聚在一起，讨论COE和事后复盘，看看能学到什么，怎么把这些经验应用到全公司。

我认为这种特殊的机制，几乎是AWS成功的一个核心因果因素。因为它允许并迫使我们投入领导精力、专家力量、最好工程师的时间，去深入理解系统如何运行、为什么这样运行。这种极度贴近现实的视角，能帮你设计更好的产品、架构更好的系统，也能让你更清晰地思考下一步，帮你解决问题。所以这是一个根本性的学习实践，真的很有益。我会向任何想学习分布式系统实践的人推荐值班。我当然也建议花时间读COE、事后复盘，深入思考：我们不仅能战术上修什么，还能组织上和战略上改进什么，需要哪些工具来防止这类事再发生。这也是一个绝佳的灵感来源。

Q：有意思。因为大多数工程师其实都躲着值班走，但你好像主动靠上去，还从中学了很多，毕竟值班是客户问题的主要来源之一。

Marc：对我来说，归根结底是优化，找到最重要的事情去做。如果你不贴近系统实际运行，不知道它到底怎么工作的，你怎么知道该修什么？你可以猜一些理论，但很可能不对。再说，值班中那些机械关单的工作其实价值不大，那些该由自动化做。真正有价值的是深度理解、深度调查，以及对复盘和COE的深度反思。几个月前我为了一个演讲粗略估算，我职业生涯读过多少行业事后复盘和亚马逊COE。大概一年前，估计在3000到4000份之间。哪怕每份只学到一点点，积累起来就会留下烙印。

二、从3000多起云系统事后复盘中汲取的技术经验

Q：一份优秀的事后分析报告应该具备哪些要素？

Marc：首先要深入细节，确保你深刻理解发生了什么，而不是仅仅基于你自身的偏见去假设发生了什么。所以这其中蕴含着一个教训：如果你搞不清楚发生了什么，那本身就说明你的日志、指标、可观测性和模拟等方面存在问题。一旦你深刻理解了事件本身就能更好地进行事后分析，从多个层面探究其背后的原因。比如为什么会发生？是代码有bug。代码bug可以修，但不能就止步于此。为什么测试和验证没有发现它？我们能改进什么？能围绕这些问题构建什么？再往下一层：为什么我们的测试和验证会处于那种状态？为什么我们对系统行为做了某种假设，而这种假设在之前是不会做的？随着你一层层深入，一份好的复盘不仅能找到直接原因的修复方案，还能找到更广泛的技术、组织和产品层面的改进方向。所以这是一个多层次的事情。

你不能只停留在"这次事故最直接的原因是什么"，也不能只停留在"事情偶尔会出故障，我们又能怎么办"这种层面。你必须提出一套具体可行的行动项，在不同层面上修复问题：修复软件中导致问题的某一行代码、修复未能捕获它的测试流程、修复导致那些技术流程的社会或团队流程问题。如果你在多份复盘中看到规律性的模式，就把它们提炼出来：这里显然有一个深层次的底层问题。我们能不能围绕它建一个服务？能不能建一个库？能不能建一个实践社区？有没有技术上的改变可以规避一整类问题？这个回答有点长。

但我确实认为，一切都源于在多个层面上的"理解"：既要知道具体发生了什么，也要广泛理解技术和组织层面发生了什么以及背景是什么，还要有能力把特定事件或复盘与其他事件联系起来，并提取出模式。我们在DSQL做的一件事就是，在设计过程中花了很多时间翻阅关系型数据库相关的复盘，思考我们自己和客户的经验，考虑如何设计一个能帮助人们避开这些陷阱的数据库。

关系型数据库一个很常见的故障模式是：分布式系统上的客户端启动了一个事务，然后因为某种原因，可能是GC暂停、网络丢包或连接中断，但此时它还在持有锁。因此，关系型数据库通常无法很好地应对客户端的这种异常行为。这是基于关系型数据库的系统一个非常常见的运维问题根源。所以在设计DSQL时，我们思考的是：如何从根源上规避这一类问题？这样用户就可以说，我基于DSQL构建，就不用再面对这一类问题了。我认为这是事后复盘流程之外一个有效的"外循环"：如何把这些教训转化成新服务和服务改进。

Q：如何防止数据库受到客户端异常行为的影响？

Marc：在DSQL中，我们没有悲观锁。因此事务中发生的一切操作，包括所有读取操作，都使用一种称为多版本并发控制的机制。在这种机制下，数据库中的每一行都会存储一个版本历史记录。你可以读取旧版本的行，而不会阻塞写操作，也不会出现"你刚读了它就不能更新它"的情况。

在处理客户端连接的查询处理器中，我们会把写入操作先在本地缓存起来。在提交时进行乐观检查，确认是否可以提交此事务。通过多版本并发控制、横向扩展存储以及提交时的乐观检查，我们有把握说读取数据的进程绝不会阻塞其它写入进程。写数据的人不会阻碍读取数据的人，写操作可以阻塞其它操作，但只能通过修改数据来实现，而不仅仅是查看数据。这是特定数据库隔离级别定义固有的特性。

Q：为了支持"过时读"，保留旧行副本在实际中大概会带来多少百分比的额外开销？

Marc：实际上开销小得惊人。原因在于，大多数在线数据库的访问模式，即使是写流量很大的，写操作也往往非常集中。在线数据库工作负载（甚至分析型工作负载）很少会对数据库中的每一行都创建第二个版本。通常它只是对某一行创建第1、第2、第3、第100个版本，对另一行创建第50个版本。绝大多数数据其实并没有变化。所以这非常依赖具体的工作负载，数据库领域的一切都是如此。但开销通常相对较小。对于在线数据库工作负载，存储方面的额外开销超过10%的情况我认为并不常见。

Q：从我的经验来看，我看到团队之间有一个有趣的两极分化：有些团队非常理解复盘文化，通常是基础设施团队，他们非常重视这件事。技术负责人都会问你"为什么？为什么会发生？"然后真正跟进，确保问题不再发生。但我也注意到，有些团队在这方面就弱很多，他们不太当回事。你如何说服他们应该认真对待？

Marc：归根结底在于你想把时间花在哪里。你是想把时间花在改进产品、让它变得更好，还是想把时间花在反反复复救同样的火？建立良好复盘文化的真正目的，是在产品层面和组织层面修复已知问题，避免反复踩同一个坑。

当我看到那些复盘能力很差的团队时，我认为他们可能存在以下两种情况。第一种是缺乏对结果的关注，比如这个产品是否表现得非常出色？这本质上是一个文化和领导力的问题，即设定正确标准的问题。顺便说，我觉得标准不必统一。有些地方细节确实至关重要，比如持久性就是关键，你需要非常高的标准；而有些地方你可能想优化其他方面，可以接受更高的缺陷率。只要那是经过深思熟虑的有意选择，就没问题。

第二种情况是更难改变的，是把"英雄主义式运维"正常化。比如：我们不需要修复根因，因为我们的值班团队是超人，他们能熬夜，他们会想办法临时绕过去，他们不介意每周被呼叫100次。从内部看，这感觉像是一种好的文化。但如果你从外部看，就会意识到：我们其实并没有真正修复问题的根源。我们只是在做一个极其昂贵的事情：把所有这些人的责任心和专业知识全部消耗在"修了又坏、坏了又修"的循环里。

这时候你就需要跳出这个循环来看：把这个团队的能量集中到改进服务上，跳出那个循环，找到新的事情去修复和构建。这可能会很难，因为那些已经沉浸在这种模式里的人会觉得"这种感觉很好"，觉得自己在关心客户、关心产品、关心业务，却意识不到他们关心的层级错了。他们没有以最好的方式处理业务，而是过于狭隘地陷在修修补补的循环里。这时候你需要把他们拉出来，多花点时间事后复盘，思考事情的根本原因，用更战略性的方式解决这些问题。你会发现打破循环之后你有了更多的时间可以用不同的方式来改进产品。

三、缓存的陷阱与亚稳态故障

Q：我看你发过一条推文，说在某些情况下缓存是有问题的，尽管大家都说这是最佳实践，能解释一下吗？

Marc：缓存本身当然是好的。但缓存的缺点，尤其在分布式系统中，是它存在两种状态模式。一种模式下缓存是满的，里面都是正确且适时的数据，系统表现很好。另一种模式下缓存是空的，或者装的是错误数据。

第一种模式下，系统又快又健康。在第二种模式下，系统很慢，通常还会宕机，因为后端没有为处理全部未缓存流量而扩展，客户会非常失望。而且这种宕机往往是"稳定地宕着"，这就是所谓的亚稳态故障：系统从状态一切换到了状态二，在状态二下它仍然是稳定的，但它是宕机的，而且靠自身能量回不来。因为所有流量都在给数据库造成巨大压力，或者把网络打满了，你连缓存都填不进去，根本无法把正确的数据灌进去。所以当我说缓存的缺点时，实际上是在讨论：如何避免在速度和缓存的价值之间取得平衡，以及如何避免宕机状态？

回到DSQL，我们的做法是：存储层本质上就是一个缓存，但它是一个完整缓存，它包含了数据库中的每一行数据，所以它不存在缓存为空或装错数据时怎么恢复的问题。同样，在更传统的关系型数据库设计中，比如Aurora，Aurora的leader节点会持续告诉潜在的故障转移目标："你应该缓存这个、缓存那个"，这样当故障转移发生时，目标上的缓存已经是热的。这些就是规避此类模式的方法。

所以当发生故障转移时，缓存会在故障转移目标上处于"热"状态。因此，你可以采取一些措施来避免这种情况。但总的来说，我不会把这当作一条规则，或者说它100%适用，但我更倾向于尽可能避免使用缓存。

我更喜欢这样的模式：如果你有数据的完整物化视图，需要非常快速的访问，尤其是当数据变化缓慢时，就把它拉到本地机器上，在内存里处理。如果它每周只更新一次，多复制几份就行了。另一种模式是使用可扩展的后端：DSQL、DynamoDB，或者任何你喜欢的可扩展数据库，让你的数据库供应商兑现你所需的规模和性能，而不是在它前面加一层缓存。缓存不是一个坏模式，但它有显著的缺点，在实践中最好尽量避免。

Q：多久会看到一次这种亚稳态故障呢？

Marc：其实不算特别常见，你可能好几年都碰不到一次。但如果你去看行业内影响最大、最严重的事后复盘，我敢说这种亚稳态故障在其中大多数里都是根本原因之一。作为一个行业、一个实践社区，深入理解这些东西非常重要。因为一旦发生，往往是大规模问题、恢复时间更长、修复更复杂的问题。你经常不得不"关了再开"，这对团队或组织来说是非常痛苦的操作。所以，你可能运行一个系统好几年都看不到这种情况，但如果你看那些影响最严重的事件，它其实相当常见。

四、人工智能将如何改变软件工程

Q：你认为AI会如何影响软件工程，会带来哪些变化？

Marc：我深信软件对世界的影响才刚刚开始。未来软件的发展潜力巨大，规模更大、功能更强大、更个性化等等，各种类型的软件都将成为可能。在软件近60年的发展历程中，供应一直受到限制，我认为这种情况还会持续下去。软件在全球范围内的发展机遇几乎是无限的。我们正处于软件开发经济模式快速变革的时代，这让我们有机会思考，如果我们拥有更多的软件，例尤其是更多个性化、更精准地出现在合适时机和位置的软件，我们能为这个世界带来什么。

这让我对这个行业的未来充满期待，因为软件开发经济格局的转变带来了巨大的机遇。同时，这些变化也要求我们这些从业者，开发软件和热爱软件的人去适应。这意味着软件行业的职业面貌会发生改变，无论是早期阶段还是后期阶段都会不同。未来五到十年，个人和组织能否成功，很大程度上取决于他们适应和引领这种变化的能力。

Q：你讲过这样一个故事：有人押注模拟电路，尽管我们都知道数字电路后来成了主流，但他还是赚了不少钱。这是否在说明，即使有人不想适应，也仍然能过得去、能成功？这是你想传达的意思吗？

Marc：你理解得没错。如果我把这个领域分成两几个层次来看：首先，软件本身带来的乐趣会一直存在，但从经济角度看已经没那么吸引人了。不过，我们做的每一件事不一定都要有经济价值。它可以只是因为我喜欢、我享受它的成果或者喜欢和别人讨论它。这种乐趣不会消失，就像复古计算一样，有人把Apple II当主力机用，不实用也不划算，但很有趣。这部分大概会永远留在软件世界里。

另外，我在博客里提到的那种情况是：在现实世界中推动变革总是比表面看起来要难。一旦深入到细节，事情就变得更复杂，更依赖人、政策，依赖我们各种非理性因素。因此，软件行业中会有很大一部分继续以"老方式"运行，即过去的技术、语言和方法。而跟这部分打交道，其实也有实实在在的经济机会。

就像模拟电路一样，它们今天依然大量存在。在射频、电力系统等领域，模拟技术仍然有令人瞩目的进步，只是变得更专门化了。数字技术成了主流，如果没有数字晶体管数量那种数量级的爆炸式增长，我们今天也不会这样交流。但这些细分领域仍然有机会，只是它们会越来越专业、越来越窄。

而主流方向，我认为会采用这些新技术。从智能体驱动开发，到AI辅助开发，再到规格驱动开发，以及许多我们目前还叫不上名字的新方法，以旧技术无法想象的速度和成本来构建软件。我认为这才是整个行业大多数应该走的方向，大多数职业和经济机会也在这里。我现在的工作也在这个方向上，这也是我个人最感兴趣的。

软件实践会有一个完整的频谱，尤其是在软件与物理世界交汇的地方，会出现一些非常有趣的问题：我们如何把这些新技术、新实践带入软件在过去六十多年里已经渗透进去的众多细分领域？这值得深思。

五、AI时代给初级和资深工程师的建议

Q：对于初级工程师来说，在代码像流水一样几乎可以自动生成的今天，什么才是真正重要的？

Marc：这又回到了我们之前聊的话题：关键是找到那些真正重要的方向，并在职业生涯早期就去着手解决它们。这需要理解客户、业务、经济学和系统。我认为，这方面的能力将逐渐前置，比如"现在你要去和客户沟通，真正了解你构建的产品的背景"，这成为工程师在职业生涯早期就需要具备的素养。也就是说，带着对背景、问题和客户的完整理解去协作解决问题。

这对一部分人来说会非常令人兴奋，但对那些只想要"纯粹开发软件"工作的人来说可能会有些沮丧。他们希望坐下来、打开IDE、开始编码，然后一口气干八个小时。我认为这种模式会越来越少见，围绕它来建立职业生涯也会越来越困难。而另一种模式："我很乐意去跟客户学习，了解他们正在构建什么、需要什么"，会变得越来越有价值，也是一个非常棒的职业发展机会。

这听起来可能有点自相矛盾。我认为对于那些技术非常精湛的人来说，比如在优化问题、基础设施问题、各种科学领域、数据库方面有深厚造诣，或者对我们行业背后的众多其他领域之一有深入研究的人，也有很多机会。提出正确问题的能力比以往任何时候都更有价值。带着深厚技术或科学知识进入这个行业的人，现在有很多方式可以发挥他们的专长，而这些方式在过去可能难以实现。过去有太多的"样板代码"工作拖累你，让你无法真正发挥杠杆作用。因此，我们会看到更多这样的职业路径：在一个技术或科学领域深耕专业知识，然后将其转化为软件和产品。

Q：面对如此巨大的变化，你会对这些刚刚进入这个行业、感到不安的软件工程师说些什么？

Marc：我会提醒他们：我们这些负责招聘和组建软件工程师团队的人，和他们这些正在规划软件工程职业生涯的人，利益是完全一致的。招一群人进来然后让他们注定失败，这对谁都没好处，没人想要这样的结果。所以我们需要认真思考：如何在这条道路上支持他们？如何帮助他们学习这些东西？如何为他们提供正确的指导？

我第一次跟AWS客户交谈时也非常紧张，但我得到了很多帮助、很多建议、很多指导和反馈。随着时间的推移，我在这方面做得越来越好。这个过程就是这样：从小事做起，边做边学，反馈循环会越来越快。所以我不指望刚毕业的人进来就什么都懂。事实上，从来没有哪个技术或工程职业路径是毕业生刚出来就什么都会的，任何领域都一样，关键在于学习。

这需要我们这些关心招聘和培养早期职业人才的领导者，认真思考新的培养路径应该是什么样。我们正在做大量的思考，整个行业也都在进行类似的思考。变化很快，充满不确定性，对毕业生来说这是一个有趣的时代，但也是一个极其令人兴奋的时代。我认为，机遇比以往任何时候都要多。

Q：听起来你给资深工程师的建议和给初级工程师的不太一样。你是怎么想的？

Marc：对资深人士来说，挑战在于：如何在保持职业生涯中积累的宝贵经验和知识价值的同时不掉队，并且学会如何更好地利用这些新工具？当我观察资深同行时，这确实是他们面前的一道难题。很多人已经身处有影响力的领导职位，不再每天都亲力亲为地参与构建。

在这种角色下还能以积极的方式施加影响和提供建议，会变得越来越难。我的建议是：你得重新投入实践，回到一线。需要深刻理解软件开发和软件设计的实践方式已经发生的变化，以及未来将如何继续变化。挑战在于：如何真正利用职业生涯中积累的所有知识和专长，保持强烈的好奇心和亲力亲为，真正关注细节？

我觉得现在有两个好处。其一，因为这些新工具的出现，时间利用率比以前高得多。你可以在那段时间里做出很酷的东西。其二，回到一个根本问题：当初为什么选择进入这个领域？进入这个领域不是为了开会显摆自己聪明，是因为热爱学习、热爱技术、热爱解决客户问题、热爱了解新技术和新事物。而这套新工具及其带来的杠杆效应，让做这些事的机会比以往任何时候都更多。

所以归根结底，还是要回到那个问题：你为什么选择这条路？现在和从业者交流时，有一点非常明显：谁真正在用AI驱动的开发实践，谁没有？那些真正实践的人，对方法的优劣、还缺什么、哪些集成还没做、什么有效、什么无效等等，都有非常有趣的见解。而那些没有亲自动手的人，对它们的运作方式、擅长什么、不擅长什么，往往非常模糊，以至于他们的描述基本上只是虚构。

所以我认为我们现在正处于这样一个阶段：如果没有亲自实践，你对AI的看法很可能完全错误。承认这一点需要一定的谦逊，这对于头衔响亮的人和拥有杰出职业生涯的人来说都很难。但这是必须的。

Q：我觉得软件工程师在和所谓的"技术主管"共事时，普遍存在一种感受：这些人虽然名义上是技术主管，但实际上并不亲力亲为。他们过去五年左右的时间里可能只是在研究文档，所以很容易就能看出这个人对底层原理缺乏理解。而且随着这些新工具的出现，这种差距似乎会越来越大。如果你只是高高在上地看待问题，却不实际使用这些工具，那么你和真正参与开发的人之间就会产生更大的隔阂，你会完全脱离实际。

Marc：这种情况一直存在，只是现在比以往任何时候都更加明显。我职业生涯中真正尊敬并从中获益良多的工程领导者，比如二十年前构建S3的那些人。S3之所以如此成功，是因为他们对细节极其了解，对用例非常熟悉，对经济模型也深入掌握，既思考了战略层面的问题，也关注了非常细碎的具体问题。

像S3或EC2这样经久不衰的产品，正是从早期开始就对细节的扎实把握，才造就了它们的成功。而其它一些同样在早期充满潜力的产品，最后却没有取得同样的成功。

六、为什么工程师应该写作

Q：你的博客上有很多很棒的文章，文风清晰易懂。我很好奇，作为一名工程师，你为什么写这么多文章呢？

Marc：写作拥有不可思议的力量。对于技术人员来说，它能极大地提升你的影响力，能够将脑海中的想法分享给全世界。你也可以将脑海中的技术理念转化为一款优秀的产品，和他人分享。这是一件非常棒的事情。还可以通过一对一的指导、教学、小组学习等方式与他人分享这些理念，这也是一种很好的消磨时间的方式。

我十年前写在博客上的东西，现在仍然可以分享给别人，告诉他们"这是思考某个问题的一种方式"，或者让别人自然地发现它，这非常有用。写作让你能以其它媒介很难做到的方式，在时间和空间上放大你的专业影响力。视频和播客也有类似的作用，但我认为写作仍然具有独特的力量。

此外，还有一种理念，可以说是亚马逊文化的核心信念。写作能迫使你达到一种演讲或制作PPT无法达到的思维清晰度。这在我的亲身经历中也得到了印证：坐下来写作会迫使我深入思考。所以我有时候写很多东西，甚至只是为了自己。我会写一篇文档，并不打算分享，只是为了让自己对某个问题思考得更透彻。所以写作之于我，有三重作用：有想法想表达、想把影响力在时间和空间上放大、以及想通过写作来磨砺自己或一小群人的思考。

Q：我记得职业生涯早期，我的一位经理或技术主管让我写一些关于设计或策略的文档，这让我很惊讶。他说，即使你写完就扔掉，也仍然很有价值，因为在编写过程中你会意识到一些问题，这种清晰的思路会在以后为你节省大量时间。这让我觉得很有意思，因为很多工程师都在抱怨写文档、写代码相关的各种东西。你会对这样一位工程师说什么呢？

Marc：这取决于你要解决的问题的层次。拿UML来说，它是一种半正式的软件设计流程，但我一直觉得它没什么用，因为我觉得它的语义层次不对，过于关注一些无关紧要的细节。很多"让我们去记录一下"的做法都存在类似的问题：这真的需要那种程度的反思和思考吗？

有价值的文档写作和思考过程，与"忙碌无用的工作"之间的区别在于：你明白你从中得到了什么。你得到的可能是一份可以留给未来的成果，无论是给记性不好的自己、新团队、新同事，还是给客户或全世界，这都很有价值。或者你想写下来，以便思考一个非常困难、难以更改的技术决策或API设计决策。当然，我不可能每次做技术决策都这么做。但当需要做出关键决策、找到关键洞见时，我会把时间花在写作上。写作的目的决定了时间是花得值还是不值。

我觉得这是一项值得培养的技能，尤其是在记录设计背后的核心技术决策方面。这种用处体现在两个方面：当我们构建大型系统时，会做出成千上万个决策，有些是经过深思熟虑、影响深远的，有些则是没有数据支撑时凭直觉做出的。对于后来加入改进系统的人来说，能够分辨出哪些决策是经过仔细思考的、哪些是随意的。因为那些随意的决定，后来者可以基于更好的数据直接改掉；而那些深思熟虑的决定，他们就需要认真理解背后的原因。了解一个决策背后投入了多少思考与了解决策本身同等重要。

七、专业能力与可见性的权衡

Q：你之前写过一篇很有意思的博文，标题是《四种爱好与表面专业能力》。你提出了一个非常有趣的观点：一个二乘二的矩阵，一边是"实践"与"讨论"，另一边是"爱好"与"装备"。我可以把它叠加展示给感兴趣的人。后来你还用这个框架类比了自己的职业生涯。根据你处在哪个象限，专业能力和可见性之间存在一种权衡，你如何把握这个平衡？

Marc：这是我经常思考的问题。我认为100%偏向任何一端都是一种失败模式。我个人更喜欢和那些100%在实践、0%在空谈的人一起工作，我非常欣赏他们的专业能力。但我认为，如果他们能稍微向中间移动一点，就能发挥更大的影响力和作用。我不太喜欢和那些只会夸夸其谈的人交流，如果他们能稍微回归到中间立场，他们就能提出更多有价值的观点。而完全专注于行动的另一个问题，其实也回到了这个话题：找到真正重要的方向。如果你整天埋头于自己的想法，很可能是在做错误的事情。

如何找到最佳平衡点，我没有一个万能的最佳方案。我通常会把实践和讨论的比例定在75%和25%之间，有时候可能会是80%和20%。我合作过的优秀同行，大概分布在90%和10%到50%和50%这个区间。超出这个范围的人往往会遇到问题。我找到的最佳平衡点在75%和25%左右，这对我是有效的。在如今变化如此之快、有太多东西要学的时代，稍微向实践端倾斜一些对人有帮助。但也不能走得太远，否则你会失去与外界互动带来的那些重要的东西。

Q：在"实践vs讨论"这个维度上，我觉得如果太偏向实践，你就会被低估；如果太偏向讨论，你就会被高估。对于那些正在规划职业生涯的人，你觉得被高估更好，还是被低估更好？

Marc：长远来看，被低估可能更好。被高估在当下可能感觉很好，但很难持续，也无法真正把你带到需要去的地方。我喜欢体育运动和各种创意爱好，因为它们会让你更贴近现实。就像运动员，你不可能长期欺骗世界，谁行谁不行很快就会变得很明显。在我们这个有很多定性因素的领域，这个过程可能需要更长一点的时间。但从长远来看，当我看那些我真正尊敬的人时，他们往往都是对自己的知识、理解和技能水平非常坦诚的人。

八、Marc欣赏的AWS工程师

Q：你在AWS工作了这么久，见过那么多传奇工程师。在AWS里，你欣赏谁？为什么？

Marc：在AWS工作的一大幸事，就是能和那么多优秀的人共事。Allan Vermeulen是AWS早期的工程师之一，也是S3设计的主要贡献者，他对我们很多数据库服务的设计都做出了巨大贡献。Allan实际上还担任过一段时间的Amazon CTO，后来他意识到那并不是他想做的工作。我职业生涯早期就很钦佩Allan，很明显他是一个对自己所做的事理解极深的人，而且他能在两种模式之间自如切换。

2010年左右，我和Allan争论Paxos论文里的一些边界情况，他在那个层面上非常深入。但他同时也能上升到高管的层面，谈论云战略、应该如何向人们解释以及需要构建的基础性东西。我非常钦佩他那种几乎能在任何层级工作的能力。我当时就觉得：这就是我向往的，也是我想用来规划自己职业生涯的榜样。那才是我真正喜欢与之共事的人：拥有这种广度和深度的人。而且这些人还有一个非常令人钦佩的特点：他们并不想成为名人。

九、给年轻时的自己的建议

Q：如果你能回到刚加入AWS的自己，会给自己一些什么建议？

Marc：也许可以再大胆一点。我非常喜欢我合作过的团队，尤其是在EC2和EBS早期的那段经历。但我当时在离开那些团队、寻找下一个方向这件事上，比较犹豫不决。当我在那些地方个人成长开始变慢，影响力不够大时，我并没有及时离开。回顾起来，我在职业生涯中大概做了四次大的组织变动，也许五到六次会是更优的选择。

所以我的建议是：不要犹豫，而是去思考：我在学什么？我在向谁学习？有没有更好的环境能让我学得更快、更多？我个人的驱动力很大程度上来自于跟随自己的好奇心。每一次我这样做的时候，都发现那是一步有价值的行动，也是我个人非常享受的经历。

来源丨网址：https://www.youtube.com/watch?v=u3GjIXP9N0s

dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn