本文简化字版由OpenCC转换

十二、现金流压力

从瑞士到美国以后，工资大减近四成。虽然这是预期之中的事情，毕竟瑞士的基本工资真的很高，而税又很低。但真正到美国看到自己收入大幅缩水以后，还是有些难以接受。刚刚搬过来的时候还有各种事情纷至沓来，让我一度情绪低落。不过几个月后我终于适应了新的环境，同时因为升职和调薪我的收入超过了之前在瑞士的收入。我在上一篇在Google的这四年（三）里面提到美国的生活给我带来的一大收获就是对资本、投资、现金流的理解，不得不说其实也是因为一开始的资金压力给我带来的。

我的资金压力有很大一部分原因其实是投资过于贪婪带来的。我是年中到美国的，但又想把一年的401k（税前和税后）、IRA、HSA这些账户全部交满，结果就是每次工资到手只有几百美元。虽然有了复式记账以后从账面上看我的净资产是在增加的，但现金流的确非常可怜，困难到信用卡难以偿还的地步，我可谓是陷入了「流动性危机」。当然我还是不会信用卡最低还款缴纳巨额利息的，因为我通过学习了解到了一个强大的金融工具：「保证金借贷（Margin loan）」。保证金借贷其实就是把自己的金融资产作为抵押，获得一笔贷款，这笔贷款的利率通常非常低，甚至低于政府隐性担保的房贷。我印象中在2016年我付出的年化利率在2.5%左右。这个方法对我来说非常实用，因为我有股票、基金这样高流动性的产品，虽然迫不得已我可以变现，但有了保证金借贷以后我并不需要变现了。在美国如果有账面盈利变现是要缴资本利得税的。保证金借贷本质上和提高投资杠杆是一样的，只要我借得不太多（杠杆不太高），市场波动风险就不会影响到我。

十三、搜索基础架构

我继续参与了Google搜索的项目，但是从前端转到了后端。所谓Google搜索的前端，简而言之指的是用户查询时在线即时计算的部分。这包括关键字的语意理解、信息检索、排名算法等等。后端则是离线的部分，指的是网址发现、页面抓取、索引建立等这些不在用户查询时即时计算的工作。这个划分非常粗略，也不准确，Google的真实搜索系统要复杂得多。

在Google，大规模的离线数据处理系统也可以做到低延时，我做的恰恰是其中最实时的部分——Google搜索的即时索引系统。这个系统负责为新闻、Twitter这种高频率、低延时的内容建立索引。相比之前在瑞士的时候参与的语意理解项目，这个工作偏向于系统架构的设计。Google大规模数据处理的引擎很多，绝大多数都是为海量数据高吞吐量设计的，而这个系统则对实时性的要求很高，工作内容极具挑战。因为高实时性的要求，而且对Google搜索结果影响十分关键，这个系统有专门的运维工程师（Site Reliability Engineer）团队。此外我也不得不身兼一部分运维工程师的工作，某些时候要随传随到（Oncall）。作为开发工程师我的工作的重要部分就是让这个系统尽量稳定，这样也可以减轻自己的工作量。

Google搜索对即时新闻的支持早在十多年前就开始有了。这是一个历史悠久的系统，代码经过多代演进，一环扣一环。它的学习曲线要比之前的项目（语义理解）陡峭得多，光是把系统的每个部分在干什么搞明白我就花了差不多大半年。

在这个项目的两年里，我的工作可以分两类，一类是维护现有的系统和在现有系统上开发新功能，另一类是开发下一代的系统取代现有系统。Google的许多重要项目每几年就要有一次更新换代。这样的项目还是很吸引人的，因为一旦成功不仅会有个人的成就感，还有更大的升职机会，无论是对于普通工程师还是项目的管理层。

十四、项目的风险

新项目是有风险的，因为成熟的项目通常都有巨大的技术负债，而且又十分重要，新的系统必须在各个方面都要比原来更好才能说服决策层下决心取代旧的系统。这其实对决策层来说也是一个长远利益和短期利益平衡的问题。Google搜索的任何大改动都有可能会给这个市值几千亿美元的公司带来重大风险，对短期来说可能又好处有限。而长期来看项目都是有生命周期的，随着「老化」会让开发越来越困难，陷入停滞，所以必须再适当的时候引入新的系统。新项目失败的风险总是存在的，可能来自技术难关——新的系统并没有比旧的更好；可能来自利益冲突——新的系统使某些团队的利益遭到损害；可能来自资源的投入——决策层可能会在某个时候改变人选或者改变注意，撤回对项目的支持。这些原因都会导致项目的流产，但对于基层的工程师来说基本上是不可控的。

技术原因的失败并不罕见，因为Google前人开发的系统已经在各个方面都很优异了，可能只是使用的技术栈比较旧而已。新的技术栈并不一定就比旧的更好。要证明新的系统比旧的在某关键方面要好很多，而且其他各个方面也都不能差，是一件很难的事情。如果不可能，就要退而求其次，证明新的系统「利大于弊」。这就更难了，什么是利什么是弊，对谁来说是利还是弊，都是需要考虑的问题。

好在目前看了这个机制还是在运转的。在升职及个人成就感的激励之下，Google的各种系统一直在不断迭代更新，始终引领技术发展，或者至少保持在前沿。这样的激励同时有一个副作用，即很难有十分稳定的系统。Google内外都有很多批评的声音，声讨Google「随意」关停项目，令用户失望。系统的不断更新甚至关停对于公司内部的下游使用者来说也是个痛苦的难题。有人这么总结「Google的系统要么是没有文档（快速开发中），要么是已经废弃了」。历史悠久的产品面临的一个重大挑战是它们依赖的子系统不时就会有通知说即将关闭，必须要在某个截止日期前迁移到新的系统。这样的通知意味着凭空出现的额外工作，而完成这样的工作吃力不讨好，没法说明自己工作的影响力。反过来说，上游系统开发者必须考虑新系统给下游带来的迁移成本。如果这个成本过高，又无法提供足够的技术支持，必然会有来自下游团队的激烈反对。这种情况就可能会带来所谓的「利益冲突」。

我在这个项目的两年可以说是很幸运的。因为一方面我的工作让Google搜索成功应对了AMP的爆发式增长，另一方面我们还成功发布了新系统，完整取代了运行十多年的老古董。在这个项目中，我除了积累了个人经验，还锻炼了重要的协作能力。如前文所述新项目会带来团队之间的利益冲突，这个项目也不例外。慢慢地我发现工程师的协作能力的很大程度上决定了一个人的高度，这是一个老生常谈的问题，但只有自己体会过才能理解为什么。个人技术能力呢？那当然更重要了，否则一切都是浮云。

十五、路径依赖

我大概是在2017年10月决定离开美国的，这回目的地是日本。这个决定可以说比离开瑞士更疯狂，更难被人理解。其实我自己也更难下决心，因为我离开那个团队可能并非当下职业发展的最佳打算。与此同时我还要再次面临收入的削减，会比上次从瑞士到美国幅度更大，即便是再次晋升也无法抹平的差距。最终，出于对不同的文化探索的热情以及一点冒险的基因，我下定了决心。

我是这么说服自己的，我毕竟当时才毕业工作三年而已，未来有无限可能，这些可能性要趁早尝试。许多顺风顺水的人在某个时候都会陷入路径依赖——尽管每个局部选择可能都是最优的，但最终归于普通。这就像贪心算法的问题——取决于初值，沿着梯度优化最终只能得到局部最优解。这相当于最终能达到的高度在一开始就被决定了。

破解这种局面的算法之一是模拟退火。模拟退火算法的理念是在初期引入随机性，随着迭代次数的增加而减小随机因子，这样最终收敛到全局最优解的机率更大。跟随这个理念来考虑职业的选择，我决定跳出现有的路径，哪怕是这个路径的前方一片光明，现在只是为了体验不同的选择。

以上是模拟退火算法寻求全局最值，图片来自维基百科。

下一篇：在Google的这四年（五）

上次修改时间 2019-04-09