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在此后二十年还会遇到很多次。
一家网上书店，和一个康奈尔学者
就在那场宕机的几个月前，Werner对亚马逊的技术栈判断，还不是这样。那时，他已经在康奈尔做了十几年高可靠分布式系统研究。他关于大型系统怎样传播信息、如何做冗余备份与恢复的研究，让他经常收到各种去大型公司做咨询分享的邀约。微软、太阳微系统公司、数字设备公司都在名单里。
而亚马逊找上门来时，他一度觉得：一家网上书店，网页后面接一个数据库能有多难？二十多年后，他自己重新讲起这件事，仍然觉得这个判断很好笑。因为真正进入亚马逊后，他看到的是一套几乎把分布式系统教材里的每个问题都推到了极端的系统：原本在论文和实验系统里研究的系统规模，变成了订单、客户和凌晨响起来的报警。与此同时，订单、支付、推荐、供应链、机器学习，以及大量因为业务增长太快、根本找不到现成商业软件来解决的问题。
再之后，贝索斯向他发出了入职邀请。但他做出选择前，先把电话打给了好朋友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想做的，是通过亚马逊云科技改变这个默认的起点。
从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，也伴随着每年一度的分享与基础设施的演化，成为了一代人的云计算教父。
变化永恒
整个科技圈，要说拥抱变化最积极，也最善于自我否定、自我迭代的大佬们，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重构而停止。
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万名志愿者参与了这场搜索。
热门跟贴