二〇〇四年的圣诞季，亚马逊正在度过创立十年来最好的一个年末。
感恩节过后，消费电子第一次超过图书，成为这家网站最大的品类。整个假日季最忙的一天，全球订单超过二百八十万件。平均每秒三十二件。十年前那家靠卖书起家的互联网公司，已经露出了后来那个商业帝国的轮廓。
撑起这个帝国的数据库，来自当时企业数据库领域里最成熟的玩家甲骨文。
然后，十二月十二日，其中一套彻底崩溃。
一个只在极端规模下才会出现的缺陷，偏偏赶上了圣诞购物季最关键的节点。数据库停摆十二个小时。损失不断扩大。事情很快越过普通的技术支持，一路捅到甲骨文高层。从工程师到高管，一大批人紧急飞往西雅图。
那时，距离后来长期担任亚马逊 CTO 的这位荷兰人入职，还不到三个月。
排查一圈之后，问题浮出水面。当时业内通常不区分简单访问和复杂关系查询，两类操作被挤在同一种数据库里。可亚马逊的整体业务规模，早就超过了绝大多数数据库产品的默认边界。大量按 key 取 value 的简单操作，占掉了本该留给复杂查询的资源。
这个发现，成了亚马逊自研数据库的起点。
几年后，九名亚马逊工程师发表了一篇论文，沃纳是其中之一。论文叫《Dynamo：亚马逊的高可用键值存储》。它影响了后来一整代非关系型数据库，也是亚马逊云科技的技术前史。
亚马逊科学官网上的 Dynamo 论文页面
规模变了，时代就变了。过去那些再自然不过的技术前提，也会跟着失效。
这样的变化，沃纳在此后二十年里还会遇上很多次。
一家网上书店，和一个康奈尔学者
其实就在那场宕机的几个月前，沃纳对亚马逊技术栈的判断还不是这样。
沃纳·沃格尔斯（Werner Vogels）
那时，他已经在康奈尔大学做了十几年高可靠分布式系统研究。研究的东西很具体。大型系统怎样传播信息，怎样做冗余备份，又怎样恢复。
这类研究让他经常收到去大公司做咨询分享的邀约。名单里有微软，有太阳微系统，也有老牌小型机巨头 DEC。
亚马逊找上门的时候，他一度觉得，一家网上书店，网页后面接一个数据库，能有多难。
二十多年后他重新讲起这件事，自己都觉得好笑。
真正进去以后，他看到的是另一回事。那套系统几乎把分布式系统教材里的每个问题都推到了极端。原本在论文和实验系统里研究的规模，变成了订单，变成了客户，变成了凌晨响起来的报警。
再往后，贝索斯发出了入职邀请。做决定之前，他先把电话打给了一个好朋友，吉姆·格雷。
吉姆·格雷（Jim Gray）
格雷是一九九八年图灵奖得主，也是现代数据库事务处理的奠基者之一。
在沃纳的描述里，这个人只听三十秒机器磁盘的响动，就能判断数据库布局有没有问题。沃纳遇到研究和职业上的困惑，第一个想打电话讨论的人就是他。他还是沃纳长期的朋友和导师。
在格雷的建议下，沃纳接受了亚马逊的邀请。
两年后，也就是二〇〇六年春天，格雷来到西雅图，和沃纳又见了一次面。这场谈话后来成了一篇长篇对谈。杂志编辑部写的开篇导语，仍然从那个人人熟悉的说法讲起，一家极其成功的网上书店。
沃纳在对谈里专门纠正了这一点。
「首先，亚马逊是一家技术公司。」
《ACM Queue》上那场对谈的标题
那时的亚马逊，正处在身份转换的关键节点。
对内，早期那个巨大的单体应用已经被增长不断拆开。共享数据库和团队之间的依赖越来越复杂。每项业务开始有自己的服务，有自己的接口，也有自己的数据和部署节奏。
对外，后来改写整个软件产业的亚马逊云科技，此时刚刚露出轮廓。
格雷顺着话题问到了组织。系统拆开以后，如果开发团队只负责写代码，再交给另一支运维团队运行，很多问题并没有消失。写代码的人仍然可以不知道，自己的设计进了生产环境会发生什么。真正面对故障的人，又未必知道代码为什么写成这样。
沃纳的回答是，谁构建，谁运行。
写服务的团队也负责运行它。容量不够，延迟上升，半夜报警找的还是这群人。客户真的遇到问题，也不会因为一句「代码已经交付」就变成另一支团队的事。
对谈里关于服务模型的那段原话
随着业务规模越来越大，一些通用的经验和组件被沉淀了下来。
可这些问题并不只属于亚马逊。越来越多公司开始在互联网上搭自己的产品时，仍然要从服务器，存储和数据库重新起步。
亚马逊想做的，是通过云把这件事的默认起点改掉。
后来，云把服务器变成了一种随取随用的资源。做一款 AI工具 的门槛，也从一间机房降到了一个人。这一点，二十年前谁也想不到。
从 CTO 到教父
二〇一四年十一月，又一批极客从全球各地飞往拉斯维加斯。
那一年的 re:Invent 期间，超过一万三千名开发者、架构师和创业者挤进城里的酒店与会展中心。四百名演讲人、二百五十多场分论坛从早到晚排满日程。
有人来听数据库和分布式系统。有人排队参加刚发布的产品 workshop。还有人干脆守着 keynote，等云科技再宣布一个新东西。最好是那种能改掉自己明年架构的东西。
2014 年的 re:Invent 现场
此时距离亚马逊云科技发布 S3 已经过去整整八年。
这八年里，S3 把存储变成了接口。EC2 让计算资源变成随时可以取用的弹性资源。数据库和消息，还有数据处理这些基础能力，也陆续成了云的一部分。
对越来越多公司来说，做一个产品的起点变了。从「先准备多少台服务器」，变成了「云上有哪些积木可以直接用」。
这套思路，和今天开发者装一个技能插件 就能拿到一项能力，其实同源。区别只是，那时候还没有人给这些积木起这样的名字。
站在 keynote 中央的沃纳，身份也变了。他曾经是那个差点对「网上书店」失去兴趣的康奈尔学者。现在，他是云计算时代开发者最熟悉的面孔之一。
将近两米的个子，牛仔裤，还有每年一件不同的乐队 T 恤。这些都成了 re:Invent 后来延续多年的固定节目。
那一年，他在台上发布了 Lambda。
Lambda 发布时的产品介绍
但 Lambda 最初展示的需求，小得几乎看不出日后会成为基础设施。
发布它的理由很具体。过去，客户只想在一个事件出现时运行一小段代码。比如图片进入 S3 以后生成缩略图。可他要为此提前创建实例，部署程序，再配置扩缩容。服务器就在那里守着，等一个不知道什么时候才会发生的事件。
Lambda 允许开发者直接提交代码。事件发生，代码运行。需要多少机器，什么时候扩容，哪台机器坏了怎么替换，都由云来管。
从这时候开始，那句「谁构建，谁运行」的边界被逐渐拓宽。
开发者不必再关心服务器在第几个机架。流量突增时要多出多少机器，不用他算。底层硬件什么时候会失效，也不用他盯。这些今天 AI编程 里的常识，在那之前，都是每个团队必须自己掌握的底层能力。
变化永恒
整个科技圈里，要说拥抱变化最积极，也最善于自我否定、自我迭代的大佬，沃纳必定榜上有名。
二〇二一年三月十四日，S3 十五岁。
二〇〇六年刚上线时，它只有几个非常简单的接口。到那一年，它已经存着超过一百万亿个对象，峰值每秒处理数千万次请求。
亚马逊云科技给它办了一场相当隆重的生日会。连续四天，每天四个小时，在直播里公开「打脸」。沃纳把当年参与这套系统演化的几位同事重新请了回来。他们挨个细数，每个产品当年为什么这么设计，后来又改过什么。
直播第二天讲到的 S3 一致性故事，一个月后被沃纳写进了博客。
故事里，他提到了云科技最早的大客户 Netflix。
二〇〇八年，一次严重的数据库损坏让 Netflix 三天没法向用户寄送 DVD。这件事直接推动它开始离开自己的数据中心。之后七年，Netflix 基于云完整重建了整套技术系统。到二〇一六年，流媒体业务的最后一批自有数据中心也关了。大量计算和存储搬到了云上。大数据处理和分析也是。
早在二〇一四年，Netflix 的工程师就把 S3 称作自己数仓的「唯一事实来源」。数据可以长期放在 S3。Hadoop 集群在需要时动态创建，也能随时销毁。不同计算任务围绕同一份数据工作。
但这种用法，也把 S3 的一个老问题放大了。
早期的 S3 提供的是最终一致性。一次写入返回成功以后，数据本身已经被可靠保存。可它并不保证所有读取路径在同一时刻都能看到最新状态。对存图片和视频来说，这个很短的时间窗口未必有影响。
可在数据流水线里就不一样了。一个节点刚写完一批文件，下一个节点立刻开始计算。少看到几份，拿到的就是一份不完整的输入。
Netflix 的实际行动告诉亚马逊云科技，这套取舍已经过时了。
后来，Netflix 在 S3 旁边又造了一套系统。它用 DynamoDB 维护一份额外且一致的元数据索引。当应用怀疑 S3 返回的结果可能不完整时，再用它去核对。
Netflix 开源的 s3mper 项目
于是出现了一个荒诞的现实。Netflix 使用 S3，本来就是为了不用自己维护一整套存储基础设施。现在为了弥补 S3 的一致性，又在旁边多维护了一套基础设施。
察觉到不对的沃纳，再次选择推翻自己，重构 S3 的一致性模型。写入成功以后，随后的读取和列表操作都能立即看到最新状态。对新旧对象都适用，也没有额外的性能和成本代价。
好在，他对这种变化并不陌生。
早在二〇一六年亚马逊云科技十周年时，他总结过去十年做大型系统的经验，第一条就是构建可演化的系统。
在他看来，一个系统每跨过一两个数量级，都应该重新检查一次架构。过去做对的选择，不代表面对新的规模和工作负载时仍然该保持不动。系统的任务不是证明设计者当年是对的，而是继续解决今天的问题。
沃纳离场，沃纳回来
二〇二五年十二月，沃纳第十四次站上 re:Invent 的闭幕演讲。
沃纳最后一场 keynote 现场的那句标语
这些年，观众已经习惯了三件事。先猜他的乐队 T 恤，再看那些相当前卫的开场短片。最后听这个荷兰人用一个多小时，讲架构，讲开发者，讲下一轮技术变化。
那一天他上台不久，就告诉台下，这是自己的最后一场 keynote。
但他不会离开亚马逊，也不会退休。他只是觉得连续十四年站在这里已经够久了。云科技有很多年轻工程师，观众应该开始听到新的声音。
聚光灯之外，他的另一种生活已经开始了很久。
同一年夏天，日内瓦，联合国 AI for Good 全球峰会。他罕见地没有从新产品讲起，而是先提到了一位朋友。那个人得过图灵奖，也是他入职亚马逊前第一个接到他电话的人。
吉姆·格雷。
二〇〇七年一月二十八日，格雷独自驾驶一艘四十英尺长的帆船，从旧金山驶向法拉隆岛。此后再也没有回来。
那条航线他走过很多次。天气没有明显异常，船也没有发出求救信号。直到晚上船没回来，家人才发现异常。
美国海岸警卫队开始搜索，飞机和船只扫过超过十三万平方英里的太平洋。没有发现格雷，没有救生筏，甚至没有一块可以确认来自那艘船的残骸。
正式搜救停止以后，格雷的朋友们接棒继续寻找。
那是一个几乎能调动当时科技界和科学界最强资源的朋友圈。商业卫星重新安排拍摄，NASA 的飞机飞过搜索区域，海洋学家计算水流和漂移。微软和甲骨文，亚马逊和谷歌，几家公司的人一起想办法。
卫星把大片太平洋拍了下来，新的困难随之出现。数据太多了。云层和浪花，航迹和船影，混在巨幅图像里。当时的算法并不擅长从里面可靠地认出一艘帆船。
沃纳想到了 Mechanical Turk。这是亚马逊二〇〇五年推出的一套众包平台。计算机不擅长、人眼却很容易完成的小任务，都可以分给大量在线用户。
搜救时，卫星图像被切成一块块小图，存进 S3，再送到平台上。志愿者逐张寻找一艘叫 Tenacious 的船。
只是，在卫星照片上，格雷的船可能只有六个像素大小。
第一批影像传到亚马逊时，画面一度全部显示成黑色。团队浪费了几个关键小时，才发现不是卫星出了问题，而是自己没有正确处理影像的位深。
沃纳后来回忆这件事，没有给自己找技术借口。他说，那是我们自己的无知。
亚马逊 Mechanical Turk 官网
最终，超过一万二千名志愿者加入，检查了五十六万组影像。搜索第八天，他们已经看过大约三万平方英里的海面，筛出二十多张疑似图片。其中一张被专家判断为高度可能是那艘船的残骸。可等飞机能够重新前往那个坐标，天气和海流已经过去几天。
那里什么也没有。
他们最终没有找到格雷。
讲完这位朋友，他话题一转，讲起了三年后二〇一〇年的海地地震。
寻找格雷时，一个人的失踪就足以调动卫星和飞机，还有政府资源和整个技术圈的人脉。
海地地震以后，太子港有成千上万的人等待救援。国际救援人员手里甚至有 GPS。可他们拿不到一张足够可靠的地图。道路在哪里，医院和避难所在哪里，某个具体的社区该从哪里进去，没有人说得清。
志愿者随后开始根据卫星影像补图。他们用的是 OpenStreetMap，一套由全球社区共同维护的开放地图。道路和医院，营地和受损区域，被一点点补进去。很快，这张地图开始直接进入联合国和其他救援机构的实际工作。
沃纳在那场演讲里，把这种差距称作数据鸿沟。有些地方的数据多到需要讨论怎么分析。有些地方，人得先被数据看见。
这并不是他为了联合国的一次演讲临时找的题目。
早在二〇一八年，他就开始把摄像团队带到客户真正工作的地方，拍了一档纪录片。片子叫《Now Go Build》。他想知道，这些人是怎样用同一批技术解决农业和医疗，处理灾害和教育，以及难民问题。
《Now Go Build》的剧集列表
二〇二〇年，节目组去了菲律宾的瓜瓜。
镜头里的沃纳一身黑衣，踩着棕色皮靴。将近两米的个子走在一条狭窄街道上，身后追着十几个笑个不停的孩子。冰淇淋车出现以后，孩子们围过去拿冰淇淋。他坐下来，在路边一张简单的牌桌旁，和当地做灾害地图的团队聊火山、洪水和撤离路线。
瓜瓜的问题没有海地那么极端，逻辑却高度相似。地图上少一条路，少一个社区，灾难发生时，救援系统就少知道一些人在哪里。
聊了没多久，他就开始往代码细节的方向追问，然后思考技术能帮到什么，自己和团队又能做些什么。
这也是《Now Go Build》里很常见的时刻。他去拜访不同的客户，最后总会追问技术到底怎样落地，以及在这个不断变化的时代里，怎样帮到更多的人。
尾声
其实在进入亚马逊以前，沃纳最早工作的地方不是大学，也不是科技公司，而是荷兰癌症研究所的放射科。
那里有一位叫弗兰克的同事，经常跟他说，你的能力也许更适合去做一种能够大规模地帮助人的技术。
很难说一个人后续四十多年的人生，会被年轻时听到的一句话提前写好。
但回头看，沃纳后来确实一直在和「规模」打交道，只是这个词指向的东西不断变化。
最早在康奈尔，研究的是一套系统怎样容纳更多机器和故障。到了亚马逊，是数据库怎样扛住越来越多的订单。再往后，S3、EC2 和 Lambda 依次登场。它们把一批老大难问题，一层层做成了其他开发者可以直接取用的基础设施。那些问题，原先只有亚马逊这种规模的公司才有能力解决。
这一代人真正熟悉的，并不是如何守住一个答案。他们更擅长判断另一件事。一个曾经正确的答案，什么时候已经开始妨碍后来的人。
二十多年前，他第一次走进亚马逊，工程师还在为数据库宕机、服务器和扩容这些最底层的问题彻夜工作。
二十多年以后，一个年轻开发者想做一个产品，已经不太需要从采购服务器和规划磁盘开始。很多当年必须由工程团队亲自解决的问题，已经退到了接口后面。
它们并没有消失，只是有人提前把这一层做完了。
当然，新的问题还会出现。沃纳这一代人留下的，不只是一代基础设施，更是一代人拥抱变化的经验与信念。
