DevOps實踐指南(第2版) The Devops Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations, 2/e
[美] 吉恩·金(Gene Kim)
- 出版商: 人民郵電
- 出版日期: 2024-04-01
- 定價: $839
- 售價: 8.5 折 $713
- 語言: 簡體中文
- 頁數: 298
- 裝訂: 平裝
- ISBN: 7115638772
- ISBN-13: 9787115638779
-
相關分類:
DevOps
- 此書翻譯自: The Devops Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations, 2/e (Paperback)
-
相關翻譯:
DevOps Handbook |打造世界級技術組織的實踐指南, 2/e (中文版) (The Devops Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations, 2/e) (繁中版)
下單後立即進貨 (約4週~6週)
相關主題
商品描述
本書是軟件開發與運維領域經典參考書新升級版,由DevOps領域幾位先驅撰寫。第2版根據新研究和best practice更新了內容,增加了大量新案例,方便大家在各行各業落地DevOps實踐。
本書內容分為六部分,圍繞“DevOps三要義”(流動、反饋、持續學習與探索)探討DevOps的理論、原則和落地實踐。第一部分介紹DevOps理論基礎和關鍵主題,第二部分介紹如何尋找切入點並啟動轉型,第三部分介紹如何通過構建部署流水線來加速流動,第四部分討論如何通過建立有效的生產環境監控發現和解決問題,第五部分探討如何通過建立公正的文化促進持續學習與探索,第六部分介紹將安全與合規活動集成到日常工作。
本書適合所有互聯網企業和傳統企業從業者閱讀。
作者簡介
【作者简介】
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