大規模組織DevOps實踐（簡體書）

DevOps是開發運維一體化的軟件工程思想，DevOps嘗試打破部門牆，構建一個協同的IT建設運行環境，通過工具鏈形成數據關聯的規範化、規模化的軟件持續交付流水線，從而助力企業業務的敏捷發展。本書用9章內容，結合項目實戰案例和業界主流工具，從思想、實踐方法、工具技術、案例等方面闡述了DevOps在傳統規模化IT組織中實施落地的方法。本書適合IT主管、項目經理、開發、測試、配置管理、運維等IT從業人員閱讀。

陳能技
擁有16年IT從業經驗，歷任測試工程師、QA、項目經理、培訓講師、諮詢顧問、架構師、技術總監等職位，親歷手工作坊式軟件團隊到專業化交付工程團隊的發展過程。現任新維數聯（北京）科技有限公司DevOps售前顧問及解決方案總監、北京量子仿真科技有限公司產品經理、工信部 ITSS工作組DevOps專家組組長。專注於研究DevOps以及軟件專業化交付能力，目前正在帶領團隊致力於打造覆蓋軟件全生命週期交付的DevOps產品――“AutoChain”，以及定位於“讓天下沒有難測的軟件”為產品價值導向的接口仿真驗證平臺。

付勇

擁有18年IT從業經驗，先後擔任過系統管理員、研發工程師、項目經理、售前顧問、產品經理、研發總監、CTO等職位。主要專注于金融、運營商等行業客戶的監控運維體系設計與系統建設，近5年主要從事大規模組織DevOps的體系設計、諮詢與自動化工具鏈的研究工作，主導過多個金融行業DevOps項目的諮詢及建設工作，積累了較為豐富的DevOps體系設計與落地建設經驗。
目前專注於大規模組織DevOps工程實踐方面的研究，在代碼版本管理策略、持續集成、應用與數據庫腳本發佈等領域有著深刻理解和實踐經驗，同時研究的專業領域還包括自動化測試、服務虛擬化、自動化監控等。

未來的企業都是軟件企業，是面向互聯網、物聯網、大數據和人工智能的企業，軟件作為信息系統的核心部分一直面臨著專業化交付的問題，如何才能像工廠生產零部件和整機一樣可以流水線作業、批量化生產和交付，是IT從業人員一直追求的目標。
從早年的ISO、CMMI，到近年來的敏捷、精益，再到最近所倡導的DevOps，其實都在嘗試解決軟件行業的專業化交付問題。看起來ISO、CMMI有點過於保守、笨重、僵化，而敏捷又過於靈活、難以規模化應用，直到最近我們看到DevOps所倡導的開發、測試、運維一體化協同，以及自動化流水線的構建，結合新興的技術（如微服務、容器等），我們認為這是非常有希望解決規模化組織下的專業化交付問題的。
陳能技在軟件專業化交付這個領域探索和實踐了十幾年，將自己的所見、所思、所想、所踐、所得集結成冊，共享給行業同人，實屬可貴、可敬。
潤和軟件自成立至今始終堅持“國際化”“專業化”“高端化”的發展戰略，公司的主營業務為向國內外客戶提供基於業務解決方案的軟件和信息技術服務，業務聚焦在“金融信息化”“智能電網信息化”“智能終端嵌入式軟件”“智能供應鏈信息化”“系統集成及運維服務”等專業領域，擁有全球軟件服務能力，能夠為客戶提供全面、即時、高效的軟件和信息技術服務。
我們將借助DevOps（開發運維一體化）、SAFe（規模化）等新興的軟件交付方法，打造和持續完善我們的專業化交付團隊，為國內外客戶提供優質的IT服務。
陳 斌
潤和軟件總裁

前 言

DevOps代表了IT領域最新的發展趨勢，傳統金融IT部門在嘗試DevOps轉型中碰到各種問題和諸多誤區，我們在DevOps領域深耕多年，結合金融企業實際問題進行各種探索與實踐，提出從流水線設計、自動化、度量等多個維度進行DevOps體系建設，從而形成企業IT“專業化交付”能力的實踐方法，構建全生命週期雙模軟件自動化生產發佈與智能化運維的“BTO”藍圖。
我們將這幾年在傳統企業落地實施敏捷、DevOps的經驗集結成書，分享給大家，希望能夠幫助大家在DevOps的轉型中少走一些彎路。
在本書即將出版之際，我想談談這幾年從事DevOps領域業務的一些感悟，不管是幫助某運營商企業規劃設計DevOps體系，還是在某科技公司擔任架構師設計DevOps工具平臺，或者是現在所專注的工作――DevOps解決方案諮詢和售前，我始終在思考一個問題，即如何將看似先進的DevOps思想和理念成功地導入國內的傳統企業。
不管是不是敏捷、是否DevOps，始終要解決如下幾個核心問題。
1. 流程改進
如何使流程更加精益，以及通過杜絕浪費提高效率。
2. 工具自動化
如何利用工具實現流程的自動化改進，使其具有可重複性及可擴展性，同時減少錯誤的發生。
3. 平臺及環境
如何為從需求到生產上線全過程中各種應用的交付流水線，搭建更具彈性、靈活、可伸縮、可配置的平臺及環境。
4. 文化
尤其是如何塑造信任、溝通、協作的文化氛圍。
DevOps的實施一定要有業務目標。通常業務線對IT部門的要求包括快速交付、敏捷、創新、優質、低成本。因此，IT部門需要想辦法建立以下能力：
? 價值交付時間。
? 部署速度。
? 成本節約―交付時間。
? 成本節約―測試時間。
? 提高測試覆蓋率。
? 提高環境利用率。
? 最大限度地縮短部署所需的停機時間。
? 最大限度地減少部署所花費的時間。
? 盡可能地減少部署應用的回滾。
? 提高再現與缺陷修復能力。
? 最大限度地縮短產品問題的平均修復時間（MTTR）。
? 縮短缺陷週期。
本書分為思想篇、實踐方法篇、工具技術篇、案例篇四部分，把傳統企業實施DevOps會碰到的困惑，在開發、測試、運維三大領域各有哪些DevOps最佳實踐，以及如何結合開源或商業工具打造交付流水線工具鏈，分別進行了闡述，希望對你在實施DevOps轉型過程中實現上述業務目標有所幫助。
本書出版之時恰逢國內DevOps領域蓬勃發展之際，DevOps相關的峰會已經舉辦了兩年，我們一直關注會議的各類議題，發現從前幾年的大談概念為主，到近期大家紛紛聚焦在落地實踐方法、工具鏈的打造、各種探索實驗總結、國內外不同行業的實踐案例等，這表明DevOps已經開始逐步深入人心，逐步地幫企業解決IT中的各類問題，走向更高級的發展階段。
在出版本書的過程中，得到了所在公司新維數聯（北京）科技有限公司（前身為“天維科技”）的大力支持，書中提煉的很多實踐經驗及工具平臺設計理念來源於該公司的項目交付團隊及產品團隊。第6章“雙模發佈管理平臺的設計與應用”的內容主要來自公司的DevOps產品線經理付勇兩年多的實戰經驗總結，該產品AutoChain已經獲得業界領先地位，更獲得了傳統金融行業（銀行、保險）客戶的認可，知名度比較高，值得大家參考借鑒其設計理念。另外，也要特別感謝新維數聯的CEO王勇先生及VP王思國先生對本書的出版給予的支持和幫助，他們在DevOps領域的業務洞察能力和方向把握能力令我欽佩，王勇把軟件系統的建設（Build）、檢驗（Test）、運營（Operation）提煉成了“BTO”藍圖，並以此為公司業務發展戰略落實執行，在本書的成稿過程中也提出了很多有建設性的意見。
本書中的“軟件工廠”的先進軟件工程思想來源於王傑先生，他是一個能深入思考和洞察軟件行業發展趨勢及傳統IT行業各類問題所在的人。他一手創辦了中國金融IT行業最大的軟件測試服務提供商――捷科智誠，提出“軟件工廠”思想並創辦了隆正互聯公司，該公司的負責人吳向東老師也是我非常敬佩的人，在落地實施軟件工廠的建設方面不遺餘力，我也有幸在兩位老師的指導下，基於DevOps的理念設計了軟件工廠的生產流水線。書中不少實踐經驗的總結提煉都來源於我所服務的客戶，如中國銀行、中信銀行、安邦保險、青島銀行等，在此也感謝它們給予我這麼寶貴的實踐機會和項目上的協助，讓我在產品設計及理論方法上都能更上一個臺階。
本書關於軟件標準化生產、IT CT化的思想來源於與福建某運營商高管的交流過程中的領悟，獲益匪淺，在此表示感謝；本書關於技術債務的處理實踐方法來源於浙江某運營商的項目經驗，在此表示感謝。該運營商曾在業界率先引入敏捷、DevOps思想，並建設了相關的DevOps平臺，我有幸參與該平臺的建設過程並負責相關規劃設計工作，獲益匪淺。
本書關於持續集成的部分案例來自深圳某政府單位的研發過程管控項目的實踐，在此表示感謝。從這個項目的實踐中我探索了中等規模企業對DevOps的需求與實踐方法，提煉出不少有用的經驗。
本書關於敏捷、規模化敏捷的思考受到光環國際李建昊老師的啟發，該公司是國內最大的PMP、敏捷項目培訓、諮詢服務公司之一。
本書關於容器技術相關的內容得到了合作夥伴數人雲的幫助，他們是國內專注於微服務、容器雲、DevOps領域的公司，感謝公司創始人王璞和售前總監賀洪龍在DevOps合作項目過程中給予的幫助，以及對本書內容提出的寶貴建議。
本書關於持續集成過程中整合性能測試的內容得到了合作夥伴臻雲科技的幫助，公司的創始人金髮華、王凡基於開源的JMeter發展了業界領先的性能測試平臺XMeter。
本書關於精准測試的內容得到了合作夥伴星雲測試的幫助，精准測試所倡導的通過代碼覆蓋率度量測試充分度，關聯測試用例進行精准回歸測試的做法與DevOps的協同、自動化理念非常吻合。
本書成書過程中還得到了公司同事的幫助，如付勇、彭菲、陳強、彭偉國、黃凱、李翅展等，他們在各自的領域都非常資深，包括SCRUM、配置管理、自動化測試等，他們在並肩作戰的各類項目中提煉總結經驗，提供書稿素材，在此表示衷心感謝。
本書將採用敏捷思想持續迭代優化，歡迎大家提出優化修改建議，我將在“IT運營公社”公眾號與讀者進行互動。

陳能技
2018年7月

第一部分 思想篇
第1章 軟件工廠 2
1.1 軟件的生產力 2
1.2 軟件工廠――軟件的標準化生產 4
1.2.1 標準化生產模式需要一個集成底座――PaaS 4
1.2.2 標準化軟件生產流水線 6
第2章 DevOps思想 8
2.1 DevOps思想與生產流水線 8
2.1.1 DevOps的起源 8
2.1.2 DevOps對軟件工廠的啟發 9
2.1.3 從DevOps實踐原則看軟件生產工藝化水平的提高 10
2.1.4 軟件工廠模式下對生產工具發展的促進作用 10
2.2 從瀑布到敏捷 11
2.2.1 傳統項目管理問題 12
2.2.2 向互聯網企業學習的“敏捷” 13
2.2.3 敏捷的起源 14
2.2.4 瀑布模型 15
2.2.5 傳統企業不可能全盤敏捷化 15
2.2.6 從版本上線過程管理看敏捷與瀑布 16
2.2.7 敏捷的前提是“不敏捷” 17
2.3 敏捷與DevOps核心思想 18
2.3.1 增量開發與測試 18
2.3.2 持續集成與持續交付 19
2.3.3 自動化 21
2.4 規模化的敏捷 22
2.4.1 從敏捷項目管理到敏捷項目集群管理 22
2.4.2 企業規模化敏捷思想 24
2.4.3 規模化敏捷方法――SAFe 25
2.4.4 規模化敏捷開發的最佳實踐 28
2.5 企業規模化敏捷與軟件工廠 31
2.5.1 軟件生產環境 31
2.5.2 軟件工廠生產環境管理――開發測試雲 33
2.5.3 整合環境仿真 37
2.5.4 不可忽略的辦公環境因素 43
2.5.5 軟件工廠質量檢測――深度自動化測試裝置 45
第二部分 實踐方法篇
第3章 DevOps體系的建立 49
3.1 構建DevOps流水線，打通開發―測試―運維持續交付通道 49
3.2 敏捷開發知識體系 50
3.3 Scrum框架 51
3.3.1 Scrum的3類角色 52
3.3.2 Scrum的3份工件 52
3.3.3 Scrum的5項活動 53
3.3.4 Scrum的5個價值觀 54
3.4 敏捷、DevOps與協作 54
3.5 開發域DevOps實踐 55
3.5.1 敏捷需求 55
3.5.2 傳統需求分析 55
3.5.3 敏捷需求方法 57
3.5.4 面向敏捷的架構設計 61
3.5.5 向微服務架構遷移的基本做法 63
3.5.6 向微服務架構遷移的低風險演進方法 64
3.5.7 微服務架構設計模式 74
3.5.8 開發敏捷 77
3.5.9 分支策略 77
3.5.10 依賴包管理 79
3.5.11 技術債務 80
3.5.12 技術債務的形成 80
3.5.13 技術債務的分類 83
3.5.14 技術債務與質量投資 84
3.5.15 技術債務處理方法 85
3.5.16 持續集成 88
3.5.17 持續集成最佳實踐 91
3.5.18 持續集成最佳實踐――持續編譯 92
3.5.19 持續集成最佳實踐――持續代碼檢查 92
3.5.20 持續集成最佳實踐――持續測試 93
3.5.21 持續集成最佳實踐――持續部署 94
3.5.22 持續集成最佳實踐――持續報告 94
3.5.23 企業持續集成實施方法 95
3.5.24 持續集成實施案例介紹 96
3.6 測試域DevOps實踐 96
3.6.1 敏捷測試環境管理 96
3.6.2 業界關於測試環境管理的實踐 98
3.6.3 測試如何納入持續集成體系中 100
3.6.4 敏捷測試方法與傳統測試方法的不同之處 105
3.6.5 敏捷測試人員的定義 106
3.6.6 敏捷測試過程管理 107
3.6.7 敏捷測試團隊管理 112
3.7 運維域DevOps實踐 113
3.7.1 敏捷基礎設施 113
3.7.2 自動化部署 113
3.7.3 自動化部署的要素 114
3.7.4 部署常見場景及問題 115
3.7.5 部署服務工具鏈 116
3.7.6 資源部署 117
3.7.7 自動化資源部署 117
3.7.8 應用部署 119
3.7.9 應用交付容器化 120
3.7.10 應用容器化改造 121
3.7.11 不中斷服務的部署方法 121
3.7.12 敏捷運維 125
第4章 DevOps的有效實踐 129
4.1 敏捷模式與傳統企業研發模式的結合 129
4.2 敏捷模式與傳統ISO、CMMI標準規範的兼容 131
4.2.1 需求獲取 131
4.2.2 方案制定（或技術評估） 132
4.2.3 生產任務排期 135
4.2.4 Sprint 0――迭代前準備 135
4.2.5 Sprint 0――基礎框架搭建 143
4.2.6 迭代實施 143
4.2.7 驗收測試 154
4.2.8 投產 155
4.3 敏捷與DevOps基礎實踐 155
4.3.1 SRE與發佈工程 155
4.3.2 配置管理――版本管理 161
4.3.3 配置管理――發佈包製作規範 165
4.3.4 缺陷管理 167
4.3.5 缺陷預防 168
4.3.6 迭代週期的時間 169
4.4 敏捷與DevOps反模式 170
4.4.1 急功近利 170
4.4.2 跨部門協作的浪費 172
4.4.3 持續集成“壞味道” 176
4.4.4 手工完成所有部署 178
4.4.5 開發與運維各一套自動化部署系統 178
4.4.6 重建數據庫比較困難 179
第三部分 工具技術篇
第5章 精准測試技術 182
5.1 什麼是精准測試技術 182
5.1.1 傳統測試方法面臨大型軟件時的問題與瓶頸 182
5.1.2 傳統白盒測試方法的問題 183
5.1.3 開發團隊和測試團隊協同工作難 183
5.1.4 精准測試方法解決的問題 184
5.1.5 精准測試的工作模式與工作原理 185
5.2 精准測試雲平臺 186
5.2.1 測試複雜度分析 186
5.2.2 測試複雜度種類 187
5.2.3 覆蓋率分析 188
5.2.4 軟件內部邏輯結構可視化 192
5.2.5 函數列表功能說明 196
5.2.6 覆蓋率可視化 197
5.2.7 動態實時測試監控 199
5.2.8 缺陷管理系統 199
5.2.9 Bug與崩潰代碼級捕獲 201
5.2.10 雙向追溯 202
5.2.11 多版本與累計覆蓋率 205
5.2.12 智能的回歸測試用例選取分析算法 206
5.2.13 測試用例的聚類分析算法 207
5.3 精准測試與度量分析 208
5.3.1 獲取度量信息 208
5.3.2 項目度量指標 208
5.3.3 項目匯總 211
5.3.4 測試用例――按日趨勢圖 213
5.3.5 測試用例――測試用例列表 215
5.3.6 測試人、機 218
5.3.7 測試缺陷――Bug信息匯總 219
5.3.8 測試缺陷――Bug詳細列表 220
5.3.9 覆蓋率――按日增長趨勢圖 221
5.3.10 函數、類、文件覆蓋率統計 223
5.3.11 函數、類、文件複雜度和覆蓋率關係圖 223
5.3.12 覆蓋率列表 224
5.3.13 函數、類、包複雜度統計 226
5.3.14 測試覆蓋率漏洞的智能分析 227
第6章 雙模發佈管理平臺的設計與應用 229
6.1 產生背景 229
6.1.1 傳統企業數字化轉型浪潮下的雙模挑戰 229
6.1.2 雙模發佈管理平臺 230
6.2 雙模發佈管理平臺設計 231
6.2.1 設計思路 231
6.2.2 架構設計 233
6.3 案例及功能說明 234
6.3.1 案例背景介紹 235
6.3.2 痛點診斷及建設目標 236
6.3.3 功能說明 236
第7章 整合環境仿真技術 252
7.1 服務虛擬化技術 252
7.2 Lisa解決方案特色 253
7.3 採用Lisa方案的預期效果 254
7.4 Lisa實施和服務模式舉例 256
第8章 容器技術 259
8.1 容器與Docker 259
8.2 應用容器化 261
8.3 Dockerfile 命令詳解 266
8.4 Dockerfile使用建議 270
8.5 應用上雲容器 271
8.5.1 上雲應用的場景 271
8.5.2 軟件和硬件的限制 272
8.5.3 應用架構的限制 272
8.5.4 應用上雲建議 274
8.6 容器化應用開發規範 275
8.6.1 應用預編譯 275
8.6.2 熱點數據緩存 277
8.6.3 應用無狀態化 277
8.6.4 應用上配置的定時任務需與應用分離 278
8.6.5 應用使用固定的服務監聽端口 278
8.6.6 主機名和服務端口獲取 278
8.6.7 數據庫連接池 279
8.6.8 應用日誌 279
8.6.9 應用中間件選型 279
8.6.10 應用環境配置規範 280
8.6.11 硬件負載 280
8.6.12 不要在容器中存儲數據 281
8.6.13 不要發佈兩個應用 281
8.6.14 清除不必要的包和文件 281
8.6.15 不要在容器中運行多個進程 281
8.6.16 不要在鏡像中存儲憑據、使用環境變量 281
8.6.17 使用非root用戶運行 281
8.6.18 不要依賴IP