SRE:Google運維解密

SRE:Google運維解密

《SRE:Google運維解密》 作者Betsy Beyer等,孫宇聰譯,電子工業出版社2016年10月出版。

內容提要

大型軟體系統生命周期的絕大部分都處於“使用”階段,而非“設計”或“實現”階段。那么為什麼我們卻總是認為軟體工程應該首要關注設計和實現呢?在《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一職。回國後,積極推動國內容器化運維架構升級。目前是開放運維聯盟之套用運維規範制定組,高可用運維規範制定者。

目錄

前言 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

數據完整性的強需求 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

不要一廂情願 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

相關詞條

熱門詞條

聯絡我們