SRE實踐手冊:軟件組織如何規模化實施站點可靠性工程 Establishing Sre Foundations: A Step-By-Step Guide to Introducing Site Reliability Engineering in Software Delivery Organizations

[德]弗拉迪斯拉夫·烏基斯(Vladyslav Ukis)著 周靖 譯

  • SRE實踐手冊:軟件組織如何規模化實施站點可靠性工程-preview-1
  • SRE實踐手冊:軟件組織如何規模化實施站點可靠性工程-preview-2
  • SRE實踐手冊:軟件組織如何規模化實施站點可靠性工程-preview-3
SRE實踐手冊:軟件組織如何規模化實施站點可靠性工程-preview-1

買這商品的人也買了...

相關主題

商品描述

《SRE實踐手冊:軟件組織如何規模化實施站點可靠性工程》基於作者在西門子醫療的SRE轉型經歷,為讀者提供了SRE落地實踐過程,主題涉及如何從基礎設施、組織文化和流程等層面,從全景的角度實際導入和實施SRE工程過程。《SRE實踐手冊:軟件組織如何規模化實施站點可靠性工程》共15章,實用性強,可操作性強,指導性強,適合想要啟動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