在硅谷的历史上，你可能再也找不到第二个像他这样的人。
他没有住在公司附近，没有加班到凌晨三点，甚至不常出现在办公室。
相反，他每周二都要坐飞机，横跨加州的天空，从洛杉矶赶到山景城的 Google 去上班。
当同事们坐在工位上，熟练地刷着 Perl、写着 C++、飞快地交付新功能时，他可能在机场排队过安检，或者在机舱里对着一台旧笔记本和一堆 Java 错误信息发呆。
就是这个在 Google 内部都自认“垫底”的人，却亲手写出了后来几乎吞噬了整个互联网的巨型印钞机： Google AdWords。
01 Google是啥？
时间倒回 1988 年，刚刚硕士毕业的罗恩（Ron Garrett）加入了 NASA 的 JPL（喷气推进实验室，钱学森是创始人之一），在自主机器人的人工智能组工作。
在 JPL 的 12 年间，他成绩斐然，一度是 NASA 所有计算机科学研究人员中被引用次数最多的，受人尊敬。但他心里总有个疙瘩：他是一个 Lisp 语言的忠实拥趸，而 NASA 的世界以嵌入式开发为主，是 C 语言的天下。
在经历了 Lisp 火星车项目失败后，罗恩有些心灰意冷。有一天，他在逛 comp.lang.* 编程语言新闻组时，注意到有个人回答了一个非常冷门的问题，最后附言道：“谢天谢地有 Google。”
这勾起了罗恩的好奇心：Google 是啥？
他在浏览器里敲入 www.google.com，发现这是个新的搜索引擎。仅仅玩了几分钟，他立刻意识到——这玩意儿比其他搜索引擎要领先好几年。
那时正值互联网泡沫顶峰，无数公司在纳斯达克上市，人们通过股票一夜暴富。而当时的 Google 还非常小，不到 100 人，刚刚从 KPCB 拿到融资。罗恩心想，这不正是加入的好时机吗？
他看到 Google 首页下方写着“我们正在招聘”，便立刻投了简历。没想到，仅仅 15 分钟后，他就接到了 Google 的面试电话。
面试很快通过，但开出的薪水比他在 JPL 的还低！不过，薪水不是重点，重点是股票期权。真正的难题是：罗恩已经在洛杉矶买房，走路即可到 JPL 上班，工作稳定，生活安逸。而 Google 总部在硅谷的山景城，距离洛杉矶五六百公里，这怎么通勤？
Google 方面见状，立刻提高了罗恩的薪酬，并提供了差旅补贴。他们还给出了一个极具诱惑力的条件：你可以先试一年，如果不行，随时可以回去。
于是，罗恩做出了改变命运的决定。
02 “垫底”的程序员
罗恩开始了“空中飞人”式的上班生活。
他凌晨 4 点起床，5 点出门，6 点赶到机场，坐飞机到圣何塞，再通过拼车或出租车去 Google 办公室。通常 10 点才能到公司，然后一直工作到深夜。
当然，他不是每天都如此奔波。他的节奏是：周二去，周四回，在 Google 待上三天两夜。在硅谷，他没有朋友、没有家人、没有宠物，生活只剩下一件事：工作。
说起工作，罗恩被分配到了广告组，任务是开发一个全新的广告系统—— AdWords。
这个系统的逻辑听起来很简单：
- 客户输入想在 Google 投放的广告。
- 广告系统在搜索结果中展示广告，并记录投放情况。
- 计费系统统计数据，从客户信用卡中扣款。
当时没有人能预料到，这个简单的模式，日后会成为 Google 历史上最大、最持久的现金牛。
当时，Java 正值鼎盛时期，AdWords 被确定用 Java 开发，而罗恩则被任命为首席工程师。颇具讽刺意味的是，Google 的经理们可能并不知道，罗恩骨子里是个“Java 黑”。他认为这门语言有个“邪恶”的目的：把程序员变成可以随意替换的标准化零件。
但既然已经上了“贼船”，这位“被迫的 Java 布道师”也只能硬着头皮往前走。用户界面决定用 JSP 编写——如果你在 2000 年代初用过它，就会明白这方式有多折磨人。
<h2>用户列表</h2>
<ul>
<%
List<String> users = (List<String>) request.getAttribute("users");
for (String user : users) {
%>
<li><%= user %></li>
<%
}
%>
</ul>
JSP 的本质就是把 HTML 和 Java 代码粗暴地混合在一个文件里。 HTML 不关心括号，Java 却极度依赖括号。一旦你漏写一个 } 或 %>，整个文件的解析都会“错位”。
在那个年代，可没有语法感知编辑器、没有智能高亮、没有括号匹配、没有自动缩进、也没有清晰的错误提示……你在文件开头犯个小错，编译器可能在几十行后报出一个让你摸不着头脑的古怪信息。
于是，这位 Lisp 专家就坐在那里，一个接一个地调试着 JSP 错误，艰难地推进项目。
更让他备受打击的是 Google 的同事。认识一些人后，罗恩被他们的聪明程度深深震撼。有时一个他觉得需要一周才能搞定的事情，别人可能只用一个小巧的 Perl 脚本，一个小时就解决了。亲眼看到那些脚本后，罗恩的下巴都快惊掉了。
在 JPL 的象牙塔里，罗恩一直是顶尖梯队的一员。而在早期人才密度极高的 Google，他觉得自己可能排在后 10%，是个“垫底”的程序员。
项目开发进度因此落后了。经理的解决办法是进行“微观管理”：要求罗恩每天列出详细的工作清单。这让他相当反感，以至于后来几乎不再和经理主动交流。
03 账单灾难与“即时满足”
经过三个月堪称煎熬的开发，AdWords 终于完成了。
上线前，罗恩遇到了一个关键问题：客户的广告要不要先审核再上线？ 按照他在 NASA 的习惯，任何关键操作发射前都必须经过严格验证，因为错误可能意味着灾难。
但 Google 创始人拉里·佩奇（Larry Page）坚持：所有审核都放到事后去做，广告提交后直接上线。
原因非常简单，甚至有些疯狂：要给客户“即时满足感”。在 2000 年左右，传统广告流程是“提交、审核、对接、排期、上线”，周期漫长。Google 要把它压缩成：“填表、刷卡、上线”。
出了错怎么办？拉里的态度是：“到时候再说。”
事后证明，拉里是对的。这种“即时满足”的模式，连同按点击付费的机制，彻底颠覆并重塑了整个在线广告行业。
AdWords 上线最初两周比较顺利。罗恩的主要工作是监控系统、修复小 Bug，以及——当一名客服，给用户回复邮件。
这就是早期创业公司的文化：人人都是多面手，什么活儿都得干，目的只有一个——解决问题。
然而，平静很快被打破。有一天，罗恩检查账单数据时，发现了一堆异常记录：计费程序竟然向一些客户收取了数十万甚至上百万美元的费用！
罗恩立刻停掉了计费程序，开始排查。这是个非常棘手的 Bug，因为系统大部分时间运行良好，只是偶尔“抽风”。起初根本找不到问题根源，他只能先重启系统，然后加入一个“合理性检查”：如果计算出的费用超过某个阈值，就自动停止并触发告警。
同时，罗恩还得继续履行“客服”职责，向受影响的客户解释、道歉并进行赔偿。
但让罗恩意外的是，即使发生了如此严重的生产事故，老板也没有斥责或辱骂他，只是说：“赶紧想办法修复。” 这种专注于解决问题而非追责的文化，给了他喘息的空间。
这样的错误又发生了好几次后，团队终于发现了规律：Bug 出在由 C++ 编写的广告服务器上。当它关闭或重启时（很可能是多线程引起的竞态条件），会向数据库写入一些随机数据，导致部分客户的广告展示量被记录为“几百万次”。
Bug 最终被修复了，但罗恩的身心也已接近极限。他感到精神崩溃，身体健康亮起红灯，与妻子的关系变得紧张，和经理更是几乎零交流。
04 最大的遗憾：在浪潮之巅转身
在持续的高压之下，罗恩开始认真反思：自己是否真的适应创业公司这种“快速行动、打破常规、出了问题再火速修复”的文化。
就在这时，两件震动世界的大事接连发生：
1. 9/11 恐怖袭击事件，彻底打乱了他依靠航空通勤的计划，空中旅行变得充满不确定性和压力。
2. 互联网泡沫彻底破裂，纳斯达克指数狂泻。虽然 Google 当时情况相对较好，但没人能保证它最终可以活下来。
身心俱疲的罗恩，动用了在 JPL 的人脉。一位高层主任非常希望他能回去，并为他争取到了一个顶级技术职位：Principal（首席工程师）。这个职位几乎相当于大学的终身教授，还附带一项令人羡慕的福利：一个带遮阳棚的专属停车位——实验室里 7000 人，只有不到 100 人能享有此待遇。
于是，在 AdWords 上线运行不久后，罗恩选择了离开如火如荼的 Google，回到了稳定而熟悉的 JPL。他负责的不再是开发，而是与搜索引擎相关的采购工作。
罗恩没有料到，这成了他职业生涯中可能最错误的抉择。他在 Google 编写的，绝非边角料代码，而是 Google 广告系统的核心算法与初始架构——这堪称人类商业史上最赚钱的一段代码之一。今天 Google 每年数千亿美元的广告收入，其基石正是当年那个从混乱中诞生的系统。
他只要留下，几乎注定会成为 AdWords 业务的早期负责人。再坚持 3 年，等到 2004 年 Google IPO，罗恩很可能就此步入亿万富翁的行列。
但在 2001 年那个时间点，未来迷雾重重，少有人能看清。
罗恩后来回忆说：
“在 Google 工作最棒的地方是，我感觉自己是历史的一部分……我从小就是电脑迷，硅谷是我梦寐以求的圣地。当我第一次置身其中，就连那疯狂的通勤也让我感到莫名的兴奋。”
“环顾四周，看到那些正在创造未来的人物，而我也曾是其中一员，这种感觉实在太棒了……”
05 后记：伟大的系统始于混乱
今天回看 Google，人们很容易被它后来建立的、近乎神话的工程体系所迷惑：完善的分布式系统、严格的代码规范、极高的人才密度、以及高度自动化的流程。
但在 AdWords 诞生的那个蛮荒年代，Google 远没有后来那么“体面”和“严谨”：
- 它从 NASA 挖来一位 Lisp 专家，却让他用他并不喜欢的 Java 去写核心系统。
- 它让工程师在最原始的编辑器里，痛苦地调试着 JSP 文件。
- 它一边高喊“工程师文化”，一边对进度落后的员工进行微观管理。
- 它允许几乎所有人拥有 root 权限，为混乱埋下种子。
- 它将文本直接“硬编码”在页面里，让后来的国际化工作困难重重。
- 它的系统充满 Bug，计费错误甚至能产生天文数字般的账单。
用今天的工程标准来衡量，AdWords 早期的开发过程几乎可以称得上是一场“灾难”！
但 Google 不仅活了下来，还迅速成长为一个前所未有的巨兽。原因并不神秘：当时代的浪潮拍岸时，Google 的创始人做对了一件最最关键的事——他们为搜索引擎找到了一个与用户体验正向耦合的商业模式，即“即时满足”的 AdWords。
剩下的，就交给了一群工程师。
这群工程师未必拥有完美的工具、清晰的流程或安稳的生活。他们在一片混沌、压力和无数个不眠之夜中，硬是把一个模糊的想法，磕磕绊绊地变成了一个能够持续运转、并最终支撑起一个帝国的系统。
历史往往并非由完美的设计蓝图所启动。更多时候，它是由勉强可用的代码、疲惫却坚持的工程师，以及一次又一次被硬撑过去的夜晚所共同推动的。
这个故事，或许能让许多在复杂系统与高压环境中挣扎的开发者们会心一笑。技术的演进充满偶然与艰辛，而这正是工程实践最真实的一面。如果你对这类充满细节的开发者故事或极客文化感兴趣，欢迎在云栈社区继续探索交流。
发表于 15 小时前
|
查看: 1|
回复: 0
