什麼是DevOps及其誤區
DevOps概念從2009年提出已有8個年頭。可是在8年前的那個時候，爲什麼DevOps沒有迅速走紅呢？即便是在2006年Amazon發佈了ECS，微軟在2008年和2010年提出和發佈了Azure，DevOps的重要性似乎都沒有那麼強烈。我分析其原因主要有：
第一個很重要的原因是因爲那時候雲計算還是小衆產品，更多的與虛擬化、虛擬機相關，它們還是重量級的IT基礎設施。
第二個很重要的原因是容器相關技術（Docker爲代表）還沒有橫空出世，直到2013年7月。
第三個很重要的原因是，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時，存在誤區是必然的。在我們同大量的客戶交流中，大致有這幾種誤區認知：
1.沒有使用雲相關產品（IaaS、PaaS），組織很難開展DevOps；
2.微服務架構開發的應用適合DevOps，傳統SOA應用不適合；實施DevOps和應用架構無關，無論是微服務架構，還是SOA類型應用，都可以開展DevOps工作；
3.認爲將一組自動化工具的運用等同於DevOps的成功，那就太小瞧DevOps了。採用自動化工具本身不是DevOps，只有將這些工具與持續集成、持續交付、持續的反饋與優化進行端到端的整合時，這些工具才成爲DevOps的一部分；
4.設立獨立的DevOps團隊是很多組織開啓DevOps之旅的另外一個誤區。事實上，如果這麼做，將會導致更多的豎井。在責任沒有清晰定義的情況下，成立這些團隊，會創造更多的混亂，不要試圖把。
5.DevOps不僅僅是自動化。毫無疑問，自動化是DevOps非常重要的一部分，但不是唯一的部分，一定程度的部署自動化往往會與DevOps混爲一談，實施DevOps需要從敏捷、持續、協作、系統性、自動化五個維度進行建設與改進。
在DevOps實施過程中，團隊經過總結積累，制定了團隊的DevOps宣言，支撐團隊從敏捷型組織轉向DevOps（企業敏捷）。
DevOps企業實踐
實施DevOps的核心目標是加速團隊、企業的IT精益運行，從根本上提升IT的生產效率，加速部門、企業的業務創新能力。讓團隊從IT支撐部門，轉向爲IT創新部門。
實施DevOps過程中，需要從組織、技術、流程三個維度進行持續的優化與改進。
實施DevOps，可以參考總結的“DevOps實踐模型”，從組織、技術、流程三個維度中選擇關鍵的活動項進行最佳實踐活動。
可以梳理出目前團隊中欠缺但又容易改進的點，逐步將更多的實踐活動納入團隊當中。團隊實施DevOps的目的在於，將重複、價值低的事情交由DevOps平臺實現，讓團隊成員做更有創新、更有價值的事情。
根據我們的實施經驗，在傳統企業中，技術方面的實踐最容易在團隊中實現、流程次之、組織的優化與變革最爲艱難；大家嘗試的時候，可以由易入難。
組織方面
全棧團隊：按照RDT（需求、開發、測試）模式組建交付小團隊（團隊中以虛擬的方式將交互設計、運維、DBA包含進來），團隊大小按照「兩個披薩原則」進行組建。全棧團隊負責整個項目從需求、開發到上線運維的全生命週期管理，打破部門的籬笆；
特性團隊：基於特性的交付意味着工程團隊將構建最終產品的特性；讓團隊關注價值交付，減少團隊依賴，打破職能團隊；
技術方面
集成工具鏈：打通應用開發工具鏈：需求、項目、代碼、構建、測試、打包、發佈、配置、監控；
基礎設施即編碼：將基礎環境服務化、可編程化，基礎設施讓項目團隊可以自助獲取；讓基礎設施從物理機、虛擬機、走向容器；
一鍵編譯、測試、部署：開發人員可以從代碼開始，一鍵獲得可訪問的環境，根據需要可以推送開發、測試、預發、生產環境；
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的落地實現。
1.Portal（DevOps門戶），自研，提供給用戶使用的統一操作門戶，包括用戶管理、產品看板、產品全生命週期（設計、開發、測試、預發、生產、監控、故障處理）管理等；
2.IAM（身份識別與訪問管理），自研，提供用戶身份識別和訪問控制的能力，包括用戶管理、Token管理和用戶授權等功能；
3.SPM（軟件產品管理），自研，提供產品、組件的基準定義和管理能力，包括產品類型、產品管理、組件管理、依賴產品管理及產品投放市場等功能；
4.SCM（軟件配置管理），自研，提供產品、組件配置管理能力，包括配置項的定義和在各個不同環境下的配置信息的管理維護能力；
5.SRM（軟件資源管理），自研，提供產品和組件自動編譯、打包和部署的能力，提供部署模板管理，支持編譯和部署流程編排，編譯和部署進度跟蹤以及日誌查看；
SEM（軟件環境管理），自研，提供租戶和產品環境資源配額、負載均衡，以及運行容器的管理能力，包括租戶可用資源的配額，以及基於租戶資源的產品和組件在各種環境下的資源配額（如開發環境、測試環境、生產環境等等）和負載均衡；同時，還提供運行容器的創建、銷燬、調度、複製以及持久化卷管理等能力；
6.QAF（質量保證反饋），自研，提供產品的質量管理和監控能力，包括測試用例管理、缺陷管理、質量監控等；
7.UMC（統一運維中心），開源集成、借鑑自研相結合，提供統一的監控、預警、故障處理等能力，包括系統日誌和業務日誌的監控，產品的資源使用情況和運行情況監控，故障定位等。
8.VCS（版本控制系統），開源集成 ，主要以GitLab爲核心，不直接提供GitLab的原生界面，所有功能在統一的DevOps上提供；提供源代碼庫管理的能力，包括代碼庫的創建、維護，分支的管理和用戶權限控制等；
9.CI（持續集成），主要以Jenkins爲核心，使之成爲以API爲主要使用方式的服務，提供持續集成任務調度和執行的能力，包括集成任務管理、編譯、打包等；
10.BPR（二進制介質倉庫)），開源集成，主要以nexus爲核心；提供二進制包倉庫的管理能力，包括二進制包、文檔等編譯產物的上傳、下載和存儲訪問等；
11.DPR（可部署介質倉庫），自研，主要存儲可部署的介質，其主要區別是注入了與環境相關的配置（這種部署模型是很適合沒有上Docker或者容器，以虛機爲主的IT基礎設施或者物理機）；
12.PM（項目管理），自研，可以與常見的PM管理工具對接與集成，提供產品的開發過程的管理和協作的能力，主要包括：任務計劃、人員分工和過程跟蹤、看板等；
13.MOC（API模擬），開源集成，爲REST API調用提供模擬能力，以便產品或組件在開發調試期間可以脫離依賴、減少阻塞、單獨運行，支持根據Swagger和Mock數據發佈Mock Rest Service，支持用戶私有的MOCK數據；
14.DOC（API文檔），開源集成，提供REST API/SPI文檔的自動生成能力；
15.TM（租戶管理），自研，提供租戶管理的能力，包括租戶管理、邀請碼管理和租戶配額等功能；
16.IM（即時溝通），開源集成，提供產品設計、開發、測試、運維等相關人員間的協作溝通能力，支持羣組聊天、離線消息推送、聊天記錄查詢和導出；
囉囉嗦嗦，羅列了18個核心的領域系統。
邏輯架構整個DevOps平臺分爲三層：
1.基礎設施層：包括IaaS，CaaS，我們分別是基於OpenStack和Kubernetes、Docker的，上層有一層不同環境的適配；
2.基礎服務層：包括服務管理與調度的基礎能力，如註冊中心，編排，伸縮漂移；還有一堆具體的企業級或互聯網式的雲服務；
3.DevOps層：更多的是工作流程（需求、設計、開發、測試、發佈等）的串接，看板等文化的體現；
在整個平臺研發過程中，採用了是自己開發自己的模式，即使用上一個發佈的平臺作爲生產線，支撐下一個版本的產品研發工作。自己交付自己可以帶來兩點好處：
1.平臺交付客戶前，自己先把可能的坑趟掉；
2.當前生產線所有不能滿足的功能，視作下一版本的需求（實際操作過程中，我們僅允許使用wiki作爲輔助工具來支撐生產線未滿足的需求）；
所以可以拿一些數字估算一下當前的規模。在研發過程中，把DevOps視爲一套業務平臺，目前規劃的領域有18個，如果每個領域中再有多個以微服務架構落地的系統進行支撐，預計總共支撐DevOps的系統，就會超過50個。同時提供Mock、開發、測試、預發、生產5類環境（每類環境中可能還會有多套，比如集成測試、性能測試、全鏈路測試）。
當前版本的DevOps，整體的部署規模將超過200個集羣，部署的進程實例總數也會輕鬆超過500個。需要注意的是，500這個數字，還沒包含技術平臺中的一些分佈式中間件，比如緩存、消息隊列等等集羣。
不過，500映射到企業內IT人員自己用的平臺，這個數字，對於不同的企業，可能是個天文數字，也可能只是九牛一毛。
實施DevOps價值
在部門實施DevOps之後，我們團隊有顯著改變：
1.在團隊組織上，每個團隊小而自治且是全棧團隊，溝通、技能互補，每個團隊負責獨立的領域系統，目標感非常明確，團隊在走向使命型組織；
2.項目的從原先線下協作、溝通，統一到統一的DevOps平臺上協作、溝通；團隊成員可以隨時瞭解項目進展全貌，利用平臺可以做到各種過程數據的實時收集（舉例，比如需求變更、任務延期等）；
3.資源管理由原來專職人員，過渡到開發人員實現自助化服務，可以按需實現各類環境申請與開通，基礎設施即服務提供來技術的支撐；
4.從原來的郵件文化，到DevOps平臺統一溝通，同時DevOps打通多個工具鏈路端，任務分發、溝通、提醒可以實時推送；
最後給大家奉上DevOps成熟度評判指標，在踐行DevOps時，可以從運營效率、IT服務水平、組織效能、客戶價值、經營業績五個維度進行評判，持續優化與改進。