●緒論1
第一部分SRE實施
第1章SRE中的上下文與控制7
第2章面試站點可靠性工程師17
面試10117
誰參與17
行業與大學18
偏見18
漏鬥18
SRE漏鬥19
電話篩查20
現場面試20
帶回家的問題22
面試SRE的最終思考24
延伸閱讀24
第3章你想建立一個SRE團隊嗎?25
出於正確的原因選擇SRE26
面向數據驅動方法28
對SRE的承諾29
做出關於SRE的決定30
第4章使用事件指標在規模上
提高SRE31
救援到良性循環：你需要測量……31
指標回顧：如果指標無法找到……33
代理指標34
修復債務35
虛擬修復債務：在機器中驅除幽靈36
實時儀表板：SRE的面包和黃油37
學習：終身學習38
延伸閱讀38
第5章與第三方合作的藝術39
自建、購買或采用？39
建立重要性40
確定利益相關者40
做出決策41
承認現實42
第三方作為“一等公民”45
當他們倒下時，你也倒下46
像服務一樣運行黑匣子48
服務級別指標、服務級別目標和SLA49
行動手冊：從預發布到生產51
總結想法58
第6章如何在沒有專用SRE團隊的情況下應用SRE
原則60
向SRE求救（以及他們如何失敗）60
按員工人數計算的規模問題61
嵌入式SRE61
你建造它，你就得運行它62
部署平臺62
完成循環：自行運維63
介紹生產工程團隊64
一些實施詳細信息66
開發人員的工作效率和健康與監控66
使用事後分析解決跨團隊可靠性問題68
統一的基礎設施和工具與自主和創新69
獲得支持者70
小結72
延伸閱讀73
第7章無SRE的SRE模式：Spotify案例研究74
蹣跚學步：2006–200775
前奏75
關鍵收獲76
測試版和正式發布：2008–200976
前奏77
將可擴展性和可靠性帶到前沿78
關鍵收獲79
成功的詛咒：201080
前奏80
新的所有權模型81
核心服務正規化82
部署時間的抉擇83
輪值和警報83
生成內部辦公室支持84
解決剩餘首要問題84
創建偵探85
關鍵收獲86
寵物和動物，以及敏捷：201187
前奏87
形成不良習慣88
打破那些壞習慣88
關鍵收獲89
無法擴展的繫統：201289
前奏89
手工運維踫壁90
關鍵收獲91
介紹小組內嵌運維：2013–201591
前奏91
以信任為基礎94
推動模式轉變95
關鍵收獲96
自主性與一致性的權衡：2015–201796
前奏97
受益之處98
權衡98
關鍵收獲99
未來：規模化的速度和安全99
第8章大型企業SRE的介紹103
背景103
介紹SRE104
定義當前狀態104
識別和教育利益相關者106
展示業務案例108
實施SRE團隊109
經驗和教訓111
實施路線圖示例112
總結反思114
延伸閱讀114
第9章從繫統管理員到SRE115
澄清術語116
服務級別指示器116
SLA117
服務級別目標117
為內部組件建立SLA119
了解外部依賴關繫125
非技術解決方案127
跟蹤可用性級別128
處理罕見情況133
小結135
第10章為企業中的SRE掃清道路137
瑣事，SRE的敵人138
企業中的瑣事141
孤島、隊列和工單141
路上的孤島142
工單驅動的請求隊列成本高昂144
立即行動146
從精益開始146
盡可能多地擺脫交接150
將剩餘的移交替換為自助服務153
自助服務不僅僅是一個按鈕154
自助服務以多種方式幫助SRE155
運維作為服務156
錯誤預算、瑣事和其他增強人類能力的工具159
錯誤預算159
瑣事上限160
利用DevOps的現有熱情161
統一任務列表並保護容量161
心理安全與人為因素162
加入運動163
第11章SRE模式深受DevOps的熱愛164
模式1：Google誕生的自動測試165
模式2：在谷歌啟動和移交準備審查167
模式3：創建共享源代碼存儲庫170
小結172
進一步閱讀和源材料172
第12章DevOps和SRE：來自社區的聲音174
背景174
方法174
結果175
回復175
第13章Facebook的生產工程師191
第二部分SRE前沿領域
第14章起初，有混沌215
繫統問題216
復雜性的經濟支柱218
開始混沌219
安全和復雜性的權衡220
混沌變大221
形式化221
高級原則222
常見問題223
小結225
第15章可靠性與隱私的交集226
可靠性與隱私的交集概述227
隱私工程的一般景觀228
隱私和SRE：常見方法230
減少辛勞230
高效、慎重地解決問題232
關繫管理233
早期干預與價值觀傳播233
細微差別、差異和權衡235
小結236
延伸閱讀236
第16章數據庫可靠性工程237
數據庫可靠性工程師的指導原則237
保護數據238
自助縮放服務238
數據庫不特殊239
數據庫可靠性工程文化240
可恢復性241
恢復注意事項241
恢復策略的剖析242
構建基塊1：檢測242
構建基塊2：多樣化的存儲244
構建基塊3：各種工具箱245
構建基塊4：測試246
倡導恢復可靠性247
持續交付：從開發到生產247
協作249
部署249
遷移和版本控制249
影響分析250
遷移模式250
倡導CD251
為DBRE提供支持252
延伸閱讀252
第17章數據耐久性工程253
復制是基礎253
備份253
復制254
真實世界的耐久性257
保護261
測試261
保障262
恢復262
驗證263
零的力量264
驗證範圍264
監視器的觀察者266
自動化266
漏洞之窗266
運維人員疲勞267
可靠性267
小結268
第18章SRE機器學習概述270
為什麼要使用機器學習輔助SRE工作？270
為什麼我的公司應該如何參與這項工作？271
AI應用方面的覺醒272
什麼是機器學習？273
我們所說的學習是什麼意思？274
從國際像棋到圍棋：我們可以潛水有多深？276
為什麼是現在？我們改變了什麼？277
什麼是神經網絡？278
應該如何以及何時應用神經網絡？280
我們可以使用哪些類型的數據？280
實用機器學習281
神經網絡的熱門庫281
實用機器學習示例282
成功案例296
延伸閱讀297
我的GitHub存儲庫297
推薦書籍297
第三部分SRE很好實踐和技術
第19章使文檔更好：將文檔集成到工作流程中301
定義質量：好文檔是什麼樣子的？302
SRE文檔的功能要求304
將文檔集成到工程的工作流中306
谷歌的經驗：g3doc和EngPlay307
我們學到的知識310
更好的文檔：很好實踐311
為每個文檔類型創建模板311
更好>很好：為質量設定現實標準313
要求將文檔作為代碼評審的一部分313
大膽地修剪你的文檔314
對文檔進行表彰和獎勵314
傳達文檔的價值315
延伸閱讀317
第20章主動教學和自學319
主動學習320
主動學習示例：不幸之輪321
活動學習示例：事件管理（紙牌遊戲）322
活動學習示例：SRE教室326
不能學習的代價327
有效SRE團隊的學習氛圍328
生產會議328
故障報告329
行動號召：放棄無聊的幻燈片330
第21章服務級別目標的藝術與科學331
為什麼要設定目標？331
可用性332
時間計量333
事務334
時間跨度的事務統計334
關於評估SLO335
直方圖338
百分位數的不足之處（和直方圖的優點）339
思路的不同：自底向上的分析SLO339
延伸閱讀340
第22章SRE作為一種成功文化341
SRE是從哪裡來的？341
SRE的關鍵價值343
保持網站運行343
授權團隊“做正確的事情”345
將運維視為工程問題346
通過承諾（服務級別）實現業務成功347
SRE的關鍵啟用功能348
監視、指標和KPI348
事件管理和應急響應349
容量規劃和需求預測349
性能分析和優化349
預配、更改管理和速度349
SRE執行階段350
第1階段：滅火/應急350
第2階段：守門員350
第3階段：倡導者/合作伙伴351
第4階段：催化351
不同階段的並發癥352
關注成功的細節352
延伸閱讀353
第23章SRE反模式354
反模式1：站點可靠性運維355
反模式2：人類盯著屏幕356
反模式3：事件響應時一窩蜂357
反模式4：根本原因=人為錯誤358
反模式5：丟包袱360
反模式6：馬戲團表演模式！361
反模式7：警報可靠性工程362
反模式8：雇用他人來遛狗363
反模式9：減速帶工程364
反模式10：設計阻塞點365
反模式11：批評太多，鼓勵不夠366
反模式12：推遲生產環境發布368
反模式13：優先避免故障而不追求快速恢復（MTTF>MTTR）369
反模式14：依賴性地獄371
反模式15：笨拙的治理372
反模式16：考慮不周的SLO373
反模式17：讓人惱火的API接口374
反模式18：修復運維團隊376
那麼，這就足夠了嗎？377
第24章不變的基礎架構和SRE379
可擴展性、可靠性和性能379
故障恢復380
更簡單的運維380
更快的啟動時間381
已知狀態381
自信地完成持續集成/持續部署382
安全性382
多區域操作383
發布的工程學383
構建基本鏡像384
部署應用程序385
缺點385
小結386
第25章可編寫腳本的負載均衡器387
可編寫腳本的負載均衡器：新新人類387
使困難變得簡單389
分片感知路由390
利用潛力394
案例研究：休息時間394
服務級別中間件395
作為救援的中間件397
服務級別中間件的API397
案例研究：WAF/Bot緩解397
避免災難398
獲得狀態的技巧398
案例研究：結賬隊列400
展望未來，進一步閱讀401
第26章服務網格化：微服務的牧人？403
準備好擺脫全家桶了嗎？404
微服務網絡的當前狀態405
服務網格來救援407
邊三輪代理的好處408
最終一致的服務發現409
可觀察性和報警機制410
邊三輪性能影響411
精簡庫和上下文傳播412
配置管理（控制平面與數據平面）413
實踐中的服務網格414
Envoy在Lyft的起源與發展415
Lyft運維的Envoy416
服務網格的未來418
延伸閱讀418
第四部分SRE的人性化一面
第27章SRE的心理安全421
成功團隊的主要指標421
延伸閱讀430
第28章SRE認知工作431
簡介431
SRE人員是做什麼的？432
我們為什麼要關心從業者認知？433
在不確定性和時間壓力下做出的關鍵決策無法重現434
現代復雜繫統中的人類表現：主題434
關於圍繞事件的SRE認知工作的觀察435
每一次事件都可能更糟435
在不確定的情況下做出犧牲性決策436
正常繫統的維修437
關於復雜繫統的專業知識438
管理協調成本439
SRE是聯合認知繫統中工作的認知主體439
知識校準問題440
心理模型441
事件觸發個人重新校準443
事件是集體重新校準的機會443
這一切意味著什麼？444
事件將繼續444
事件將導致代價445
事件模式將發生變化446
事件指向特定的校準問題和位置447
接下來會發生什麼？447
構建案例庫447
專注於使自動化成為SRE中的團隊合作者448
解決校準問題449
你能做什麼？450
小結451
參考451
第29章勝過倦怠454
定義精神障礙456
純潔不是業務需求458
光是思想和祈禱還不夠459
全棧包容性459
申請職務460
面試過程461
薪酬462
效益463
入職464
工作條件464
工作職責466
培訓466
晉升467
離職468
人人為我，我為人人469
精神障礙資源469
第30章反對輪值：一次論戰471
輪值的理由472
首先，不造成傷害472
與SRE的相似性472
與SRE的差異473
推動工程師輪值的基本假設474
輪值是急診醫學，而不是病房醫學476
反駁意見478
輪值給我們帶來的麻煩479
實際解決方案483
培訓483
確定優先次序483
提高在職績效485
我們需要從根本上改變方法486
嚴格抵制輪值（SAOC）487
盡量避免輪值（WAOC）488
二合一489
小結490
第31章復雜繫統的挽歌491
計算機和人類繫統無法分離492
消除一致性和級聯失敗493
始終處於部分故障狀態494
優先級倒置的新嘗試495
沒有人預見到協調的代價495
你的healthcaregov在那裡496
延伸閱讀497
第32章運維與社會活動之間的交集499
之前、期間、之後500
創建完美計劃501
組織原則502
管理危機：在崩潰時做出反應503
書寫我們自己的歷史：了解到底發生了什麼505
長尾效應：將行動轉化為革新506
小結509
第33章結語511
作者介紹513
封面介紹513

大大小小的企業和機構已經開始意識到繫統和應用程序的可靠性對他們的業務的重要性。他們還發現，以市場需求的速度進行迭代的同時還要保持可靠性有多麼困難。站點可靠性工程（SRE）是應對這一挑戰的行之有效的方法。SRE是一個廣泛而豐富的討論話題。Google憑借《SiteReliabilityEngineering》一書推動著SRE向前發展。這是一本非常成功的O'Reilly圖書，它描述了能讓Google成功運維超大規模平臺的SRE指導思想和實施細節。受Google早期工作的啟發，本書試圖發掘SRE領域非常不同的部分。本書用30多章的篇幅帶你進入SRE領域正在進行的一些重要對話。聆聽工程師和該領域的其他領導人討論：在各種環境中實現SRE及其指導思想的不同方法。SRE與其他方法（例如DevOps）的關繫。最前沿的專業技術很快將在SRE中十分常見。簡化實現SRE的很好實踐和技術。重要但很少有人探索的SR等