本書是軟件開發(fā)與運維領域經(jīng)典參考書新升級版,由DevOps領域幾位先驅撰寫。第2版根據(jù)新研究和best practice更新了內容,增加了大量新案例,方便大家在各行各業(yè)落地DevOps實踐。
本書內容分為六部分,圍繞DevOps三要義(流動、反饋、持續(xù)學習與探索)探討DevOps的理論、原則和落地實踐。第一部分介紹DevOps理論基礎和關鍵主題,第二部分介紹如何尋找切入點并啟動轉型,第三部分介紹如何通過構建部署流水線來加速流動,第四部分討論如何通過建立有效的生產(chǎn)環(huán)境監(jiān)控發(fā)現(xiàn)和解決問題,第五部分探討如何通過建立公正的文化促進持續(xù)學習與探索,第六部分介紹將安全與合規(guī)活動集成到日常工作。
本書適合所有互聯(lián)網(wǎng)企業(yè)和傳統(tǒng)企業(yè)從業(yè)者閱讀。
1-【經(jīng)典】DevOps領域經(jīng)典重磅升級,原版Amazon 4.7星好評
2-【靠譜】DevOps先驅Gene Kim、持續(xù)交付之父Jez Humble領銜作品
3-【專業(yè)】國內DevOps資深實踐者翻譯,一線專家聯(lián)袂推薦
4-【實戰(zhàn)】匯聚全球一線DevOps落地案例(40個大案例)
5-【系統(tǒng)】IT名作《鳳凰項目》實戰(zhàn)篇,數(shù)字化轉型三劍客讀本
6-【落地】打造敏捷、可靠、安全、高效的技術型組織
【作者簡介】
Gene Kim · DevOps先驅
熱銷書作者、研究員、首席技術官、IT Revolution創(chuàng)始人、DevOps企業(yè)峰會創(chuàng)始人,專注于研究大型復雜組織的技術轉型。著有風靡全球的《鳳凰項目》《獨角獸項目》。
Jez Humble · 持續(xù)交付之父
Google Cloud SRE、加州大學伯克利分校講師、熱銷書作者,著有Jolt大獎獲獎圖書《持續(xù)交付》。
Patrick Debois · DevOps之父
Snyk公司DevOps關系總監(jiān)兼顧問。致力于通過在開發(fā)、項目管理和系統(tǒng)管理中運用敏捷技術,彌合項目和運營之間的鴻溝。
John Willis · DevOps先驅
Red Hat全球轉型辦公室高級總監(jiān)、Beyond The Phoenix Project作者、Profound播客主持人。在IT管理行業(yè)擁有超過40年經(jīng)驗。
【譯者簡介】
茹炳晟 · 騰訊Tech Lead
騰訊研究院特約研究員、中國計算機學會(CCF)TF研發(fā)效能SIG主席。《測試工程師全棧技術進階與實踐》等暢銷技術書作者。公眾號茹炳晟聊軟件研發(fā)主理人。
管俊 · 戴爾DevOps架構師
目前就職于戴爾中國卓越研發(fā)集團,擔任ACP & VxRail產(chǎn)品研發(fā)部門DevOps架構師。在數(shù)字化轉型方向擁有超過10年一線DevOps工程實踐和團隊建設經(jīng)驗。
董越 · 阿里前架構師
獨立DevOps咨詢師、研發(fā)運營一體化(DevOps)能力成熟度模型核心專家,曾任阿里巴巴集團研發(fā)效能事業(yè)部架構師,當前主要從事企業(yè)級DevOps體系建設的咨詢工作!盾浖桓锻ㄗR》等暢銷技術書作者。
王曉翔 · 去哪兒網(wǎng)前高級總監(jiān)
獨立DevOps咨詢師、研發(fā)運營一體化(DevOps)能力成熟度模型核心專家、去哪兒網(wǎng)前工程效率部高級總監(jiān)。目前致力于為傳統(tǒng)企業(yè)提供DevOps轉型指導。
第 一部分 DevOps三要義
第 1章 敏捷、持續(xù)交付與DevOps三要義5
1.1 制造業(yè)價值流5
1.2 技術價值流5
1.2.1 聚焦部署前置時間6
1.2.2 關注返工指標%C A8
1.3 DevOps三要義:DevOps的基礎原則9
案例研究:向著巡航高度爬升:美國航空的DevOps之旅(第 一部分,2020年)11
1.4 小結14
第 2章 第 一要義:流動15
2.1 使工作可視化15
2.2 限制在制品數(shù)量16
2.3 縮減批量大小17
2.4 減少工作交接19
2.5 持續(xù)識別并改進約束20
2.6 消除價值流中的困境和浪費21
案例研究:醫(yī)療行業(yè)中改善流動性和改進約束的實踐(2021年)22
2.7 小結24
第3章 第二要義:反饋25
3.1 在復雜系統(tǒng)中安全地工作25
3.2 及時發(fā)現(xiàn)問題26
3.3 群策群力,攻克難題28
案例研究:Excella的安燈繩實驗(2018年)30
3.4 從源頭保障質量32
3.5 為下游工作中心優(yōu)化33
3.6 小結33
第4章 第三要義:持續(xù)學習與探索34
4.1 建立學習型組織,打造安全文化35
4.2 將日常工作的改進制度化36
4.3 將局部經(jīng)驗轉化為全局改進38
4.4 在日常工作中注入彈性模式38
4.5 領導層強化與鞏固學習文化39
案例研究:貝爾實驗室的故事(1925年)40
4.6 小結41
第 一部分總結42
第二部分 從哪里開始
第5章 選擇合適的價值流切入45
5.1 綠地項目與棕地項目47
案例研究:Kessel Run:空中加油系統(tǒng)的棕地項目轉型(2020年)49
5.2 兼顧記錄型系統(tǒng)和交互型系統(tǒng)50
5.3 從最具同理心和創(chuàng)新精神的團隊開始51
案例研究:在整個企業(yè)中推廣DevOps轉型:美國航空的DevOps之旅(第二部分,2020年)52
5.4 在組織中推廣DevOps轉型52
案例研究:英國稅務及海關總署如何通過超大規(guī)模PaaS拯救經(jīng)濟于水火(2020年)55
5.5 小結57
第6章 理解、可視化和運用價值流58
6.1 通過繪制價值流圖改進工作58
6.2 確定價值流的參與團隊59
6.3 通過繪制價值流圖展現(xiàn)工作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章 參照康威定律設計組織結構與系統(tǒng)架構69
7.1 組織原型71
7.2 過度以職能為導向的危害(成本優(yōu)化)72
7.3 組建市場型團隊(速度優(yōu)化)72
7.4 讓職能型組織高效運轉73
7.5 將測試、運維和信息安全納入日常工作74
7.6 讓團隊成員都成為通才75
7.7 投資服務與產(chǎn)品,而非項目76
7.8 依照康威定律設定團隊邊界76
7.9 創(chuàng)建松耦合的架構,保證生產(chǎn)力和安全77
7.10 保持小規(guī)模團隊(兩張比薩原則)78
案例研究:Target公司的API啟用項目(2015年)80
7.11 小結81
第8章 將運維融入日常開發(fā)工作82
8.1 構建共享服務,提升開發(fā)人員生產(chǎn)力83
8.2 將運維工程師融入服務團隊85
8.3 為服務團隊指派運維聯(lián)絡人85
8.4 邀請運維工程師參加開發(fā)團隊的例行活動86
8.4.1 邀請運維工程師參加每日站會87
8.4.2 邀請運維工程師參加回顧會議87
8.4.3 使用共享的看板展示相關運維工作88
案例研究:全英房屋抵押貸款協(xié)會:擁抱更好的工作方式(2020年)88
8.5 小結91
第二部分總結91
第三部分 第 一要義:流動的具體實踐
第9章 為部署流水線奠定基礎95
9.1 按需搭建開發(fā)、測試和生產(chǎn)環(huán)境96
9.2 使用統(tǒng)一的代碼倉庫97
9.3 簡化基礎設施的重建99
案例研究:酒店公司如何通過容器技術實現(xiàn)年收入300億美元(2020年)100
9.4 代碼運行在類生產(chǎn)環(huán)境才算開發(fā)完成101
9.5 小結102
第 10章 實現(xiàn)快速可靠的自動化測試103
10.1 持續(xù)構建、測試和集成代碼與環(huán)境106
10.2 構建快速可靠的自動化測試套件108
10.3 在自動化測試階段盡早發(fā)現(xiàn)問題109
10.3.1 確保測試快速運行110
10.3.2 測試驅動開發(fā)111
10.3.3 盡可能將手工測試自動化112
10.3.4 在測試套件中集成性能測試113
10.3.5 在測試套件中集成非功能性需求測試113
10.4 在部署流水線失敗時拉下安燈繩114
10.5 小結116
第 11章 實現(xiàn)持續(xù)集成117
11.1 小批量開發(fā)vs大批量合并119
11.2 基于主干的開發(fā)實踐120
案例研究:Bazaarvoice的持續(xù)集成實踐(2012年)121
11.3 小結123
第 12章 自動化和低風險的發(fā)布124
12.1 部署流程自動化126
案例研究:CSG的每日部署(2013年)127
12.1.1 實現(xiàn)自動化的自助部署129
12.1.2 將代碼部署集成到部署流水線130
案例研究:Etsy持續(xù)部署案例:開發(fā)者自助部署(2014年)131
12.2 部署與發(fā)布解耦133
12.2.1 基于部署環(huán)境的發(fā)布模式134
案例研究:Dixons Retail:藍綠部署在POS系統(tǒng)中的應用(2008年)136
12.2.2 基于應用程序的發(fā)布模式138
案例研究:Facebook Chat功能的灰度發(fā)布案例(2008年)140
12.3 持續(xù)交付和持續(xù)部署實踐調研141
案例研究:CSG:實現(xiàn)開發(fā)與運維的雙贏(2016年)142
12.4 小結146
第 13章 降低發(fā)布風險的架構147
13.1 提高研發(fā)效能、可測試性和安全性的架構148
13.2 架構原型:單體架構vs微服務149
案例研究:亞馬遜的演進式架構(2002年)150
13.3 安全地演進企業(yè)架構151
案例研究:Blackboard Learn的絞殺者應用模式(2011年)152
13.4 小結155
第三部分總結155
第四部分 第二要義:反饋的具體實踐
第 14章 使用監(jiān)控發(fā)現(xiàn)和解決問題159
14.1 搭建集中式的監(jiān)控基礎設施161
14.2 為應用程序添加日志監(jiān)控163
14.3 用監(jiān)控指引問題的分析和解決165
14.4 把添加監(jiān)控融入日常工作165
14.5 以自助方式訪問監(jiān)控數(shù)據(jù)166
案例研究:搭建自助的監(jiān)控體系:LinkedIn的實踐(2011年)167
14.6 對監(jiān)控配置查漏補缺169
14.6.1 應用程序和業(yè)務的監(jiān)控169
14.6.2 基礎設施的監(jiān)控171
14.6.3 顯示其他相關信息172
14.7 小結172
第 15章 使用監(jiān)控預防問題并實現(xiàn)業(yè)務目標173
15.1 用均值和標準差發(fā)現(xiàn)潛在問題174
15.2 監(jiān)測到非預期結果時告警175
15.3 監(jiān)控數(shù)據(jù)非高斯分布帶來的問題176
案例研究:Netflix的自動擴容能力(2012年)177
15.4 使用異常檢測技術179
案例研究:異常檢測中的高級技術(2014年)180
15.5 小結182
第 16章 引入反饋機制實現(xiàn)安全部署183
16.1 利用監(jiān)控確保部署上線更安全184
16.2 讓開發(fā)和運維輪流值班186
16.3 讓開發(fā)人員到價值流下游看一看186
16.4 先由開發(fā)人員自行運維188
案例研究:谷歌的移交就緒評審和發(fā)布就緒評審(2010年)190
16.5 小結192
第 17章 將假設驅動開發(fā)和A B測試納入日常工作193
17.1 A B測試簡史194
17.2 在新功能測試中整合A B測試195
17.3 在軟件發(fā)布中整合A B測試196
17.4 在功能規(guī)劃中整合A B測試196
案例研究:雅虎問答在快速迭代中實驗,實現(xiàn)收入翻倍197
17.5 小結198
第 18章 通過評審和協(xié)調提升工作質量199
18.1 變更審批流程帶來的問題200
18.2 過度變更控制帶來的問題201
案例研究:從三位高管審批到自動審批阿迪達斯的大規(guī)模發(fā)布實踐(2020年)202
18.3 對變更進行協(xié)調和規(guī)劃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
第五部分 第三要義:持續(xù)學習與探索的具體實踐
第 19章 將學習融入日常工作215
19.1 建立公正的學習文化216
19.2 故障發(fā)生后及時召開回顧會議217
19.3 盡可能廣泛公開回顧會議紀要219
19.4 降低事故容差以發(fā)現(xiàn)更弱的故障信號220
19.5 重新定義失敗并鼓勵評估風險221
19.6 向生產(chǎn)環(huán)境注入故障,培養(yǎng)系統(tǒng)彈性和學習氛圍222
19.7 設立故障演練日223
案例研究:CSG如何將故障轉化為有效的學習機會(2021)224
19.8 小結226
第 20章 將局部經(jīng)驗轉化為全局改進227
20.1 將可復用的標準流程自動化228
20.2 創(chuàng)建組織級的單一共享源代碼倉庫229
20.3 用自動化測試記錄、交流實踐以傳播知識231
20.4 通過規(guī)范非功能性需求來設計運維231
20.5 將可復用的運維用戶故事融入開發(fā)過程232
20.6 確保技術選型有助于組織達成目標233
案例研究:Etsy的新技術棧標準化(2010年)234
案例研究:Target的眾包技術治理(2018年)235
20.7 小結236
第 21章 預留時間開展組織學習和改進237
21.1 將償還技術債務變?yōu)槔谢顒?38
21.2 讓所有人教學相長239
21.3 在DevOps會議中分享經(jīng)驗241
案例研究:美國全國保險、Capital One和Target的內部技術會議(2014年)242
21.4 創(chuàng)建社區(qū)結構來推廣實踐243
21.5 小結245
第五部分 總結245
第六部分 整合信息安全、變更管理和合規(guī)性的技術實踐
第 22章 信息安全是每個人的日常工作249
22.1 將安全集成到開發(fā)迭代演示249
22.2 將安全問題納入缺陷跟蹤和事后分析250
22.3 將預防性安全控制集成到共享源代碼倉庫及共享服務250
22.4 將安全集成到部署流水線252
22.5 保障應用程序安全253
案例研究:Twitter的靜態(tài)安全測試(2009年)254
22.6 保障軟件供應鏈安全256
22.7 保障環(huán)境安全261
案例研究:18F使用Compliance Masonry實現(xiàn)聯(lián)邦政府合規(guī)性審查自動化(2016年)261
22.8 將信息安全集成到生產(chǎn)監(jiān)控系統(tǒng)262
22.8.1 為應用程序創(chuàng)建安全監(jiān)控263
22.8.2 為環(huán)境創(chuàng)建安全監(jiān)控263
案例研究:Etsy的環(huán)境監(jiān)測(2010年)264
22.9 保護部署流水線265
案例研究:在Fannie Mae開展安全左移(2020年)266
22.10 小結267
第 23章 保護部署流水線268
23.1 將安全和合規(guī)集成到變更審批流程268
23.2 將低風險的變更歸類為標準變更269
23.3 當變更被歸類為常規(guī)變更時如何處理270
案例研究:Salesforce將自動化基礎設施變更歸類為標準變更(2012年)270
23.4 通過代碼評審實現(xiàn)職責分離271
案例研究:Etsy的PCI合規(guī)性以及一則職責分離的警示故事(2014年)272
案例研究:通過業(yè)務與技術合作,Capital One實現(xiàn)每天10次有信心的發(fā)布(2020年)274
23.5 確保為合規(guī)官和審計師提供文檔和證據(jù)275
案例研究:證明監(jiān)管環(huán)境下的合規(guī)性(2015年)275
案例研究:ATM系統(tǒng)離不開生產(chǎn)監(jiān)控(2013年)277
23.6 小結278
第六部分 總結278
附錄1:DevOps大融合286
附錄2:約束理論和長期存在的根本矛盾288
附錄3:惡性循環(huán)列表289
附錄4:交接和隊列的危害289
附錄5:工業(yè)安全的誤區(qū)291
附錄6:豐田安燈繩291
附錄7:COTS軟件292
附錄8:事后分析會議(回顧會議)292
附錄9:猿猴軍團293
附錄10:上線時間透明化294