在Google的這四年(四)

十二、現金流壓力

從瑞士到美國以後,工資大減近四成。雖然這是預期之中的事情,畢竟瑞士的基本工資真的很高,而稅又很低。但真正到美國看到自己收入大幅縮水以後,還是有些難以接受。剛剛搬過來的時候還有各種事情紛至沓來,讓我一度情緒低落。不過幾個月後我終於適應了新的環境,同時因爲升職和調薪我的收入超過了之前在瑞士的收入。我在上一篇在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的這四年」系列文章

相關日誌