中圖網小程序
一鍵登錄
更方便
本類五星書更多>
-
>
公路車寶典(ZINN的公路車維修與保養秘籍)
-
>
晶體管電路設計(下)
-
>
基于個性化設計策略的智能交通系統關鍵技術
-
>
花樣百出:貴州少數民族圖案填色
-
>
山東教育出版社有限公司技術轉移與技術創新歷史叢書中國高等技術教育的蘇化(1949—1961)以北京地區為中心
-
>
鐵路機車概要.交流傳動內燃.電力機車
-
>
利維坦的道德困境:早期現代政治哲學的問題與脈絡
SRE實踐手冊:軟件組織如何規模化實施站點可靠性工程 版權信息
- ISBN：9787302633082
- 條形碼：9787302633082 ; 978-7-302-63308-2
- 裝幀：平裝-膠訂
- 冊數：暫無
- 重量：暫無
- 所屬分類：>
SRE實踐手冊:軟件組織如何規模化實施站點可靠性工程 本書特色
谷歌首創的“站點可靠性工程”(SRE)用于創建伸縮性更強和穩定性更高的大型交付系統，是當前更有價值的軟件創新機會。《SRE實踐手冊:軟件組織如何規模化實施站點可靠性工程》作為一本簡明、實用和全面的SRE指導手冊，展示了如何才能順利實施SRE。作者提出一個循序漸進的方法，基于文化、組織和技術流程這三個支點來建構SRE基礎，幫助軟件交付組織快速實現“*小可行SRE”并在此基礎上進行持續的迭代和精進。 烏基斯博士在書中分享了西門子醫療的SRE轉型過程。貫穿全書，他全面解答了落地SRE所涉及的問題，指出可能存在的種種陷阱，并說明了如何避免和克服這些容易被忽視的坑。從事軟件開發、工程或運維的讀者，可借助于本書巧妙地應用SRE來持續提升服務體驗。
SRE實踐手冊:軟件組織如何規模化實施站點可靠性工程 內容簡介
《SRE實踐手冊:軟件組織如何規模化實施站點可靠性工程》基于作者在西門子醫療的SRE轉型經歷，為讀者提供了SRE落地實踐過程，主題涉及如何從基礎設施、組織文化和流程等層面，從全景的角度實際導入和實施SRE工程過程。《SRE實踐手冊:軟件組織如何規模化實施站點可靠性工程》共15章，實用性強，可操作性強，指導性強，適合想要啟動SRE實踐的組織和團隊閱讀與參考。
SRE實踐手冊:軟件組織如何規模化實施站點可靠性工程 目錄
簡明目錄
Ⅰ 基礎知識
第1章 SRE概述 3
第2章 面臨的挑戰 18
第3章 SRE基本概念 36
第4章 評估現狀 54 Ⅱ 啟動轉型
第5章 取得組織的認同 75
第6章 奠定基礎 114
第7章 響應SLO違反警報 151
第8章 警報分派 183
第9章 實現事故響應 198
第10章 設置錯誤預算策略 265
第11章 實現基于錯誤預算的決策 284
第12章 實現組織結構 340 Ⅲ 度量和維持轉型
第13章 度量SRE轉型 405
第14章 持續推進SRE運動 411
第15章 未來之路 424 附錄 主題快速參考 430
詳細目錄
第Ⅰ部分 基礎知識
第1章 SRE概述 3
1.1 為什么要選擇SRE 3
1.1.1 ITIL 3
1.1.2 COBIT 4
1.1.3 建模 5
1.1.4 DevOps 5
1.1.5 關于SRE 6
1.1.6 比較不同的方法 7
1.2 使用SRE進行協同 12
1.3 SRE為什么有用 15
1.4 小結 17
第2章 面臨的挑戰 18
2.1 種種不協同 18
2.2 集體所有權 20
2.3 SRE應用場景下的所有權 21
2.3.1 產品開發 21
2.3.2 產品運營 23
2.3.3 產品管理 27
2.3.4 效益和成本 30
2.4 挑戰聲明 32
2.5 教練 33
2.6 小結 35
第3章 SRE基本概念 36
3.1 服務水平指標 36
3.2 服務水平目標 37
3.3 錯誤預算 39
3.3.1 可用性錯誤預算的例子 40
3.3.2 錯誤預算為零 41
3.3.3 延遲錯誤預算的例子 43
3.4 錯誤預算策略 44
3.5 SRE概念金字塔 46
3.6 使用SRE概念金字塔進行協同 49
3.7 小結 53
第4章 評估現狀 54
4.1 組織現狀 54
4.1.1 組織結構 54
4.1.2 組織協同 56
4.1.3 正式和非正式領導 57
4.2 人員現狀 58
4.3 技術現狀 59
4.4 文化現狀 63
4.4.1 是否高度合作 64
4.4.2 培訓 64
4.4.3 是否共擔風險 65
4.4.4 是否鼓勵交流 65
4.4.5 失敗后是否可以追根溯源 65
4.4.6 是否接納新的想法 66
4.5 過程現狀 66
4.6 SRE成熟度模型 68
4.7 提出假設 70
4.8 小結 72
第Ⅱ部分 啟動轉型
第5章 取得組織的認同 75
5.1 取得組織內部對SRE的認同 75
5.2 SRE營銷漏斗 77
5.2.1 認識SRE 78
5.2.2 興趣 79
5.2.3 理解 80
5.2.4 共識 80
5.2.5 參與 81
5.3 SRE教練 82
5.3.1 特質 82
5.3.2 責任 83
5.4 自上而下認同 84
5.4.1 利益相關者圖表 85
5.4.2 與開發主管接觸 87
5.4.3 與運營主管接觸 92
5.4.4 和產品管理主管接觸 93
5.4.5 實現聯合認同 95
5.4.6 讓SRE進入項目組合 97
5.5 自下而上認同 99
5.5.1 與運營團隊接觸 99
5.5.2 與開發團隊接觸 100
5.6 橫向認同 103
5.7 交錯認同 104
5.8 團隊輔導 104
5.9 跨組織 106
5.9.1 組織的分組 106
5.9.2 組織穿越與SRE基礎設施需求 108
5.9.3 接觸各個團隊的時機 108
5.10 組織輔導 111
5.11 小結 112
第6章 奠定基礎 114
6.1 團隊導入對話 114
6.2 傳達基礎知識 115
6.2.1 SLO作為契約 115
6.2.2 SLO作為客戶滿意度的代理度量 116
6.2.3 用戶畫像 117
6.2.4 用戶故事地圖 119
6.2.5 對SLO被違反情況進行修復的積極性 121
6.2.6 SLO和技術問題無關 123
6.2.7 SLO違反的原因 123
6.2.8 值班應對違反SLO的情況 125
6.3 SLI標準化 125
6.3.1 應用程序性能管理設施 127
6.3.2 可用性 128
6.3.3 延遲 129
6.3.4 優先級排序 130
6.4 啟用日志記錄 132
6.5 日志查詢語言的培訓 133
6.6 定義初始SLO 134
6.6.1 什么是好的SLO 135
6.6.2 SLO迭代過程 136
6.6.3 修訂SLO 139
6.7 默認SLO 140
6.8 提供基本的基礎設施 141
6.8.1 儀表盤 142
6.8.2 警報內容 143
6.9 與擁護者接觸 144
6.10 和反對者打交道 144
6.10.1 人們為什么會反對 145
6.10.2 警報的問題 145
6.10.3 工具的問題 146
6.10.4 產品負責人的問題 147
6.10.5 團隊激勵的問題 147
6.11 創建文檔 148
6.12 宣傳成功 148
6.13 小結 150
第7章 響應SLO違反警報 151
7.1 環境選擇 151
7.2 責任 153
7.2.1 開發責任與運營責任 153
7.2.2 運營責任 154
7.2.3 劃分運營責任 154
7.3 工作模式 156
7.3.1 基于中斷的工作模式 156
7.3.2 基于專注的工作模式 160
7.4 設置輪流值班 160
7.4.1 初始輪換周期 161
7.4.2 單人值班 161
7.4.3 雙人值班 162
7.4.4 三人值班 162
7.5 值班管理工具 163
7.5.1 發布SLO違反 163
7.5.2 排班 165
7.5.3 專業值班管理工具 165
7.6 非工作時間進行值班 167
7.6.1 使用可用性目標和產品需求 168
7.6.2 取舍 168
7.7 系統化的知識共享 170
7.7.1 知識共享需求 172
7.7.2 知識共享金字塔 173
7.7.3 值班培訓 175
7.7.4 運行手冊 176
7.7.5 內部Stack Overflow工具 178
7.7.6 SRE實踐社區 179
7.8 宣傳成功 180
7.9 小結 182
第8章 警報分派 183
8.1 警報升級 184
8.2 定義警報升級策略 186
8.3 定義利益相關者分組 187
8.4 觸發利益相關者通知 189
8.5 定義利益相關者環 190
8.6 定義有效的利益相關者通知 193
8.7 允許利益相關者訂閱 195
8.7.1 使用值班管理工具訂閱 196
8.7.2 使用其他方式訂閱的可行性 196
8.8 宣傳成功 196
8.9 小結 197
第9章 實現事故響應 198
9.1 事故響應基礎 198
9.2 事故優先級 199
9.2.1 SLO違反與事故 200
9.2.2 在事故期間更改事故優先級 202
9.2.3 定義通用事故優先級 203
9.2.4 將SLO映射到事故優先級 205
9.2.5 將錯誤預算映射到事故優先級 207
9.2.6 將基于資源的警報映射到事故優先級 208
9.2.7 發現事故優先級的新用例 209
9.2.8 根據利益相關者的反饋來調整事故優先級 210
9.2.9 擴展SLO定義過程 211
9.2.10 基礎設施 212
9.2.11 消除重復 213
9.3 協調復雜事故 215
9.3.1 什么是復雜事故 215
9.3.2 現有的事故協調系統 216
9.3.3 事故分類 217
9.3.4 定義通用事故嚴重性 217
9.3.5 事故分類的社會維度 219
9.3.6 事故優先級與事故嚴重性 220
9.3.7 定義角色 221
9.3.8 事故嚴重性分別對應哪些角色 223
9.3.9 值班角色 223
9.3.10 事故響應過程評估 224
9.3.11 事故響應過程動態 225
9.3.12 事故響應團隊的幸福感 228
9.4 事后回顧 232
9.5 有效事后回顧的標準 233
9.5.1 發起事后回顧 234
9.5.2 事后回顧的生命周期 235
9.5.3 事后回顧之前 236
9.5.4 事后回顧會議 238
9.5.5 事后回顧之后 244
9.5.6 分析事后回顧過程 245
9.5.7 事后回顧模板 250
9.5.8 促進從事后回顧中學習 252
9.5.9 成功的事后回顧實踐 252
9.5.10 事后回顧實例 253
9.6 工具整合 254
9.6.1 與值班管理工具連接 254
9.6.2 其他工具之間的連接 256
9.6.3 移動集成 257
9.6.4 示例工具搭配 258
9.7 服務狀態廣播 259
9.8 撰寫事故響應過程文檔 261
9.9 宣傳成功 262
9.10 小結 263
第10章 設置錯誤預算策略 265
10.1 動機 265
10.2 術語 267
10.3 錯誤預算策略的結構 267
10.4 錯誤預算策略的條件 269
10.5 錯誤預算策略的后果 270
10.6 錯誤預算策略治理體系 271
10.7 擴展錯誤預算策略 273
10.8 簽署錯誤預算策略 277
10.9 存儲錯誤預算策略 278
10.10 實行錯誤預算策略 279
10.11 審查錯誤預算策略 280
10.12 相關概念 281
10.13 小結 282
第11章 實現基于錯誤預算的決策 284
11.1 可靠性決策的分類法 284
11.2 實現SRE指標 287
11.2.1 SRE指標的維度 287
11.2.2 “按服務劃分的SLO”指標 288
11.2.3 “SLO遵守情況”指標 289
11.2.4 “SLO錯誤預算消耗”指標 290
11.2.5 “SLO錯誤預算過早耗盡”指標 295
11.2.6 “按服務劃分的SLA”指標 299
11.2.7 “SLA錯誤預算消耗”指標 300
11.2.8 “SLA遵守情況”指標 303
11.2.9 “客戶支持工單趨勢”指標 304
11.2.10 “團隊輪流值班”指標 308
11.2.11 “事故恢復時間趨勢”指標 309
11.2.12 “*不可用服務端點”指標 311
11.2.13 “*慢服務端點”指標 312
11.3 過程指標（而非人員的KPI） 313
11.4 決策與指標 314
11.5 決策工作流 316
11.5.1 “使用API”決策工作流 316
11.5.2 “收緊依賴項的SLO”決策工作流 319
11.5.3 “功能與可靠性優先級排序”工作流 321
11.5.4 “設置SLO”決策工作流 325
11.5.5 “設置SLA”決策工作流 329
11.5.6 “為團隊分配SRE能力”決策工作流 331
11.5.7 “選擇混沌工程假設”工作流 334
11.6 小結 338
第12章 實現組織結構 340
12.1 SRE原則與組織結構 341
12.2 誰構建，誰運行 342
12.2.1 “誰構建，誰運行？”譜系 343
12.2.2 混合模式 344
12.2.3 改善可靠性的動力 344
12.2.4 模式比較標準 347
12.2.5 模式比較 349
12.3 “你構建，你運行” 350
12.4 “你構建，你和SRE運行” 352
12.4.1 開發組織內的SRE團隊 352
12.4.2 運營組織內的SRE團隊 354
12.4.3 專門的SRE組織內部的SRE團隊 355
12.4.4 對比 357
12.4.5 SRE團隊的激勵、身份和自豪感 358
12.4.6 SRE團隊的人數和預算 359
12.4.7 SRE團隊成本核算 362
12.4.8 SRE團隊KPI 363
12.5 你構建，SRE運行 365
12.5.1 開發組織內的SRE團隊 366
12.5.2 運營組織內的SRE團隊 367
12.5.3 專門的SRE組織內部的SRE團隊 367
12.6 成本優化 368
12.7 團隊拓撲結構 370
12.7.1 報告線 371
12.7.2 SRE身份三角 372
12.7.3 合弄制：無報告線 374
12.8 選擇一個模式 375
12.8.1 模式轉換選項 375
12.8.2 決策維度 376
12.8.3 報告選項 378
12.8.4 SRE組織的定位 379
12.8.5 將價值傳達給管理層 381
12.9 一個新的角色：SRE 382
12.9.1 為什么需要一個新角色 382
12.9.2 角色定義 384
12.9.3 角色命名 387
12.9.4 角色分配 388
12.9.5 角色履行 390
12.10 SRE職業道路 391
12.10.1 SRE角色發展 392
12.10.2 SRE角色轉換 394
12.10.3 文化的重要性 395
12.11 就所選模式進行溝通 396
12.12 導入所選的模式 397
12.12.1 組織變化 398
12.12.2 報告結構的變化 400
12.12.3 角色變化 401
12.13 小結 401
第Ⅲ部分 度量和維持轉型
第13章 度量SRE轉型 405
13.1 測試轉型假設 405
13.2 內部未檢測到的故障 406
13.3 過早耗盡錯誤預算的服務 407
13.4 管理層的看法 408
13.5 用戶和合作伙伴對可靠性的看法 409
13.6 小結 410
第14章 持續推進SRE運動 411
14.1 建立成熟的SRE CoP 411
14.2 SRE時間 411
14.3 可用性新聞簡報 412
14.4 工程博客中的SRE專欄 413
14.5 推廣SRE維基頁面長文 413
14.6 SRE的宣發 414
14.7 結合SRE和CD指標 415
14.7.1 對比CD與SRE指標 416
14.7.2 瓶頸分析 417
14.8 SRE反饋回路 418
14.9 新的假設 419
14.10 提供學習機會 420
14.11 為SRE教練提供支持 421
14.12 小結 423
第15章 未來之路 424
15.1 服務目錄 425
15.2 SLA 426
15.3 監管合規 426
15.4 SRE基礎設施 427
15.5 游戲日 428
附錄 主題快速參考 430
第1章 SRE概述 3
第2章 面臨的挑戰 18
第3章 SRE基本概念 36
第4章 評估現狀 54 Ⅱ 啟動轉型
第5章 取得組織的認同 75
第6章 奠定基礎 114
第7章 響應SLO違反警報 151
第8章 警報分派 183
第9章 實現事故響應 198
第10章 設置錯誤預算策略 265
第11章 實現基于錯誤預算的決策 284
第12章 實現組織結構 340 Ⅲ 度量和維持轉型
第13章 度量SRE轉型 405
第14章 持續推進SRE運動 411
第15章 未來之路 424 附錄 主題快速參考 430
詳細目錄
第Ⅰ部分 基礎知識
第1章 SRE概述 3
1.1 為什么要選擇SRE 3
1.1.1 ITIL 3
1.1.2 COBIT 4
1.1.3 建模 5
1.1.4 DevOps 5
1.1.5 關于SRE 6
1.1.6 比較不同的方法 7
1.2 使用SRE進行協同 12
1.3 SRE為什么有用 15
1.4 小結 17
第2章 面臨的挑戰 18
2.1 種種不協同 18
2.2 集體所有權 20
2.3 SRE應用場景下的所有權 21
2.3.1 產品開發 21
2.3.2 產品運營 23
2.3.3 產品管理 27
2.3.4 效益和成本 30
2.4 挑戰聲明 32
2.5 教練 33
2.6 小結 35
第3章 SRE基本概念 36
3.1 服務水平指標 36
3.2 服務水平目標 37
3.3 錯誤預算 39
3.3.1 可用性錯誤預算的例子 40
3.3.2 錯誤預算為零 41
3.3.3 延遲錯誤預算的例子 43
3.4 錯誤預算策略 44
3.5 SRE概念金字塔 46
3.6 使用SRE概念金字塔進行協同 49
3.7 小結 53
第4章 評估現狀 54
4.1 組織現狀 54
4.1.1 組織結構 54
4.1.2 組織協同 56
4.1.3 正式和非正式領導 57
4.2 人員現狀 58
4.3 技術現狀 59
4.4 文化現狀 63
4.4.1 是否高度合作 64
4.4.2 培訓 64
4.4.3 是否共擔風險 65
4.4.4 是否鼓勵交流 65
4.4.5 失敗后是否可以追根溯源 65
4.4.6 是否接納新的想法 66
4.5 過程現狀 66
4.6 SRE成熟度模型 68
4.7 提出假設 70
4.8 小結 72
第Ⅱ部分 啟動轉型
第5章 取得組織的認同 75
5.1 取得組織內部對SRE的認同 75
5.2 SRE營銷漏斗 77
5.2.1 認識SRE 78
5.2.2 興趣 79
5.2.3 理解 80
5.2.4 共識 80
5.2.5 參與 81
5.3 SRE教練 82
5.3.1 特質 82
5.3.2 責任 83
5.4 自上而下認同 84
5.4.1 利益相關者圖表 85
5.4.2 與開發主管接觸 87
5.4.3 與運營主管接觸 92
5.4.4 和產品管理主管接觸 93
5.4.5 實現聯合認同 95
5.4.6 讓SRE進入項目組合 97
5.5 自下而上認同 99
5.5.1 與運營團隊接觸 99
5.5.2 與開發團隊接觸 100
5.6 橫向認同 103
5.7 交錯認同 104
5.8 團隊輔導 104
5.9 跨組織 106
5.9.1 組織的分組 106
5.9.2 組織穿越與SRE基礎設施需求 108
5.9.3 接觸各個團隊的時機 108
5.10 組織輔導 111
5.11 小結 112
第6章 奠定基礎 114
6.1 團隊導入對話 114
6.2 傳達基礎知識 115
6.2.1 SLO作為契約 115
6.2.2 SLO作為客戶滿意度的代理度量 116
6.2.3 用戶畫像 117
6.2.4 用戶故事地圖 119
6.2.5 對SLO被違反情況進行修復的積極性 121
6.2.6 SLO和技術問題無關 123
6.2.7 SLO違反的原因 123
6.2.8 值班應對違反SLO的情況 125
6.3 SLI標準化 125
6.3.1 應用程序性能管理設施 127
6.3.2 可用性 128
6.3.3 延遲 129
6.3.4 優先級排序 130
6.4 啟用日志記錄 132
6.5 日志查詢語言的培訓 133
6.6 定義初始SLO 134
6.6.1 什么是好的SLO 135
6.6.2 SLO迭代過程 136
6.6.3 修訂SLO 139
6.7 默認SLO 140
6.8 提供基本的基礎設施 141
6.8.1 儀表盤 142
6.8.2 警報內容 143
6.9 與擁護者接觸 144
6.10 和反對者打交道 144
6.10.1 人們為什么會反對 145
6.10.2 警報的問題 145
6.10.3 工具的問題 146
6.10.4 產品負責人的問題 147
6.10.5 團隊激勵的問題 147
6.11 創建文檔 148
6.12 宣傳成功 148
6.13 小結 150
第7章 響應SLO違反警報 151
7.1 環境選擇 151
7.2 責任 153
7.2.1 開發責任與運營責任 153
7.2.2 運營責任 154
7.2.3 劃分運營責任 154
7.3 工作模式 156
7.3.1 基于中斷的工作模式 156
7.3.2 基于專注的工作模式 160
7.4 設置輪流值班 160
7.4.1 初始輪換周期 161
7.4.2 單人值班 161
7.4.3 雙人值班 162
7.4.4 三人值班 162
7.5 值班管理工具 163
7.5.1 發布SLO違反 163
7.5.2 排班 165
7.5.3 專業值班管理工具 165
7.6 非工作時間進行值班 167
7.6.1 使用可用性目標和產品需求 168
7.6.2 取舍 168
7.7 系統化的知識共享 170
7.7.1 知識共享需求 172
7.7.2 知識共享金字塔 173
7.7.3 值班培訓 175
7.7.4 運行手冊 176
7.7.5 內部Stack Overflow工具 178
7.7.6 SRE實踐社區 179
7.8 宣傳成功 180
7.9 小結 182
第8章 警報分派 183
8.1 警報升級 184
8.2 定義警報升級策略 186
8.3 定義利益相關者分組 187
8.4 觸發利益相關者通知 189
8.5 定義利益相關者環 190
8.6 定義有效的利益相關者通知 193
8.7 允許利益相關者訂閱 195
8.7.1 使用值班管理工具訂閱 196
8.7.2 使用其他方式訂閱的可行性 196
8.8 宣傳成功 196
8.9 小結 197
第9章 實現事故響應 198
9.1 事故響應基礎 198
9.2 事故優先級 199
9.2.1 SLO違反與事故 200
9.2.2 在事故期間更改事故優先級 202
9.2.3 定義通用事故優先級 203
9.2.4 將SLO映射到事故優先級 205
9.2.5 將錯誤預算映射到事故優先級 207
9.2.6 將基于資源的警報映射到事故優先級 208
9.2.7 發現事故優先級的新用例 209
9.2.8 根據利益相關者的反饋來調整事故優先級 210
9.2.9 擴展SLO定義過程 211
9.2.10 基礎設施 212
9.2.11 消除重復 213
9.3 協調復雜事故 215
9.3.1 什么是復雜事故 215
9.3.2 現有的事故協調系統 216
9.3.3 事故分類 217
9.3.4 定義通用事故嚴重性 217
9.3.5 事故分類的社會維度 219
9.3.6 事故優先級與事故嚴重性 220
9.3.7 定義角色 221
9.3.8 事故嚴重性分別對應哪些角色 223
9.3.9 值班角色 223
9.3.10 事故響應過程評估 224
9.3.11 事故響應過程動態 225
9.3.12 事故響應團隊的幸福感 228
9.4 事后回顧 232
9.5 有效事后回顧的標準 233
9.5.1 發起事后回顧 234
9.5.2 事后回顧的生命周期 235
9.5.3 事后回顧之前 236
9.5.4 事后回顧會議 238
9.5.5 事后回顧之后 244
9.5.6 分析事后回顧過程 245
9.5.7 事后回顧模板 250
9.5.8 促進從事后回顧中學習 252
9.5.9 成功的事后回顧實踐 252
9.5.10 事后回顧實例 253
9.6 工具整合 254
9.6.1 與值班管理工具連接 254
9.6.2 其他工具之間的連接 256
9.6.3 移動集成 257
9.6.4 示例工具搭配 258
9.7 服務狀態廣播 259
9.8 撰寫事故響應過程文檔 261
9.9 宣傳成功 262
9.10 小結 263
第10章 設置錯誤預算策略 265
10.1 動機 265
10.2 術語 267
10.3 錯誤預算策略的結構 267
10.4 錯誤預算策略的條件 269
10.5 錯誤預算策略的后果 270
10.6 錯誤預算策略治理體系 271
10.7 擴展錯誤預算策略 273
10.8 簽署錯誤預算策略 277
10.9 存儲錯誤預算策略 278
10.10 實行錯誤預算策略 279
10.11 審查錯誤預算策略 280
10.12 相關概念 281
10.13 小結 282
第11章 實現基于錯誤預算的決策 284
11.1 可靠性決策的分類法 284
11.2 實現SRE指標 287
11.2.1 SRE指標的維度 287
11.2.2 “按服務劃分的SLO”指標 288
11.2.3 “SLO遵守情況”指標 289
11.2.4 “SLO錯誤預算消耗”指標 290
11.2.5 “SLO錯誤預算過早耗盡”指標 295
11.2.6 “按服務劃分的SLA”指標 299
11.2.7 “SLA錯誤預算消耗”指標 300
11.2.8 “SLA遵守情況”指標 303
11.2.9 “客戶支持工單趨勢”指標 304
11.2.10 “團隊輪流值班”指標 308
11.2.11 “事故恢復時間趨勢”指標 309
11.2.12 “*不可用服務端點”指標 311
11.2.13 “*慢服務端點”指標 312
11.3 過程指標（而非人員的KPI） 313
11.4 決策與指標 314
11.5 決策工作流 316
11.5.1 “使用API”決策工作流 316
11.5.2 “收緊依賴項的SLO”決策工作流 319
11.5.3 “功能與可靠性優先級排序”工作流 321
11.5.4 “設置SLO”決策工作流 325
11.5.5 “設置SLA”決策工作流 329
11.5.6 “為團隊分配SRE能力”決策工作流 331
11.5.7 “選擇混沌工程假設”工作流 334
11.6 小結 338
第12章 實現組織結構 340
12.1 SRE原則與組織結構 341
12.2 誰構建，誰運行 342
12.2.1 “誰構建，誰運行？”譜系 343
12.2.2 混合模式 344
12.2.3 改善可靠性的動力 344
12.2.4 模式比較標準 347
12.2.5 模式比較 349
12.3 “你構建，你運行” 350
12.4 “你構建，你和SRE運行” 352
12.4.1 開發組織內的SRE團隊 352
12.4.2 運營組織內的SRE團隊 354
12.4.3 專門的SRE組織內部的SRE團隊 355
12.4.4 對比 357
12.4.5 SRE團隊的激勵、身份和自豪感 358
12.4.6 SRE團隊的人數和預算 359
12.4.7 SRE團隊成本核算 362
12.4.8 SRE團隊KPI 363
12.5 你構建，SRE運行 365
12.5.1 開發組織內的SRE團隊 366
12.5.2 運營組織內的SRE團隊 367
12.5.3 專門的SRE組織內部的SRE團隊 367
12.6 成本優化 368
12.7 團隊拓撲結構 370
12.7.1 報告線 371
12.7.2 SRE身份三角 372
12.7.3 合弄制：無報告線 374
12.8 選擇一個模式 375
12.8.1 模式轉換選項 375
12.8.2 決策維度 376
12.8.3 報告選項 378
12.8.4 SRE組織的定位 379
12.8.5 將價值傳達給管理層 381
12.9 一個新的角色：SRE 382
12.9.1 為什么需要一個新角色 382
12.9.2 角色定義 384
12.9.3 角色命名 387
12.9.4 角色分配 388
12.9.5 角色履行 390
12.10 SRE職業道路 391
12.10.1 SRE角色發展 392
12.10.2 SRE角色轉換 394
12.10.3 文化的重要性 395
12.11 就所選模式進行溝通 396
12.12 導入所選的模式 397
12.12.1 組織變化 398
12.12.2 報告結構的變化 400
12.12.3 角色變化 401
12.13 小結 401
第Ⅲ部分 度量和維持轉型
第13章 度量SRE轉型 405
13.1 測試轉型假設 405
13.2 內部未檢測到的故障 406
13.3 過早耗盡錯誤預算的服務 407
13.4 管理層的看法 408
13.5 用戶和合作伙伴對可靠性的看法 409
13.6 小結 410
第14章 持續推進SRE運動 411
14.1 建立成熟的SRE CoP 411
14.2 SRE時間 411
14.3 可用性新聞簡報 412
14.4 工程博客中的SRE專欄 413
14.5 推廣SRE維基頁面長文 413
14.6 SRE的宣發 414
14.7 結合SRE和CD指標 415
14.7.1 對比CD與SRE指標 416
14.7.2 瓶頸分析 417
14.8 SRE反饋回路 418
14.9 新的假設 419
14.10 提供學習機會 420
14.11 為SRE教練提供支持 421
14.12 小結 423
第15章 未來之路 424
15.1 服務目錄 425
15.2 SLA 426
15.3 監管合規 426
15.4 SRE基礎設施 427
15.5 游戲日 428
附錄 主題快速參考 430
展開全部
SRE實踐手冊:軟件組織如何規模化實施站點可靠性工程 作者簡介
弗拉迪斯拉夫·烏基斯博士是西門子醫療Teamplay云平臺的研發主管及SRE負責人。作為軟件開發負責人，他先后推動了組織內部的持續交付、SRE和DevOps轉型，參與了架構、部署、測試、運維和文化相關工作以及規模化實施新的工作流程。
烏基斯博士在德國埃爾朗根-紐倫堡大學獲得計算機科學學士學位，后來在英國曼徹斯特大學獲得碩士學位。在他的職業生涯中，先后從事軟件架構、企業架構、創新管理、私有云和公有云計算、團隊管理、工程管理、投資組合管理、合作伙伴管理以及數字化轉型過程等工作。
書友推薦
- >
月亮虎
- >
唐代進士錄
- >
姑媽的寶刀
- >
羅庸西南聯大授課錄
- >
煙與鏡
- >
二體千字文
- >
史學評論
- >
伯納黛特,你要去哪(2021新版)
本類暢銷
