建站
咨詢
售后
建站咨詢
新聞中心
DevOps 建設(shè)似乎已經(jīng)成為了企業(yè)共識，但是何時建設(shè)、如何建設(shè)仍然是企業(yè)關(guān)心和頭疼的問題。企業(yè)的技術(shù)、人才、業(yè)務(wù)達到何種程度才適合建設(shè) DevOps？建設(shè)過程中，從哪里先入手，又應(yīng)該如何處理組織架構(gòu)、原有技術(shù)棧與 DevOps 之間的矛盾？是否有 DevOps 建設(shè)的參考架構(gòu)？建設(shè)完成之后，DevOps 的下一步該如何發(fā)展？...... 為了解答以上問題，我們采訪了 15 年的技術(shù)老兵、現(xiàn)任華為云 DevCloud 首席解決方案架構(gòu)師王金倫。
DevOps，是 Development 和 Operations 的組合詞，是指一組過程、方法與系統(tǒng)的統(tǒng)稱，用于促進開發(fā)、技術(shù)運營和質(zhì)量保障部門之間的溝通、協(xié)作與整合。據(jù)中國信通院（CAICT）發(fā)布的《中國 DevOps 現(xiàn)狀調(diào)查報告（2019 年）》顯示：“超半數(shù)企業(yè)使用 DevOps 的敏捷工程實踐管理開發(fā)項目，近 6 成企業(yè)選擇編碼規(guī)范、單元測試和持續(xù)集成?！边@說明，DevOps 已經(jīng)成為企業(yè)軟件研發(fā)的主流，被眾多企業(yè)所采用。
雖然企業(yè)都期望能夠通過 DevOps 獲得更多的價值，并有意愿積極嘗試，但是 DevOps 的成功實踐仍然是個難題。據(jù)《中國 DevOps 現(xiàn)狀調(diào)查報告（2019 年）》的調(diào)查結(jié)果顯示：“實際能夠真正成功實施 DevOps 的企業(yè)僅有 31.65%，另外，還有接近四成（41.13%）的企業(yè)居然不清楚自己是否成功實施 DevOps?！?/p>
這個結(jié)果雖然在意料之外，但也在情理之中，畢竟 DevOps 實踐之路，成功的方法很多，但是失敗的方式更多。本文將聚焦 DevOps 建設(shè)過程中的矛盾、難點，讓大家的 DevOps 建設(shè)之路更加順暢。
DevOps 中的矛盾與沖突
任何新事物的出現(xiàn)和推行，必定時刻伴隨著矛盾與沖突，DevOps 也不例外。DevOps 甫一出現(xiàn)，很多人就開始擔(dān)心：“傳統(tǒng)運維將被 DevOps 干掉？”沒錯，DevOps 的第一個矛盾沖突很快就顯現(xiàn)了，那就是傳統(tǒng)運維和 DevOps 之間的矛盾，有人認為這兩者之間是水火不相容，那實際情況是如何呢？
針對傳統(tǒng)運維和 DevOps，王金倫是這樣理解的：“從本質(zhì)上來講，運維（Operations）是綜合運用人員、流程與工具平臺等對 IT 基礎(chǔ)設(shè)施和應(yīng)用系統(tǒng)進行管理，將平臺與系統(tǒng)服務(wù)的價值按照一定的 SLA 持續(xù)地提供給內(nèi)部或者外部客戶。隨著企業(yè)業(yè)務(wù)目標、IT 基礎(chǔ)設(shè)施、應(yīng)用系統(tǒng)、運維理念、運維方法、運維工具平臺的不斷發(fā)展，運維會在不同的階段或者從不同角度呈現(xiàn)一定的發(fā)展特征?！?/p>
“傳統(tǒng)運維和自動化運維可以簡單理解為業(yè)界在不同階段或者從不同角度為運維打上的特征標簽，它們各自具備不同的特征，例如傳統(tǒng)運維通常具有被動、規(guī)范化低、自動化低等特征；自動化運維通常具有主動、規(guī)范化程度高、自動化程度高等特征。”
企業(yè)實施 DevOps 的合適節(jié)點
在很多人的印象中 DevOps 是一種先進的方法框架，使用 DevOps 能夠給企業(yè)帶來無限的好處，但事實是我們看到很多企業(yè)的 DevOps 實踐并不成功，也有很多開發(fā)者抱怨 DevOps 就是個“累贅”。之所以會出現(xiàn)這種情況，絕大部分的原因都是企業(yè)根本沒有做好實踐 DevOps 的準備。那么，想要建設(shè) DevOps 的企業(yè)應(yīng)該具備哪些特質(zhì)呢？
“理論上來講，無論是大型企業(yè)還是中小型企業(yè)，無論是敏態(tài)還是穩(wěn)態(tài)業(yè)務(wù)系統(tǒng)均可以采用 DevOps 相關(guān)的方法與實踐。”王金倫表示 ，“企業(yè)在開展 DevOps 轉(zhuǎn)型或者變革時，建議從業(yè)務(wù)敏捷性要求高的產(chǎn)品（例如企業(yè)面向終端用戶提供的基于互聯(lián)網(wǎng)的業(yè)務(wù)）入手，可以更加充分地體現(xiàn) DevOps 的能力。當(dāng)然 DevOps 的有效落地離不開人員技能、流程以及工具鏈平臺的支撐，同時又與系統(tǒng)架構(gòu)（例如微服務(wù)架構(gòu)等）、系統(tǒng)依賴基礎(chǔ)設(shè)施（例如云計算等）息息相關(guān)。因此企業(yè)應(yīng)該在 DevOps 方法、微服務(wù)架構(gòu)、云原生架構(gòu)、云計算、自動化測試、持續(xù)集成、持續(xù)交付、灰度發(fā)布等技術(shù)上進行儲備。當(dāng)然企業(yè)最好不要希望運動式一夜之間完成這些儲備，而應(yīng)該參考 DevOps 實施框架，在軟件交付的過程中逐漸進行技術(shù)儲備，自然而然地落地 DevOps 方法與實踐?！?/p>
DevOps 實踐與企業(yè)組織架構(gòu)
在企業(yè) DevOps 的建設(shè)過程中，組織架構(gòu)的調(diào)整和員工職責(zé)的變動是始終存在的，尤其是 Dev 和 Ops 相關(guān)角色之間的變動。 DevOps Topologies 曾經(jīng)提出了 9 種有效的 DevOps 團隊結(jié)構(gòu)：
模型 1：Dev 與 Ops 無縫協(xié)作，適用于具有強技術(shù)領(lǐng)導(dǎo)力。
模型 2：完全共擔(dān) Ops 職責(zé)，適用于擁有單一的主要 web 產(chǎn)品或者服務(wù)的組織。
模型 3：Ops 即 IaaS（平臺），適用于擁有幾個不同的產(chǎn)品或服務(wù)、一個傳統(tǒng)的 Ops 部門或者應(yīng)用全部運行在公有云上的組織。
模型 4：DevOps 作為外部服務(wù)，適用于運維經(jīng)驗不足的小型組織。
模型 5：設(shè)定有效期的 DevOps 組，是模型 1 的前身。
模型 6：DevOps 布道師組，適用于 Dev 與 Ops 有疏遠趨勢的組織。
模型 7：SRE 組（Google 模型），適應(yīng)于用于高水平的工程師和成熟度的企業(yè)。
模型 8：容器驅(qū)動協(xié)作，適應(yīng)于容器可以很好地發(fā)揮作用的組織。
模型 9：Dev 和 DBA 協(xié)作，適應(yīng)于擁有多個應(yīng)用鏈接一個或者多個大型、中央式數(shù)據(jù)庫的組織。
以上 9 個只是比較常見的 DevOps 團隊的組織架構(gòu)，但世界上沒有完美的 DevOps 組織結(jié)構(gòu)，王金倫建議：“組織結(jié)構(gòu)的調(diào)整應(yīng)該從組織的產(chǎn)品組合、技術(shù)領(lǐng)導(dǎo)力、團隊人員技能水平、運作成本等角度進行綜合考慮。建議企業(yè)盡可能圍繞價值流建立跨功能自治團隊，實現(xiàn)價值的持續(xù)交付，并隨著 DevOps 實踐成熟度的提升，持續(xù)地調(diào)整組織結(jié)構(gòu)。”
當(dāng)企業(yè)向 DevOps 轉(zhuǎn)型時，企業(yè)中各部門人員的工作內(nèi)容是否會跟隨著發(fā)生變化呢？王金倫表示：“企業(yè)實踐 DevOps，并不會使得業(yè)務(wù)、需求、開發(fā)、架構(gòu)、開發(fā)、測試、部署、運維等人員的核心工作內(nèi)容發(fā)生太大的變化，不過工作方式可能會有所變化，例如業(yè)務(wù)人員應(yīng)該有敏捷的思維，而不再是恪守傳統(tǒng)的業(yè)務(wù)方法；運維人員應(yīng)該更好地與開發(fā)人員協(xié)作，將運維需求納入到產(chǎn)品待辦事項中等等?！?/p>
DevOps 與云平臺
無論是基于云平臺還是 IDC，又或者是 OpenShift，都可以搭建出的一套完整的 DevOps 環(huán)境，所以 DevOps 與云平臺之間并不是充分必要的關(guān)系，雙方互有聯(lián)系，又彼此獨立。那么，企業(yè)如何判斷是否要在云平臺中部署實踐 DevOps 呢？
王金倫表示：“企業(yè)運維平臺的部署方式（On Premises 或 Public Cloud）取決于企業(yè)的業(yè)務(wù)系統(tǒng)的部署方式（私有云、混合云或公有云）。在業(yè)務(wù)系統(tǒng)全部部署在公有云的情況下，運維平臺建議部署在公有云上。在業(yè)務(wù)系統(tǒng)運行在私有云或者混合云場景下，運維平臺的部署方式建議采用 On Premises 方式。”
如果本來是 On Premises 部署的運維平臺現(xiàn)在想要上云，那么主要需要考慮數(shù)據(jù)安全性、運維通道速度等問題。上云之后，對于企業(yè)的組織架構(gòu)與員工來講，變化較小，不過需要熟悉公有云廠商的運維產(chǎn)品特性能力等。
DevOps 的完整路徑及技術(shù)選型
雖然每家企業(yè)都有各自的實際情況，無法照搬其它人的 DevOps 實踐，但是我們可以有一個較為標準、完整的 DevOps 參考架構(gòu)。
在王金倫看來，一個完整的理想的 DevOps 平臺應(yīng)該能夠滿足業(yè)務(wù)、需求、架構(gòu)、開發(fā)、測試、部署、運維等角色在其上自主的完成相關(guān)工作，“DevOps 平臺應(yīng)該提供項目管理、原型設(shè)計、源代碼版本管理、代碼質(zhì)量分析、持續(xù)交付流水線、編譯構(gòu)建、測試管理、UI 自動化測試、接口測試、性能測試、移動 App 測試、部署、發(fā)布、運維、Web IDE、文檔管理、Wiki 百科、開源鏡像站等功能特性?！?/p>
從理論及實踐上來講，使用業(yè)界開源工具（例如 Redmine、GitLab、Jenkins 等）打造基本可用的 DevOps 平臺，并不是一件特別困難的事情。但是想要做好 DevOps 平臺的技術(shù)選型并不是一件易事，因為據(jù) XebiaLabs 統(tǒng)計，DevOps 相關(guān)工具有 15 類，120 種之多，種類繁多的同時，企業(yè)還要考慮可靠性、可用性、性能、安全、集成、持續(xù)升級、異構(gòu)技術(shù)棧等問題。
王金倫以持續(xù)交付流水線、代碼質(zhì)量和移動 App 為例，詳細介紹了如何做技術(shù)選型。
- 對于 DevOps 平臺來講，持續(xù)交付流水線是最為關(guān)鍵核心的。目前 Gitlab、Jenkins、阿里云效、華為云 DevCloud 都可以提供相關(guān)特性。對于流水線來講，主要能力在于可視化任務(wù)編排能力（分層、并行 / 串行、人工介入、門禁等）、大規(guī)模并行調(diào)度能力等。如果企業(yè)使用開源軟件，特別要關(guān)注對于大規(guī)模并行調(diào)度的支持能力。
- 對于軟件交付來講，開發(fā)者非常關(guān)注代碼質(zhì)量?，F(xiàn)在不少企業(yè)使用 SonarQube、Findbugs、Checkstyle、Infer 等工具進行代碼質(zhì)量的檢查，但是他們都不得不面臨不同工具之間的相似規(guī)則如何歸一、多個工具的檢查結(jié)果如何統(tǒng)一等挑戰(zhàn)。同時應(yīng)用人工智能 AI 進行代碼質(zhì)量分析以及自動修復(fù)已經(jīng)成為一種趨勢，開源工具是否能夠及時跟進以及跟進的質(zhì)量如何，也是企業(yè)需要關(guān)注的。
- 移動 App 基本上成為各個企業(yè)對外服務(wù)系統(tǒng)的標配。如何兼容不同類型的移動終端，成為開發(fā)者極為頭疼的問題。雖然移動終端提供了模擬器或者仿真器，但是真機兼容性測試仍然是不可或缺的一環(huán)。對于此種場景下，自建移動 App 測試平臺并采購型號眾多的移動終端幾乎對于所有企業(yè)來講都是很大的成本負擔(dān)，企業(yè)可以考慮相關(guān)廠商提供的移動 App 兼容性測試服務(wù)。
DevOps 實踐的注意點
企業(yè) DevOps 平臺建設(shè)說起來容易，做起來難！王金倫認為在實踐 DevOps 的過程中，企業(yè)應(yīng)該特別關(guān)注以下三點：
首先，需要注意的就是組織架構(gòu)、文化與行為等與 DevOps 契合度方面的問題。DevOps 融合敏捷、精益、自治團隊、分布式?jīng)Q策等理念，企業(yè)應(yīng)通過頂層設(shè)計、實踐社區(qū)（CoP）、組織變革等方式建立與 DevOps 相匹配的組織與文化。我們通常說 DevOps 變革是“一把手”工程，很大程度上就是組織與文化的變革必須高層推動，否則 DevOps 也就只能停留在純粹的工具、工程方法等皮毛上，難以走得遠，給企業(yè)帶來可觀的價值。
其次，企業(yè)會面臨工程方法方面的挑戰(zhàn)。目前 DevOps 并沒有一以貫之的標準或者知識體系，因此企業(yè)應(yīng)體系化地理解敏捷與 DevOps，并形成一致認可的適合本企業(yè)的 DevOps 實施框架，這樣才會更有效地提升能力。
在我們接觸的很多軟件企業(yè)中，他們并沒有體系化的掌握 Scrum 方法，對 Backlog、EPIC/Feature/Story、Scrum 會議等都缺乏基本理解，因此，在進行敏捷項目管理時就遇到了很大的困難，更遑論 DevOps 整個體系了。華為云 DevCloud 推出的 HE2E 工作坊，基于 HE2E DevOps 實施框架與案例項目，以訓(xùn)戰(zhàn)結(jié)合的方式，能夠幫助企業(yè)更體系化地理解 DevOps。
最后企業(yè)將面臨的問題是如何打造端到端的一站式 DevOps 工具平臺。企業(yè)可以從 2+1（項目管理 + 源代碼版本管理、持續(xù)交付流水線）能力來進行 DevOps 平臺的打造。我們建議企業(yè)盡可能使用業(yè)界主流商業(yè)平臺，在這些平臺確實無法滿足自己的核心需求的時候，再尋求自行搭建這條艱難的路。
AIOps 是 DevOps 的下一步嗎？
DevOps 誕生于 2009 年項目經(jīng)理兼敏捷實踐者 Patrick Debois 主持的比利時會議，目前已有眾多的企業(yè)在實踐應(yīng)用，借助 DevOps，自動化程度得到提高，測試變得更加容易，部署速度更快。而智能化運維（AIOps）是在自動化的基礎(chǔ)上，突出強調(diào)將人工智能等技術(shù)運用到運維的相關(guān)環(huán)節(jié)（例如根因分析、預(yù)測、故障恢復(fù)等），進一步提升運維的效率和效能。
那么 AIOps 會是 DevOps 的下一步嗎？對此，王金倫認為：“從理論以及業(yè)界實際上來講，AI 將成為 Ops 或者 DevOps 能力提升的重要技術(shù)途徑。因此，AIOps 是將 AI 與 DevOps 中的 Ops 相結(jié)合，希望利用 AI 能力來解決 Ops 方面的一些難題。AIOps 或者智能化運維應(yīng)該是運維的一個重要演進方向，未來，企業(yè)級端到端的 AIOps 解決方案會成為一個重要趨勢?！?/p>
目前 AIOps 主要應(yīng)用的場景包括異常檢測、預(yù)測分析、優(yōu)化分析、根因分析、智能自動運維等。任何事情都是機遇與挑戰(zhàn)并存，同樣，AIOps 也面臨著很多挑戰(zhàn)，王金倫認為其中最大的挑戰(zhàn)是大規(guī)模的有質(zhì)量的數(shù)據(jù)、經(jīng)過訓(xùn)練的有效的模型、失敗的成本等問題。
除此之外，運維領(lǐng)域還出現(xiàn)了很多其它新技術(shù)，它們可以幫助提升運維效率與效能。例如利用機器學(xué)習(xí)、大數(shù)據(jù)分析等技術(shù)提升根因分析、故障預(yù)測、自動修復(fù)等運維能力；通過 Service Mesh、微服務(wù)等技術(shù)對運維平臺架構(gòu)進行重構(gòu)，為 DevOps 環(huán)節(jié)提供反饋服務(wù)能力等；采用混沌工程等方法，一方面檢驗生產(chǎn)系統(tǒng)的突發(fā)事件應(yīng)對能力，另一方面也可以檢驗運維平臺應(yīng)對過程提供的價值等等。
網(wǎng)站欄目：對話15年技術(shù)老兵：我是如何填平DevOps的深坑？
URL網(wǎng)址：http://www.fisionsoft.com.cn/article/djsspoc.html
