大家好，今天和在座的各位分享一些失敗的經(jīng)驗教訓(xùn)。聊一聊這一類的話題要比那些成功案例更有意思。行業(yè)在進(jìn)步，我們可以從過去的錯誤中吸取經(jīng)驗，并主動在未來的計劃中避免，這一點很令人鼓舞。

背景信息

在開始之前，先介紹一下我在谷歌的經(jīng)歷。2003 年大學(xué)畢業(yè)后我直接加入了谷歌，在這之前我是一個音樂營地的營地顧問，營地顧問之前我在一家冰激凌店工作。我還記得在谷歌的第一天，第一個項目的技術(shù)負(fù)責(zé)人是 Andrew Fights，他現(xiàn)在是類似谷歌杰出的工程師的角色，我記得當(dāng)時告訴他，我得去找人聊一聊因為實在不知道我在做什么，今天想起來還是很有趣的事情。在谷歌里我像海綿一樣快速的吸收技術(shù)和其他的信息。今天我在這里談?wù)摰囊恍┦虑槠鋵嵰缬谖以诠雀璧臅r間，大約 2000 年和 2001 年左右。讓我們從微服務(wù)，即谷歌的微服務(wù)版本開始講起。

當(dāng)時，谷歌的業(yè)務(wù)仍然押注在 GSA（谷歌搜索服務(wù)器）產(chǎn)品，其實最終 GSA 也并沒有像想象中的那么順利。當(dāng)然了，其它事情也是這樣，畢竟不能將一個虛擬的壟斷產(chǎn)品與像廣告這樣數(shù)十億美元的巨額業(yè)務(wù)相對比。不過，谷歌最開始是以搜索起家的，并專注在解決這一類的技術(shù)問題。

接下來要討論的很多內(nèi)容的原始驅(qū)動力來自于這張幻燈片。在經(jīng)濟危機之前，很多企業(yè)都將他們的基礎(chǔ)設(shè)施構(gòu)建在 Sun Microsystems 的硬件之上，并將 Solaris 作為操作系統(tǒng)。如果不考慮成本的話，這一套解決方案比現(xiàn)有的其它東西都要好，很多人買了很多這種 Sun box 也是基于這樣的原因。但 Sun box 真的很貴，尤其是一個擁有龐大數(shù)據(jù)中心的企業(yè)，整個數(shù)據(jù)中心需要填滿這種機箱以支撐業(yè)務(wù)的發(fā)展，成本就會影響到其業(yè)務(wù)渠道和活下去的底線。

谷歌當(dāng)時就處在這樣一個狀況。當(dāng)時的人會很自然的說：“Linux 雖然不夠完美，不過功能也夠用，它的硬件又很便宜，所以平衡下來我們可以選擇 Linux 作為替代”。一定程度上，我也認(rèn)同這些過往的事情是真實的，當(dāng)時的人們成本意識很強，所以他們會不遺余力的去解決一系列 RAM、芯片等 Linux 出現(xiàn)的一切故障，以降低成本。而這就帶來了一個結(jié)果 – 即 Linux 真的不可靠，特別是使用垃圾站硬件的時候，且問題很嚴(yán)重。我認(rèn)為，谷歌從 Compaq DEC 并購中受益匪淺，這也是導(dǎo)致 90 年代一些真正令人難以置信的研究實驗室死亡的原因。許多人比如 Jeff Dean 和 Sanjay Kumar 都來自那個世界，他們現(xiàn)在幾乎都是質(zhì)量工程師。當(dāng)時的他們對如何在那些難以令人置信的不可靠硬件之上構(gòu)建軟件這個問題產(chǎn)生了強大的興趣，后面發(fā)生的事情也是很多接下來要分享的內(nèi)容。

然而在 2001 年并沒有什么可以替代的方案，所以必須自己做。另一個問題是非常古怪的擴展要求。他們試圖做一些當(dāng)時非常大膽的事情，即索引每個網(wǎng)頁的每個字。一些人將每個網(wǎng)頁的每個單詞收錄并編入索引，其他人只是給它建立索引，然后丟棄那些限制競爭對手能力的原始數(shù)據(jù)。這是一項艱巨的任務(wù)，需要用到當(dāng)時根本不存在的計算機軟件。

因此，由于不可靠的 Linux 盒子，該軟件必須橫向擴展，并且必須在堆棧的任何組件中容納頻繁的例行故障。之前有一篇很棒的文章提出了“機器是牛而不是寵物”。我認(rèn)為在這件事情上谷歌做對了。這些機器沒有來自“星際迷航”的酷炫名字，它們只是 AB 1,2,5,7 類似的東西，那也是機器名。系統(tǒng)對它沒有太多的依賴，它死了或者繼續(xù)運行都不會影響其它部分。這個問題讓人們開始思考如何建立更具彈性的系統(tǒng)。

以上是我如何描述事物的方式。在谷歌很多人都有博士學(xué)位。記得面試時，我還沒有博士學(xué)位。而且，我只跟一個沒有博士學(xué)位的人談過，面試結(jié)束時，他說，“別擔(dān)心，現(xiàn)在開始雇用沒有博士學(xué)位的人了”，在那里有很多人比我更聰明，并且真的想將他們的知識應(yīng)用到 CS 系統(tǒng)研究中，將這種類型的經(jīng)驗和知識應(yīng)用于現(xiàn)實問題是一件很有趣的事情。

我認(rèn)為構(gòu)建微服務(wù)的唯一充分理由是組織結(jié)構(gòu)，并且這也應(yīng)該是大多數(shù)組織構(gòu)建微服務(wù)的唯一原因。然而，這并不是谷歌構(gòu)建微服務(wù)的原因。谷歌構(gòu)建微服務(wù)是為了計算機科學(xué)，在這里，我不會去爭辯從這個角度構(gòu)建微服務(wù)其實也沒有什么好處，當(dāng)然肯定是有很多痛點驅(qū)動。

開始構(gòu)建微服務(wù)之后，如果簡單的認(rèn)為它一定會很順利，也沒有事先調(diào)研所有可能的失敗情況，那么一定不會順利，而且實際上也可能會帶來很多令人遺憾的結(jié)果。我和很多企業(yè)討論過這個問題，這些企業(yè)也因為遷移的過程實在太痛苦了而放棄了向微服務(wù)的遷移。所以，一定要事先了解構(gòu)建微服務(wù)的動因。就像谷歌里有很多人效仿大型的基礎(chǔ)設(shè)施項目一樣，有時我認(rèn)為他們在構(gòu)建一些并不必須的架構(gòu)。理智的投資方式應(yīng)該是遵循以下原則：“如果你不需要就不要去做，否則只會會讓事情變得更困難”。

這樣做的主要原因是最大限度地減少團隊之間的人員溝通成本，一個超過 10 個或 12 個人的團隊無法在一個工程項目上成功協(xié)作，它與人員溝通結(jié)構(gòu)和工作授權(quán)有很大關(guān)系。因此，將項目團隊映射到微服務(wù)可以減少人與人之間的溝通開銷，從而提高開發(fā)速度。這是一個選擇微服務(wù)的合理原因，但這也并不是我們在谷歌構(gòu)建微服務(wù)的原因。

我認(rèn)為可觀察性包括兩件事，一個是檢測關(guān)鍵信號，即 SLI 的部分，它需要非常精確；另一個則是改進(jìn)搜索空間。每增加一個微服務(wù)，可能發(fā)生的故障模式的數(shù)量隨著服務(wù)數(shù)量的增長而幾何式增長。我并不認(rèn)為機器學(xué)習(xí)或 AI 可以神奇地解決這個問題。我們需要盡快發(fā)現(xiàn)可以幫助減少人腦假設(shè)的方法，只有在使用巨型儀表板之外的技術(shù)時才能實現(xiàn)引導(dǎo)過程。巨型儀表板在單體環(huán)境中運行良好，但我看到人們采用這種理念并圍繞它構(gòu)建微服務(wù)的可觀察性。我認(rèn)為有必要使用儀表板，但肯定不夠。我采訪過的 SRE 小組當(dāng)時正在構(gòu)建巨大的儀表板，我們的效率明顯低于讓它設(shè)計上更緊湊的團隊，之后再使用其他工具來改進(jìn)搜索空間。所以，不要混淆搜索空間的可視化和對它的精煉優(yōu)化。整個搜索空間太大了且無法可視化，而且人類迄今也無法處理那么多信息。

在 LightStep，我們看到很多客戶一直在努力解決這類問題。我不知道在座的各位是否經(jīng)歷過同樣的情況，但我認(rèn)為這是一種失敗模式，谷歌肯定也明白這一點。曾經(jīng)有一個大型的 Google 服務(wù)，大概名字是家庭類型之類的服務(wù)，它不得不使用代碼生成器生成告警配置，最終導(dǎo)致了 35,000 行還要長的代碼。我不記得其中的所有原因。但隨后他們不得不開始手動維護這 35,000 行代碼，然而這些配置是在 Google 內(nèi)部完全模糊的 DSL 中編寫的，手動維護所帶來的痛苦程度無法比擬，這就是因為他們混淆了對 SLI 的告警信息和可能是根本原因的告警信息。監(jiān)控不應(yīng)該對根本原因發(fā)出告警，它應(yīng)該是細(xì)化過程的一部分；而應(yīng)該對 SLI 發(fā)出告警，對于任何特定系統(tǒng)，SLI 的信息不會有那么多而導(dǎo)致無法處理。