到底該如何理解DevOps這個詞

炒了8年的概念，到底該如何理解DevOps這個詞？

轉載本文需註明出處：EAII企業架構創新研究院，違者必究。如需加入微信羣參與微課堂、架構設計與討論直播請直接回復公衆號：「EAII企業架構創新研究院」。（微信號：eaworld）

 

如何實施DevOps成爲衆多企業迫切面臨的問題，本文做者劉相，有10多年的從業經驗，他結合自身企業實施DevOps的經驗，梳理出DevOps在企業的組織、技術、流程等方面的最佳實踐與價值，以及如何搭建DevOps平臺來支撐DevOps的落地工做。

本文內容包括：

1.什麼是DevOps及誤區

2.DevOps企業實踐

3.DevOps架構支撐

4.實施DevOps價值

什麼是DevOps及誤區

DevOps概念從2009年提出已有8個年頭。但是在8年前的那個時候，爲何DevOps沒有迅速走紅呢？即使是在2006年Amazon發佈了ECS，微軟在2008年和2010年提出和發佈了Azure，DevOps的重要性彷佛都沒有那麼強烈。我分析其緣由主要有：

1.第一個很重要的緣由是由於那時候雲計算仍是小衆產品，更多的與虛擬化、虛擬機相關，它們仍是重量級的IT基礎設施。

2.第二個很重要的緣由是容器相關技術（Docker爲表明）尚未橫空出世，直到2013年7月。

3.第三個很重要的緣由是，Martin Fowler在2014年3月提出了Micro Service，這爲DevOps的推廣也打了興奮劑。

能夠看出，當前DevOps概念的深刻人心，離不開雲計算、容器/Docker、微服務、敏捷等相關概念和實施的成熟發展。

另外，隨着互聯網對傳統企業的衝擊，須要更快的業務試錯與業務創新，其背後本質是企業IT的精益運營，讓軟件的生產、交付、獲取、升級、遙測變得自動與自助，近兩年，DevOps在傳統企業也開始備受關注與各類嘗試。

對DevOps的理解，可能千人千面。先來看下對DevOps的狹義理解。

維基百科對DevOps的定義比較拗口。其實往簡化裏講DevOps是提倡開發和IT運維之間的高度協同，從而在完成高頻率部署的同時，提升生產環境的可靠性、穩定性、彈性和安全性。

從另一個維度，廣義上來講，DevOps不只須要打通開發運維之間的部門牆，咱們認爲DevOps更多的須要從應用的全生命週期考慮，實現全生命週期的工具全鏈路打通與自動化、跨團隊的線上協做能力。

第一，縱向集成，打通應用全生命週期（需求、設計、開發、編譯、構建、測試、打包、發佈、配置、監控等）的工具集成。縱向集成中DevOps強調的重點是跨工具鏈的「自動化」，最終實現所有人員的「自助化」。舉個例子，項目組的開發人員能夠經過DevOps的平臺上，自主申請開通須要的各類服務，好比開通開發環境、代碼庫等。

第二，橫向集成，打通架構、開發、管理、運維等部門牆。橫向集成中DevOps強調的重點是跨團隊的「線上協做」，也便是經過IT系統，實現信息的「精確傳遞」。舉個例子，傳統的系統上線部署方式，多是一個冗長的說明文檔，上百頁都有可能，但在DevOps的平臺下，就應該是經過標準運行環境的選擇、環境配置的設置、部署流程的編排，實現數字化的「部署手冊」，而且這樣的手冊，不只操做人員能夠理解，機器也可以執行，過程能夠被追蹤和審計。

DevOps是經過工具鏈與持續集成、交付、反饋與優化進行端到端整合，完成無縫的跨團隊、跨系統協做。

在團隊使用DevOps時，存在誤區是必然的。在咱們同大量的客戶交流中，大體有這幾種誤區認知：

? 沒有使用雲相關產品（IaaS、PaaS），組織很難開展DevOps；
? 微服務架構開發的應用適合DevOps，傳統SOA應用不適合；實施DevOps和應用架構無關，不管是微服務架構，仍是SOA類型應用，均可以開展DevOps工做；
? 認爲將一組自動化工具的運用等同於DevOps的成功，那就過小瞧DevOps了。採用自動化工具自己不是DevOps，只有將這些工具與持續集成、持續交付、持續的反饋與優化進行端到端的整合時，這些工具才成爲DevOps的一部分；
? 設立獨立的DevOps團隊是不少組織開啓DevOps之旅的另一個誤區。事實上，若是這麼作，將會致使更多的豎井。在責任沒有清晰定義的狀況下，成立這些團隊，會創造更多的混亂，不要試圖把。
? DevOps不只僅是自動化。毫無疑問，自動化是DevOps很是重要的一部分，但不是惟一的部分，必定程度的部署自動化每每會與DevOps混爲一談，實施DevOps須要從敏捷、持續、協做、系統性、自動化五個維度進行建設與改進。

在DevOps實施過程當中，團隊通過總結積累，制定了團隊的DevOps宣言，支撐團隊從敏捷型組織轉向DevOps（企業敏捷）。

DevOps企業實踐

實施DevOps的核心目標是加速團隊、企業的IT精益運行，從根本上提高IT的生產效率，加速部門、企業的業務創新能力。讓團隊從IT支撐部門，轉向爲IT創新部門。

實施DevOps過程當中，須要從組織、技術、流程三個維度進行持續的優化與改進。

實施DevOps，能夠參考總結的「DevOps實踐模型」，從組織、技術、流程三個維度中選擇關鍵的活動項進行最佳實踐活動。

能夠梳理出目前團隊中欠缺但又容易改進的點，逐步將更多的實踐活動歸入團隊當中。團隊實施DevOps的目的在於，將重複、價值低的事情交由DevOps平臺實現，讓團隊成員作更有創新、更有價值的事情。

根據咱們的實施經驗，在傳統企業中，技術方面的實踐最容易在團隊中實現、流程次之、組織的優化與變革最爲艱難；你們嘗試的時候，能夠由易入難。

 

組織方面

 

如何實施DevOps成爲衆多企業迫切面臨的問題，本文做者劉相，有10多年的從業經驗，他結合自身企業實施DevOps的經驗，梳理出DevOps在企業的組織、技術、流程等方面的最佳實踐與價值，以及如何搭建DevOps平臺來支撐DevOps的落地工做。

技術方面

集成工具鏈：打通應用應用開發工具鏈：需求、項目、代碼、構建、測試、打包、發佈、配置、監控；

基礎設施即編碼：將基礎環境服務化、可編程化，基礎設施讓項目團隊能夠自助獲取；讓基礎設施從物理機、虛擬機、走向容器；

一鍵編譯、測試、部署：開發人員能夠從代碼開始，一鍵得到可訪問的環境，根據須要能夠推送開發、測試、預發、生產環境；

ChatOps：開發以及運營人員在內的團隊成員將溝通、工具和過程整合在一塊兒的協做模型。基於對話驅動開發，將工具植入對話中，保障團隊可以自動執行任務與協做。最近比較流行的hubot能夠認爲是ChatOps的探路者。

流程方面

 

看板：在DevOps中不能僅僅把看板當作任務協調溝通的機制；把看板做爲在製品管制平臺，量化組織生產能力的工具；

MVP：採用MVP（最小可行產品）原則，快速擁抱變化。最短期內快速交付產品原型，而後經過測試並收集用戶的反饋，快速迭代，不斷修正產品，最終適應市場的需求。

發佈：創建持續發佈機制，造成自動化、自助化兩種能力，支持常見的灰度發佈、金絲雀、藍綠、回滾、A/B測試等；

軟件度量：經過軟件度量（包括過程度量、質量度量、用戶度量、成本度量），推算出組織的各類有效指標；一則掌控組織的生產力水平，二則經過度量數據，反向優化組織瓶頸點；

一切皆代碼：文檔（用戶故事、用戶場景、功能特性等）、配置（應用配置、環境配置、腳本等）、環境（基礎設施、中間件環境等）、發佈包（二方庫、三方庫、部署包）須要統一看待成代碼，歸入版本管理，同時創建5者間的關係，提供全視角的鏈路追蹤。舉個例子，每一個發佈的版本，能夠追溯其對應的配置，代碼、文檔，發佈的功能點。

組織、技術、流程三個維度中，技術、流程能夠經過平臺或者工具進行最佳實踐的固化。

基於此，咱們規劃了DevOps平臺，支持廣義的DevOps，幫助客戶快速實現DevOps建設。

平臺建設第一步，梳理出DevOps的總體概念模型。從角色、規劃設計、開發交付、運營反饋四個維度進行梳理。

以產品爲核心，將代碼、配置、環境進行嚴格分離，同時覆蓋產品全生命週期。

這裏面概念看似簡單，其實不少：好比：部署包=介質包+配置，這和傳統的CI和CD體系就有點不同；

再好比：環境分開發、測試、預發、生產，咱們以爲即便公有云上，也應該給客戶將這些作物理或邏輯隔離，由於你們的配額需求不同，容器replication需求也可能不同；

再好比：運營反饋，既然要作DevOps，那整個過程導出都應該能夠有檢查點插入，爲運營提供有效數據，咱們把檢查點至少分紅了四類，包括過程的、安全的、性能的、業務的。

DevOps架構支撐

 

基於領域模型梳理DevOps平臺業務架構，目前共建設18個領域系統來支撐，好比：軟件產品的管理、軟件各階段環境的管理、質量的管理、部署包、二進制包的管理、資源管理、監控中心、認證中心等。

每一個領域系統嚴格按照AKF擴展立方體的Y軸進行拆分，採用微服務架構模式進行平臺建設。

「DevOps業務架構」，是咱們基於對企業IT管理的理解，所進行的平臺化設想。從圖裏還能夠看到，紅色字部分，是咱們對現有DevOps的落地實現。

 

? Portal（DevOps門戶），自研，提供給用戶使用的統一操做門戶，包括用戶管理、產品看板、產品全生命週期（設計、開發、測試、預發、生產、監控、故障處理）管理等；
? IAM（身份識別與訪問管理），自研，提供用戶身份識別和訪問控制的能力，包括用戶管理、Token管理和用戶受權等功能；
? SPM（軟件產品管理），自研，提供產品、組件的基準定義和管理能力，包括產品類型、產品管理、組件管理、依賴產品管理及產品投放市場等功能；
? SCM（軟件配置管理），自研，提供產品、組件配置管理能力，包括配置項的定義和在各個不一樣環境下的配置信息的管理維護能力；
? SRM（軟件資源管理），自研，提供產品和組件自動編譯、打包和部署的能力，提供部署模板管理，支持編譯和部署流程編排，編譯和部署進度跟蹤以及日誌查看；
? SEM（軟件環境管理），自研，提供租戶和產品環境資源配額、負載均衡，以及運行容器的管理能力，包括租戶可用資源的配額，以及基於租戶資源的產品和組件在各類環境下的資源配額（如開發環境、測試環境、生產環境等等）和負載均衡；同時，還提供運行容器的建立、銷燬、調度、複製以及持久化卷管理等能力；
? QAF（質量保證反饋），自研，提供產品的質量管理和監控能力，包括測試用例管理、缺陷管理、質量監控等；
? UMC（統一運維中心），開源集成、借鑑自研相結合，提供統一的監控、預警、故障處理等能力，包括系統日誌和業務日誌的監控，產品的資源使用狀況和運行狀況監控，故障定位等。
? VCS（版本控制系統），開源集成 ，主要以GitLab爲核心，不直接提供GitLab的原生界面，全部功能在統一的DevOps上提供；提供源代碼庫管理的能力，包括代碼庫的建立、維護，分支的管理和用戶權限控制等；
? CI（持續集成），主要以Jenkins爲核心，使之成爲以API爲主要使用方式的服務，提供持續集成任務調度和執行的能力，包括集成任務管理、編譯、打包等；
? BPR（二進制介質倉庫），開源集成，主要以nexus爲核心；提供二進制包倉庫的管理能力，包括二進制包、文檔等編譯產物的上傳、下載和存儲訪問等；
? DPR（可部署介質倉庫），自研，主要存儲可部署的介質，其主要區別是注入了與環境相關的配置（這種部署模型是很適合沒有上Docker或者容器，以虛機爲主的IT基礎設施或者物理機）；
? PM（項目管理），自研，能夠與常見的PM管理工具對接與集成，提供產品的開發過程的管理和協做的能力，主要包括：任務計劃、人員分工和過程跟蹤、看板等；
? MOC（API模擬），開源集成，爲REST API調用提供模擬能力，以便產品或組件在開發調試期間能夠脫離依賴、減小阻塞、單獨運行，支持根據Swagger和Mock數據發佈Mock Rest Service，支持用戶私有的MOCK數據；
? DOC（API文檔），開源集成，提供REST API/SPI文檔的自動生成能力；
? TM（租戶管理），自研，提供租戶管理的能力，包括租戶管理、邀請碼管理和租戶配額等功能；
? IM（即時溝通），開源集成，提供產品設計、開發、測試、運維等相關人員間的協做溝通能力，支持羣組聊天、離線消息推送、聊天記錄查詢和導出；

囉囉嗦嗦，羅列了18個核心的領域系統。

邏輯架構整個DevOps平臺分爲三層：

? 基礎設施層：包括IaaS，CaaS，咱們分別是基於OpenStack和Kubernetes、Docker的，上層有一層不一樣環境的適配；

? 基礎服務層：包括服務管理與調度的基礎能力，如註冊中心，編排，伸縮漂移；還有一堆具體的企業級或互聯網式的雲服務；

? DevOps層：更多的是工做流程（需求、設計、開發、測試、發佈等）的串接，看板等文化的體現；

在整個平臺研發過程當中，採用了是本身開發本身的模式，即便用上一個發佈的平臺做爲生產線，支撐下一個版本的產品研發工做。本身交付本身能夠帶來兩點好處：

1. 平臺交付客戶前，本身先把可能的坑趟掉；

2. 當前生產線全部不能知足的功能，視做下一版本的需求（實際操做過程當中，咱們僅容許使用wiki做爲輔助工具來支撐生產線未知足的需求）；

因此能夠拿一些數字估算一下當前的規模。在研發過程當中，把DevOps視爲一套業務平臺，目前規劃的領域有18個，若是每一個領域中再有多個以微服務架構落地的系統進行支撐，預計總共支撐DevOps的系統，就會超過50個。同時提供Mock、開發、測試、預發、生產5類環境（每類環境中可能還會有多套，好比集成測試、性能測試、全鏈路測試）。

當前版本的DevOps，總體的部署規模將超過200個集羣，部署的進程實例總數也會輕鬆超過500個。須要注意的是，500這個數字，還沒包含技術平臺中的一些分佈式中間件，好比緩存、消息隊列等等集羣。

不過，500映射到企業內IT人員本身用的平臺，這個數字，對於不一樣的企業，多是個天文數字，也可能只是九牛一毛。

實施DevOps價值

在部門實施DevOps以後，咱們團隊有顯著改變：

? 在團隊組織上，每一個團隊小而自治且是全棧團隊，溝通、技能互補，每一個團隊負責獨立的領域系統，目標感很是明確，團隊在走向使命型組織；

? 項目的從原先線下協做、溝通，統一到統一的DevOps平臺上協做、溝通；團隊成員能夠隨時瞭解項目進展全貌，利用平臺能夠作到各類過程數據的實時收集（舉例，好比需求變動、任務延期等）；

? 資源管理由原來專職人員，過渡到開發人員實現自助化服務，能夠按需實現各種環境申請與開通，基礎設施即服務提供來技術的支撐；

? 從原來的郵件文化，到DevOps平臺統一溝通，同時DevOps打通多個工具鏈路端，任務分發、溝通、提醒能夠實時推送；

最後給你們奉上DevOps成熟度評判指標，在踐行DevOps時，能夠從運營效率、IT服務水平、組織效能、客戶價值、經營業績五個維度進行評判，持續優化與改進。

關於做者：

劉相

EAII-企業架構創新研究院 專家委員

計算機應用技術碩士，現任普元軟件產品部副總兼SOA產品線總經理。十年IT行業經驗，專一於企業軟件平臺，在SOA、分佈式計算、企業架構設計等領域。前後主導公司EOS七、Portal、雲PAAS平臺、雲流程平臺、BPM等系列產品的開發和設計工做。著有國內首本解析SpringBatch的中文原創圖書《SpringBatch批處理框架》。我的愛好：閱讀，慢跑。

 

關於EAII

EAII（Enterprise Architecture Innovation Institute）企業架構創新研究院，致力於軟件架構創新與實踐，加速企業數字化轉型。