SRE：Google運維解密 pdf epub mobi txt 電子書 下載 2025

簡體網頁||繁體網頁

☆☆☆☆☆

[美] Betsy Beyer（貝特西·拜爾），Chris Jones，Jennifer Petoff，Niall Murphy 等 著，孫宇聰 譯

圖書標籤:

• SRE
• Google
• 運維
• 可靠性工程
• DevOps
• 係統設計
• 互聯網工程
• 故障管理
• 自動化
• 監控
• 性能優化

齣版社： 電子工業齣版社

ISBN：9787121297267

版次：1

商品編碼：11973579

品牌：Broadview

包裝：平裝

開本：16開

齣版時間：2016-10-01

用紙：膠版紙

産品特色

編輯推薦

　　√ 超級暢銷書，國外在綫書店長居前列，打標#1 Best Seller
　　√ 運維高燒不退，榖歌神書問世，繼續為這一熱潮推波助瀾
　　√ 本書解密全球神秘又讓人仰望的技術崗位——榖歌SRE
　　√ 未齣先火，本書原著問世時各大社區火爆異常、人氣爆棚

內容簡介

　　大型軟件係統生命周期的絕大部分都處於“使用”階段，而非“設計”或“實現”階段。那麼為什麼我們卻總是認為軟件工程應該首要關注設計和實現呢？在《SRE：Google運維解密》中，Google SRE的關鍵成員解釋瞭他們是如何對軟件進行生命周期的整體性關注的，以及為什麼這樣做能夠幫助Google成功地構建、部署、監控和運維世界上現存的軟件係統。通過閱讀《SRE：Google運維解密》，讀者可以學習到Google工程師在提高係統部署規模、改進可靠性和資源利用效率方麵的指導思想與具體實踐——這些都是可以立即直接應用的寶貴經驗。
　　任何一個想要創建、擴展大規模集成係統的人都應該閱讀《SRE：Google運維解密》。《SRE：Google運維解密》針對如何構建一個可長期維護的係統提供瞭非常寶貴的實踐經驗。

作者簡介

　　Betsy Beyer，是Google 紐約負責SRE 的一名技術文檔作傢。她之前曾為遍布全球的Google 數據中心與Mountain View 硬件運維團隊編寫文檔。在搬到紐約之前，Betsy 是Stanford 大學技術性寫作課程的講師。她曾經學習國際關係與英文文學，並在Stanford和Tulane 獲得學曆。

　　Chris Jones，是Google App Engine 的一名SRE。Google App Engine 是一個PaaS 服務，每天處理超過280 億個請求。他的辦公室在舊金山，他之前的工作包括Google 廣告統計、數據倉庫，以及用戶支持係統的維護。在之前，Chris 曾經在學校IT 行業任職，同時參與過競選數據分析，以及一些BSD 內核的修改。他有計算機工程、經濟學，以及技術政策學的學位。同時他也是一名有執照的職業工程師。

　　Jennifer Petoff，是Google SRE 團隊的一名項目經理，工作地點在都柏林，愛爾蘭。她曾經負責管理大型全球項目，包括：科學研究、工程、人力資源，以及廣告等。Jennifer在加入Google 之前，曾在化工行業任職八年。她獲得瞭Stanford 大學的化學博士與學士學位，同時她還擁有Rochester 大學的心理學學位。

　　Niall Murphy，是Google 愛爾蘭團隊廣告SRE 的負責人。他擁有20 年互聯網行業經驗，目前是INEX（愛爾蘭網絡互聯樞紐）的主席。他曾經寫作以及參與寫作很多科技文章與書籍，包括O’Reilly 齣版的IPv6 Network Administration，以及很多RFC。他目前在參與書寫愛爾蘭互聯網發展史。他擁有計算機科學、數學，以及詩歌學的學曆（他當時一定是想錯瞭！）。他目前與妻子和兩個兒子居住在都柏林。

　　孫宇聰，前Google SRE（2007-2015），山景城總部，曾參與構建運維Youtube 全球CDN網絡，2008年奧運會直播項目，構建維護海量視頻編碼傳輸係統。後參與Google內部雲平颱運維工作，負責運維全球百萬級彆服務器集群，以及Borg、Omega等大規模集群理係統。2015年加入Coding，任CTO一職。迴國後，積極推動國內容器化運維架構升級。目前是開放運維聯盟之應用運維規範製定組，高可用運維規範製定者。

精彩書評

　　我們都知道 Google公司的分布式係統設計和實現在業界遙遙領先，這些分布式係統多年前就已經運行在百萬颱服務器上，很多公司也都在覬覦這麼多服務器是如何運行和管理的。本書揭開瞭這層神秘的麵紗， SRE就是運行和管理這百萬颱服務器和眾多分布式係統的關鍵。
　　多年前，Google是通過發布技術論文幫助業界解決分布式難題的，如今各種分布式係統百花齊放，如何管理這些係統對傳統的運維技術和理念産生瞭極大的挑戰，現在 Google給我們帶來瞭技術指導和實踐。該書匯集瞭 Google多年生産環境的管理經驗，連編寫工作都采用瞭分布式實現的方法，由各個領域的資深專傢聯閤創作而成。可以把本書看作是一座燈塔，很多公司的集群規模還遠達不到 Google的規模，但是參照本書中的技術指導和實踐，不僅可以加速傳統運維嚮 SRE的進化，更重要的是可以幫助公司高效地運維和管理各種復雜的分布式係統。
　　——呂宏利，Google Ads SRE
　　
　　信息技術領域是英文縮寫詞的高産領域，幾乎所有的新概念、新技術和新産品的推齣甚至一場市場營銷的策劃都會伴隨著新的英文縮寫詞的齣現。 SRE這個縮寫，在公司內部不僅代錶瞭一個全新的運維理念和其伴隨的嶄新的工程領域、一套完整的係統運維體係和其對應的實踐，而且也是我和我的好朋友——本書的譯者孫宇聰一起工作瞭數年的戰鬥集體。而本書的作者們也都是這個大集體中的師長和夥伴。
　　係統運維長久以來都依賴實踐積纍之上的口口相傳，經驗通常是領域從業者手裏掌握的秘訣。本書從實踐齣發，匯集瞭眾多業內優秀的係統運維人員的實戰心得，理論基礎和實操指導並重，係統化地闡述瞭在新一代信息係統架構（大規模、分布式、高並發、多業務、多租戶）下係統運維的理念（當前被廣泛接受並被大量實踐的 DevOps就起源於此）、思路、實踐以及對應的組織架構和人員管理的方方麵麵，是係統運維領域從業人員不可多得的參考和學習資料。本書是對新時代係統運維領域實踐的總結和理論升華。
　　本書的譯者孫宇聰在生活中是一個略顯粗獷的大男人，但對於本書的翻譯，他充分發揮瞭自己在這個領域中多年的從業經驗和對係統運維的深刻理解，細緻入微地做到內容和語言兩個方麵的精準和優美，這在翻譯的技術圖書中是非常難得的。
　　——張矩，鋒瑞資本執行董事，前 Google SRE
　　
　　很高興受譯者孫宇聰邀請為該書寫推薦序，這本書是 Google的 SRE部門多年實踐的總結，孫宇聰本人也在 Google SRE部門工作多年。SRE部門在 Google真正落實瞭 DevOps。 SRE工程師在 Google不隻是維護各種綫上服務的穩定性，還要負責保證各項服務的性能，同時負責管理維護數據中心。美國多傢互聯網公司都在依照 Google的方式來組織和運作 SRE部門，可以說 SRE被 Google發揚光大，Google的 SRE實踐正在成為 DevOps的標準。
　　SRE和傳統的 IT運維有很大區彆，SRE真正實現瞭 DevOps：首先， SRE深度參與開發階段的工作，對應用程序的設計實現方式、依賴庫、運行時的資源消耗都有嚴格的規約；其次，SRE工程師本身也要做不少編程工作，來實現各種工具用以自動解決問題和故障，換句話說，SRE強調的是對問題和故障的自動處理，而非人工乾預；再者，按照 SRE的約定，開發人員自行負責程序上綫部署更新，畢竟開發人員對自己開發的程序更熟悉，易於處理程序上綫過程中遇到的問題。總之，作為 Google的 DevOps實踐，SRE非常注重開發和運維職能的結閤，極大地加快瞭業務應用迭代周期，提升瞭 IT對業務的支撐能力。
　　隨著 DevOps在國內的宣傳推廣，國內的很多企業客戶也逐漸接受瞭 DevOps的理念，但是在具體落地實踐 DevOps的過程中缺乏實際案例作為參照。本書的推齣，方便瞭國內廣大 IT人員在落地 DevOps過程中參照 Google的 SRE實踐。非常感謝孫宇聰把這麼好的一本書翻譯成中文。
　　——王璞，數人雲創始人
　　
　　Google首創瞭 SRE這個職業，並將其 SRE思想體係和方法論貢獻齣來匯集成此書。中文版的及時齣版，使得國內廣大運維從業者可以更高效地賞閱並實踐。很榮幸此書在 GOPS全球運維大會首發，高效運維社區將繼續作為 Google SRE國內第1傳播平颱，推進其和《互聯網應用運維框架及能力模型》（本書譯者孫宇聰先生聯閤撰寫）的融閤，促進其在中國運維行業的落地生根、蓬勃發展。
　　——蕭田國，高效運維社區發起人，開放運維聯盟聯閤主席
　　
　　從接觸 Google SRE的概念開始，就感受到它神秘地存在，直到看到英文版的 SRE書籍，纔知道它對傳統運維的顛覆性。本書的麵世，讓國內更多的運維人員接觸到 Google先進的運維理論與實踐。個人堅信這種理論和實踐的提升與改變，纔是運維人的齣路，運維的業務價值、行業價值便也隨之而來。運維也可以“高大上”地存在！
　　——王津銀，“精益運維”發起人；優維科技創始人；開放運維聯盟發起人之一；開放運維聯盟應用標準規範組組長、起草人
　　
　　大型互聯網應用的部署規模從幾韆颱到幾十萬颱不一，隨著軟件係統的復雜度提升也呈現齣越來越龐大的趨勢，如何通過少數人力管理好龐大復雜的應用環境？如何在環境極度復雜的情況下確保軟件的服務質量？如何在確保質量的情況下優化軟件迭代速度？很多問題睏擾著項目管理者、産品經理、軟件工程師、運維人員。本書從 Google所麵臨的問題、價值觀、解決方案、體係建設、實踐等方麵理論結閤實際，非常具備指導意義，每一個希望提高工作效率、改進工作成果的技術和管理人員都應該認真閱讀理解，結閤自身工作環境進行實踐，找齣一條適閤自己的持續發展之路。
　　——莫顯峰，Ucloud聯閤創始人，CTO
　　
　　Google豐富的産品與服務已成為全球多數網民每天生活的一部分，而支撐這許多應用的是其背後龐大的基礎設施。為瞭更有效地保證用戶體驗，Google建立瞭獨樹一幟的運維體係並稱之為 SRE（Site Reliability Engineering）。絕大部分傳統 IT公司會雇傭係統管理員（ sysadmin）來運維復雜的計算機係統，但由於大部分工作依靠手工操作，所以隨著用戶增長，Sysadmin的團隊也必須相應地增長。Google SRE團隊的精華在於研發軟件係統，將運維自動化以替代傳統模型中的人工操作。這本書詳細地描述瞭 Google SRE的原則與理念，並列舉瞭實際案例來說明如何靈活運用這些準則。
　　孫宇聰在 Google任職八年。他不僅精通基礎設施的各個方麵，還熱衷於鑽研平颱架構。他緻力於為中文讀者解析 Google運維的竅門，於是在繁忙的工作之餘，翻譯瞭這本由他的原同事們撰寫的書。由於 Google的規模很大，許多人可能認為 Google的做法無法效仿，但書中描述的原則與道理是可以觸類旁通的。書中提及許多實用的道理，比如， 100%的可用性是不現實的，需要達到這個目標的成本通常遠超於所能獲得的價值，所以 Google會針對每種産品設定一個錯誤預算（容錯率），既能保證用戶體驗又不影響創新和部署的速度。
　　我希望讀者像我一樣，通過閱讀這本書，能學習到如何更有效地運維自己的産品與平颱。
　　——Joe Zhu，Zenlayer創始人
　　
　　Google SRE團隊通過寫作本書為整個運維行業做齣瞭巨大的貢獻。通過本書，他們將指導思想、實踐和常見的應用架構模式以及團隊建設模式共享齣來，揭示瞭 Google如何能夠持續不斷地建設、部署世界級的工程項目，同時保持世界一流的可靠性標準。每個感興趣的人都應該通讀本書，切身嘗試書裏提到的一些想法。
　　Jez Humble，Continuous Delivery和 Lean Enterprise書籍的共同作者
　　
　　我還記得 Google第1次在運維技術論壇上發錶的演講。感覺就像聽瞭一場野生動物專傢針對兩棲爬行動物的專題介紹。演講非常有意思，但是由於演講的內容和觀眾的日常工作感覺距離太遙遠，因此演講的效果並不好。
　　隨著 IT行業的不斷改變，中小型企業的運維實踐逐漸和 Google接軌。突然之間， Google多年打磨、積纍形成的運維實踐變成瞭熱門的行業焦點。對於一個麵臨日益嚴峻的可靠性、可擴展性、可維護性挑戰的行業，這本書真是太及時瞭！
　　——David N. Blank-Edelman，總監，USENIX董事會成員，以及 SREcon 大會的共同創始人
　　
　　自從我離開 Google這座充滿魔力的城堡，我就一直在等這本書麵世，我一直在用書中的思想理念給同事們布道。
　　——Bjo.. rn Rabenstein，SoundCloud 生産工程團隊負責人， Prometheus（開源項目）開發者，前 Google SRE（2013）
　　
　　Google是 SRE理念的發明者。本書不光介紹瞭這個職位的技術細節，還包括瞭其中的思考過程、團隊目標、設計理念以及學到的寶貴課程。如果你想從起源上瞭解 SRE一詞的意義，應該從本書開始。
　　——Russ Allbery，Google SRE，安全工程師
　　
　　本書的作者們和大傢分享瞭 Google SRE團隊的成長經曆，包括其中走過的彎路。 Google憑藉這些實踐經驗，將 Google服務部署到全世界，同時保持世界一流的可靠性。我高度建議任何一個想要創建、擴展大規模集成係統的人閱讀本書。這本書針對如何構造一個可長期維護的係統提供瞭非常寶貴的實踐經驗。
　　——Rik Farrow，USENIX成員
　　
　　開發一個 Gmail這樣的大型分布式係統已經很難瞭。如何運營維護這樣的一套係統，在保障每天不斷更新的同時保障一流的可靠性就更難瞭。這本書就像一套完備的菜譜，收集瞭 Google在實踐過程中積纍的寶貴經驗。希望通過閱讀本書，讀者能夠繞開一些 Google曾經走過的彎路。
　　——Urs Ho..lzle，Google 基礎架構組資深副總裁

目錄

前言　 xxxi
序言　 xxxv
第Ⅰ部分　概覽
第1 章　介紹　 2
係統管理員模式　 2
Google 的解決之道：SRE　 4
SRE 方法論　 6
確保長期關注研發工作　 6
在保障服務SLO 的前提下最大化迭代速度　 7
監控係統　 8
應急事件處理　 8
變更管理　 9
需求預測和容量規劃　 9
資源部署　 10
效率與性能　 10
小結　 10
第2 章　Google 生産環境：SRE 視角　 11
硬件　 11
管理物理服務器的係統管理軟件　 13
管理物理服務器　 13
存儲　 14
網絡　 15
其他係統軟件　 16
分布式鎖服務　 16
監控與警報係統　 16
軟件基礎設施　 17
研發環境　 17
莎士比亞搜索：一個示範服務　 18
用戶請求的處理過程　 18
任務和數據的組織方式　 19
第Ⅱ部分　指導思想
第3 章　擁抱風險　 23
管理風險　 23
度量服務的風險　 24
服務的風險容忍度　 25
辨彆消費者服務的風險容忍度　 26
基礎設施服務的風險容忍度　 28
使用錯誤預算的目的　 30
錯誤預算的構建過程　 31
好處　 32
第4 章　服務質量目標　 34
服務質量術語　 34
指標　 34
目標　 35
協議　 36
指標在實踐中的應用　 37
運維人員和最終用戶各關心什麼　 37
指標的收集　 37
匯總　 38
指標的標準化　 39
目標在實踐中的應用　 39
目標的定義　 40
目標的選擇　 40
控製手段　 42
SLO 可以建立用戶預期　 42
協議在實踐中的應用　 43
第5 章　減少瑣事　 44
瑣事的定義　 44
為什麼瑣事越少越好　 45
什麼算作工程工作　 46
瑣事繁多是不是一定不好　 47
小結　 48
第6 章　分布式係統的監控　 49
術語定義　 49
為什麼要監控　 50
對監控係統設置閤理預期　 51
現象與原因　 52
黑盒監控與白盒監控　 53
4 個黃金指標　 53
關於長尾問題　 54
度量指標時采用閤適的精度　 55
簡化，直到不能再簡化　 55
將上述理念整閤起來　 56
監控係統的長期維護　 57
Bigtable SRE ：警報過多的案例　 57
Gmail ：可預知的、可腳本化的人工乾預　 58
長跑　 59
小結　 59
第7 章　Google 的自動化係統的演進　 60
自動化的價值　 60
一緻性　 60
平颱性　 61
修復速度更快　 61
行動速度更快　 62
節省時間　 62
自動化對Google SRE 的價值　 62
自動化的應用案例　 63
Google SRE 的自動化使用案例　 63
自動化分類的層次結構　 64
讓自己脫離工作：自動化所有的東西　 66
舒緩疼痛：將自動化應用到集群上綫中　 67
使用Prodtest 檢測不一緻情況　 68
冪等地解決不一緻情況　 69
專業化傾嚮　 71
以服務為導嚮的集群上綫流程　 72
Borg ：倉庫規模計算機的誕生　 73
可靠性是最基本的功能　 74
建議　 75
第8 章　發布工程　 76
發布工程師的角色　 76
發布工程哲學　 77
自服務模型　 77
追求速度　 77
密閉性　 77
強調策略和流程　 78
持續構建與部署　 78
構建　 78
分支　 79
測試　 79
打包　 79
Rapid 係統　 80
部署　 81
配置管理　 81
小結　 82
不僅僅隻對Google 有用　 83
一開始就進行發布工程　 83
第9 章　簡單化　 85
係統的穩定性與靈活性　 85
乏味是一種美德　 86
我絕對不放棄我的代碼　 86
“負代碼行”作為一個指標　 87
最小 API　 87
模塊化　 87
發布的簡單化　 88
小結　 88
第Ⅲ部分　具體實踐
第10 章　基於時間序列數據進行有效報警　 93
Borgmon 的起源　 94
應用軟件的監控埋點　 95
監控指標的收集　 96
時間序列數據的存儲　 97
標簽與嚮量　 98
Borg 規則計算　 99
報警　 104
監控係統的分片機製　 105
黑盒監控　 106
配置文件的維護　 106
十年之後　 108
第11 章　on-call 輪值　 109
介紹　 109
on-call 工程師的一天　 110
on-call 工作平衡　 111
數量上保持平衡　 111
質量上保持平衡　 111
補貼措施　 112
安全感　 112
避免運維壓力過大　 114
運維壓力過大　 114
奸詐的敵人—運維壓力不夠　 115
小結　 115
第12 章　有效的故障排查手段　 116
理論　 117
實踐　 119
故障報告　 119
定位　 119
檢查　 120
診斷　 122
測試和修復　 124
神奇的負麵結果　 125
治愈　 126
案例分析　 127
使故障排查更簡單　 130
小結　 130
第13 章　緊急事件響應　 131
當係統齣現問題時怎麼辦　 131
測試導緻的緊急事故　 132
細節　 132
響應　 132
事後總結　 132
變更部署帶來的緊急事故　 133
細節　 133
事故響應　 134
事後總結　 134
流程導緻的嚴重事故　 135
細節　 135
災難響應　 136
事後總結　 136
所有的問題都有解決方案　 137
嚮過去學習，而不是重復它　 138
為事故保留記錄　 138
提齣那些大的，甚至不可能的問題：假如……　 138
鼓勵主動測試　 138
小結　 138
第14 章　緊急事故管理　 140
無流程管理的緊急事故　 140
對這次無流程管理的事故的剖析　 141
過於關注技術問題　 141
溝通不暢　 141
不請自來　 142
緊急事故的流程管理要素　 142
嵌套式職責分離　 142
控製中心　 143
實時事故狀態文檔　 143
明確公開的職責交接　 143
一次流程管理良好的事故　 144
什麼時候對外宣布事故　 144
小結　 145
第15 章　事後總結：從失敗中學習　 146
Google 的事後總結哲學　 146
協作和知識共享　 148
建立事後總結文化　 149
小結以及不斷優化　 151
第16 章　跟蹤故障　 152
Escalator　 152
Outalator　 153
聚閤　 154
加標簽　 155
分析　 155
未預料到的好處　 156
第17 章　測試可靠性　 157
軟件測試的類型　 158
傳統測試　 159
生産測試　 160
創造一個構建和測試環境　 163
大規模測試　 165
測試大規模使用的工具　 166
針對災難的測試　 167
對速度的渴求　 168
發布到生産環境　 170
允許測試失敗　 170
集成　 172
生産環境探針　 173
小結　 175
第18 章　SRE 部門中的軟件工程實踐　 176
為什麼軟件工程項目對SRE 很重要　 176
Auxon 案例分析：項目背景和要解決的問題　 177
傳統的容量規劃方法　 177
解決方案：基於意圖的容量規劃　 179
基於意圖的容量規劃　 180
錶達産品意圖的先導條件　 181
Auxon 簡介　 182
需求和實現：成功和不足　 183
提升瞭解程度，推進采用率　 185
團隊內部組成　 187
在SRE 團隊中培養軟件工程風氣　 187
在SRE 團隊中建立起軟件工程氛圍：招聘與開發時間　 188
做到這一點　 189
小結　 190
第19 章　前端服務器的負載均衡　 191
有時候硬件並不能解決問題　 191
使用DNS 進行負載均衡　 192
負載均衡：虛擬IP　 194
第20 章　數據中心內部的負載均衡係統　 197
理想情況　 198
識彆異常任務：流速控製和跛腳鴨任務　 199
異常任務的簡單應對辦法：流速控製　 199
一個可靠的識彆異常任務的方法：跛腳鴨狀態　 200
利用劃分子集限製連接池大小　 201
選擇閤適的子集　 201
子集選擇算法一：隨機選擇　 202
子集選擇算法二：確定性算法　 204
負載均衡策略　 206
簡單輪詢算法　 206
最閑輪詢策略　 209
加權輪詢策略　 210
第21 章　應對過載　 212
QPS 陷阱　 213
給每個用戶設置限製　 213
客戶端側的節流機製　 214
重要性　 216
資源利用率信號　 217
處理過載錯誤　 217
決定何時重試　 218
連接造成的負載　 220
小結　 221
第22 章　處理連鎖故障　 223
連鎖故障産生的原因和如何從設計上避免　 224
服務器過載　 224
資源耗盡　 225
服務不可用　 228
防止軟件服務器過載　 228
隊列管理　 229
流量拋棄和優雅降級　 230
重試　 231
請求延遲和截止時間　 234
慢啓動和冷緩存　 236
保持調用棧永遠嚮下　 238
連鎖故障的觸發條件　 238
進程崩潰　 239
進程更新　 239
新的發布　 239
自然增長　 239
計劃中或計劃外的不可用　 239
連鎖故障的測試　 240
測試直到齣現故障，還要繼續測試　 240
測試最常用的客戶端　 241
測試非關鍵性後端　 242
解決連鎖故障的立即步驟　 242
增加資源　 242
停止健康檢查導緻的任務死亡　 242
重啓軟件服務器　 242
丟棄流量　 243
進入降級模式　 243
消除批處理負載　 244
消除有害的流量　 244
小結　 244
第23 章　管理關鍵狀態：利用分布式共識來提高可靠性　 246
使用共識係統的動力：分布式係統協調失敗　 248
案例1 ：腦裂問題　 249
案例2 ：需要人工乾預的災備切換　 249
案例3 ：有問題的小組成員算法　 249
分布式共識是如何工作的　 250
Paxos 概要：協議示例　 251
分布式共識的係統架構模式　 251
可靠的復製狀態機　 252
可靠的復製數據存儲和配置存儲　 252
使用領頭人選舉機製實現高可用的處理係統　 253
分布式協調和鎖服務　 253
可靠的分布式隊列和消息傳遞　 254
分布式共識係統的性能問題　 255
復閤式Paxos ：消息流過程詳解　 257
應對大量的讀操作　 258
法定租約　 259
分布式共識係統的性能與網絡延遲　 259
快速Paxos 協議：性能優化　 260
穩定的領頭人機製　 261
批處理　 262
磁盤訪問　 262
分布式共識係統的部署　 263
副本的數量　 263
副本的位置　 265
容量規劃和負載均衡　 266
對分布式共識係統的監控　 270
小結　 272
第24 章　分布式周期性任務係統　 273
Cron　 273
介紹　 273
可靠性　 274
Cron 任務和冪等性　 274
大規模Cron 係統　 275
對基礎設施的擴展　 275
對需求的擴展　 276
Google Cron 係統的構建過程　 277
跟蹤Cron 任務的狀態　 277
Paxos 協議的使用　 277
領頭人角色和追隨者角色　 278
保存狀態　 281
運維大型Cron 係統　 282
小結　 283
第25 章　數據處理流水綫　 284
流水綫設計模式的起源　 284
簡單流水綫設計模式與大數據　 284
周期性流水綫模式的挑戰　 285
工作分發不均造成的問題　 285
分布式環境中周期性數據流水綫的缺點　 286
監控周期性流水綫的問題　 287
驚群效應　 287
摩爾負載模式　 288
Google Workflow 簡介　 289
Workflow 是模型—視圖—控製器（MVC）模式　 290
Workflow 中的執行階段　 291
Workflow 正確性保障　 291
保障業務的持續性　 292
小結　 294
第26 章　數據完整性：讀寫一緻　 295
……
第27 章　可靠地進行産品的大規模發布　 322
……
第Ⅳ部分　管理
第28 章　迅速培養SRE 加入on-call　 341
……
第29 章　處理中斷性任務　 355
……
第30 章　通過嵌入SRE 的方式幫助團隊從運維過載中恢復　 363
……
第 31 章　SRE 與其他團隊的溝通與協作　 370
……
第32 章　SRE 參與模式的演進曆程　 383
……
第Ⅴ部分　結束語
第33 章　其他行業的實踐經驗　 398
……
第34 章　結語　 408
附錄A　係統可用性　 411
附錄B　生産環境運維過程中的最佳實踐　 412
附錄C　事故狀態文檔示範　 417
附錄D　事後總結示範　 419
附錄E　發布協調檢查列錶　 423
附錄F　生産環境會議記錄示範　 425
參考文獻　 427
索引　 439

精彩書摘

　　譯者序
　　當我在2016 年年初聽說本書的英文版即將麵世時，第一時間就意識到這將是一本不可多得的經典之作。我作為Google SRE 曾經的一員，看到本書中提到的那些熟悉的技術和理念時非常興奮——現在終於有機會用一種體係化、結構化的方式將這些知識和技術與大傢分享瞭！
　　Google SRE 全球共計約1000 人，負責運維Google 的大部分傢喻戶曉、不可或缺的商業應用。同時，SRE 還負責運維幕後那些全球首屈一指的計算基礎設施，不管是全球百萬颱級彆的服務器集群，還是全球一流的網絡架構，背後都有SRE 的身影。每個小的傳統運維問題在這個平颱上似乎都被無限放大瞭。但是與此同時，Google 恰恰又是利用最傳統、最樸素的軟件工程方法將其一一解決的。
　　SRE 是一群天生的懷疑論者，我們懷疑一切宣傳起來“高大上”的技術，以及任何“神奇”的産品——我們隻想看具體的設計架構、實現細節，以及真實的監控圖錶。SRE 在保障係統可靠性方麵並沒有什麼萬能藥，有的隻是這種極強的務實態度（pragmatic）。這種務實的態度決定瞭SRE 會認真對待運維問題。在設計評審中，他們會認真推演各種災難場景。在每周例會時，他們又會討論如何消除和防範事故發生、優化各種警報策略以及增強自動化功能。在平時工作中，他們則會精心維護團隊的各種文檔和項目源代碼，一點一點地提高服務質量。迴頭看來，SRE 其實是一群崇尚工匠主義的人，我們堅信隻要不斷地解決根源問題，服務質量就一定會得到提升。而SRE 正是用這種“日拱一卒”的方法造就瞭Google 這個世界級的奇跡。
　　本書的風格亦是如此。書中很多章節用務實的語言記錄瞭Google SRE 團隊在麵臨各種睏難時的思考過程、所采用的解決方案以及事後總結的經驗教訓。本書中沒有介紹任何“魔法係統”，也沒有提供任何“奇技淫巧”，有的隻是對問題本質發人深省的深入探討。從這種意義上講，本書體係化地覆蓋瞭運維工作的方方麵麵，是一本運維行業的教科書。我希望通過翻譯此書，能將這種體係和理念分享給更多的人。期待與大傢更深入地探討與交流！
　　迴首在Google 度過的8 年時光，我想感謝我所有的前同事，感謝他們對我的各種幫助，這段職業經曆是我終生難忘的。而且，我還要感謝我的傢人，是他們的耐心陪伴和幫助纔讓我踏踏實實地度過瞭這200 多個小時，完成瞭我人生中最大的一個Project。
　　孫宇聰
　　2016 年8 月3 日 傍晚

前言/序言

　　如果用一個詞語來描述 Google 的曆史，那就是不斷地“擴大規模”（scaling up）。Google 的成長經曆，是計算機行業中數一數二的成功故事，標誌著整個社會嚮 IT 為中心的商業模式的轉變。Google 很早就開始實踐 IT 與商業模式的結閤，也是嚮社區推廣DevOps 理念的先行者。本書就是由來自公司各個部門，切身參與甚至主導瞭整個行業轉型實踐的人寫成的。
　　Google 是在一個係統運維工程師行業轉型的階段發展壯大的。Google 的發展史就像是對傳統的係統運維理念發齣的革命宣言：我們無法按照傳統方式運維Google 係統，必須要思考一種新的模式，但是同時我們也沒有時間等待其他人驗證和支持我們的理論。在Principles of Network and System Administration（參見文獻[bur99]）一書的介紹中，我提齣瞭一種觀點：係統運維本質上是人與計算機共同參與的一項係統性工程。當時的一些評論者對這種觀點錶示瞭強烈的反對：“這個行業還遠遠沒有成熟到可以稱為一項工程”。在那時，我甚至對整個運維行業産生瞭懷疑，認為這個行業在個人英雄主義與神秘色彩中已經永久地迷失瞭自己，無法前進。但是，這時Google 誕生瞭，Google 的高速發展將我的預言變成瞭現實。我之前的定義變成瞭一個具體的詞語：SRE，站點可靠性工程師。我的幾個朋友切身參與瞭這個新職業的創立，用軟件工程理念和自動化工具定義瞭這個行業。一開始，他們顯得很神秘，Google 公司內的體驗和整個行業也格格不入，Google 太特殊瞭！ 隨著時間的推移，公司內外交流逐漸增多。這本書的目標就是將SRE 的一些思考和實踐帶給整個行業，以促進交流。
　　在本書中，我們不僅僅展示瞭 Google 是如何建設維護其富有傳奇色彩的大型計算集群的。更重要的是，我們展示瞭在建設過程中，Google 工程師團隊是如何學習、成長、反復修改，zui後定義齣一套完整的工具和科技體係的過程。IT 行業大多自我封閉，交流過少，很多從業人員都或多或少地受教條主義的限製。如果Google 工程師團隊能剋服這個慣性，保持開放的精神，那麼我們也能夠一起和他們麵對 IT 行業內zui尖端的挑戰。
　　這本書由一群有共同目標的 Google 工程師寫就的短文組成。本書的作者們聚集在同一個公司旗下，為瞭同一個目標努力，本身就是一件很特彆的事情。在本書的各個章節之間經常能看到軟件係統的共同點，以及工作模式上的共通之處。我們經常可以從多個角度分析不同的決策選擇，瞭解他們是如何一起解決公司內部多種利益衝突的。這些文章並不是嚴謹的學術研究論文，而是這些人的切身經曆。雖然本書的作者們有著不同的工作目標、寫作風格，以及技術背景，但是他們都嘗試著去真誠地描述自己遇到的問題和解決的經曆。這和 IT 行業內的普遍文風截然不同，風格迥異。有些作者會宣稱：“不要做A，隻有做B 纔是正確的。” 另一些作者會更謹慎，行文更富有哲學性。這其實恰恰代錶瞭整個 IT 行業內不同個性融閤的現狀。而我們作為讀者，作為觀察者，並不瞭解整個Google 的曆史，也沒有參與到具體的決策過程中，無法全麵瞭解當事人所麵臨的糾纏不清的挑戰，隻能帶著謙遜的態度遠遠旁觀。在閱讀本書的過程中，相信讀者一定會産生齣許多疑問：“他們當時為什麼沒有選擇X ？”“ 如果他們選擇瞭Y，結果會是怎樣？”“ 如果多年之後迴頭再看，這個選擇會是正確的嗎?” 這些問題，恰恰是閱讀本書的zui大收獲，因為我們第1次有機會將自己的經曆、選擇和本書陳列的決策邏輯相互對應，從中發現不足和缺陷。
　　這本書的成書過程也堪稱奇跡。今天，我們能感受到整個行業都在鼓吹厚顔無恥的 “代碼拿來主義”（just show me the code）。開源軟件社區內部正在形成一種“不要問我問題”的風氣，過於強調平等卻忽略領域專傢的意見。Google 是行業內為數不多的，願意投入精英力量鑽研本質問題的公司，而且這些公司精英很多都有工學博士學位。工具永遠隻是解決方案中的一個小小組件，用來鏈接日益龐雜的軟件、人和海量的數據。這本書中沒有萬能藥，沒有什麼東西能解決一切問題，但是這恰恰是本書的宗旨：相比zui後的軟件結果、架構設計而言，真實的設計過程、作者本身的思考經曆更有價值。實現細節永遠隻是短暫存在的，但是文檔化的設計過程卻是無價之寶。有機會瞭解到這些設計的內幕真是太難得瞭！
　　這本書，歸根到底，記錄瞭 Google 這個公司的成長經曆。書中的很多故事都是由相互重疊的故事組成的，這恰恰說明瞭擴展一個計算機係統，要比簡單按照書本上的標準架構放大睏難得多。一個公司的成長，意味著整個公司商業模式和工作模式的擴展，而不是簡單的資源擴張。僅此一點，這本書就物超所值瞭。
　　自省，是一個在 IT 行業內部並不流行的詞語。我們不斷重復發明各種係統。很多年以來，隻有 USENIX LISA 大會論壇以及其他幾個專注於操作係統的會議會討論一些 IT 基礎設施的設計和實現。很多年後的今天，IT 行業已經天翻地覆，但是本書仍然彌足珍貴：它詳細記錄瞭Google 邁過分水嶺時期的全過程。很顯然，這些經曆沒有辦法完全復製，也許隻能被模仿，但是卻可以啓發讀者，指引未來。本書作者們錶現齣瞭極大的真誠，顯示瞭謙遜的風格，以及極強的凝聚力、領導力。這些文章記錄瞭作者們的希望、擔憂、成功與失敗的經曆。我嚮這些作者們和編者們的勇氣緻敬，正是這種坦率，讓我們能夠作為旁觀者和後來人，從前人的經曆中學習到zui寶貴的知識。
　　Mark Burgess
　　In Search of Certainty 一書作者
　　Oslo，2016 年3 月
　　序言
　　軟件工程有的時候和養孩子類似：雖然生育的過程是痛苦和睏難的，但是養育孩子成人的過程纔是真正需要花費絕大部分精力的地方。但是，傳統軟件工程專業花費瞭很多精力討論軟件的開發過程，而不是其後的維護過程。有統計顯示， 一個軟件係統的40%~90% 的花銷其實是花在開發建設完成之後不斷維護過程中的。行業內流行的一個說法是：一個係統如果已經開發完成，部署在生産環境上，那麼它就是 “穩定的”，就不需要那麼多工程師花費精力去優化、維護。我們認為這個說法是錯誤的。從這個視角齣發，我們認為如果軟件工程職業主要專注於設計和構建軟件係統， 那麼應該有另外一種職業專注於整個軟件係統的生命周期管理。從其設計一直到部署，曆經不斷改進，zui後順利退役。這樣一種職業必須具備非常廣泛的技能，但是和其他職業的專注點都不同。Google 將這個職位稱為站點可靠性工程師（SRE，Site Reliability Engineering）。
　　那麼，站點可靠性工程師究竟代錶著什麼呢？的確，這個詞語並不能夠特彆清晰地描述這個職位的意義。基本上每個 Google SRE 都會被經常問到這個職位到底代錶什麼意思，以及他們的日常工作究竟是什麼。
　　將這個詞語展開來說：首先，也是zui重要的一點，SRE 是工程師（engineer）。SRE 使用計算機科學和軟件工程手段來設計和研發大型、分布式計算機軟件係統。有的時候，SRE 和産品研發團隊共同工作，其他時候我們需要開發這些係統的額外組件：例如備份係統和負載均衡係統等。理想情況下，同時推進這些組件在多個項目中復用。還有的時候，我們的任務是想齣各種各樣的辦法用現有組件解決新的問題。
　　其次，SRE 的關注焦點在於可靠性。Ben Treynor Sloss，Google 負責7×24 運維的副總裁，SRE 名稱的發明者，宣稱可靠性應該是任何産品設計中zui基本的概念：任何一個係統如果沒有人能夠穩定地使用，就沒有存在的意義。因為可靠性 是如此重要，因此SRE 專注於對其負責的軟件係統架構設計、運維流程的不斷優化，讓這些大型軟件係統運行得更可靠，擴展性更好，能更有效地利用資源。但是，SRE 並不是無止境地追求完美：當一個係統已經 “足夠可靠” 的時候，SRE 通常將精力轉而投入到研發新的功能和創造新的産品中。
　　zui後，SRE 的主要工作是運維在分布式集群管理係統上運行的具體業務服務（service）。不論是遍布全球的存儲服務，還是億萬用戶賴以工作的 E-mail 服務，還是 Google zui初的 Web 搜索服務。SRE 中的“ S” zui開始指代的就是google.com 的運維服務，因為SRE的第1個工作就是維持網站的正常運轉。隨著時間的推移，SRE 逐漸接管瞭 Google 內部絕大部分産品係統，包括 Google Cloud Platform 這類開發者平颱，也包括內部的一些非網站類的基礎設施係統，例如 Bigtable。
　　雖然我們在這裏將 SRE 的職位定義得比較寬泛，但是在這樣一個互聯網業務高速發展的時代，這個職位的齣現毫不奇怪。同樣，雖然在應用係統運營維護的過程中有數不清的重要環節需要關注，我們zui關注的是“可靠性”這一點也不奇怪。在Web 服務領域裏，對服務器端軟件的優化和修改是相對可控的，變更管理與生産安全又結閤得非常緊密，一種類似於 SRE 的職業早晚會在這個環境下誕生。
　　雖然 SRE 這個行業是在 Google 內部，從Web 社區中誕生的，但我們認為這個職業對其他團隊和組織也有很多值得藉鑒的地方。本書是對闡述SRE 發展過程的一次嘗試：我們既希望將這些寶貴經驗共享給其他相關行業，也希望能從其他行業中汲取知識，從而更好地定義各種角色和術語。為瞭這個目的，本書將通用的理論、設計理念和思想，與實際的應用工具介紹等分開。在某些需要結閤Google 內部信息討論主題的時候，我們相信讀者可以進行類比，將書中的理念與自己的實際環境相結閤，以便得齣更為有效的結論。本書中也包含瞭一些對 Google 內部生産環境的介紹，將 Google 內部環境與外部常見的開源類軟件相對應。這樣可以讓本書的一些設計理念與實踐的結閤度更強，應用起來更容易。
　　zui後，我們當然希望社區內齣現更多、更可靠的軟件係統。我們知道，創業企業甚至中型企業經常對如何應用這些理念和技術感到睏惑。可靠性就像安全性，越早關注越好。這就意味著一些小型創業公司，在應付日常麵臨的種種挑戰時，也應該抽齣一部分精力來麵對可靠性這個話題。這與蓋房子有些類似，如果一開始將整個地基打好並保持繼續修繕，要比蓋好房子之後再重新修改設計要容易得多。本書第4 部分著重介紹瞭 SRE 團隊如何進行內部培訓、如何加強內部溝通等zui佳實踐，很多都可以直接拿來應用。
　　對中型企業來說，企業內部可能已經有這樣的一組人在做著與SRE 非常類似的工作。這些人可能並不叫 SRE 這個名字，甚至可能沒有受到管理層的重視。在這樣的企業中，提高可靠性zui好的辦法往往就是去認可這些人的工作，並配備足夠的激勵機製。在牛頓被世界正式認可為物理學傢之前，他經常被稱作是zui後的煉金術師。而這些專注於可靠性的工程師們，正如當年的牛頓一樣，是一個新時代的開拓者。
　　如果一定要為SRE 尋找一個起源的話，誰纔能夠被稱為世界上第1個SRE 呢？我們選擇瞭 Margaret Hamilton，MIT 教授，參與瞭阿波羅登月計劃的軟件開發工作。她的工作具有現代SRE 的一切特性。用她自己的話來講：“團隊文化就是從一切經曆中不斷學習，包括來自那些我們zui意想不到的地方的經曆。”
　　在Apollo 7 飛船研發期間的某一天，Margaret 帶著她的小女兒 Lauren 一起來到公司。在 Margaret 忙著和組員們在大型計算機上運行飛行模擬測試的時候，她的小女兒偷偷地按下瞭控製颱上的 DSKY 鍵。整個模擬程序齣乎意料地崩潰瞭，導緻整個火箭發射程序意外終止。Margaret 和組員調試後發現，原來Lauren 意外觸發瞭 P01 這段子程序的執行，導緻瞭整個模擬過程的失敗。（該子程序是起飛前調試程序，執行時會刪除現存的導航信息，如果在火箭飛行過程中執行這段程序，計算機將無法繼續維持火箭航綫，後果將是災難性的。）
　　憑藉著 SRE 的直覺， Margaret 為項目組提交瞭一個軟件改動，申請在飛行程序中增加一項特殊狀態檢查，以避免飛行員在飛行過程中意外觸發P01 程序的執行。但不幸的是，NASA 管理層認為，這項錯誤發生的可能性太小，根本不值得為此添加這項修改。於是Margaret 沒有能夠成功提交這項軟件修改。她隻能在火箭飛行手冊中添加瞭一段文字，寫道：“在飛行過程中，請勿觸發P01 程序。” （當時增加這段文字時，很多NASA 工程師都認為這很好笑，認為Margaret 是小題大做，幾乎所有人都認為宇航員經過如此長時間的專業訓練，是絕對不會犯如此低級的錯誤的。）
　　幾天後，在Apollo 8 飛船執行下一項飛行任務時。宇航員 Jim Lovell、William Anders和Frank Borman 三人執行一個長達四天的飛行計劃途中，Jim Lovell 意外地觸發瞭 P01程序的執行。更巧的是，當天正好是美國聖誕節，大部分工程師都休假去瞭。可想而知，當時NASA 的一片混亂狀態。這次不是演習，而是人命關天的危急時刻，如果不能及時解決，三名宇航員將永遠無法安全返迴瞭。所幸，當時 Margaret 的飛行手冊更新中恰恰提到瞭這種情形，並且提供瞭重新上傳數據以及恢復執行的有效辦法，在有限的時間內解決瞭問題，使任務可以繼續進行。
　　Margaret 曾經說過：“無論對一個軟件係統運行原理掌握得多麼徹底，也不能阻止人犯意外錯誤。” 在這次危機過後，Margaret 之前提交的修改申請很快就被批準瞭。
　　雖然Apollo 8 的事故發生在幾十年前，但是工程師們一定不會對此感到陌生， 類似的場景總是在不斷重演。希望讀者以史為鑒，隻有靠著對細節的不懈關注，做好充足的災難預案和準備工作，時刻警惕著，不放過一切機會去避免災難發生。這就是SRE zui重要的理念！歡迎加入SRE 的大傢庭！
　　如何閱讀本書
　　這本書是由一係列短文組成的， 由Google SRE 成員和前成員共同寫就。相比之下，這本書更像是一本會議文集。本書的每一章都可以作為一個獨立部分進行閱讀，但是讀者也可以根據自己的興趣選擇某些章節重點閱讀。（如果本書中引用瞭某些額外文章，你可以在參考文獻中找到。）
　　讀者可以按照任何順序閱讀本書，但是我們推薦從第2 章和第3 章開始。這兩章描述瞭Google 的生産運行環境，以及SRE 是如何係統化認知與量化“風險”的（畢竟 “風險” 是SRE zui關注的要點）。讀者當然也可以選擇逐章閱讀，本書邏輯上分為以下幾個部分：理念性介紹（第Ⅱ部分）、zui佳實踐（第Ⅲ部分）和管理經驗（第Ⅳ部分）。每一部分都配有簡介，並且配有SRE 成員以前發錶的文章的引用地址。
　　最後，本書配有網站https://g.co/SREBook，其中包括瞭一些有益讀物， 希望讀者能從中獲得閱讀的樂趣。
　　……

評分☆☆☆☆☆

這本書對於我的工作很有幫助。IT行業的知識更新太快，終生學習是非常有必要的，時刻準備著迎接新生技術！

評分☆☆☆☆☆

很好的書 天天都翻一翻

評分☆☆☆☆☆

還不錯，挺好的，下次還在這裏買咯。

評分☆☆☆☆☆

書不錯，很專業的圖書，，還很喜歡

評分☆☆☆☆☆

物美價廉非常閤適，給我一次滿意的購物，京東會員還不錯，免郵費。

評分☆☆☆☆☆

京東送貨很給力，書也不錯

評分☆☆☆☆☆

圖書節購買，囤貨，囤知識。超贊

評分☆☆☆☆☆

聽說很好，但畢竟是人傢的技術經驗積纍，我們隻能參考，學習思路。

評分☆☆☆☆☆

運維指南。都是理念