DevOps實踐指南（第2版）

第 一部分 DevOps三要義
第 1章 敏捷、持續(xù)交付與DevOps三要義5
1.1 制造業(yè)價值流5
1.2 技術(shù)價值流5
1.2.1 聚焦部署前置時間6
1.2.2 關(guān)注返工指標——%C A8
1.3 DevOps三要義：DevOps的基礎(chǔ)原則9
案例研究：向著巡航高度爬升：美國航空的DevOps之旅（第 一部分，2020年）11
1.4 小結(jié)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 小結(jié)24
第3章 第二要義：反饋25
3.1 在復雜系統(tǒng)中安全地工作25
3.2 及時發(fā)現(xiàn)問題26
3.3 群策群力，攻克難題28
案例研究：Excella的安燈繩實驗（2018年）30
3.4 從源頭保障質(zhì)量32
3.5 為下游工作中心優(yōu)化33
3.6 小結(jié)33
第4章 第三要義：持續(xù)學習與探索34
4.1 建立學習型組織，打造安全文化35
4.2 將日常工作的改進制度化36
4.3 將局部經(jīng)驗轉(zhuǎn)化為全局改進38
4.4 在日常工作中注入彈性模式38
4.5 領(lǐng)導層強化與鞏固學習文化39
案例研究：貝爾實驗室的故事（1925年）40
4.6 小結(jié)41
第 一部分總結(jié)42
第二部分 從哪里開始
第5章 選擇合適的價值流切入45
5.1 綠地項目與棕地項目47
案例研究：Kessel Run：空中加油系統(tǒng)的棕地項目轉(zhuǎn)型（2020年）49
5.2 兼顧記錄型系統(tǒng)和交互型系統(tǒng)50
5.3 從最具同理心和創(chuàng)新精神的團隊開始51
案例研究：在整個企業(yè)中推廣DevOps轉(zhuǎn)型：美國航空的DevOps之旅（第二部分，2020年）52
5.4 在組織中推廣DevOps轉(zhuǎn)型52
案例研究：英國稅務(wù)及海關(guān)總署如何通過超大規(guī)模PaaS拯救經(jīng)濟于水火（2020年）55
5.5 小結(jié)57
第6章 理解、可視化和運用價值流58
6.1 通過繪制價值流圖改進工作58
6.2 確定價值流的參與團隊59
6.3 通過繪制價值流圖展現(xiàn)工作60
6.4 組建專職轉(zhuǎn)型團隊61
6.4.1 目標一致62
6.4.2 保持小跨度的改進計劃63
6.4.3 為非功能性需求和償還技術(shù)債務(wù)預留20%的時間63
案例研究：LinkedIn的“反轉(zhuǎn)行動”（2011年）65
6.4.4 提高工作的可視化程度67
6.5 使用工具強化預期行為67
6.6 小結(jié)68
第7章 參照康威定律設(shè)計組織結(jié)構(gòu)與系統(tǒng)架構(gòu)69
7.1 組織原型71
7.2 過度以職能為導向的危害（“成本優(yōu)化”）72
7.3 組建市場型團隊（“速度優(yōu)化”）72
7.4 讓職能型組織高效運轉(zhuǎn)73
7.5 將測試、運維和信息安全納入日常工作74
7.6 讓團隊成員都成為通才75
7.7 投資服務(wù)與產(chǎn)品，而非項目76
7.8 依照康威定律設(shè)定團隊邊界76
7.9 創(chuàng)建松耦合的架構(gòu)，保證生產(chǎn)力和安全77
7.10 保持小規(guī)模團隊（“兩張比薩”原則）78
案例研究：Target公司的“API啟用”項目（2015年）80
7.11 小結(jié)81
第8章 將運維融入日常開發(fā)工作82
8.1 構(gòu)建共享服務(wù)，提升開發(fā)人員生產(chǎn)力83
8.2 將運維工程師融入服務(wù)團隊85
8.3 為服務(wù)團隊指派運維聯(lián)絡(luò)人85
8.4 邀請運維工程師參加開發(fā)團隊的例行活動86
8.4.1 邀請運維工程師參加每日站會87
8.4.2 邀請運維工程師參加回顧會議87
8.4.3 使用共享的看板展示相關(guān)運維工作88
案例研究：全英房屋抵押貸款協(xié)會：擁抱更好的工作方式（2020年）88
8.5 小結(jié)91
第二部分總結(jié)91
第三部分 “第 一要義：流動”的具體實踐
第9章 為部署流水線奠定基礎(chǔ)95
9.1 按需搭建開發(fā)、測試和生產(chǎn)環(huán)境96
9.2 使用統(tǒng)一的代碼倉庫97
9.3 簡化基礎(chǔ)設(shè)施的重建99
案例研究：酒店公司如何通過容器技術(shù)實現(xiàn)年收入300億美元（2020年）100
9.4 代碼運行在類生產(chǎn)環(huán)境才算“開發(fā)完成”101
9.5 小結(jié)102
第 10章 實現(xiàn)快速可靠的自動化測試103
10.1 持續(xù)構(gòu)建、測試和集成代碼與環(huán)境106
10.2 構(gòu)建快速可靠的自動化測試套件108
10.3 在自動化測試階段盡早發(fā)現(xiàn)問題109
10.3.1 確保測試快速運行110
10.3.2 測試驅(qū)動開發(fā)111
10.3.3 盡可能將手工測試自動化112
10.3.4 在測試套件中集成性能測試113
10.3.5 在測試套件中集成非功能性需求測試113
10.4 在部署流水線失敗時拉下安燈繩114
10.5 小結(jié)116
第 11章 實現(xiàn)持續(xù)集成117
11.1 小批量開發(fā)vs大批量合并119
11.2 基于主干的開發(fā)實踐120
案例研究：Bazaarvoice的持續(xù)集成實踐（2012年）121
11.3 小結(jié)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)中的應(yīng)用（2008年）136
12.2.2 基于應(yīng)用程序的發(fā)布模式138
案例研究：Facebook Chat功能的灰度發(fā)布案例（2008年）140
12.3 持續(xù)交付和持續(xù)部署實踐調(diào)研141
案例研究：CSG：實現(xiàn)開發(fā)與運維的雙贏（2016年）142
12.4 小結(jié)146
第 13章 降低發(fā)布風險的架構(gòu)147
13.1 提高研發(fā)效能、可測試性和安全性的架構(gòu)148
13.2 架構(gòu)原型：單體架構(gòu)vs微服務(wù)149
案例研究：亞馬遜的演進式架構(gòu)（2002年）150
13.3 安全地演進企業(yè)架構(gòu)151
案例研究：Blackboard Learn的絞殺者應(yīng)用模式（2011年）152
13.4 小結(jié)155
第三部分總結(jié)155
第四部分 “第二要義：反饋”的具體實踐
第 14章 使用監(jiān)控發(fā)現(xiàn)和解決問題159
14.1 搭建集中式的監(jiān)控基礎(chǔ)設(shè)施161
14.2 為應(yīng)用程序添加日志監(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īng)用程序和業(yè)務(wù)的監(jiān)控169
14.6.2 基礎(chǔ)設(shè)施的監(jiān)控171
14.6.3 顯示其他相關(guān)信息172
14.7 小結(jié)172
第 15章 使用監(jiān)控預防問題并實現(xiàn)業(yè)務(wù)目標173
15.1 用均值和標準差發(fā)現(xiàn)潛在問題174
15.2 監(jiān)測到非預期結(jié)果時告警175
15.3 監(jiān)控數(shù)據(jù)非高斯分布帶來的問題176
案例研究：Netflix的自動擴容能力（2012年）177
15.4 使用異常檢測技術(shù)179
案例研究：異常檢測中的高級技術(shù)（2014年）180
15.5 小結(jié)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 小結(jié)192
第 17章 將假設(shè)驅(qū)動開發(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 小結(jié)198
第 18章 通過評審和協(xié)調(diào)提升工作質(zhì)量199
18.1 變更審批流程帶來的問題200
18.2 過度變更控制帶來的問題201
案例研究：從三位高管審批到自動審批——阿迪達斯的大規(guī)模發(fā)布實踐（2020年）202
18.3 對變更進行協(xié)調(diào)和規(guī)劃204
18.4 對變更進行同行評議204
案例研究：谷歌的代碼評審（2010年）206
18.5 凍結(jié)變更并進行大量手工測試的隱患207
18.6 用結(jié)對編程提升各種類型變更的質(zhì)量207
案例研究：Pivotal用結(jié)對編程代替阻滯的代碼評審過程（2011年）208
18.7 分析拉取請求過程的有效性209
18.8 對官僚化流程進行大膽簡化210
18.9 小結(jié)211
第四部分 總結(jié)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 設(shè)立故障演練日223
案例研究：CSG如何將故障轉(zhuǎn)化為有效的學習機會（2021）224
19.8 小結(jié)226
第 20章 將局部經(jīng)驗轉(zhuǎn)化為全局改進227
20.1 將可復用的標準流程自動化228
20.2 創(chuàng)建組織級的單一共享源代碼倉庫229
20.3 用自動化測試記錄、交流實踐以傳播知識231
20.4 通過規(guī)范非功能性需求來設(shè)計運維231
20.5 將可復用的運維用戶故事融入開發(fā)過程232
20.6 確保技術(shù)選型有助于組織達成目標233
案例研究：Etsy的新技術(shù)棧標準化（2010年）234
案例研究：Target的眾包技術(shù)治理（2018年）235
20.7 小結(jié)236
第 21章 預留時間開展組織學習和改進237
21.1 將償還技術(shù)債務(wù)變?yōu)槔谢顒?38
21.2 讓所有人教學相長239
21.3 在DevOps會議中分享經(jīng)驗241
案例研究：美國全國保險、Capital One和Target的內(nèi)部技術(shù)會議（2014年）242
21.4 創(chuàng)建社區(qū)結(jié)構(gòu)來推廣實踐243
21.5 小結(jié)245
第五部分 總結(jié)245
第六部分 整合信息安全、變更管理和合規(guī)性的技術(shù)實踐
第 22章 信息安全是每個人的日常工作249
22.1 將安全集成到開發(fā)迭代演示249
22.2 將安全問題納入缺陷跟蹤和事后分析250
22.3 將預防性安全控制集成到共享源代碼倉庫及共享服務(wù)250
22.4 將安全集成到部署流水線252
22.5 保障應(yīng)用程序安全253
案例研究：Twitter的靜態(tài)安全測試（2009年）254
22.6 保障軟件供應(yīng)鏈安全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 為應(yīng)用程序創(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 小結(jié)267
第 23章 保護部署流水線268
23.1 將安全和合規(guī)集成到變更審批流程268
23.2 將低風險的變更歸類為標準變更269
23.3 當變更被歸類為常規(guī)變更時如何處理270
案例研究：Salesforce將自動化基礎(chǔ)設(shè)施變更歸類為標準變更（2012年）270
23.4 通過代碼評審實現(xiàn)職責分離271
案例研究：Etsy的PCI合規(guī)性以及一則職責分離的警示故事（2014年）272
案例研究：通過業(yè)務(wù)與技術(shù)合作，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 小結(jié)278
第六部分 總結(jié)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