《SRE：Google運維解密》

前言

問世近一年以來，《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 ( 不少人不知道這個優秀的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 運維解密》目前各大網店均有銷售，期待與你們的交流活動！

更多Linux諮詢請查看www.linuxprobe.com