對話15年技術老兵:我是如何填平 DevOps 的深坑?

2019-09-11 06:14:31

作者 | 田曉旭
採訪嘉賓 | 王金倫
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 環節提供反饋服務能力等;採用混沌工程等方法,一方面檢驗生產系統的突發事件應對能力,另一方面也可以檢驗運維平臺應對過程提供的價值等等。

作者介紹

王金倫,於 2003 年清華大學計算機系畢業,擁有 15 年軟體架構設計及開發管理經驗,具有 PMP、ITIL、COBIT 等認證,具有 EXIN DevOps Professional、SAFe 認證授權培訓資格。先後在明華證、中國移動等公司負責總架構師工作,主導過網際網路基金交易平臺、基金投資交易管理系統、中國移動漫遊清算系統、測試雲平臺等大型平臺系統的架構設計與研發工作。現任華為雲 DevCloud 首席解決方案架構師,主要從事研發方法諮詢、DevOps 解決方案、安全架構與方案、微服務架構等工作,熟悉業界主流的雲端計算與大資料平臺,精通 DevOps 理念與相關工具鏈。


活動推薦

王金倫老師即將在QCon上海2019分享DevOps轉型中工程效率提升的話題,通過經典案例和血淋淋的教訓,剖析團隊如何應對 DevOps 轉型過程中必須跨越的問題,為團隊應用 DevOps 定製合理的路線圖,此外大會還有架構、AIOps、大資料等話題等你瞭解。大會9折報名中,點選「閱讀原文」或識別二維碼檢視詳細日程,如有問題歡迎聯絡票務小姐姐Ring:17310043226(微信同號)

已同步到看一看



熱點新聞