[[275666]]

 DevOps 建設似乎已經成為了企業共識，但是何時建設、如何建設仍然是企業關心和頭疼的問題。企業的技術、人才、業務達到何種程度才適合建設 DevOps？建設過程中，從哪里先入手，又應該如何處理組織架構、原有技術棧與 DevOps 之間的矛盾？是否有 DevOps 建設的參考架構？建設完成之后，DevOps 的下一步該如何發展？...... 為了解答以上問題，我們采訪了 15 年的技術老兵、現任華為云 DevCloud 首席解決方案架構師王金倫。

DevOps，是 Development 和 Operations 的組合詞，是指一組過程、方法與系統的統稱，用于促進開發、技術運營和質量保障部門之間的溝通、協作與整合。據中國信通院（CAICT）發布的《中國 DevOps 現狀調查報告（2019 年）》顯示：“超半數企業使用 DevOps 的敏捷工程實踐管理開發項目，近 6 成企業選擇編碼規范、單元測試和持續集成。”這說明，DevOps 已經成為企業軟件研發的主流，被眾多企業所采用。

雖然企業都期望能夠通過 DevOps 獲得更多的價值，并有意愿積極嘗試，但是 DevOps 的成功實踐仍然是個難題。據《中國 DevOps 現狀調查報告（2019 年）》的調查結果顯示：“實際能夠真正成功實施 DevOps 的企業僅有 31.65%，另外，還有接近四成（41.13%）的企業居然不清楚自己是否成功實施 DevOps。”

這個結果雖然在意料之外，但也在情理之中，畢竟 DevOps 實踐之路，成功的方法很多，但是失敗的方式更多。本文將聚焦 DevOps 建設過程中的矛盾、難點，讓大家的 DevOps 建設之路更加順暢。

DevOps 中的矛盾與沖突

任何新事物的出現和推行，必定時刻伴隨著矛盾與沖突，DevOps 也不例外。DevOps 甫一出現，很多人就開始擔心：“傳統運維將被 DevOps 干掉？”沒錯，DevOps 的第一個矛盾沖突很快就顯現了，那就是傳統運維和 DevOps 之間的矛盾，有人認為這兩者之間是水火不相容，那實際情況是如何呢？

針對傳統運維和 DevOps，王金倫是這樣理解的：“從本質上來講，運維（Operations）是綜合運用人員、流程與工具平臺等對 IT 基礎設施和應用系統進行管理，將平臺與系統服務的價值按照一定的 SLA 持續地提供給內部或者外部客戶。隨著企業業務目標、IT 基礎設施、應用系統、運維理念、運維方法、運維工具平臺的不斷發展，運維會在不同的階段或者從不同角度呈現一定的發展特征。”

“傳統運維和自動化運維可以簡單理解為業界在不同階段或者從不同角度為運維打上的特征標簽，它們各自具備不同的特征，例如傳統運維通常具有被動、規范化低、自動化低等特征；自動化運維通常具有主動、規范化程度高、自動化程度高等特征。”

企業實施 DevOps 的合適節點

在很多人的印象中 DevOps 是一種先進的方法框架，使用 DevOps 能夠給企業帶來無限的好處，但事實是我們看到很多企業的 DevOps 實踐并不成功，也有很多開發者抱怨 DevOps 就是個“累贅”。之所以會出現這種情況，絕大部分的原因都是企業根本沒有做好實踐 DevOps 的準備。那么，想要建設 DevOps 的企業應該具備哪些特質呢？

“理論上來講，無論是大型企業還是中小型企業，無論是敏態還是穩態業務系統均可以采用 DevOps 相關的方法與實踐。”王金倫表示 ，“企業在開展 DevOps 轉型或者變革時，建議從業務敏捷性要求高的產品（例如企業面向終端用戶提供的基于互聯網的業務）入手，可以更加充分地體現 DevOps 的能力。當然 DevOps 的有效落地離不開人員技能、流程以及工具鏈平臺的支撐，同時又與系統架構（例如微服務架構等）、系統依賴基礎設施（例如云計算等）息息相關。因此企業應該在 DevOps 方法、微服務架構、云原生架構、云計算、自動化測試、持續集成、持續交付、灰度發布等技術上進行儲備。當然企業最好不要希望運動式一夜之間完成這些儲備，而應該參考 DevOps 實施框架，在軟件交付的過程中逐漸進行技術儲備，自然而然地落地 DevOps 方法與實踐。”

DevOps 實踐與企業組織架構

在企業 DevOps 的建設過程中，組織架構的調整和員工職責的變動是始終存在的，尤其是 Dev 和 Ops 相關角色之間的變動。   DevOps Topologies 曾經提出了 9 種有效的 DevOps 團隊結構：

模型 1：Dev 與 Ops 無縫協作，適用于具有強技術領導力。

模型 2：完全共擔 Ops 職責，適用于擁有單一的主要 web 產品或者服務的組織。

模型 3：Ops 即 IaaS（平臺），適用于擁有幾個不同的產品或服務、一個傳統的 Ops 部門或者應用全部運行在公有云上的組織。

模型 4：DevOps 作為外部服務，適用于運維經驗不足的小型組織。

模型 5：設定有效期的 DevOps 組，是模型 1 的前身。

模型 6：DevOps 布道師組，適用于 Dev 與 Ops 有疏遠趨勢的組織。

模型 7：SRE 組（Google 模型），適應于用于高水平的工程師和成熟度的企業。

模型 8：容器驅動協作，適應于容器可以很好地發揮作用的組織。

模型 9：Dev 和 DBA 協作，適應于擁有多個應用鏈接一個或者多個大型、中央式數據庫的組織。

以上 9 個只是比較常見的 DevOps 團隊的組織架構，但世界上沒有完美的 DevOps 組織結構，王金倫建議：“組織結構的調整應該從組織的產品組合、技術領導力、團隊人員技能水平、運作成本等角度進行綜合考慮。建議企業盡可能圍繞價值流建立跨功能自治團隊，實現價值的持續交付，并隨著 DevOps 實踐成熟度的提升，持續地調整組織結構。”

當企業向 DevOps 轉型時，企業中各部門人員的工作內容是否會跟隨著發生變化呢？王金倫表示：“企業實踐 DevOps，并不會使得業務、需求、開發、架構、開發、測試、部署、運維等人員的核心工作內容發生太大的變化，不過工作方式可能會有所變化，例如業務人員應該有敏捷的思維，而不再是恪守傳統的業務方法；運維人員應該更好地與開發人員協作，將運維需求納入到產品待辦事項中等等。”

DevOps 與云平臺

無論是基于云平臺還是 IDC，又或者是 OpenShift，都可以搭建出的一套完整的 DevOps 環境，所以 DevOps 與云平臺之間并不是充分必要的關系，雙方互有聯系，又彼此獨立。那么，企業如何判斷是否要在云平臺中部署實踐 DevOps 呢？

王金倫表示：“企業運維平臺的部署方式（On Premises 或 Public Cloud）取決于企業的業務系統的部署方式（私有云、混合云或公有云）。在業務系統全部部署在公有云的情況下，運維平臺建議部署在公有云上。在業務系統運行在私有云或者混合云場景下，運維平臺的部署方式建議采用 On Premises 方式。”

如果本來是 On Premises 部署的運維平臺現在想要上云，那么主要需要考慮數據安全性、運維通道速度等問題。上云之后，對于企業的組織架構與員工來講，變化較小，不過需要熟悉公有云廠商的運維產品特性能力等。

DevOps 的完整路徑及技術選型

雖然每家企業都有各自的實際情況，無法照搬其它人的 DevOps 實踐，但是我們可以有一個較為標準、完整的 DevOps 參考架構。

在王金倫看來，一個完整的理想的 DevOps 平臺應該能夠滿足業務、需求、架構、開發、測試、部署、運維等角色在其上自主的完成相關工作，“DevOps 平臺應該提供項目管理、原型設計、源代碼版本管理、代碼質量分析、持續交付流水線、編譯構建、測試管理、UI 自動化測試、接口測試、性能測試、移動 App 測試、部署、發布、運維、Web IDE、文檔管理、Wiki 百科、開源鏡像站等功能特性。”

從理論及實踐上來講，使用業界開源工具（例如 Redmine、GitLab、Jenkins 等）打造基本可用的 DevOps 平臺，并不是一件特別困難的事情。但是想要做好 DevOps 平臺的技術選型并不是一件易事，因為據 XebiaLabs 統計，DevOps 相關工具有 15 類，120 種之多，種類繁多的同時，企業還要考慮可靠性、可用性、性能、安全、集成、持續升級、異構技術棧等問題。

王金倫以持續交付流水線、代碼質量和移動 App 為例，詳細介紹了如何做技術選型。

• 對于 DevOps 平臺來講，持續交付流水線是最為關鍵核心的。目前 Gitlab、Jenkins、阿里云效、華為云 DevCloud 都可以提供相關特性。對于流水線來講，主要能力在于可視化任務編排能力（分層、并行 / 串行、人工介入、門禁等）、大規模并行調度能力等。如果企業使用開源軟件，特別要關注對于大規模并行調度的支持能力。
• 對于軟件交付來講，開發者非常關注代碼質量。現在不少企業使用 SonarQube、Findbugs、Checkstyle、Infer 等工具進行代碼質量的檢查，但是他們都不得不面臨不同工具之間的相似規則如何歸一、多個工具的檢查結果如何統一等挑戰。同時應用人工智能 AI 進行代碼質量分析以及自動修復已經成為一種趨勢，開源工具是否能夠及時跟進以及跟進的質量如何，也是企業需要關注的。
• 移動 App 基本上成為各個企業對外服務系統的標配。如何兼容不同類型的移動終端，成為開發者極為頭疼的問題。雖然移動終端提供了模擬器或者仿真器，但是真機兼容性測試仍然是不可或缺的一環。對于此種場景下，自建移動 App 測試平臺并采購型號眾多的移動終端幾乎對于所有企業來講都是很大的成本負擔，企業可以考慮相關廠商提供的移動 App 兼容性測試服務。

DevOps 實踐的注意點

企業 DevOps 平臺建設說起來容易，做起來難！王金倫認為在實踐 DevOps 的過程中，企業應該特別關注以下三點：

首先，需要注意的就是組織架構、文化與行為等與 DevOps 契合度方面的問題。DevOps 融合敏捷、精益、自治團隊、分布式決策等理念，企業應通過頂層設計、實踐社區（CoP）、組織變革等方式建立與 DevOps 相匹配的組織與文化。我們通常說 DevOps 變革是“一把手”工程，很大程度上就是組織與文化的變革必須高層推動，否則 DevOps 也就只能停留在純粹的工具、工程方法等皮毛上，難以走得遠，給企業帶來可觀的價值。

其次，企業會面臨工程方法方面的挑戰。目前 DevOps 并沒有一以貫之的標準或者知識體系，因此企業應體系化地理解敏捷與 DevOps，并形成一致認可的適合本企業的 DevOps 實施框架，這樣才會更有效地提升能力。

在我們接觸的很多軟件企業中，他們并沒有體系化的掌握 Scrum 方法，對 Backlog、EPIC/Feature/Story、Scrum 會議等都缺乏基本理解，因此，在進行敏捷項目管理時就遇到了很大的困難，更遑論 DevOps 整個體系了。華為云 DevCloud 推出的 HE2E 工作坊，基于 HE2E DevOps 實施框架與案例項目，以訓戰結合的方式，能夠幫助企業更體系化地理解 DevOps。

最后企業將面臨的問題是如何打造端到端的一站式 DevOps 工具平臺。企業可以從 2+1（項目管理 + 源代碼版本管理、持續交付流水線）能力來進行 DevOps 平臺的打造。我們建議企業盡可能使用業界主流商業平臺，在這些平臺確實無法滿足自己的核心需求的時候，再尋求自行搭建這條艱難的路。

AIOps 是 DevOps 的下一步嗎？

DevOps 誕生于 2009 年項目經理兼敏捷實踐者 Patrick Debois 主持的比利時會議，目前已有眾多的企業在實踐應用，借助 DevOps，自動化程度得到提高，測試變得更加容易，部署速度更快。而智能化運維（AIOps）是在自動化的基礎上，突出強調將人工智能等技術運用到運維的相關環節（例如根因分析、預測、故障恢復等），進一步提升運維的效率和效能。

那么 AIOps 會是 DevOps 的下一步嗎？對此，王金倫認為：“從理論以及業界實際上來講，AI 將成為 Ops 或者 DevOps 能力提升的重要技術途徑。因此，AIOps 是將 AI 與 DevOps 中的 Ops 相結合，希望利用 AI 能力來解決 Ops 方面的一些難題。AIOps 或者智能化運維應該是運維的一個重要演進方向，未來，企業級端到端的 AIOps 解決方案會成為一個重要趨勢。”

目前 AIOps 主要應用的場景包括異常檢測、預測分析、優化分析、根因分析、智能自動運維等。任何事情都是機遇與挑戰并存，同樣，AIOps 也面臨著很多挑戰，王金倫認為其中最大的挑戰是大規模的有質量的數據、經過訓練的有效的模型、失敗的成本等問題。

除此之外，運維領域還出現了很多其它新技術，它們可以幫助提升運維效率與效能。例如利用機器學習、大數據分析等技術提升根因分析、故障預測、自動修復等運維能力；通過 Service Mesh、微服務等技術對運維平臺架構進行重構，為 DevOps 環節提供反饋服務能力等；采用混沌工程等方法，一方面檢驗生產系統的突發事件應對能力，另一方面也可以檢驗運維平臺應對過程提供的價值等等。