DevOps重塑研發運維體系
目前DevOps相關的概念很多，比如DevSecOps、AIOps、SRE、CI、CD等。這么多概念往往讓人很困惑，搞不清楚彼此之間的關系。不少人喜歡用圖1來解釋DevOps、敏捷、CI、CD等之間的關系，不過這可能會造成對DevOps的誤解。
我們都知道DevOps要形成閉環，但僅僅關注閉環還是不夠的，更別說僅關注研發或者CICD了。作為云原生思想之一，DevOps的核心是圍繞應用生命周期過程的管理。在應用生命周期過程中，研發階段可以采用敏捷研發方式，也可以采用瀑布等其他研發方式；SRE是Google對DevOps的一種很好的實踐；CICD是實現DevOps集成部署自動化能力的手段；AIOps側重于智能化運維而沒有考慮研發；DevSecOps側重于DevOps過程中的安全能力。如果僅僅關注其中一點，我們是難以建設好DevOps能力的。
我們也在嘗試構建DevOps體系。“什么是真正的DevOps？DevOps的價值在哪里，DevOps如何能夠重塑企業的研發運維體系？如何落地？”。筆者認為，在做任何具體項目落地之前，都需要理解其概念、理念、原則、方法、過程等，需要有一定的認知、有方向，才不會無的放矢。
圖1 一種DevOps、敏捷開發、CICD關系示意圖
DevOps到底是什么
DevOps到底是什么？我們認為DevOps從來不是一個產品，DevOps落地不是一個系統，而是一個體系。有人說，DevOps是一種思想、方法、理論。這沒錯，不過我們要把這種思想、方法、理論落地，就需要很多系統、組件的支撐。比如說需求管理系統、應用管理系統、研發平臺、測試平臺、運維平臺、源碼管理工具、缺陷管理工具、文檔管理工具等。這些系統、平臺和工具等及相關的人員共同構成一個DevOps體系。在這個體系中彼此相互聯系、相互影響。為更好地達到DevOps體系建設的目標，需對體系中的系統、構成要素、組織結構、信息流動、控制機制等進行系統分析和設計，實現人和信息的持續反饋與協調。
很多人關注更多的是討論DevOps具體功能實現而不是DevOps思想本質，很多人上來就談CICD，談流水線、工具鏈。但我們是否想過DevOps的本質是什么？DevOps要解決的核心問題是什么？我們知道敏捷研發嘗試解決的是研發效率問題，智能運維嘗試解決的是運維效率問題。那么DevOps解決的核心問題什么？DevOps的本質是協調開發和運維的關系，說到底，其實解決的核心問題是協作效率問題。不管研發運維一體化，還是持續集成持續交付，核心在于人。無論開發或運維，都有彼此的關切和利益需求，會相互影響。做開發肯定希望需求不要變來變去，盡快交付；做運維肯定希望系統穩定運行不出事。而業務總是在不斷變化的，今天提個需求，明天又提個需求，唯一不變的就是變。所以只有解決了人與人之間的關切和利益分配，才能理順DevOps中的關系，才不會有阻礙和相互負影響，才能提升效率。
DevOps為什么能夠重塑研發運維體系？
DevOps是一種思想、方法論。它涉及的東西很多，不是一個產品所能夠容納的。需求收集、需求分析可能會用到需求管理、用戶故事地圖、服務藍圖等工具；設計可能用到UML、SysML、DFD等模型工具；編碼有眾多的開發語言和開發框架；測試、監控等工具更是數不勝數。不同的業務場景需求是不一樣的，每種技術、工具都有最適合的場景。DevOps的核心并不在工具上，而是尋求開發和運維之間的高效協同。DevOps生命周期過程是個閉環，為什么要閉環？是為了使研發和運維能夠高效協同起來，表現為一體化，從而實現研發運維體系質的變化。
DevOps閉環只是一維的流程，難以描述開發人員和運維之間的關系。協調平衡開發和運維之間的關系，才是DevOps關注的重點。傳統方式下，開發人員開發測試完畢交付運維部署上線運維，每次的改動必然帶來變化和不確定性，這就可能導致異常和故障，從而對運維人員利益帶來損害。GoogleSRE使用系統工程的思想和方法替代軟件工程系統管理員的手工工作，其終極責任是確保應用服務可以正常運轉。為達成這一目標，SRE需要完成開發監控系統、規劃資源容量、處理緊急事件、跟蹤修復事故根源等。SRE天然排斥重復性、手工性的操作，SRE要求有足夠的技術能力快速開發出軟件系統以替代手工操作。SRE有50%的時間來做開發，但他們開發的是確保業務應用正常運轉的工具、平臺等，從而實現應用運維和系統、資源運維的自動化和智能化。SRE不做業務應用的開發，其專注于運維平臺和運維工具的研發和運維，在SRE內部實現“研發運維一體化”。使業務研發人員專注于業務應用的研發，不需要考慮運行環境和運行資源，按需使用（云計算思想），這就極大地提升了研發效率。
開發和運維都有自己的訴求。DevOps的核心是要解決企業內部門與部門、團隊與團隊之間的協作難題，滿足彼此的關切和利益需求。DevOps的目的是協調開發和運維的關切，在交付效率和系統穩定性之間尋求平衡，既保障開發又保障運維的利益訴求，追求最優或接近最優的協同狀態。
容器云平臺是DevOps中提供測試運維運營環境的平臺。既要考慮敏捷，又要考慮穩定。測試環境要敏捷，生產環境要穩定，敏態和穩態并行。所以我們以鏡像倉庫為媒介，支撐著研發和運維不同的利益訴求。研發可以頻繁的發布測試，但只有經過完整測試的鏡像才能部署生產，確保生產的穩定。同時容器化環境也為穩定的運行和異常回滾提供了技術保障，為研發減少了大量的環境準備時間和環境運維工作量。這就解決了彼此的關切，使研發和運維專注于自己的事情。這就提升了協作效率。
圖2 重塑的DevOps研發運維體系
DevOps怎么重塑研發運維體系？
要重塑研發運維體系，需要用系統工程的思想。首先，將基礎設施資源運維、PaaS平臺（或應用部署運行平臺）運維和業務應用運維分離。可以通過多云管理平臺來管理各種不同的基礎設施資源（私有云、公有云、行業云等），向PaaS平臺提供經過抽象和封裝的規范化、標準化資源服務。而PaaS平臺（或應用部署運行平臺）以應用管理為核心支撐業務應用的部署、運行、運維和運營等。PaaS平臺（或應用部署運行平臺）為Dev開發提供應用的敏捷測試、部署、運行環境，Dev開發無需關注環境運維和資源運維，按需申請和使用資源及相應的工具、組件。SRE模型成功的關鍵在于對工程的關注，如果沒有持續的、工程化的解決方案，運維的壓力就會不斷增加，也就需要更多的人來完成工作。用系統工程分層思想，通過標準化服務來支撐上一層平臺或系統，松耦合了彼此之間的關系，職責分工相對明確，而工程化的方法也使運維人員通過自動化、智能化的工具和手段提升了運維效率和運維能力。所以Ops的終極目標也需要像SRE一樣推動整個系統趨向于無人化運行，也就是智能化，不僅僅是自動化。
第二，DevOps生命周期是以業務應用為中心的。Dev交付的是業務應用，Ops確保穩定運行的是業務應用。這里的應用可以是微服務應用，當然也可以是其他類型的應用，只要能契合DevOps的理念就可以。DevOps尋求是Dev交付效率和Ops穩定運行之間平衡，并不是說一天發布10次8次就是DevOps了。每天發布多少次其實沒有多大意義，關鍵在于業務場景的需求。在需要發布的時候能夠支撐按需發布，具備這樣的能力就可以了。如果把每天的發布次數作為一項考核指標，那就有點舍本逐末了。
SRE關注站點或產品、應用服務等運行的穩定性，以“錯誤預算”協調開發和運維之間的利益關系，錯誤預算是根據經驗拍腦袋定的，有其局限性。SRE其實更多地關注Ops端，但關注“運維Ops”無疑是正確的，和我們習慣于更關注“開發Dev”是不一樣的。SRE強調用工程化的手段應對運維問題。軟件運維問題達到一定規模時，也確實只能通過軟件工程化的手段來解決。
企業中研發Dev和運維Ops之間最主要的矛盾就是應用服務迭代創新的速度與應用服務穩定運行程度之間的矛盾。要解決Dev和Ops雙方的利益沖突，則需要同時能關注矛盾雙方的訴求、保障矛盾雙方的利益。既要保證“速度”，更要關注“穩定性”。但任何軟件系統都不應該一味追求100%可靠。對最終用戶來說，99.99%、99.999%和100%的可用性并沒有實質的區別。因此DevOps建設就是追求這種矛盾的統一。DevOps的關鍵在于利益平衡問題，這不是技術問題，而是社會學問題。
第三，DevOps由于涉及內容眾多，在人員和團隊之間的協同、角色和權限管理、訪問控制等方面需要在不同的平臺、工具、系統之間打通。這是基礎的能力，但也是重塑研發運維體系的關鍵能力。不同的角色根據訪問控制權限可以訪問不同的資源API、服務API等，從而實現了DevOps體系統一的安全管控能力。
要實現這一點其實就面臨著很多的問題。認證權限和訪問控制是企業各種信息系統最基礎的組成部分，每個系統都需要都會有。由于不同的系統由不同的廠商研發，也就造成了認證權限訪問控制等管理體系各不相同。在實現系統集成的時候就面臨著額外很多的工作量和麻煩。基于這點，在DevOps體系建設中結合技術中臺架構的思路，我們提出構建企業統一身份認證服務中臺和權限服務中臺。可以采用微服務架構，重構身份認證和權限管理體系，以企業級標準化服務的形式，實現認證和授權、訪問控制的企業級復用。
圖3 企業級統一身份認證、權限中臺
DevOps落地意味著很多基礎的工具和平臺的服務化、標準化、自動化甚至智能化。基于容器的PaaS平臺提供敏捷的部署、運維、托管、彈性伸縮等能力，這也是我們為什么優先建設容器云平臺的原因，優先解決Ops的需求，提供敏態和穩態的支撐能力，才能更好地支撐應用的生命周期管理。以微服務架構實現企業級的共享和復用以減少重復建設、節約成本、提升效率等，以復用服務逐步構建企業中臺體系，進一步支撐業務的敏捷變化需求。認證、權限、日志等可復用服務的建設也促進了系統的融合，有利于DevOps的落地。容器化PaaS、微服務、中臺、DevOps等相輔相成，重塑了企業的研發和運維架構體系。
DevOps提出的目的在于解決開發和運維之間的利益沖突問題，要落地DevOps，就需要重塑開發和運維的架構體系，不是簡單的用CICD或者一個DevOps產品能夠解決的。簡單的說，原來那些習慣于系統運維而不具備研發工具的人員，完全可以讓他們繼續去運維基礎設施資源，和上層業務應用運維分離，這樣即便在傳統企業也不會影響到DevOps的建設。我們建議用系統工程思想立體思維或多元思維構建DevOps體系，協調好開發、運維及相關利益者關系，以系統融合的思路架構，分步構建和完善DevOps體系，這樣才能重塑研發和運維體系，使開發和運維高效協同，帶來質的變化。
