作者｜Cynthia
编辑｜ 郑玄
AI 时代，开发者要如何跟上技术的变化？亚马逊 CTO Werner Vogels，用了二十多年的时间来解答这个问题：基于他主导的 S3、EC2、Lambda……无数企业与开发者实现了加速奔跑。他每一年的 re:Invent 演讲，也成为了无数人的认知风向标。
虽然自 2025 年之后，他将不再登上 re:Invent 的主舞台。
但今年 10 月 13 日，他将带着 2026 年最新技术洞察，出席中国深圳的亚马逊云科技软件企业峰会「创业加速营巅峰路演——通往 re:Invent」，并与极客公园创始人张鹏炉边对话。他的经验，或许会成为我们关于如何拥抱变化的宝贵答案。
2004 年的圣诞季，亚马逊正在度过创立十年以来最好的一个年末。
感恩节过后，消费电子第一次超过图书，成为网站最大的品类；整个假日季最忙的一天，全球订单超过 280 万件，平均每秒 32 件。十年前那家靠卖书起家的互联网公司，已经开始显出后来那个商业帝国的轮廓。
支撑这个帝国的数据库来自全世界企业数据库领域最成熟的玩家 Oracle。然后，12 月 12 日，其中一套彻底崩溃了。一个只会在极端规模下出现的 bug，偏偏赶上圣诞购物季最关键的节点，让数据库停摆了十二个小时。
而此时，距离后来长期担任亚马逊 CTO 的 Werner 到亚马逊履职还不到三个月。时间一分一秒过去，宕机引发的损失不断扩大，事情很快越过普通技术支持，一路捅到 Oracle 高层；从工程师到高管，一大批人紧急赶到西雅图。
然而，排查一圈后，系统 bug 之外，他们还发现在当时，业内通常不会区分各种简单访问和复杂关系查询，两者都被挤在同一种数据库中；但偏偏，亚马逊的整体业务规模早就超过了绝大多数数据库产品的默认规模边界。于是，大量给定 key 读取 value 的简单操作，挤占了本应留给原本复杂查询的资源，长期来看，系统隐患也不小。
这个发现，也成为了后来亚马逊自研数据库的起点：几年后，包括 Werner 在内的九名亚马逊工程师发表了一篇名为《Dynamo:Amazon』s Highly Available Key-value Store》的论文。它后来影响了 Cassandra、Riak 等一代 NoSQL 系统，也成为 DynamoDB 乃至来的亚马逊云科技的技术前史之一。
它也让亚马逊逐渐意识到：规模变了，时代变了，过去那些再自然不过的技术前提，也会随之失效。
而这种变化，Werner 在此后二十年还会遇到很多次。
01
一家网上书店，和一个康奈尔学者
事实上，就在那场宕机的几个月前，Werner 对亚马逊的技术栈判断，还不是这样。
图注：Werner Vogels
那时，他已经在康奈尔做了十几年高可靠分布式系统研究。而他关于大型系统怎样传播信息，如何做冗余备份与恢复的研究，也让他经常收到各种去大型公司做咨询分享的邀约。微软、太阳微系统公司（Sun Microsystems）、数字设备公司（DEC，老牌小型机巨头）都在名单里。
而亚马逊找上门来时，他一度觉得：一家网上书店，网页后面接一个数据库能有多难？
二十多年后，他自己重新讲起这件事，仍然觉得这个判断很好笑。因为真正进入亚马逊后，他看到的是一套几乎把分布式系统教材里的每个问题都推到了极端的系统：原本在论文和实验系统里研究的系统规模，变成了订单、客户和凌晨响起来的报警。与此同时，订单、支付、推荐、供应链、机器学习，以及大量因为业务增长太快，根本找不到现成商业软件来解决的问题。
再之后，贝索斯向他发出了入职邀请。但他做出选择前，先把电话打给了好朋友 Jim Gray。
图注：Jim Gray
Gray 是 1998 年图灵奖得主，也是现代数据库事务处理的奠基者之一；在 Werner 后来的描述中，Gray 是只听了 30 秒机器磁盘的响动，就能判断数据库布局有问题的天才；是他产生研究与职业生涯问题后，第一个想要打电话讨论的人；也是他长期的朋友和导师。
而在 Gray 的建议下，Werner 最终接受了亚马逊的邀请。两年以后，2006 年春天，Gray 来到西雅图，与 Werner 再次会面。这次谈话，后来变成了《ACM Queue》中的一场长篇对谈。杂志编辑部为这篇访谈撰写的开篇导语，仍然从那个人人熟悉的亚马逊说起：一家极其成功的网上书店。
Werner 在对谈中专门纠正了这个观点。
「First and foremost Amazon is a technology company.」
那时的亚马逊处在身份变换的关键节点。对内，早期巨大的单体应用已经被增长不断拆开，共享数据库和团队之间的依赖越来越复杂，每项业务开始拥有自己的服务、接口、数据和部署节奏。对外，后来改写整个软件产业的亚马逊云科技，此时也刚刚露出了轮廓。
Gray 顺着这个话题问到组织。系统拆开以后，如果开发团队只负责把代码写出来，再交给另一支运维团队运行，很多问题并没有消失。写代码的人仍然可以不知道自己的设计到了生产环境里会发生什么；而真正面对故障的人，又未必知道代码为什么会被写成这样。
Werner 的回答是 「You build it, you run it.」 写服务的团队也运行它，容量不够、延迟上升、半夜报警找到的还是这群人。客户真正遇到问题了，也不会因为「代码已经交付」而变成另一支团队的事情。
而随着业务规模越来越大，需要承载的业务越来越多，一些通用的经验与组件也就逐渐被积累了下来。
可这些问题并不只属于亚马逊。当越来越多公司开始在互联网上搭建自己的产品时，它们仍然要从服务器、存储和数据库重新起步。
亚马逊与 Werner 想做的，是通过亚马逊云科技改变这个默认的起点。
02
从 CTO 到教父
2014 年 11 月，又一批极客从全球各地飞往拉斯维加斯。
这一年的亚马逊云科技 re:Invent 期间，超过一万三千名开发者、架构师、创业者和企业技术负责人等等科技爱好者挤进城里的酒店和会展中心，400 名演讲人、250 多场分论坛从早到晚排满日程。有人来听数据库和分布式系统，有人排队参加刚刚发布的产品 workshop，还有人干脆守着 keynote，等亚马逊云科技再宣布一种可能改变自己明年架构的新东西。
此时，距离亚马逊云科技发布 S3 已经过去了整整 8 年。在这八年间，S3 已经把 storage 变成 API，EC2 也让计算资源变成随时可以获得的弹性资源，数据库、消息、数据处理和更多基础设施能力也成为亚马逊云科技的一部分。对于越来越多公司来说，做一个产品的起点已经从「先准备多少台服务器」，变成「云上有哪些 building block 可以直接使用」。
站在 keynote 中央的 Werner，也从那个差点对「一家网上书店」失去兴趣的康奈尔学者，变成云计算时代开发者最熟悉的科技教父之一。快两米的个子、牛仔裤、每年不同的乐队 T-shirt，也成了 re:Invent 后来延续多年的固定节目。
这一年，他在台上发布了 Lambda。
但 Lambda 最初展示的需求小得几乎看不出日后有成为基础设施的影子。发布它只是因为亚马逊云科技团队发现：过去，客户只想在一个事件出现时运行一小段代码，比如图片进入 S3 以后生成缩略图，却要为此提前创建 EC2 实例、部署程序、配置扩缩容，再让服务器在那里等待一个不知道什么时候才会发生的事件。
Lambda 允许开发者直接提交代码。事件发生，代码运行；需要多少机器、什么时候扩容、哪台机器坏了以后如何替换，由亚马逊云科技管。
也是从这时候开始，过去的那句「You build it, you run it.」边界逐渐被拓展。用户不必再关心服务器在第几个机架，一次流量突增需要瞬间多出多少机器，底层硬件何时失效，这些都不再需要成为每个开发团队必须掌握的底层能力。
而一家企业的 CTO，也伴随着每年一度的分享与基础设施的演化，成为了一代人的云计算教父。
03
变化永恒
整个科技圈，要说拥抱变化最积极，也最善于自我否定、自我迭代的大佬们，Werner 必定榜上有名。
2021 年 3 月 14 日，S3 十五岁。这个 2006 年刚上线时只有非常简单 API 的对象存储，到 2021 年已经存着超过 100 万亿个 object，峰值每秒处理数千万次请求。
亚马逊云科技给它办了一场相当隆重的生日会：连续四天，每天四个小时，在 Twitch 公开直播「打脸」。直播中，Werner 将负责块存储与对象存储业务的 Mai-Lan Tomsen Bukovec 、 长期负责存储技术的 Bill Vass、负责安全的 Eric Brandwine 这几位参与这套系统演化的人重新请了回来，挨个细数每个产品当年为什么这么设计、后来又改过什么。
直播第二天的日程里讲到的 Amazon S3 一致性强的故事，后来又在一个月后被 Werner 写进了博客《Diving Deep on S3 Consistency》里。
在这个故事里，他提到了亚马逊云科技最早的大客户 Netflix。
2008 年，一次严重的数据库损坏让 Netflix 连续三天无法向用户寄送 DVD，也直接推动它开始离开自己的数据中心。之后七年，Netflix 基于亚马逊云科技，完整重新构建了整套技术系统；到 2016 年，内部的流媒体业务最后一批数据中心也被关闭，大量计算、存储、大数据处理和分析都已经运行在亚马逊云科技上。
早在 2014 年，Netflix 的工程师就把 S3 称作自己数仓的「source of truth」。数据可以长期放在 S3，Hadoop 集群可以在需要时再动态创建和销毁，不同计算任务都围绕同一份数据工作。
但这种用法也把 S3 的一个老问题放大了。
早期的 S3 提供的是最终一致性。一次写入返回成功以后，数据本身已经被可靠保存，但并不保证所有读取路径在同一时刻都已经看到这个最新状态。对存图片、视频来说，这个很短的时间窗口未必有什么影响；可在 data pipeline 里，一个节点刚写完一批文件，下一个节点立刻开始计算，如果少看到几份，拿到的就是一份不完整的输入。
2008 年，Werner 在《Eventually Consistent - Revisited》里系统讨论过，大规模分布式系统为了可用性、性能和全球扩展能力，往往必须在一致性、可用性与时延之间做取舍。
但 Netflix 实际行动告诉亚马逊云科技：对于新的工作负载，这个取舍已经过时了。后来，Netflix 在 S3 旁边又造了一套系统——s3mper。它用 DynamoDB 维护一份额外的、一致的元数据索引；当应用怀疑 S3 返回的结果可能不完整时，再用 s3mper 去核对。
于是，一个荒诞的现实出现了：Netflix 使用 S3，本来就是为了不用自己维护一整套存储基础设施，现在为了弥补 S3 的一致性，又在旁边多维护了一套基础设施。
察觉到不对的 Werner，再次选择了推翻自己，重构 S3。 把 S3 的一致性模型改掉：GET、PUT、LIST 等操作开始默认提供一致性强，一次写入成功以后，随后的读取和列表操作都能立即看到最新状态，对新旧对象全部适用，也没有额外的性能和成本代价。
但好在，Werner 对这种变化并不陌生， 早在 2016 年亚马逊云科技十周年时，Werner 总结过去十年做大型系统的经验，第一条就是构建可演化系统。在他看来：一个系统每跨过一两个数量级，都应该重新检查一次架构。过去做对的选择，不代表面对新的规模、工作负载和限制条件时仍然应该保持不动。而系统的任务不是证明设计者当年是对的，而是继续解决今天的问题。
在之后的日子里，变化的发生，也不会因为 S3 重构而停止。
04
Werner out and Werner back
2025 年 12 月，Werner 第十四次站上 re:Invent 的闭幕演讲。
这些年，观众已经习惯了先猜他的乐队 T-shirt，看那些相当前卫的开场短片，再听这个荷兰 CTO 用一个多小时讲架构、开发者和下一轮技术变化。那一天，他上台不久先告诉台下，这是自己的最后一场 re:Invent keynote。
但 Werner 不会离亚马逊，也不会退休。他只是觉得连续十四年站在这里已经够久了，亚马逊云科技有很多年轻工程师，观众应该开始听到新的声音。
而聚光灯之外，他的另一种生活也已经开始很久了。 同一年夏天，在日内瓦，联合国 AI for Good Global Summit。那场演讲中，他罕见的没有从亚马逊的新产品讲起，而是先提到了那个得过图灵奖，也是他入职亚马逊前第一个打电话，现在却已经失踪十八年的朋友。
Jim Gray。
2007 年 1 月 28 日，Gray 独自驾驶 40 英尺长的帆船，从旧金山驶向法拉隆岛，此后再也没有回来。
Gray 走过这条航线很多次。天气没有明显异常，船也没有发出求救信号。直到晚上船没有回来，家人最先发现了异常，于是美国海岸警卫队开始搜索，飞机和船只扫过超过 13 万平方英里的太平洋，没有发现 Gray、救生筏，甚至没有一块可以确认来自那艘船的残骸。
正式搜救逐渐停止以后，Gray 的朋友们接棒继续寻找。
那是一个几乎可以调动当时科技界和科学界最强资源的朋友圈。商业卫星重新安排拍摄，NASA 飞机飞过搜索区域，海洋学家计算水流和漂移，微软、甲骨文、亚马逊、谷歌的人一起想办法。
卫星把大片太平洋拍了下来，新的困难随之出现：数据太多。云层、浪花、航迹和船影混在巨幅图像里，当时的算法并不擅长从里面可靠地认出一艘帆船。
Werner 想到了 Mechanical Turk。这是亚马逊 2005 年推出的一套众包平台，可以把计算机不擅长、但人眼很容易完成的小任务分给大量在线用户。Gray 搜救时，DigitalGlobe 的卫星图像被切成一块块小图，存进 S3，再送到 Mechanical Turk，让志愿者逐张寻找 Tenacious。只是：在卫星照片上，Gray 的船可能只有六个像素大小。第一批影像传到亚马逊时，画面一度全部显示成黑色。团队浪费了几个关键小时，才发现不是卫星出了问题，而是自己没有正确处理影像的 bit。Werner 后来回忆这件事，没有给自己找什么技术借口：「That was our own ignorance.」
最终，超过 1.2 万名志愿者加入，检查了 56 万组影像。搜索第八天，他们已经看过大约 3 万平方英里的海面，筛出二十多张疑似图片，其中一张被专家判断为「高度可能」是 Gary 的船的残骸。等飞机能够重新前往那个坐标，天气和海流已经过去几天。
那里什么也没有，他们最终没有找到 Gray。
讲完这个朋友，他话题一转，又讲起了三年后 2010 年的海地地震。
寻找 Gray 时，一个人的失踪足以调动卫星、飞机、政府资源和整个技术圈的人脉；海地地震以后，Port-au-Prince 有成千上万的人等待救援，国际救援人员手里甚至有 GPS，却没有一张足够可靠的地图告诉他们道路在哪里，医院和避难所在哪里，某个具体社区应该从哪里进去。
志愿者随后开始根据卫星影像补图。他们使用的是 OpenStreetMap，一套由全球社区共同维护的开放地图。道路、医院、营地和受损区域被一点点补进去，很快，这张地图开始直接进入联合国和其他救援机构的实际工作。
Werner 在那场演讲里把这种差距称作「data divide」。有些地方的数据多到需要讨论怎样分析。有些地方，人得先被数据看见。
这并不是他为了联合国的一次演讲临时找到的题目。早在 2018 年，Werner 就开始把摄像团队带到亚马逊云科技客户真正工作的地方，拍了一档叫《Now Go Build》的纪录片。他想知道这些人是怎样用同一批技术解决农业、医疗、灾害、教育和难民问题，想去现场看看这些事情究竟怎样发生。
后来的 2020 年，节目组还去了菲律宾 Guagua。镜头里的 Werner 一身黑衣，踩着棕色皮靴，快两米的个子走在一条狭窄街道上，身后追着十几个笑个不停的孩子。冰淇淋车出现以后，孩子们围过去拿冰淇淋，他坐下来，在路边一张简单的牌桌旁和 Humanitarian Open Street Map Team 的人聊聊当地的火山、洪水和灾害地图。Guagua 的问题和海地没有那么极端， 逻辑却高度相似：地图上少一条路、一个社区，灾难发生时，救援系统就少知道一些人在哪里。
于是，聊了没多久，Werner 就开始朝着代码细节方向追问，然后思考技术可以帮到他们什么，自己与团队又能做些什么。这也是《Now Go Build》里很常见的时刻，他去拜访不同的客户，最后总会追问技术到底怎样落地，以及如何在这个不断变化的时代中，帮到更多的人。
而这，也是他后来退出 re:Invent 舞台，但仍作为亚马逊 CTO 时，一直在坚持的事情。
05
尾声
其实在进入亚马逊以前，Werner 最早工作的地方不是大学，也不是科技公司，而是荷兰癌症研究所的放射科。
那里有一位叫 Frank 的同事，经常跟他说，他的能力也许更适合去做一种能够 「help people at scale」 的技术。
很难说一个人后续四十多年的人生，会被年轻时听到的一句话提前写好。但回头看，Werner 后来确实一直在和「scale」打交道，只是这个词指向的东西不断变化。最早是在康奈尔，研究一套系统怎样容纳更多机器和故障；到了亚马逊，是数据库怎样扛住越来越多的订单；再往后，S3、EC2、Lambda 把原本只有亚马逊这种规模的公司才有能力解决的问题，一层层做成其他开发者可以直接拿来使用的基础设施。再到《Now Go Build》，关注的话题从一家商业公司的理念，提升到了人类的命运共同体。
这也是为什么，Werner 总在拥抱新变化，很少需要替过去的自己辩护。 他这一代基础设施工程师真正熟悉的，并不是如何守住一个答案，而是怎样判断一个曾经正确的答案，什么时候已经开始妨碍后来的人。
二十多年前，他第一次走进亚马逊，工程师还在为数据库宕机、服务器、存储和扩容这些最底层的问题彻夜工作。二十多年以后，站在他们的肩膀上，一个年轻开发者想做一个产品，已经不太需要从采购服务器、规划磁盘、搭存储系统开始；很多二十年前必须由工程团队亲自解决的问题，已经退进 API 后面。它们并没有消失，只是有人提前把这一层做完了。
当然，他们还会遇到新的问题，但 Werner 他们带来的，不只是一代基础设施，更是一代人如何拥抱变化的经验与信念。
一个好消息是，今年 10 月带着对 2026 年最新技术趋势的洞察，一代技术教父 Werner，要来中国了！
10 月 13 日，他还会来到在深圳举办的亚马逊云科技软件企业峰会期间的「创业加速营巅峰路演——通往 re:Invent」现场，围观精选 AI Native Startup 现场路演角逐 re:Invent 全球入场券。在与极客公园创始人张鹏带来的 炉边对话的同时，他还会提供与开发者们的现场面对面交流机会。 无论你是焦虑 AI 时代程序员应该如何转型，还是关心借助云的力量，这一代创业者应该如何加速奔跑，他的经验，或许都可以为你带来一些启发。
除此之外，活动现场，还会有 600+全球软件业务与技术领袖、100 家全球软件卖家现场展示，主办方还将提供 1 对 1 精准买卖双方对接……帮助创业者把创业路上最需要的资源一网打尽。
当前，活动已正式开启招募，感兴趣的朋友欢迎报名参与 。
*头图来源： 亚马逊云科技
本文为极客公园原创文章，转载请联系极客君微信 geekparkGO
读报 ›
