SRE：Google 運維解密

<內容簡介>

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

大型軟件系統生命週期的絕大部分都處於“使用”階段，而非“設計”或“實現”階段。那麼為什麼我們卻總是認為軟件工程應該首要關注設計和實現呢？在本書中，Google SRE的關鍵成員解釋了他們是如何對軟件進行生命週期的整體性關注的，以及為什麼這樣做能夠幫助Google成功地構建、部署、監控和運維世界上現存最大的軟件系統。通過閱讀本書，讀者可以學習到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一職。回國後，積極推動國內容器化運維架構升級。目前是開放運維聯盟之應用運維規範制定組，高可用運維規範制定者。

序言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
數據完整性的強需求296
提供超高的數據完整性的策略297
備份與存檔298
雲計算環境下的需求299
保障數據完整性和可用性：Google SRE的目標300
數據完整性是手段，數據可用性是目標300
交付一個恢復系統，而非備份系統301
造成數據丟失的事故類型301
維護數據完整性的深度和廣度的困難之處303
Google SRE保障數據完整性的手段304
24種數據完整性的事故組合304
第一層：軟刪除305
第二層：備份和相關的恢復方法306
額外一層：複製機制308
1T vs. 1E ：存儲更多數據沒那麼簡單309
第三層：早期預警310
確保數據恢復策略可以正常工作313
案例分析314
Gmail—2011年2月：從GTape上恢復數據（磁帶） 314
Google Music—2012年3月：一次意外刪除事故的檢測過程315
SRE的基本理念在數據完整性上的應用319
保持初學者的心態319
信任但要驗證320
xxvi ｜目錄
不要一廂情願320
縱深防禦320
小結321
第27章可靠地進行產品的大規模發布322
發布協調工程師323
發布協調工程師的角色324
建立發布流程325
發布檢查列表326
推動融合和簡化326
發布未知的產品327
起草一個發布檢查列表327
架構與依賴328
集成328
容量規劃328
故障模式329
客戶端行為329
流程與自動化330
開發流程330
外部依賴331
發布計劃331
可靠發布所需要的方法論332
灰度和階段性發布332
功能開關框架333
應對客戶端濫用行為334
過載行為和壓力測試335
LCE的發展335
LCE檢查列表的變遷336
LCE沒有解決的問題337
小結338
第Ⅳ部分管理
第28章迅速培養SRE加入on-call 341
新的SRE已經招聘到了，接下來怎麼辦341
培訓初期：重體系，而非混亂344
系統性、累積型的學習方式345
目標性強的項目工作，而非瑣事346
培養反向工程能力和隨機應變能力347
反向工程：弄明白系統如何工作347
統計學和比較性思維：在壓力下堅持科學方法論347
隨機應變的能力：當意料之外的事情發生時怎麼辦348
將知識串聯起來：反向工程某個生產環境服務348
有抱負的on-call工程師的5個特點349
對事故的渴望：事後總結的閱讀和書寫349
故障處理分角色演習350
破壞真的東西，並且修復它們351
維護文檔是學徒任務的一部分352
儘早、盡快見習on-call 353
on-call之後：通過培訓的儀式感，以及日後的持續教育354
小結354
第29章處理中斷性任務355
管理運維負載356
如何決策對中斷性任務的處理策略356
不完美的機器357
流狀態357
將一件事情做好358
實際一點的建議359
減少中斷361
第30章通過嵌入SRE的方式幫助團隊從運維過載中恢復363
第一階段：了解服務，了解上下文364
確定很大的壓力來源364
找到導火索364
第二階段：分享背景知識365
書寫一個好的事後總結作為示範366
將緊急事件按類型排序366
第三階段：主導改變367
從基礎開始367
獲取團隊成員的幫助367
解釋你的邏輯推理過程368
提出引導性問題368
小結369
第31章SRE與其他團隊的溝通與協作370
溝通：生產會議371
議程372
出席人員373
SRE的內部協作374
團隊構成375
高效工作的技術375
SRE內部的協作案例分析：Viceroy 376
Viceroy的誕生376
所面臨的挑戰378
建議379
SRE與其他部門之間的協作380
案例分析：將DFP遷移到F1 380
小結382
第32章SRE參與模式的演進歷程383
SRE參與模式：是什麼、怎麼樣以及為什麼383
PRR模型384
SRE參與模型384
替代性支持385
PRR ：簡單PRR模型386
參與386
分析387
改進和重構387
培訓388
“接手”服務388
持續改進388
簡單PRR模型的演進：早期參與模型389
早期參與模型的適用對象389
早期參與模型的優勢390
不斷發展的服務：框架和SRE平台391
經驗教訓391
影響SRE的外部因素392
結構化的解決方案：框架392
新服務和管理優勢394
小結395
第Ⅴ部分結束語
第33章其他行業的實踐經驗398
有其他行業背景的資深SRE 399
災難預案與演習400
從組織架構層面堅持不懈地對安全進行關注401
關注任何細節401
冗餘容量401
模擬以及進行線上災難演習402
培訓與考核402
對詳細的需求收集和系統設計的關注402
縱深防禦403
事後總結的文化403
將重複性工作自動化，消除運維負載404
結構化和理性的決策406
小結407
第34章結語408
附錄A系統可用性411
附錄B生產環境運維過程中的佳實踐412
附錄C事故狀態文檔示範417
附錄D事後總結示範419
附錄E發布協調檢查列表423
附錄F生產環境會議記錄示範425
參考文獻427
索引439__