首页 深潮精选 Research 项目发现 7x24h︎快讯 最新活动

对话 Amazon CTO：来自亚马逊内部的故事、见解和秘密

2023.06.30 - 319 天前

如果你希望成为一个快速发展的公司，你不能像传统企业那样。

编译：深潮 TechFlow

注：本文收录于深潮 TechFlow 专题《YC 创业课中文笔记》（每日更新，本篇为该系列最后一篇。），致力于收集整理 YC 课程的中文版本，第二十五篇为亚马逊首席技术官 Werner Vogels 的在线课程《对技术和初创公司的经验和见解》。

加入亚马逊之前

在加入亚马逊之前，我是一名学者，曾在康奈尔大学进行了十年的研究科学工作，并建立了大规模的分布式系统。在那之前，我并不是一个典型的计算机科学家。直到28岁才做出真正决定回学校深造。之前，我在医院从事放射治疗的工作，为荷兰癌症研究所的癌症患者提供放射治疗。有一天，我突然意识到我无法忍受身边的人们一个个离世，于是我决定做一些与此毫无关联的事情。计算机科学似乎是一个很好的选择。

当时是80年代中期，计算机科学并不像现在这样普及。但是，事实证明我拥有了一项天赋，虽然那时我并不知道。于是我开始深入研究，因为这正是我真正感兴趣的领域。我获得了博士学位，在葡萄牙的一个研究机构工作了几年，然后受邀加入康奈尔大学。

在我在康奈尔大学期间，除了研究工作之外，我还经常咨询像惠普这样的大公司，以及其他我无法听清的一些公司，并参与各种会议。有一次，亚马逊邀请我介绍我正在研究的一些材料。一开始我感到有些意外和困惑：真的吗？我需要去做这个吗？

在当时，网络浏览和数据库是多么棘手的问题吗？然而，当我开始上手时，我才意识到这其实是一个巨大的技术挑战。亚马逊不仅仅是一家零售商，它是一家技术公司，经营规模之大，我之前从未见过，也绝对不是我曾咨询过的其他公司可以相提并论的。从分布式系统研究的角度来看，他们面临的挑战是惊人的。

当亚马逊给我提供工作机会时，我毫不犹豫地接受了。

亚马逊的规模运营与技术领先

我认为大多数分布式研究人员已经认识到这些大公司需要以何种规模运营，甚至不仅限于这些大公司。无论是互联网公司还是数字公司，要想成功，都需要以巨大的规模运营。

回顾2004年，当我加入亚马逊时，许多人可能会发现以当时亚马逊的规模来运营是相对容易的。但这并不意味着你可以依靠一份职位或必不可少的基础设施。因此，在云技术和其他技术方面做出了很多工作，确保能够充分利用它们提供的优势。

亚马逊在2004年只通过实践就达到了一定规模，并没有书籍或指南可以阐明如何建立可扩展的组织或公司。因此，我认为亚马逊在技术应用、技术发展和运营规模方面走在曲线前面，领先了5到10年。这对于追求快速发展的公司尤为重要。

如果你希望成为一个快速发展的公司，你不能像传统企业那样。传统企业往往面临创新者的困境，一旦某些事情取得成功，就会变得非常缓慢。

如何建立一个持续快速发展的公司是完全不同的故事，你必须仔细权衡业务。例如，是否创造技术债务或容忍一些重复发生的事情，这在传统企业中是不可行的，因为效率是它们的主要目标。

在亚马逊，速度快、创新速度快，并且有着长期的实验管道，这是最重要的。因此，你愿意容忍一些重复发生的事情，允许产生一些技术债务，只要你知道必须还清它。

因此，在传统的MBA书籍中，很难找到亚马逊愿意做出的这些折衷。大多数情况下，亚马逊必须自己发展技术、流程和业务流程。当然，有杰夫·贝索斯这样具有远见的领导者，他真正了解未来的形态和现代世界应该是怎样的。

实现增长的关键

尽管亚马逊已经在规模上取得了巨大成功，但我们仍面临着实现更大增长的挑战。为了迈向下一个增长阶段，我们需要更加严谨地思考和行动。

一个例子是性能方面的问题。如何度量性能？我们需要怎样的基础设施来进行测量？要成为一个真正的数据驱动公司、做出数据驱动决策，首先需要拥有数据，并建立一种文化，围绕如何评估和解读这些测量数据。

即使网页加载时间稍微延迟1.2秒，也会对客户体验产生负面影响。这只是说明了50%的客户体验变差，你需要了解情况有多糟糕。从工程角度考虑，像99%或99.9%的控制也变得更加重要。然后，你需要建立一个能够真正掌握99%工程学科的机制，并将其与业务决策联系起来。

我认为在2004年，我们的可靠性相当高。有一些规则约束着我们，比如我们必须使用特定区域（SEA）的数据中心。无论你对这些SEA数据中心做了什么操作，都需要在其他数据中心进行复制，这样即使一个数据中心出现故障，客户也不会受到影响。

虽然客户可能会受到延迟的影响，但功能并不会受到影响。我们在处理所有这些规则方面非常擅长，直到有一天我们决定断开其中一个数据中心的连接，看看会发生什么。只需稍微调整网络，就可以将一个数据中心与其他数据中心隔离开来。

然而，实际上，所有这些在纸面上看起来都很好的东西，在实践中并没有像人们想象的那么顺利。虽然在首次尝试时还存在很多手动过程，例如手动数据库故障转移，这一年我们一直在进行预演。而当你进行第三或第四次运行时，你实际上已经达到了几乎可以在没有人工干预的情况下自动化运行的程度。这对于确保系统的高可用性和容错性至关重要。

在我们的努力中，我们还注重发展数据分析和洞察力。亚马逊拥有大量数据，但如何从中获得有价值的见解是一个挑战。我们致力于构建强大的数据分析工具和模型，以帮助我们理解客户行为、市场趋势和业务机会。这种数据驱动的方法使我们能够更好地做出决策，并提供个性化的产品和服务。

此外，我们还致力于改进用户体验。我们深入研究了用户在购物过程中的需求和偏好，通过设计优化、界面改进和个性化推荐等方式提升用户体验。我们追求简单、直观和无缝的购物体验，以满足客户的期望并赢得他们的忠诚。

CTO 角色的变化

成为技术供应商后，作为CTO的角色会发生改变。

我在一篇博文中谈到了这个问题。在我看来，CTO有四种不同类型的职责：

首先是企业级的CTO，通常负责基础设施管理，向CIO汇报，并负责管理大量的基础设施。
第二种是年轻企业中常见的技术联合创始人型CTO，他们具备技术远见。但我认为这个角色存在一定风险，因为很多其他事情，比如工程团队的管理等，都会被纳入这个角色的职责范围。CTO可能并不一定擅长处理这些事务，但我们稍后再详细讨论。
第三种类型是具有大思想家特点的CTO，他们推动创新的发展。例如像AT&T和朗讯这样的公司，他们有CTO或CTO办公室，致力于研究和实验下一代技术。
最后一种类型是面向外部的技术专家型CTO，在其他公司担任技术供应商时，他们负责与客户进行深入的技术互动，了解客户如何使用他们的产品，并寻找更深层次、更广泛的模式和客户的痛点。这种角色不仅关注自身技术，更加重视整体情况。

需要注意的是，这些角色更加以客户为中心，而不仅仅是以技术为中心。重要的是将客户的反馈带回公司，并思考需要开发什么新功能或产品，或者需要改变哪些流程，以更好地服务客户。

因此，作为技术供应商的CTO角色具有更强的客户导向性，而不仅仅关注技术本身。

亚马逊特有的文化

因为亚马逊是我的第一份真正的工作，我曾长时间以为其他地方的工作文化和亚马逊相似，但实际上并不是这样。

亚马逊有一种独特的文化，对于快速发展的公司来说非常有效。他们鼓励团队尽可能独立，削减组织层级和结构。等级制度在他们看来是不自然的。

他们希望拥有自组织的团队，雇佣那些真正想要独立工作、拥有产品的人。年轻的企业尤其需要这点，而不是追随者或编码员。

亚马逊有一套领导原则，包括客户执着、所有权、深度挖掘等14个原则，这推动了他们的文化发展。

在亚马逊，招聘面试也主要围绕文化匹配展开，因为一个不适应文化环境的雇员会对小团队造成很大干扰。亚马逊非常推崇小团队，通常由10至12人组成，每个成员都清楚自己的任务。

随着企业的成长，首席技术官的角色也会发生变化，从最初负责所有技术相关事务，逐渐专注于团队管理和确保工程师能够交付所需的技术和产品。

与工程副总裁相比，首席技术官更加关注技术方面，如构建正确的技术和使用合适的工具等。

亚马逊如何发展起来的？

亚马逊内部经历了一系列的变化。他们创造了独立的团队，这些团队看起来像初创公司，并且掌握了自己的目标和创新议程。然而，在过去，亚马逊为了快速发展，违反了体系结构原则，导致后端数据库基础设施脆弱且无法再增长。

为了解决效率下降的问题，他们转向面向服务的体系结构，将系统拆分成独立的功能构建块，即微服务。

然而，随着团队的增加，每个服务都需要管理自己的数据库，导致交流增加但创新减少。

为了改善情况，他们创建了共享服务平台，采用虚拟化技术和API来管理服务器。他们先在内部构建了这些技术，然后在外部推出产品，如Amazon S3和EC2，这些服务使得存储和计算能力成为可编程和可扩展的，对企业来说非常划算。

亚马逊的目标是实现互联网规模的存储和计算能力，并为各种类型的企业提供服务。

创新之路

亚马逊的创新分为两个层面：

首先是团队级别的创新，每个团队负责制定自己下一年的创新计划，并独立完成任务，例如改进推荐引擎以减少退货数量。他们负责绘制路线图、获取新数据源和与客户进行不同方式的互动。
另一个层面是需要大量资本投资的创新，如Kindle和Amazon Prime。这些项目需要大量的资金支持。亚马逊设定了一个规则，即如果一项创新项目有可能成功并对公司的资产负债表产生重大影响，那么才会进行大规模的资本投资。

亚马逊意识到在技术发展初期所做的一些决策非常明智，随着规模的扩大，他们必须重新审视体系结构并开发适应变化的软件。这涉及使用多个架构和版本来处理存储引擎等技术挑战。

此外，像其他公司一样，亚马逊也发现除了技术扩展之外，还需要解决销售、解决方案架构、技术客户经理和客户支持等与技术无关的因素。这些因素都是构建成功的公司所必需的。

如何推出新服务？

我们希望所有的团队都与客户保持紧密联系，因为我们提供的大约95%的功能和服务都是为了响应客户的直接需求。当初，我们建立的最早的服务几乎可以满足客户的所有期望，包括基本的IT基础设施、存储、计算、数据库、网络和安全等方面。

然而，随着时间的推移，客户提出了各种其他需求。他们需要分析功能、云技术、移动开发以及现在的区块链等其他技术，他们希望能够使用这些技术而无需管理它们。因此，帮助客户构建正确的特性和工具变得非常重要。

当我们推出新的产品和服务时，我们遵循一个强烈的文化氛围，即以最小功能集推出（MVP）。但这只是作为构建业务所需技术的起点。我们不能只发布一些薄片式的东西，而是需要确保其稳定可靠。然后，我们与客户一起探讨其他功能的需求。

在产品初始阶段，我们并不总是知道客户需要什么其他功能。例如，当我们推出DynamoDB时，并不知道客户想要二级索引。我们没有一开始就提供，但很明显这是客户想要的。我们通过以最小功能集启动服务来观察客户如何使用产品，并逐步迭代和添加新功能和服务。

举例来说，当我们推出Lambda时，它作为无服务器环境，使开发变得简单，只需编写代码并将其部署到S3中，无需考虑服务器等其他事项。你只需要支付你实际使用的部分，而不需要担心闲置时间等问题。

这种方式改变了开发过程，我们可以观察客户如何使用产品。他们很快就开始采用类似X射线调试环境的方式进行迭代，并使用阶梯功能构建更复杂的应用程序。我们通过观察客户的使用习惯来了解他们的需求，例如在DynamoDB中，我们意识到辅助索引对于客户比二级数据中心更重要。

基本上，客户重新定义了我们的路线图，我们开始提供对他们最重要的功能。这是非常重要的一部分。即使看起来像MVP，我们也不能将其视为MVP，因为人们会在此基础上构建业务并依赖它。因此，在产品周围形成了一个不同的文化结构。

去年我们有1400个新功能和服务的发布数量，随着团队数量的增加，这个数字当然会继续增长。我们在AWS中使用相同的结构，每个团队都与特定的客户群体合作，并根据他们的需求构建路线图。随着服务越来越多，路线图也越来越多。

然而，这是一个快速推进的环境，软件构建方式发生了巨大变化。如果我们能够决定客户应该如何开发软件，那么我们可能仍然按照五年或十年前的方式进行开发。相反，我们需要通过与客户密切合作，让他们驱动我们的创新引擎，从2020年或2025年开始开发软件的方式。

因此，我们不能为客户做决策，而是需要与他们紧密合作，让他们驱动我们的创新引擎。我们需要密切观察客户如何使用我们的产品，并根据他们的反馈不断迭代和改进。

总的来说，亚马逊 Web Services（AWS）在创新方面采取了团队级别和资本投资的双重层面。通过与客户紧密合作，了解他们的需求并观察他们的使用习惯，AWS能够提供满足客户需求的功能和服务。同时，AWS也投入大量资本用于研发和推出新的产品、服务和功能，以满足不断变化的市场需求。

这种创新方法使得AWS能够与客户保持紧密联系，确保他们能够提供稳定可靠、符合客户期望的解决方案。通过基于最小功能集的发布策略和持续迭代的方式，AWS能够快速响应客户需求，并不断提供更多先进的功能和服务。

亚马逊的创新之路是一个不断演变和发展的过程，始终以客户为中心。通过深入理解客户需求、观察客户使用习惯和持续投资研发，AWS在不断推动技术和业务的前进，为客户提供卓越的云计算解决方案。

构建客户驱动的产品

我们无处不在，无论是从客户那里开始工作还是在亚马逊内部。作为一家技术公司，我们非常注重开发对客户真正重要的东西。尽管我们是一家重型技术公司，但工程设计和工程师也承担着风险。

我们关注的是产品，而不仅仅是技术。我们想知道我们可以为客户做些什么。我们致力于构建令人惊叹的技术，但这并不是我们行动的唯一动力。我们关心的是解决客户的问题。

为了确保我们持续关注客户，我们采用一种称为逆向工作的过程。首先，我们编写一份新闻稿，清楚简洁地描述我们将要构建的东西。然后，我们准备一个包含20个常见问题的文档，并用简单明了的语言回答这些问题。在更复杂的情况下，我们可能需要反复修改这两个文档，直到我们完全清楚我们要构建的东西。

接下来，我们编写用户体验（UX）文档，详细描述客户如何使用我们的产品以及他们与产品的交互方式。我们还编写用户手册、术语表等其他相关文档。

最后，我们会得到一套四个精确描述我们要做的事情的文档。

作为亚马逊，我们始终遵循着这个原则：我们的账单不会超过我们承诺的内容。我们不会随意将第二个版本的功能添加到第一个版本中。我们专注于构建我们承诺的功能，并且只关注这一点。这种方法提供了一个强大的结构，帮助我们思考客户需求、产品体验以及技术等方面。

在亚马逊的会议中，我们不使用幻灯片或主题演讲。我们有一个称为六页备忘录的文件，每个人在会议开始前30分钟默读它。这份备忘录非常重要，因为它确保每个人都对我们讨论的内容有清晰的理解。

写一个故事是困难的，所以我们鼓励协作和反馈。我们会多次修改并完善这份备忘录，直到我们清楚地描述出特性、产品或业务领域。经过30分钟的阅读，会议室里的每个人都在同一页上，这有助于高质量的讨论。

总之，我们拥有独特的文化和流程来确保我们始终专注于解决客户问题，并提供卓越的产品和服务。

容器技术

越来越多的公司跳过容器技术，特别是在追求更微服务环境的发展中。容器技术成为流行的原因之一就是它能轻松实现组件的上下扩展，与微服务理念相契合。许多人开始从整体阶段分解出容器来进行开发，尤其是围绕无服务器环境的开发。

然而，在使用容器技术之前存在一些问题，特别是在交付Fargate之前。你需要管理多个容器在多个可用区域内运行的情况，而且需要将它们映射到虚拟机上。因此，虽然容器是一个很好的开发选择，但仍需投入大量工作来运行和管理这些容器。为了简化这一过程，我们提供了一种名为Fargate的解决方案，它基本上取消了对底层虚拟机的所有管理，只需将容器放入其中即可运行。

未来，我认为会有越来越多的工具、支持平台和基础设施，围绕构建更复杂的无服务器环境的能力进行开发。与其他服务更好地集成将成为发展方向之一。

*深潮注：Fargate是亚马逊网络服务（Amazon Web Services，AWS）提供的一项计算服务，它是一种无服务器（serverless）的计算引擎。Fargate使得开发人员可以更轻松地管理和部署容器化的应用程序，无需关心底层的基础设施和服务器。

容器技术是一种虚拟化技术，通过将应用程序及其依赖项打包到独立的、可移植的容器中，以实现应用程序的快速部署和可移植性。容器技术使用容器引擎（如Docker）来创建、管理和运行容器，使得应用程序能够在不同的计算环境中保持一致的运行方式，而无需担心底层基础设施的差异。容器化技术在现代应用开发和部署中得到广泛应用，它提供了更高的灵活性、可伸缩性和便携性。

保护客户

然而，我认为安全性问题将成为人们关注的焦点。在未来五年里，每个人都应当将安全作为首要任务，无论是CEO、CTO还是工程师，我们都需要具备安全意识并扮演安全工程师的角色。过去几年每周都发生大规模数据泄露事件，作为技术专家和数字商务领袖，我们应该感到尴尬和愤怒。保护客户数据是我们的责任，因为如果不保护客户，就没有生意可言。

我们需要开始思考如何保护从客户处收集的数据，无论是租车还是其他消费服务。安全性需要成为默认的一部分，例如在持续集成和持续部署管道中触发安全事件，确保添加新的开源库时进行审查和评估。

开发管道本身也需要是安全的，并配备各种自动化工具进行漏洞测试。特别是在医疗和金融领域，需要遵守各种规定和监管要求。

在五年内，我希望我们都能对安全问题保持高度意识，并将保护客户放在首位。在亚马逊，无论是智力资本还是金融资本，保护客户将永远是我们的首要投资领域。