2019年轉型的燈塔！DevOps 持續交付能力成熟度模型及最新實踐.pdf

1、G O P S 全 球 運 維 大 會 2 0 1 9 上 海 站G O P S 全 球 運 維 大 會 2 0 1 9 上 海 站轉型的燈塔！DevOps 持續交付能力成熟度模型及最新實踐G O P S 全 球 運 維 大 會 2 0 1 9 上 海 站目錄DevOps的重要性1DevOps實施的五個關鍵階段2DevOps實施的四個要素和七個問題3持續交付能力成熟度模型介紹4二級應該怎么做5G O P S 全 球 運 維 大 會 2 0 1 9 上 海 站為什么DevOps很重要提質增效，行業總體趨勢減少停機時間，更快上線減少人為錯誤，更安全，少故障降低人員流失帶來的傷害您的競爭對手已經在這

2、樣做G O P S 全 球 運 維 大 會 2 0 1 9 上 海 站DevOps實施的五個關鍵階段定目標 理解DevOps，培訓賦能，上下對齊，設定共同目標看現狀 評估現有研發流程，技術棧，工具鏈，文化，管理，組織結構找差距 對標DevOps能力成熟度模型，找到差距，分析原因，設計方案畫藍圖 繪制DevOps實施路線圖搞事情 小規模試驗，探索+調整，復制流程，大規模應用G O P S 全 球 運 維 大 會 2 0 1 9 上 海 站流程 基于現有產品研發流程進行梳理 打通流程的各個環節 保證流程的流暢和閉環 不斷優化 可復制的流程管理規范 需求規范 開發規范 測試規范 部署規范 運維規范技

3、術/平臺 技術架構 跨平臺，多終端 云服務，自服務 業務管理平臺 開發/測試/部署/監控平臺DevOps實施的四個要素可視化（DevOps流水線+度量體系）G O P S 全 球 運 維 大 會 2 0 1 9 上 海 站1.DevOps 長什么樣？2.DevOps 真的有用？3.DevOps 真的對我有用？4.DevOps 常見路線圖5.我在哪兒，我做的如何？6.我要做什么才能變得更好？7.我要用什么工具？DevOps標準看見全貌參考路線定位度量改進方向工具平臺DevOps 轉型與落地，我們需要弄清楚七個問題G O P S 全 球 運 維 大 會 2 0 1 9 上 海 站主管單位：工信部

4、中國信息通信研究院（國家級智庫，可信云等出品單位）聯合發起：OSCAR 聯盟、DevOps時代社區、高效運維社區起草單位：中國信息通信研究院、DevOps時代社區、高效運維社區、BATJ、中國移動、中國電信、中國銀行、中國太平洋保險集團等目前進展：工信部和聯合國ITU-T正式立項，2018年6月29發布全量送審稿DevOps 標準：研發運營一體化能力成熟度模型級別英文中文1級Initial Level初始級2級Foundation Level基礎級3級Comprehensive Level全面級4級Excellent Level優秀級5級Fabulous Level卓越級G O P S 全 球

5、 運 維 大 會 2 0 1 9 上 海 站G O P S 全 球 運 維 大 會 2 0 1 9 上 海 站 1.具備中等企業IT交付水平 2.集中式管理，在局部建立自動化能力（包括構建、測試、部署與環境配置等）3.可按月進行發布，交付時長與質量具備一定水平，部署成功率和業務連續性相對穩定二級 1.具備成熟企業IT交付水平（IT能力是業務支撐）2.專業化管理，在全流程建立自動化能力，端到端打通各個交付環節 3.可按天或周進行發布，內建質量管控，部署失敗率低，業務可用性高 4.具備一定的度量可視化能力，客觀體現團隊現狀和問題三級 1.具備頂級互聯網/科技企業IT交付水平（IT能力是核心競爭力）

6、2.團隊自治，實現持續交付平臺化，CD as Service，并對研發團隊進行賦能 3.每天具備多次發布的能力，團隊可按需自行交付，實現業務無中斷和高質量 4.具備較強的度量反饋機制，業務實現良性增長和團隊持續改進四級國內先進水平DevOps標準的級別說明G O P S 全 球 運 維 大 會 2 0 1 9 上 海 站為了實現二級，我們還有很多問題版本混亂無法回溯，修復了的Bug又出現了每次集成伴隨大量的問題和沖突，集成期間主干長期不可用迭代6次才能上線投產一次，版本如何管理進度不可控，等待上線時間太長部署步驟太多太復雜，上線經常失敗為了實現二級，我們還有很多 問題 機會G O P S 全

7、球 運 維 大 會 2 0 1 9 上 海 站配置管理過程域二級 過程域評估維度一級（初始級）二級（基礎級：自動化/腳本化、小范圍）配置管理版本控制版本控制系統源代碼分散在研發本地自行管理1)使用統一的版本控制系統2)將全部源代碼納入版本控制系統管理分支管理無分支策略，或沒有統一策略多條分支長期并行存在且分支合并到主干的周期長制品管理構建產物分散在研發本地自行管理1)使用統一的制品庫管理構建產物2)有清晰的存儲結構3)有唯一的版本號4)通過統一的制品庫地址進行構建產物分發單一可信數據源無開發測試部署環節所用到的源代碼來源于統一版本控制系統變更管理說明：該變更是指需求、代碼等內容變更過程1)無變

8、更過程2）變更信息分散在每個系統內部，缺乏信息的有效共享機制1)建立代碼基線2)記錄代碼變更管理信息3)針對重點變更內容進行評審變更追溯無1)有清晰定義的版本號規則2)實現制品和代碼基線的關聯，可追溯指定版本的完整源代碼信息變更回滾無手工實現回滾G O P S 全 球 運 維 大 會 2 0 1 9 上 海 站構建方式 采用手工方式進行構建，或者嚴重依賴于IDE 使用研發人員本地設備構建構建計劃 構建任務不定期執行 沒有統一的持續集成服務持續集成 長期本地開發代碼，集成頻率幾周或者幾月一次 代碼集成作為軟件交付流程中的一個獨立階段 每次集成伴隨大量的問題和沖突，集成期間主干長期不可用G O P

9、 S 全 球 運 維 大 會 2 0 1 9 上 海 站過程域二級 過程域評估維度一級（初始級）二級（基礎級：自動化/腳本化、小范圍）構建與持續集成構建實踐說明：關注軟件代碼到可運行程序之間的過程構建方式采用手工方式進行構建采用腳本實現構建過程自動化構建環境使用研發本地設備構建有獨立的構建服務器，多種任務共用構建環境構建計劃構建任務不定期執行1）實現每日自動構建2）根據發布策略細分構建類型，比如發布構建、測試構建構建職責無專人專崗負責構建構建工具、環境與計劃由專人負責維護并有權限管理持續集成集成服務無持續集成服務搭建統一的持續集成服務集成頻率長期本地開發代碼，集成頻率幾周或者幾月一次采用團隊定

10、期統一集成的策略，代碼集成頻率幾天或者幾周一次集成方式代碼集成作為軟件交付流程中的一個獨立階段在部分分支上進行每天多次的定時構建反饋周期每次集成伴隨大量的問題和沖突，集成期間主干長期不可用集成問題反饋和解決需要半天或者更長時間構建與持續集成G O P S 全 球 運 維 大 會 2 0 1 9 上 海 站測試分層策略 只進行用戶/業務級的UI測試 無測試分層方法或分層策略測試介入時機 測試在軟件交付過程中在開發完成后才介入 手工測試為主，自動化程度低自動化測試 自動化測試腳本與工具分散管理 測試執行以周為單位 手工對測試結果進行分析判斷G O P S 全 球 運 維 大 會 2 0 1 9 上

11、 海 站過程域二級 過程域評估維度一級（初始級）二級（基礎級：自動化/腳本化、小范圍）測試管理測試分層策略分層方法說明：分層方法是測試體系按照不同的測試對象，類型進行分類聚合的方法，每一層對應了特有的測試需求。只進行用戶/業務級的UI測試1)采用接口/服務級測試對模塊/服務進行覆蓋全面的接口測試；2)采用代碼級測試對核心模塊的函數或類方法進行單元測試；3)對系統進行基本的性能測試分層策略說明：分層策略是指基于測試分層策略對每部分的測試比重和投入，以及覆蓋度等的劃分策略。無測試分層策略1)已建立測試分層策略2)測試設計以對用戶/業務級UI測試為主，輔以少量的接口/服務級測試測試時機測試在軟件交付

12、過程中在開發完成后才介入1)測試在持續交付過程中的介入時間提前到開發的集成階段2)接口/服務級測試在模塊的接口開發完成后進行自動化測試自動化設計說明：自動化設計是指測試分層中各種測試類型的自動化設計方法，用于指導自動化測試工作的有效執 行。無對用戶/業務級的UI測試進行自動化設計自動化開發自動化測試腳本與工具分散管理1)設置專人專崗統一管理自動化測試腳本與工具2)使用版本控制系統對自動化測試腳本進行有效管理自動化執行1)手工測試為主，自動化程度低2)測試執行以周為單位1)對用戶/業務級UI測試采用自動化測試2)自動化測試的執行效率較低，以天為單位自動化分析手工對測試結果進行分析判斷對自動化測試

13、結果具備一定的自動判斷能力，存在一定的誤報測試管理G O P S 全 球 運 維 大 會 2 0 1 9 上 海 站灰度測試每周每日測試每日服務測試定時（12小時）可用性測試提交即測試（510分鐘）穩定性測試驗收測試/人工測試灰度測試壓力測試/異常測試系統測試驗收測試/人工測試功能測試/新功能測試回歸測試集成測試單元測試冒煙測試功能測試建立測試分級體系，從不同級別和頻率進行全面的質量保障。UI測試服務測試單元測試建立測試分級體系G O P S 全 球 運 維 大 會 2 0 1 9 上 海 站質量規約&環境管理過程域二級過程域評估維度一級（初始級）二級（基礎級：自動化/腳本化、小范圍）代碼質量

14、管理代碼質量管理質量規約具備初始代碼質量規約，規約停留在個人級1)建立團隊級代碼質量規約2)規約范圍覆蓋部分代碼質量指標，如：代碼規范、錯誤和圈復雜度、重復度等質量指標檢查方式代碼質量檢查采用人工方式進行評審代碼質量檢查采用自動化結合手工方式進行反饋處理無代碼質量檢查結果處理機制，存在大量技術債對代碼質量檢查結果給出反饋，只處理部分檢查結果環境管理環境管理環境類型環境類型只有生產環境和非生產環境的劃分建立功能測試環境環境構建1)人工創建環境2)環境準備時間長，需要幾周完成1)環境構建通過自動化來完成2)環境準備時間以天為單位環境依賴與配置管理1)無依賴管理2)環境的管理為操作系統的交付方式通過

15、配置管理工具實現操作系統級別的依賴管理，比如說操作系統版本、組件版本、程序包版本等等G O P S 全 球 運 維 大 會 2 0 1 9 上 海 站過程域二級 過程域評估維度一級（初始級）二級（基礎級：自動化/腳本化、小范圍）部署與發布管理部署與發布模式部署方式運維人員手工完成所有環境的部署1)運維人員通過自動化腳本實現部署2)部署過程部分自動化部署過程部署過程存在較長的服務中止時間部署過程通過流程文檔實現標準化部署策略1)采用定期部署策略，部署頻率以月為單位2)單次部署包含大量需求1)采用定期部署策略，部署頻率以周為單位2)應用作為部署的最小單位3)應用和數據庫部署實現分離4)實現測試環境

16、的自動化部署部署質量1)部署整體失敗率較高2)部署無法實現回滾，生產問題只能在線上修復，修復時間不可控1)部署失敗率中等2)實現應用部署的回滾操作，問題可及時修復部署流水線協作模式1)整個軟件交付過程嚴格遵循預先計劃2)存在復雜的部門間協作和等待3)只有在開發完成后才進行測試和部署通過定義完整的軟件交付過程和清晰的交付規范，保證團隊之間交付的有序流水線過程 軟件交付過程中的大部分工作通過手工方式完成軟件交付過程中的各個環節建立自動化能力以提升處理效率過程可視化1)交付過程中的信息是封閉的2)交付狀態追溯困難1)交付過程在團隊內部可見，信息在團隊間共享2)交付狀態可追溯部署與發布管理G O P

17、S 全 球 運 維 大 會 2 0 1 9 上 海 站數據管理過程域二級過程域評估維度一級（初始級）二級（基礎級：自動化/腳本化、小范圍）數據管理測試數據管理數據來源測試時手工創建臨時數據導出部分生產環境數據形成基準的測試數據集數據覆蓋測試數據覆蓋部分測試場景1)測試數據覆蓋主要場景，包括：正常類型，錯誤類型以及邊界類型2)進行初步的分類分級，滿足不同測試類型需要數據獨立性說明：數據獨立性是指測試數據在測試執行各階段的完整性和一致性，不會受到其他任務執行結果的影 響。無1)測試數據有明確備份恢復機制2)實現測試數據復用和保證測試一致性數據變更管理說明：數據變更管理主要是指應用程序升級和回滾過程

18、中的數據庫結構和數據的變更變更過程1)數據變更由專業人員在后臺手工完成2)數據變更作為軟件發布的一個獨立環節，單獨實施和交付1)數據變更通過文檔實現標準化2)使用自動化腳本完成數據變更兼容回滾沒有建立數據庫版本，數據庫和應用存在不兼容風險建立數據庫和應用的版本對應關系，并持續跟蹤版本變更數據監控數據變更結果需要訪問數據庫進行驗證收集和分析數據變更日志，實現變更問題快速定位G O P S 全 球 運 維 大 會 2 0 1 9 上 海 站度量與反饋過程域二級過程域評估維度一級（初始級）二級（基礎級：自動化/腳本化、小范圍）度量與反饋度量指標度量指標定義說明：度量指標是度量體系的基礎在持續交付部分

19、階段定義度量指標在持續交付各個階段定義度量指標，度量指標僅限于部門內部度量指標類型無度量指標以結果指標為主，如變更頻率，需求交付前置時間，變更失敗率和平均修復時間度量數據管理度量數據是臨時性的度量數據采用抽樣方法收集度量指標更新無度量指標的設立后變更周期較長度量驅動改進內容和生成方式度量報告通過手工方式生成度量報告以自動化方式生成度量報告具有標準格式定義數據時效性數據和度量報告的時效性存在差異 數據報告可展現最新狀態覆蓋范圍僅部分人員可查看報告團隊內部成員均可查看報告反饋改進度量反饋問題解決周期較長度量反饋的問題錄入系統跟蹤，并定期實施改進G O P S 全 球 運 維 大 會 2 0 1 9 上 海 站 DevOps轉型與落地要弄清楚七個問題 DevOps實施的五個關鍵階段 定目標，看現狀，找差距，畫藍圖，搞事情 DevOps實施的四個要素 流程，規范，技術，可視化 二級應該怎么做內容回顧