-- 會員 / 註冊 --  
 帳號:
 密碼:
  | 註冊 | 忘記密碼
3/26 新書到! 3/19 新書到! 3/14 新書到! 12/12 新書到!
購書流程Q & A站務留言版客服信箱
3ds MaxMayaRhinoAfter EffectsSketchUpZBrushPainterUnity
PhotoShopAutoCadMasterCamSolidWorksCreoUGRevitNuke
C#CC++Java遊戲程式Linux嵌入式PLCFPGAMatlab
駭客資料庫搜索引擎影像處理FluentVR+ARANSYS深度學習
單晶片AVROpenGLArduinoRaspberry Pi電路設計CadenceProtel
HadoopPythonStm32CortexLabview手機程式AndroidiPhone
可查書名,作者,ISBN,3dwoo書號
詳細書籍分類

SRE:Google運維解密

( 簡體 字)
作者:(美)Betsy Beyer(貝特西 拜爾)等類別:1. -> 程式設計 -> 綜合
譯者:
出版社:電子工業出版社SRE:Google運維解密 3dWoo書號: 45142
詢問書籍請說出此書號!

缺書
NT售價: 540

出版日:9/1/2016
頁數:480
光碟數:0
站長推薦:
印刷:黑白印刷語系: ( 簡體 版 )
加入購物車 加到我的最愛
(請先登入會員)
ISBN:9787121297267
作者序 | 譯者序 | 前言 | 內容簡介 | 目錄 | 
(簡體書上所述之下載連結耗時費功, 恕不適用在台灣, 若讀者需要請自行嘗試, 恕不保證)
作者序:

譯者序:

前言:

內容簡介:

大型軟件系統生命周期的絕大部分都處于“使用”階段,而非“設計”或“實現”階段。那么為什么我們卻總是認為軟件工程應該首要關注設計和實現呢?在《SRE:Google運維解密》中,Google SRE的關鍵成員解釋了他們是如何對軟件進行生命周期的整體性關注的,以及為什么這樣做能夠幫助Google成功地構建、部署、監控和運維世界上現存最大的軟件系統。通過閱讀《SRE:Google運維解密》,讀者可以學習到Google工程師在提高系統部署規模、改進可靠性和資源利用效率方面的指導思想與具體實踐——這些都是可以立即直接應用的寶貴經驗。
任何一個想要創建、擴展大規模集成系統的人都應該閱讀《SRE:Google運維解密》。《SRE: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
數據完整性的強需求   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__
序: