前言

問世近一年以來，《SRE: Google 運維解密》一書銷量累計已兩萬餘冊。我想首先感謝各位讀者對本書的支援，真的是衣食父母呀！如果還沒有下單購買，是不是看過本文之後可以考慮儘快呢？

隨著SRE概念在在國內外的火爆傳播，相信很多朋友也對此書有了一定程度的瞭解。感謝 GitChat 平臺，我這次有機會和大家再分享一下書內書外的故事。希望不管您是否看過本書，本文的資訊都能對您有用！

成書花絮

首先要明確的是，這本書是一本文集。Google內部在2014年進行了一次題目+作品徵集工作，由封面上的編者團將收集來的投稿篩選，據稱砍掉2/3內容才 （原始資料據稱超過1500頁） 最後得以問世。 技術類書籍成書難，和大資料專案的關鍵難點很像。那就是——沒有資料。據我和國內運維崗位交流的感覺，別說寫文件了，就連伺服器密碼都是隻記在腦子裡的，根本沒時間寫下來好嘛。玩笑歸玩笑，但是道理不變， Google SRE 給我留下的一個不可磨滅的印記就是——文件重過一切。沒寫文件，救火責任永遠在你自己身上揹著，出問題半夜也要爬起來解決啊。寫完文件，救火責任就變成大家共享的了，就可以開心的睡覺了。每個團隊成員會主動維護本組文件，時刻保持其為最新。知識共享的第一步，當然就是要先把知識記錄下來啊。

2016年初我就聽說這本書很快會發行，4月初英文版上架之後，聯絡出版社等一系列事情做完之後，已經是近5月底了。6月和7月真的是日以繼夜，每天翻譯差不多 6- 8小時 ，8月做完審校等工作，9月正式完成首發和大家見面 。我做過統計，每次我能堅持全神貫注翻譯兩個小時，最多隻能翻譯10頁原文。可是該書英文版就550頁啊，哭死。在無數個挑燈夜戰的夜晚過後，我自問還算是交上了一份差強人意的答卷，希望沒有辜負大家的期待和信任。

本書封面：巨蜥

據編者透露，他們選擇了很多動物的方案，可惜都曾被 O’Reilly 其他的書用過了，最終決定這個方案的原因是，巨蜥的英文名（(Monitor Lizard)，Monitor 與 SRE常用詞 ”監控“ 一模一樣，於是就這麼愉快的決定了。（nerd的日常，笑）

首發現場請到了編者之一 Chris Jones, 時任 App Engine SRE，很多成書的內幕訊息就是他告訴我的。據稱美國首發儀式未做宣傳，一共只發出不到10本。而在中國，在 GOPS 大會主席蕭田國蕭幫主的大力支援和宣傳下，首發一個小時之內準備的兩百本簽名書全部售罄。

下面咱們言歸正傳，詳細逐一說一說書中的內容。

第一章： SRE 概述

基本上在每次交流的過程中，大家總會談到 SRE 理論體系的建立過程，以及與國內常見的運維崗位定義之間的區別與相同之處。這裡我提出幾個看法：

馬後炮

我曾經在數次演講中用過“馬後炮”這個詞來描述SRE的理論體系。中文”馬後炮“一詞的確略有 貶義，但是感覺用在這裡卻恰如其份的描述了SRE建立過程中摸著石頭過河的過程。世界上不存在萬能藥，SRE 體系也絕非一天之內設計建成的完美羅馬城。這裡有我的個人理解：SRE 代表的是一種新的工作方式。通過主動收集以前散落給各個部門的一系列具有相關性的職責(Accountability)，管理層同時配發了一定的決策權(Authority )，再利用一定程度的自治權(Autonomy) 達到可持續發展的目的，這三種因素相互結合，相互作用最終造就了 Google 內部舉足輕重的千餘人 SRE 團隊。

與國內運維的本質區別在於職責與權力的統一

書中本章所列八條方法論，可以和上述AAA分別對應。我在交流中經常開玩笑的說，SRE也是背鍋俠，不一樣的是 SRE 是自豪的背鍋俠。不僅有鍋背鍋，還經常找到暫時沒有造成業務影響的鍋來主動背，自豪的背。如果要問這是為什麼？那我可以反問，這難道不就是職責所在嗎？既然 SRE 負責服務的穩定性，那就應該承擔服務不穩定的後果。對職責的抗拒通常是由於決策權不統一，運維團隊無法消除問題隱患，也無法改進程式碼，再加上常常歸責於人的制度而造成的。就事論事，說起來容易做起來難呀。但是我覺得一定要意識到，個人英雄主義永遠是不太穩定的依靠。鋼鐵俠也有大起大落，對吧。相比中國文化中常常灌輸的挽狂瀾於既倒這樣的大場面，SRE 更喜歡平時排除隱患，到點就回家睡覺。這些問題在書中後面的章節不是會有討論，希望大家看得時候可以多留意一些。

對SRE風潮的個人理解

很多企業的產品流程仍然停留在所謂計劃經濟+鏈條型體制下運轉。 業務交需求給研發，研發交程式碼給運維上線，許多許多問題都是在這種“扔過牆”的過程中產生的。

目前逐漸風行的 DevOps 理念強調的是將IT能力向鏈條前部推進，如果將此應用在 Dev 與 Ops 之間，那麼就是通過 CI/CD 等手段，達到促進 Dev 和 Ops 之間的合作關係的目的。 而 SRE， 或者說 Google， 則更進一步，將鏈條式體系升級換代為三根支柱體系（我冠名的）。 業務、研發、 SRE 三根支柱互相支撐，互相協作，達到了一個更高效的協作高度。這本書中蘊含的方方面面，都基本可以歸結為 SRE 與業務團隊和研發團隊之間互動所涉及到的方方面面。 所以，SRE比我們中國語境中的運維崗位要廣泛很多，可以稱為一個職業了。

第二章： Google 的生產環境

在本章中 Google 描述了其世界聞名的資料中心設計和內部應用軟體架構。用一句簡單的話講， Google內部實現的是資源交付的平臺化。一個普通員工，甚至非程式設計師所能調動的資源規模都是幾乎令人難以置信的。舉個例子，每個 Google 程式設計師入職第一週都會執行一個執行在數百臺機器上的分散式排序程式，不需要申請，也不需要排隊，隨時需要隨時執行。Google 最近計算出的 SHA1 衝突值，耗費了 6500 個CPU 年，以及110 個 GPU 年。其實算算也不過一萬多臺8核伺服器跑一個月哦，還好，還好。

我在這裡將這一章書中講的很多小點歸結為三類基本資源分別進行描述。

計算資源

計算資源的分配和使用，是現在炒得最熱門的話題了。不管是之前的OpenStack, vmware, xen, Ganeti ( http://www.ganeti.org/ 很多人不知道這個優秀的Google Xen 管理套件開源專案）, 還是最近火熱的容器雲, Docker, Kubernetes, Mesos 本質上都是在做同一件事 分配和使用物理資源。 在本章中，Google描述了Borg系統的架構。

由於 Google 物理資源規模十分巨大，全球百餘個叢集，百萬+量級的伺服器數量，很多傳統的管理方式已經不適用了。 首先，雖然單個物理資源損壞率不高，但是在這麼龐大的基數下，基本每分鐘都有伺服器宕機，重啟，或者出現硬體故障。如果以傳統 Ops 的方式來處理這些故障，由某Ops遠端處理或者親自飛到對應地點，當場除錯解決所有問題再回家，那招多少人也不夠用呀。所以在Google這個體量規模下，全球部署的現狀下，這樣做法明顯是不行的。

有位名人曾指出 （真說過，不過半開玩笑）：All computer problems can be solved with one more layer of indirection. 為了解決極大規模叢集事故造成的維護困難問題，SRE推行了物理資源與邏輯分離的做法。利用 Borg 系統，創造了一種新的資源單位——容器。 我當時所處的Borg SRE 團隊起的正是這樣一個承上啟下的作用。總有人問我 Google 內部是不是也用容器雲，此處我只能說，Google 用的時候，這玩意還木有名字呢。

向下，Borg SRE 通過書中描述的“系統管理軟體” （自動化系統）自動化的處理所有物理資源的異常狀態，根據需要利用自動化工單系統與資料中心駐場服務人員溝通解決問題。駐場人員負責執行物理操作，SRE 則負責制定計劃。分工明確又可以共同提升。

向上，Borg 則提供了一套虛擬資源的抽象層，包括相應的互動模型，讓使用者可以直接以Task, Job 等原語構建自己的應用，無需再關心物理資源的分配與使用問題。

Borg SRE團隊負責執行維護自動化系統，保障虛擬資源的交付能力 (Scheduabity) 和交付質量 (Scheduling Dealy)。Borg SRE 同時負責維護基礎的生產系統環境變更，例如每兩週更新一次全部生產伺服器的Kernel版本。在這個體量下，任何需要人工干預的過程都是不可想象的。

儲存資源

我經常說分散式系統中最大的問題就是儲存。如果將程序的狀態存在於某個分散式儲存系統中，程序本身就可以做到無狀態，可伸縮，可遷移。

Google的儲存系統明顯是分層形式構建的，大致分為 機器本地SSD / （HD基本逐漸已被淘汰），叢集本地的 Chubby, Bigtable, Colossus 等，以及跨叢集自動同步的 Megastore, Spanner 等等。 這樣，研發可以根據需要選擇最符合當前使用需求的場景的儲存服務。

這裡值得一提的是，Google大部分系統都是基於“叢集本地” (Cluster local) 的概念構建的 。整個叢集內部通常可以被視為“區域網”，其中所有機器共享一個大的網路災難域，以及數個小的供電災難域。Google叢集雖多，但是每個叢集的結構都高度一致。可以真正做到無差別遷移。SRE經常唯一需要記住的就是叢集的命名規則（物理位置）。在叢集間遷移變得如此簡單，甚至有的團隊每個季度都全球佈局一次。如果底層系統不將這類資訊公佈給使用者，而是自下向上替使用者決策，將造成極大的浪費。 所以有人問我，Google雲平臺是否超賣，答案是否。如果虛擬資源超賣，直接導致使用者效能沒有保障，也就使得使用者必須買更多的資源，這中間的浪費，誰來買單呢？曾經有人說過，如果公司內部激勵機制出了問題，數目驚人的浪費還真不如直接燒錢，每天幾百萬，還能烤烤火呢！

網路資源

Google 網路設計中分資料中心網路，B4 (Backend backbone), B2 (Backbone) 三類。其中叢集網路大家可以閱讀 Jupiter Rising: A Decade of Clos Topologies and Centralized Control in Google’s Datacenter Network 這篇 paper. 資料中心內部全三層網路，雙機之間5微秒延遲，每臺機器40G上下行頻寬，真的很難想象。

2008年的金額危機期間，美國、歐洲很多中小型ISP受損倒閉。Google作為當時的現金大戶收購了超級多的Dark fiber，隨後這些就Google骨幹網路的核心。我在 Youtube 期間，又參與構建了Google的CDN網路，在這裡我就不多寫了，有興趣可以單獨交流。

理論篇

如同前文所講， 我認為SRE的成功基礎在於職責、決策權和自治權的統一。這一篇的內容就充分體現了這三方面的內容。

首先，SRE團隊運作過程的關鍵就在於制定和維護一套可以高度量化的目標，即服務質量指標（SLO）。有了這樣一個目標，通過不斷地制定和完善執行方案，對執行過程中遇到的問題不停地追根溯源，形成了SRE獨特的而高效的工作方式。 書中第3章，風險的量化定義，是SRE的立身之本。穩定性和可靠性應該作為產品的一個重要屬性進行定義。提供定義依據，制定衡量標準，保證達標則是SRE職責所在。

SRE 應該直接向終端使用者負責，SRE 工作質量的衡量標準就是服務的質量高低。我在國內某次交流中，曾經與人聊過Google大量採用自下向上的 OKR 管理方式。但是這往往只是一個側面印象，其實 Google 內部當然也有 自上至下的管理方式，SLO 就可以算作 Google SRE 的 KPI。 這裡的詳情可閱讀書中第4章，服務質量指標，就不再贅述了。

確立了目標之後，有關如何提高或者保持該目標。可以閱讀書中第6章，分散式系統的監控來詳細瞭解。本章裡面提到的四大黃金指標是基礎中的基礎。但是更讓人腦洞大開的一點還是集中於“長尾”問題的討論上。”長尾”難題幾乎是大型分散式系統在解決完生存問題之後遇到的標配問題。由於長尾問題復現困難，對資料分析能力，系統除錯與測量能力要求很高，難以根治。

長尾問題還有放大效應，底層服務的長尾問題會給呼叫頻繁的上層應用帶來數倍以上的效能影響。曾經我有一個 Google 同事，任職期間所做的唯一工作就是跟蹤調查某儲存系統磁碟IO的長尾難題，從應用一路查到核心。最後在核心中發現並解決了一個鎖競爭問題。由於他的這幾行改動，底層儲存服務的長尾延遲降低了，上層大量依賴操作儲存的應用服務便可以省去很多超額部署的容量，這幾行程式碼為 Google 節省了每年幾千萬美金的資源成本。他笑稱，自己應該可以免費拿十年工資了。（當然了，估計沒發，所以他走了。）

本大章中的其餘章節，分別描述了在SRE工作過程中所涉及到的方方面面。其中對瑣事 (Toil) 的處理很有意思。Google SRE 每個季度都曾經發送內部調查問卷收集關於瑣事所佔比例的資訊。但是估計某位 Manager 催手下填問卷催的急了一些，這位大俠一怒之下向全體 SRE 傳送了”關於每季度瑣事調查問卷繁瑣程度的調查問卷“，笑噴了。

第9章，簡單化，這一章中的內容也很有意思。在 Google 內部我曾經參與組織過很多次 ” 刪程式碼競賽“ 活動，一刪幾萬行。後來在 Coding 也曾經舉辦，效果很好。 程式設計師一定要記得，程式碼即債務。如果無法安全的刪掉垃圾程式碼，不僅僅是編譯速度的問題，這恰恰反映了深層次的研發架構問題。Google 工程師都以少寫程式碼為榮，我曾經有連續幾個月都是程式碼行數淨輸出為負，如果按五行一元起發工資，那豈不是要哭死了。

有關簡化認知複雜度的問題，是一個值得深思的話題。一個人的認知能力總是有限的，在 Google 這樣的體量下，必須要進行統一化，簡單化，否則誰也不可能記住端到端的所有資訊。正如 Borg 通過抽象資源降低了大部分 Google 程式設計師對物理資源使用的認知複雜度一樣，大部分 Google 自動化系統都在由 指令型系統向意願型系統轉變，這一點有興趣的話，可以線下交流。

實踐篇

這一部分內容較多，我將書中章節按照自己的理解重新排序了, 方便大家閱讀和理解。

前文說過 Google SRE 都是自豪的背鍋俠，那麼如何專業的而負責的背鍋呢？這裡就應該看以下章節了：第11章 Oncall ， 第12章 故障排查方式， 第13章 緊急事件響應 第14章 事故流程管理 ，第15章 事後總結， 以及第16章 故障跟蹤工具。 我曾經舉過好多例子，SRE 的 Oncall 是一個人負責整個團隊的緊急事務處理，絕非各管各的。 這樣，非Oncall的人可以真正投入到開發專案中去。我常常開玩笑的說，什麼時候運維團隊成員可以做到能夠隨時按需請假了，下班關手機，那就說明團隊走上正軌了。一個單獨的 SRE 團隊是一個高度協作的團隊，每個人有自己的事業專注點，也有共同維護的一畝三分地。平時的監控平臺維護，文件修改，報警規則等等，都會及時與大家同步。

另外一個值得關注的重點是負載均衡問題，主要參看以下幾章： 第19章 描述了資料中心之間的負載均衡系統的設計實現，第20章 描述了資料中心內部的負載均衡系統設計實現。第21章討論過載問題，第22章討論了雪崩效應和連鎖故障問題。我曾經和很多人討論過，Google 的資料中心設計SLO為99%。 ”冗餘“ 基本上是各種服務上線第一天就所必備的要求。冗餘又分”單活“，”多活“等等，在儲存層面的”多活“功能支援下，Google 大部分系統都可以做到隨意遷移，跨區域多活，這中間主要就靠負載均衡體系的完善。一個使用者請求從發起到抵達 Google 生產伺服器，中間要經過至少三層負載均衡系統，處理過程中更是觸發N個RPC 在許多機器上併發執行。這中間又離不開資料中心內部負載均衡系統的幫助。有人問 N + M 冗餘如何做到，我總是笑著先問他 N 是多少。 不壓力測試，根本沒辦法談什麼冗餘。很多時候，為了更好的，更精確的制定N，我們還要拆分服務，重組架構，這些都是 SRE 的關注範圍。

過載與雪崩效應這兩章寫的非常之好，這和下文會提到的分散式共識系統一同成本書我最喜歡的前三章。面對著鋪天蓋地的使用者流量，負載均衡系統，伺服器元件，甚至重試邏輯等等設計稍有不慎就會觸發比全天峰值還要高几倍的流量攻擊自己，實在是不能大意啊。一旦出現雪崩效應，很難恢復正常，常常需要全服務停機一段時間才行。App Engine 就曾經出現過這樣的大問題。某種因素導致的資料中心下線，導致全球流量就像洪水一般一個一個將殘留的資料中心淹沒了。

第23章 分散式共識系統，第24章 分散式週期性任務系統 第25章 資料處理流水線 更是絕佳之作。在我參與設計實現Youtube直播系統之時，曾經花費大量精力參與設計了一套基於 BASE 儲存系統的一致性解決方案。在結束兩週討論之後，回程飛機的路上，我翻看內部文件看到了對Paxos系統的討論，當時真如醍醐灌頂，目瞪口呆。前文討論過，分散式系統最難的設計難點就在於狀態存取一致性問題，而有了Paxos之後，一切都不再是問題。回想起來，看樣還是應該好好上學，80年代就發表了的 Paxos 系統設計居然直到2010年才學到，讀書少總被騙啊！

我強烈建議大家真的仔細讀這一章，目前開源實現中ZooKeeper, Etcd, Consul等基於的也都是Paxos協議的變種，相信讀過這篇會對大家未來的分散式應用設計有直接的啟發作用。這之後的分散式週期系統，資料處理流水線系統，基本的水平擴充套件方式都依賴 Paxos ，理論指導加具體實踐，感覺全書就看這三章，足矣。

其他章節中例如第26章 資料完整性，是比較難啃的一章。Google 儲存的海量資料管理所遇到的困難數量也絕對是海量的。Gmail 當年出事之後，靠磁帶備份系統成功恢復了使用者資料，有興趣的人可以搜尋相關的 Youtube 視訊有詳細介紹。視訊中曾說過一句話，備份系統不重要，重要的是恢復系統。如果你只是搭了一套備份系統，沒有平時經常演習資料恢復，那麼關鍵時刻它一定會失效的。唯一能確保安全的方法，就是建立自動化的，隨機的資料恢復機制。

本部分其他章節在這裡就不再贅述了，測試這一章也比較難啃，如有興趣大家可以直接找我私下交流。

SRE管理

前文提到，SRE 的自治主要體現在 50% 的研發工作紅線上。 本部分中最有啟發性的討論，莫過於 第29章，對中斷性任務的處理。 我們現在都生活在一個資訊爆發的年代，每天各種方式的通知訊息不停地打斷我們的思路，甚至很多人根本已經無法長時間集中注意力。自從學習了有關 流狀態 （Flow state) 的相關知識之後，我常常自省，今天又在回微信，查郵件，以及刷朋友圈中度過了，專案木有進展啊，長此以往情何以堪。

這的確是值得我們深思的問題，運維團隊由於負擔日常運維工作，中斷型任務不可避免，如果長時間讓自己處於這個狀態中會有許多不良現象。所以，為了自己的身心健康，也應該多多關注本章。

本部分其他章節詳細描述了SRE與研發團隊，產品團隊的合作關係。中美組織結構，企業文化，團隊關係還是略有區別，計劃經濟與市場經濟的對比，從這幾章中可以窺見一斑。

與其他行業的對比

這部分雖然安排在最後，但是我認為是非常值得一讀的。伴隨而來的問題也讓人腦洞大開，比如SRE/運維團隊與民航大飛機駕駛員的共同點與區別在哪？與消防隊員，救生員相比呢？這些行業都遠比軟體行業成熟，他們職業的發展路線是不是對SRE的職業發展方向有參考價值呢？相信看完本章，你會找到自己的答案的。

結束語

感謝耐心讀者看到最後，希望本文能給您帶來一些有用的資訊，《SRE：Google 運維解密》目前各大網店均有銷售，期待與大家的交流活動！

作者：孫宇聰，前google 資深SRE，《SRE：Google運維解密》譯者，曾在 Google 總部雲端計算團隊任職 SRE 8 年，先後負責Youtube，Google Cloud Platform等產品的運維。回國創業後積極參與國內雲端計算圈內活動，致力於推進容器化應用交付升級，基礎架構服務改造。是開放運維聯盟應用運維小組核心成員，負責高可用部分規範的制定。曾在InfoQ, ArchSummit, Velocity等大會上發表專題演講，推廣容器化體系的構建經驗。