DevOps實踐指南（第2版） The Devops Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations, 2/e

【作者简介】

 

Gene Kim · DevOps先驱

热销书作者、研究员、首席技术官、IT Revolution创始人、DevOps企业峰会创始人，专注于研究大型复杂组织的技术转型。著有风靡全球的《凤凰项目》《独角兽项目》。

 

Jez Humble · 持续交付之父

Google Cloud SRE、加州大学伯克利分校讲师、热销书作者，著有Jolt大奖获奖图书《持续交付》。

 

Patrick Debois · DevOps之父

Snyk公司DevOps关系总监兼顾问。致力于通过在开发、项目管理和系统管理中运用敏捷技术，弥合项目和运营之间的鸿沟。

 

John Willis · DevOps先驱

Red Hat全球转型办公室高级总监、Beyond The Phoenix Project作者、Profound播客主持人。在IT管理行业拥有超过40年经验。

 

【译者简介】

 

茹炳晟 · 腾讯Tech Lead

腾讯研究院特约研究员、中国计算机学会（CCF）TF研发效能SIG主席。《测试工程师全栈技术进阶与实践》等畅销技术书作者。公众号“茹炳晟聊软件研发”主理人。

 

管俊 · 戴尔DevOps架构师

目前就职于戴尔中国卓越研发集团，担任ACP & VxRail产品研发部门DevOps架构师。在数字化转型方向拥有超过10年一线DevOps工程实践和团队建设经验。

 

董越 · 阿里前架构师

独立DevOps咨询师、研发运营一体化（DevOps）能力成熟度模型核心专家,曾任阿里巴巴集团研发效能事业部架构师，当前主要从事企业级DevOps体系建设的咨询工作。《软件交付通识》等畅销技术书作者。

 

王晓翔 · 去哪儿网前高级总监

独立DevOps咨询师、研发运营一体化（DevOps）能力成熟度模型核心专家、去哪儿网前工程效率部高级总监。目前致力于为传统企业提供DevOps转型指导。

第 一部分　DevOps三要義

第 1章　敏捷、持續交付與DevOps三要義 5

1.1　製造業價值流 5

1.2　技術價值流 5

1.2.1　聚焦部署前置時間 6

1.2.2　關註返工指標——%C/A 8

1.3　DevOps三要義：DevOps的基礎原則 9

案例研究：向著巡航高度爬升：美國航空的DevOps之旅（第 一部分，2020年） 11

1.4　小結 14

第 2章　第 一要義：流動 15

2.1　使工作可視化 15

2.2　限制在製品數量 16

2.3　縮減批量大小 17

2.4　減少工作交接 19

2.5　持續識別並改進約束 20

2.6　消除價值流中的困境和浪費 21

案例研究：醫療行業中改善流動性和改進約束的實踐（2021年） 22

2.7　小結 24

第3章　第二要義：反饋 25

3.1　在復雜系統中安全地工作 25

3.2　及時發現問題 26

3.3　群策群力，攻剋難題 28

案例研究：Excella的安燈繩實驗（2018年） 30

3.4　從源頭保障質量 32

3.5　為下游工作中心優化 33

3.6　小結 33

第4章　第三要義：持續學習與探索 34

4.1　建立學習型組織，打造安全文化 35

4.2　將日常工作的改進制度化 36

4.3　將局部經驗轉化為全局改進 38

4.4　在日常工作中註入彈性模式 38

4.5　領導層強化與鞏固學習文化 39

案例研究：貝爾實驗室的故事（1925年） 40

4.6　小結 41

第 一部分總結 42

第二部分　從哪裡開始

第5章　選擇合適的價值流切入 45

5.1　綠地項目與棕地項目 47

案例研究：Kessel Run：空中加油系統的棕地項目轉型（2020年） 49

5.2　兼顧記錄型系統和交互型系統 50

5.3　從最具同理心和創新精神的團隊開始 51

案例研究：在整個企業中推廣DevOps轉型：美國航空的DevOps之旅（第二部分，2020年） 52

5.4　在組織中推廣DevOps轉型 52

案例研究：英國稅務及海關總署如何通過超大規模PaaS拯救經濟於水火（2020年） 55

5.5　小結 57

第6章　理解、可視化和運用價值流 58

6.1　通過繪制價值流圖改進工作 58

6.2　確定價值流的參與團隊 59

6.3　通過繪制價值流圖展現工作 60

6.4　組建專職轉型團隊 61

6.4.1　目標一致 62

6.4.2　保持小跨度的改進計劃 63

6.4.3　為非功能性需求和償還技術債務預留20%的時間 63

案例研究：LinkedIn的“反轉行動”（2011年） 65

6.4.4　提高工作的可視化程度 67

6.5　使用工具強化預期行為 67

6.6　小結 68

第7章　參照康威定律設計組織結構與系統架構 69

7.1　組織原型 71

7.2　過度以職能為導向的危害（“成本優化”） 72

7.3　組建市場型團隊（“速度優化”） 72

7.4　讓職能型組織高效運轉 73

7.5　將測試、運維和信息安全納入日常工作 74

7.6　讓團隊成員都成為通才 75

7.7　投資服務與產品，而非項目 76

7.8　依照康威定律設定團隊邊界 76

7.9　創建松耦合的架構，保證生產力和安全 77

7.10　保持小規模團隊（“兩張比薩”原則） 78

案例研究：Target公司的“API啟用”項目（2015年） 80

7.11　小結 81

第8章　將運維融入日常開發工作 82

8.1　構建共享服務，提升開發人員生產力 83

8.2　將運維工程師融入服務團隊 85

8.3　為服務團隊指派運維聯絡人 85

8.4　邀請運維工程師參加開發團隊的例行活動 86

8.4.1　邀請運維工程師參加每日站會 87

8.4.2　邀請運維工程師參加回顧會議 87

8.4.3　使用共享的看板展示相關運維工作 88

案例研究：全英房屋抵押貸款協會：擁抱更好的工作方式（2020年） 88

8.5　小結 91

第二部分總結 91

第三部分　“第 一要義：流動”的具體實踐

第9章　為部署流水線奠定基礎 95

9.1　按需搭建開發、測試和生產環境 96

9.2　使用統一的代碼倉庫 97

9.3　簡化基礎設施的重建 99

案例研究：酒店公司如何通過容器技術實現年收入300億美元（2020年） 100

9.4　代碼運行在類生產環境才算“開發完成” 101

9.5　小結 102

第 10章　實現快速可靠的自動化測試 103

10.1　持續構建、測試和集成代碼與環境 106

10.2　構建快速可靠的自動化測試套件 108

10.3　在自動化測試階段盡早發現問題 109

10.3.1　確保測試快速運行 110

10.3.2　測試驅動開發 111

10.3.3　盡可能將手工測試自動化 112

10.3.4　在測試套件中集成性能測試 113

10.3.5　在測試套件中集成非功能性需求測試 113

10.4　在部署流水線失敗時拉下安燈繩 114

10.5　小結 116

第 11章　實現持續集成 117

11.1　小批量開發vs大批量合並 119

11.2　基於主乾的開發實踐 120

案例研究：Bazaarvoice的持續集成實踐（2012年） 121

11.3　小結 123

第 12章　自動化和低風險的發布 124

12.1　部署流程自動化 126

案例研究：CSG的每日部署（2013年） 127

12.1.1　實現自動化的自助部署 129

12.1.2　將代碼部署集成到部署流水線 130

案例研究：Etsy持續部署案例：開發者自助部署（2014年） 131

12.2　部署與發布解耦 133

12.2.1　基於部署環境的發布模式 134

案例研究：Dixons Retail：藍綠部署在POS系統中的應用（2008年） 136

12.2.2　基於應用程序的發布模式 138

案例研究：Facebook Chat功能的灰度發布案例（2008年） 140

12.3　持續交付和持續部署實踐調研 141

案例研究：CSG：實現開發與運維的雙贏（2016年） 142

12.4　小結 146

第 13章　降低發布風險的架構 147

13.1　提高研發效能、可測試性和安全性的架構 148

13.2　架構原型：單體架構vs微服務 149

案例研究：亞馬遜的演進式架構（2002年） 150

13.3　安全地演進企業架構 151

案例研究：Blackboard Learn的絞殺者應用模式（2011年） 152

13.4　小結 155

第三部分總結 155

第四部分　“第二要義：反饋”的具體實踐

第 14章　使用監控發現和解決問題 159

14.1　搭建集中式的監控基礎設施 161

14.2　為應用程序添加日誌監控 163

14.3　用監控指引問題的分析和解決 165

14.4　把添加監控融入日常工作 165

14.5　以自助方式訪問監控數據 166

案例研究：搭建自助的監控體系：LinkedIn的實踐（2011年） 167

14.6　對監控配置查漏補缺 169

14.6.1　應用程序和業務的監控 169

14.6.2　基礎設施的監控 171

14.6.3　顯示其他相關信息 172

14.7　小結 172

第 15章　使用監控預防問題並實現業務目標 173

15.1　用均值和標準差發現潛在問題 174

15.2　監測到非預期結果時告警 175

15.3　監控數據非高斯分佈帶來的問題 176

案例研究：Netflix的自動擴容能力（2012年） 177

15.4　使用異常檢測技術 179

案例研究：異常檢測中的高級技術（2014年） 180

15.5　小結 182

第 16章　引入反饋機制實現安全部署 183

16.1　利用監控確保部署上線更安全 184

16.2　讓開發和運維輪流值班 186

16.3　讓開發人員到價值流下游看一看 186

16.4　先由開發人員自行運維 188

案例研究：谷歌的移交就緒評審和發布就緒評審（2010年） 190

16.5　小結 192

第 17章　將假設驅動開發和A/B測試納入日常工作 193

17.1　A/B測試簡史 194

17.2　在新功能測試中整合A/B測試 195

17.3　在軟件發布中整合A/B測試 196

17.4　在功能規劃中整合A/B測試 196

案例研究：雅虎問答在快速迭代中實驗，實現收入翻倍 197

17.5　小結 198

第 18章　通過評審和協調提升工作質量 199

18.1　變更審批流程帶來的問題 200

18.2　過度變更控制帶來的問題 201

案例研究：從三位高管審批到自動審批——阿迪達斯的大規模發布實踐（2020年） 202

18.3　對變更進行協調和規劃 204

18.4　對變更進行同行評議 204

案例研究：谷歌的代碼評審（2010年） 206

18.5　凍結變更並進行大量手工測試的隱患 207

18.6　用結對編程提升各種類型變更的質量 207

案例研究：Pivotal用結對編程代替阻滯的代碼評審過程（2011年） 208

18.7　分析拉取請求過程的有效性 209

18.8　對官僚化流程進行大膽簡化 210

18.9　小結 211

第四部分　總結 212

第五部分　“第三要義：持續學習與探索”的具體實踐

第 19章　將學習融入日常工作 215

19.1　建立公正的學習文化 216

19.2　故障發生後及時召開回顧會議 217

19.3　盡可能廣泛公開回顧會議紀要 219

19.4　降低事故容差以發現更弱的故障信號 220

19.5　重新定義失敗並鼓勵評估風險 221

19.6　向生產環境註入故障，培養系統彈性和學習氛圍 222

19.7　設立故障演練日 223

案例研究：CSG如何將故障轉化為有效的學習機會（2021） 224

19.8　小結 226

第 20章　將局部經驗轉化為全局改進 227

20.1　將可復用的標準流程自動化 228

20.2　創建組織級的單一共享源代碼倉庫 229

20.3　用自動化測試記錄、交流實踐以傳播知識 231

20.4　通過規範非功能性需求來設計運維 231

20.5　將可復用的運維用戶故事融入開發過程 232

20.6　確保技術選型有助於組織達成目標 233

案例研究：Etsy的新技術棧標準化（2010年） 234

案例研究：Target的眾包技術治理（2018年） 235

20.7　小結 236

第 21章　預留時間開展組織學習和改進 237

21.1　將償還技術債務變為例行活動 238

21.2　讓所有人教學相長 239

21.3　在DevOps會議中分享經驗 241

案例研究：美國全國保險、Capital One和Target的內部技術會議（2014年） 242

21.4　創建社區結構來推廣實踐 243

21.5　小結 245

第五部分　總結 245

第六部分　整合信息安全、變更管理和合規性的技術實踐

第 22章　信息安全是每個人的日常工作 249

22.1　將安全集成到開發迭代演示 249

22.2　將安全問題納入缺陷跟蹤和事後分析 250

22.3　將預防性安全控制集成到共享源代碼倉庫及共享服務 250

22.4　將安全集成到部署流水線 252

22.5　保障應用程序安全 253

案例研究：Twitter的靜態安全測試（2009年） 254

22.6　保障軟件供應鏈安全 256

22.7　保障環境安全 261

案例研究：18F使用Compliance Masonry實現聯邦政府合規性審查自動化（2016年） 261

22.8　將信息安全集成到生產監控系統 262

22.8.1　為應用程序創建安全監控 263

22.8.2　為環境創建安全監控 263

案例研究：Etsy的環境監測（2010年） 264

22.9　保護部署流水線 265

案例研究：在Fannie Mae開展安全左移（2020年） 266

22.10　小結 267

第 23章　保護部署流水線 268

23.1　將安全和合規集成到變更審批流程 268

23.2　將低風險的變更歸類為標準變更 269

23.3　當變更被歸類為常規變更時如何處理 270

案例研究：Salesforce將自動化基礎設施變更歸類為標準變更（2012年） 270

23.4　通過代碼評審實現職責分離 271

案例研究：Etsy的PCI合規性以及一則職責分離的警示故事（2014年） 272

案例研究：通過業務與技術合作，Capital One實現每天10次有信心的發布（2020年） 274

23.5　確保為合規官和審計師提供文檔和證據 275

案例研究：證明監管環境下的合規性（2015年） 275

案例研究：ATM系統離不開生產監控（2013年） 277

23.6　小結 278

第六部分　總結 278

附錄1：DevOps大融合 286

附錄2：約束理論和長期存在的根本矛盾 288

附錄3：惡性循環列表 289

附錄4：交接和隊列的危害 289

附錄5：工業安全的誤區 291

附錄6：豐田安燈繩 291

附錄7：COTS軟件 292

附錄8：事後分析會議（回顧會議） 292

附錄9：猿猴軍團 293

附錄10：上線時間透明化 294