谷歌可靠性工程的“封神”之路:從大規模分散式系統高效故障響應說起

語言: CN / TW / HK
谷歌有很多工程經驗值得學習。在最近兩年參與區塊鏈儲存的研究和開發過程中,谷歌的經驗和區塊鏈的思想,這兩種相互衝突的理念在我腦海裡相互融合。

 

比如我之前分享的《谷歌可靠性工程的設計經驗》和《谷歌Colossus檔案系統的設計經驗》都是在思考區塊鏈儲存如何借鑑谷歌的經驗。

 

最近參與了Filecoin太空競賽的部分工作,對整個網路的複雜性有了新的認識和思考。整個網路在300個小時左右的時間內封裝了100PB的資料,對於一個測試網路來說,這是一個了不起的成績。

 

但應該注意到的是,依然有大量礦工沒有能力參與,並且部分參與的礦工也都出現了掉算力的情況,甚至是部分礦工叢集整體故障,退出網路。

 

前一篇文章已經談過,運維能力是Filecoin挖礦的戰略能力。近日又恰好讀到一篇谷歌的文章《Debugging Incidents in Google's Distributed Systems》,介紹了谷歌如何端到端的除錯複雜分散式系統中的故障。

 

那麼,本文就基於目前工作中的體會,分享一下從谷歌的除錯經驗中可以獲得的實用策略。

 

一、谷歌面臨的挑戰是業內少有的

 

網路上流傳的一個關於谷歌在DevOps領域,以及在自動化測試領域所面臨的挑戰:

 

  • 1.5萬程式設計師(包括開發與運維);

  • 4000個同時進行的專案;

  • 在同一個庫裡 check 所有的原始碼(數十億檔案!);

  • 5500次程式碼提交 via 1.5萬程式設計師;

  • 自動測試每天執行7500萬次;

  • 0.5%的工程師致力於開發工具;

  • 是的,你沒看錯,整個Google 只有一個程式碼倉庫。

 

這些挑戰是催生谷歌可靠性工程的重要需求來源。Filecoin的任何一個挖礦專案的複雜度,都還沒有達到谷歌的級別。其原因主要是因為區塊鏈儲存行業處於起步階段,沒有大規模應用的需求。

 

另外,谷歌還開創了SRE領域。在行業內,谷歌出版了兩本關於SRE的原則和最佳實踐的書。

 

然而,在處理生產環境中各種故障事件的緊張時刻,團隊的實際響應和除錯方法常常與理想的最佳實踐有所不同。

 

這讓我重新深度思考組織問題和流程問題。

 

二、組織的結構和動力學

 

谷歌認為,高效組織和低效組織之間存在著結構上的差異。

 

高效組織不僅在開發各種功能的技術能力方面付出巨大努力,還總是平等地關注個人、團隊和技術的協作方式,因為這些方式將對它們所屬的過程做出正向或者反向的摩擦力。

 

高效組織是過程導向,低效組織的“孤島”自治。而且在高效組織中,功能整合不僅僅是說說而已,它是每天各級管理的具體細節。

 

谷歌認為,高效組織的動力學來自不斷改進的元件和過程。無論個體還是團隊工作,無論是否有裝置,高效組織不願意接受模稜兩可,其將功能作為流程的一部分進行管理,並提前對以下內容進行詳細說明:

 

  • 預期產出;

  • 誰負責什麼工作,順序如何;

  • 產品、服務與資訊如何從上一步的負責人手上,遞交到下一步的負責人手中;

  • 完成每一部分工作的方法。

 

更為全面地,高效組織的結構和動力學可以總結為史蒂夫·斯皮爾能力模型:

 

  • 能力1:在問題發生時馬上就能發現;

  • 能力2:一旦發現問題立刻蜂群式解決(Swarming),並將此記錄下來儲備成新知識;

  • 能力3:在整個公司範圍內傳播新知識;

  • 能力4:以開發為主導。

 

高效組織善於在問題發生的時間和地點解決問題。他們同樣擅長於:

 

  • 在問題出現之前控制問題;

  • 診斷和解決問題,使問題不再發生。

 

在這樣做的過程中,高效組織建立了關於如何管理系統的深層知識,將不可避免的前期無知轉化為知識。

 

高效組織使新知識不僅對發現它的人可用,而且對整個組織都可用,從而使其力量成倍增長。而且其不僅分享發現的解決方案,還分享發現這些解決方案的過程——學習了什麼以及如何學習。

 

高效組織會控制他們的問題並傳播他們的發現,而低效組織(即他們的競爭對手)允許問題持續存在並傳播到更大的系統中,因為即使找到了解決方案,也會保留在被發現的地方。這意味著,經驗積累使高效組織具備了乘數效應。

 

我們在實際工作中,借鑑區塊鏈的思想,創新地推動開發、測試和運維之間的去中心化協作,以促進在問題出現時快速發現,然後蜂群式解決問題。去中心化溝通使得知識自然在多個團隊之間流動。在這個過程中,開發團隊起到了主導作用。

 

三、事前測量一切

 

Measure Everything:Cannot improve what we don't measure.

 

沒有測量,就沒有改進。系統越複雜,感受越深刻。事前測量一切和事後剖析免責是我秉持的兩個重要文化理念。

 

四、事後剖析免責

 

blame-free PostMortems,或稱blameless post-mortem。

 

你會發現,如果組織文化能保證事後評估的安全性,就會激發一種驚人的動力:工程師們開始相互競爭,爭取發現更大的錯誤。這將產生大量的組織學習成果,並與史蒂夫·斯皮爾模型相符:這樣做使我們能夠在災難性事件發生之前,很早就開始不斷髮現問題,然後加以解決。

 

事後剖析免責行得通的原因是我們都是工程師,我們熱愛構建和改進系統。這種暴露問題的環境創造了一個非常令人感到安全、興奮和滿意的工作環境。

 

五、關注人:區分工程師的心智模型

 

人是故障響應者,因此區分心智模型非常重要。故障響應者一般分為兩類:軟體工程師和運維工程師(在谷歌稱為SRE工程師)。在生產環境中,不同故障響應者對故障的響應是完全不同的。

 

軟體工程師更傾向於在除錯工作流中更早地查閱日誌,在工作流中他們查詢錯誤,從而指出故障發生的位置。

 

運維工程師或者SRE工程師更依賴於一種更通用的除錯方法:因為運維工程師經常對多個服務待命,基於系統的已知特徵,他們應用一種通用的方法來除錯和維護。

 

他們在服務執行狀況指標中尋找常見的故障模式(例如,請求的錯誤和延遲),以隔離問題發生的位置,並且通常只在無法確定最佳解決策略時才深入日誌。

 

六、谷歌故障響應流程和解決模式

 

以上內容基本上都是從組織的文化層面來談分散式系統的除錯問題。下面通過谷歌的真實案例討論生產環境中的故障響應流程。

 

在生產環境中,無論是開發工程師,還是運維工程師,都會遇到不同維度的事件,這些維度具備一些常見的模式:

 

  • 規模和複雜性:問題的爆炸半徑(即其位置、受影響的系統、受影響的使用者旅程的重要性等)越大,問題就越複雜;

  • 響應團隊的規模:隨著越來越多的人蔘與到調查中,團隊之間的溝通渠道就會增加,團隊之間更緊密的協作和交接就變得更加關鍵;

  • 故障原因:谷歌的oncall人員主要面對以下六個常見問題:效能問題、程式碼變更、配置變更、依賴問題(服務本身或服務的依賴)、基礎設施問題(網路或伺服器宕機)以及外部流量問題。當然,安全性或資料正確性問題也需要關注,但一般屬於特定的業務範疇;

  • 檢測:人工檢測或者機器檢測,一些常見的機制包括以下告警:白盒指標、合成流量、SLO(服務水平目標)違規和使用者檢測到的問題。

 

典型的除錯過程包括下圖所示的階段和子階段。在工程師除錯問題時,這些階段經常會重複出現,每個階段都可能會以非順序、有時甚至是迴圈的方式出現。

 

 

從檢測到解決,調查通常是時間敏感的——特別是當問題影響到終端使用者體驗時。谷歌採用的原則是:先恢復服務,再排查問題。在發現根本原因之前,運維人員總是會試圖緩解問題或對問題“止血”。止血之後,開發人員通常會對程式碼進行更深入的分析,並應用措施防止類似的情況再次發生,具體操作如下:

 

  • 檢測

 

運維人員通過告警、客戶申訴或主動調查來發現問題。這個過程的一個常見的問題是:這個問題的嚴重性是什麼?

 

檢測過程中的可觀察資料包括給定服務執行狀況的時間序列指標,執行寬度優先搜尋,以確定系統的哪些元件出現故障。oncall人員通常只在元件故障之後才開始追蹤日誌,然後需要深入研究特定問題。

 

  • 分類

 

運維人員的目標是通過檢查問題的爆炸範圍(問題的嚴重性和影響)來快速評估情況,並確定是否有必要升級(召集其他團隊,通知內部和外部的干係人)。當更多的資訊進入時,這個階段可能在單個事件中發生多次。

 

這個過程的常見問題是:我應該升級問題嗎?我需要立即解決這個問題,還是可以等一等?這次宕機是本地的、區域性的還是全球性的?如果宕機是本地或區域性的,那麼它會變成全球性的嗎?

 

  • 調查

 

oncall人員或者工程師會對潛在問題提出假設,並使用各種監控工具收集資料,以驗證或反駁理論。然後,oncall人員試圖緩解或修復潛在的問題。在單個事件中,這一階段通常會發生多次,因為oncall人員需要收集資料來驗證或反駁有關問題起因的任何假設。

 

這個過程的常見的問題是:錯誤和延遲是否達到峰值?需求有變化嗎?這個服務的健康程度?這是虛驚一場,還是問題確實存在?出問題元件的依賴關係是什麼?服務或依賴關係是否發生了變化?

 

  • 解決

 

oncall人員的目標是確定什麼措施可以解決這個問題。有時,解決嘗試可能使問題變得更糟,或對其依賴的服務之一造成負面的連鎖反應。補救或問題的完全解決通常花費所有除錯步驟中的最長時間。在單個事件中,這個步驟可以而且經常發生多次。

 

這個過程的常見問題是:應該採取什麼解決方案?你有信心這是適當的解決方案?這種方案可以解決問題嗎?

 

需要注意的是,在上述整個過程中,溝通起到非常重要的作用。oncall人員記錄他們的發現,與隊友一起進行除錯,並根據需要在團隊內外進行溝通。

 

 

在谷歌的上述案例中,還有一個問題解決和事後剖析的迴圈階段。事後剖析的目標是找出潛在的問題,以防止問題再次發生。此步驟通常發生在問題得到解決並且不再對時間敏感之後,並且可能涉及重大的程式碼更改。在此階段編寫後期分析文件。

 

事後剖析的常見問題是:哪裡出了問題?問題的根本原因是什麼?如何使流程和系統更具彈性?

 

七、日誌不是除錯工具,截圖更不是

 

我們在工作中,經常使用的日誌和截圖,這對於小規模的系統非常有效,團隊也樂於這麼做。

 

但對於大規模分散式系統的除錯來說,日誌和截圖明顯不再適用。下面是谷歌關於工具的一些原則:

 

  • 谷歌在很大程度上依賴於各種視覺化工具來排除不熟悉的問題並儘可能快地恢復服務。相關工具:Graphite、InfluxDB + Grafana和OpenTSDB。這些工具和下面提到的其他工具都不是谷歌使用的工具,也不推薦使用,但它們是有用的開源工具;

  • 建立一個框架,讓開發者可以輕鬆地把監控插入到框架中

  • 使用大量儲存專門儲存監控資料。歷史資料必須可用,以便在恢復停機後可以進行故障排除。停機完全是為了恢復服務,故障排除是稍後在清醒時所做的工作。開發人員經常參與到故障排除過程中,因為他們對系統有更深入的瞭解。恢復不應該導致停機監視資料丟失;

  • 對於關聯事件,事件圖非常有用。發揮人類的模式匹配能力,編寫機器人來完成這個任務是很困難的;

  • 有時需要深入到視覺化程序跟蹤的程序級別來識別效能問題。相關工具:Performance Co-Pilot + vector;

  • 網路流量和容量。如果儲存都很慢,問題可能是網路問題。如果你正在檢視儲存系統,並不能找出它為什麼很慢,則檢視網路。相關工具:Cacti、Observium、Nagios;

  • 當所有其他方法都失敗,則檢視日誌檔案。你不希望檢視日誌檔案。你需要一個具有更多類似SQL查詢的系統,這樣就可以深入研究日誌。日誌應該易於使用和理解。相關工具:ElasticSearch + Logstash (+Kibana)。

 

以上,我們瀏覽了谷歌關於大規模分散式系統除錯的組織文化、工程實踐、響應流程和除錯工具,在各種參考文獻中間的取捨也包含了我的思考。

 

谷歌的經驗沿襲了學術研究和工程實踐的交叉路線,並且具有大型組織實施的經驗。系統除錯的一個重要的目標是防止同一類問題重複出現,或者在不可避免的情況下將影響降低到最小。

 

學習谷歌的經驗,站在巨人的肩膀上,也是一種有效的從他山之石學習事後剖析的方法。

 

>>>>

參考資料

 

  • 《Debugging Incidents in Google's Distributed Systems》

    https://queue.acm.org/detail.cfm?id=3404974

  • 《Book Review: "The High Velocity Edge" By Dr. Steven Spear》

    https://itrevolution.com/devops-book-review-the-high-velocity-edge-by-dr-steven-spear/

  • 《Uncovering The DevOps Improvement Principles At Google (Randy Shoup Interview)》

    https://itrevolution.com/uncovering-the-devops-improvement-principles-behind-google-randy-shoup-interview/

  • 《Postmortem Culture: Learning from Failure》

    https://landing.google.com/sre/sre-book/chapters/postmortem-culture/

  • 《How Does Google Do Planet-Scale Engineering For A Planet-Scale Infrastructure?》

    http://highscalability.com/blog/2016/7/18/how-does-google-do-planet-scale-engineering-for-a-planet-sca.html

  • 《How Google Backs Up The Internet Along With Exabytes Of Other Data》

    http://highscalability.com/blog/2014/2/3/how-google-backs-up-the-internet-along-with-exabytes-of-othe.html

 

>>>>

關聯閱讀

 

  • 《谷歌Colossus檔案系統的設計經驗》

    https://mp.weixin.qq.com/s/yviATMiqjeggemzZ0bBh-A

  • 《谷歌可靠性工程的設計經驗》

    https://mp.weixin.qq.com/s/k02mCRxN19k7fLL6_zJ1Wg

  • 《Filecoin太空競賽的意義》

    https://mp.weixin.qq.com/s/2Sk1aAiHJNqggz_8mg7fGg

 

作者丨tashi

來源丨補天遺石(ID:butianys) dbaplus社群歡迎廣大技術人員投稿,投稿郵箱: [email protected]