[[275666]]

 DevOps 建設(shè)似乎已經(jīng)成為了企業(yè)共識，但是何時(shí)建設(shè)、如何建設(shè)仍然是企業(yè)關(guān)心和頭疼的問題。企業(yè)的技術(shù)、人才、業(yè)務(wù)達(dá)到何種程度才適合建設(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)稱，用于促進(jìn)開發(fā)、技術(shù)運(yùn)營和質(zhì)量保障部門之間的溝通、協(xié)作與整合。據(jù)中國信通院（CAICT）發(fā)布的《中國 DevOps 現(xiàn)狀調(diào)查報(bào)告（2019 年）》顯示：“超半數(shù)企業(yè)使用 DevOps 的敏捷工程實(shí)踐管理開發(fā)項(xiàng)目，近 6 成企業(yè)選擇編碼規(guī)范、單元測試和持續(xù)集成。”這說明，DevOps 已經(jīng)成為企業(yè)軟件研發(fā)的主流，被眾多企業(yè)所采用。

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

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

DevOps 中的矛盾與沖突

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

針對傳統(tǒng)運(yùn)維和 DevOps，王金倫是這樣理解的：“從本質(zhì)上來講，運(yùn)維（Operations）是綜合運(yùn)用人員、流程與工具平臺等對 IT 基礎(chǔ)設(shè)施和應(yīng)用系統(tǒng)進(jìn)行管理，將平臺與系統(tǒng)服務(wù)的價(jià)值按照一定的 SLA 持續(xù)地提供給內(nèi)部或者外部客戶。隨著企業(yè)業(yè)務(wù)目標(biāo)、IT 基礎(chǔ)設(shè)施、應(yīng)用系統(tǒng)、運(yùn)維理念、運(yùn)維方法、運(yùn)維工具平臺的不斷發(fā)展，運(yùn)維會在不同的階段或者從不同角度呈現(xiàn)一定的發(fā)展特征。”

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

企業(yè)實(shí)施 DevOps 的合適節(jié)點(diǎn)

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

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

DevOps 實(shí)踐與企業(yè)組織架構(gòu)

在企業(yè) DevOps 的建設(shè)過程中，組織架構(gòu)的調(diào)整和員工職責(zé)的變動是始終存在的，尤其是 Dev 和 Ops 相關(guān)角色之間的變動。   DevOps Topologies 曾經(jīng)提出了 9 種有效的 DevOps 團(tuán)隊(duì)結(jié)構(gòu)：

模型 1：Dev 與 Ops 無縫協(xié)作，適用于具有強(qiáng)技術(shù)領(lǐng)導(dǎo)力。

模型 2：完全共擔(dān) Ops 職責(zé)，適用于擁有單一的主要 web 產(chǎn)品或者服務(wù)的組織。

模型 3：Ops 即 IaaS（平臺），適用于擁有幾個(gè)不同的產(chǎn)品或服務(wù)、一個(gè)傳統(tǒng)的 Ops 部門或者應(yīng)用全部運(yùn)行在公有云上的組織。

模型 4：DevOps 作為外部服務(wù)，適用于運(yùn)維經(jīng)驗(yàn)不足的小型組織。

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

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

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

模型 8：容器驅(qū)動協(xié)作，適應(yīng)于容器可以很好地發(fā)揮作用的組織。

模型 9：Dev 和 DBA 協(xié)作，適應(yīng)于擁有多個(gè)應(yīng)用鏈接一個(gè)或者多個(gè)大型、中央式數(shù)據(jù)庫的組織。

以上 9 個(gè)只是比較常見的 DevOps 團(tuán)隊(duì)的組織架構(gòu)，但世界上沒有完美的 DevOps 組織結(jié)構(gòu)，王金倫建議：“組織結(jié)構(gòu)的調(diào)整應(yīng)該從組織的產(chǎn)品組合、技術(shù)領(lǐng)導(dǎo)力、團(tuán)隊(duì)人員技能水平、運(yùn)作成本等角度進(jìn)行綜合考慮。建議企業(yè)盡可能圍繞價(jià)值流建立跨功能自治團(tuán)隊(duì)，實(shí)現(xiàn)價(jià)值的持續(xù)交付，并隨著 DevOps 實(shí)踐成熟度的提升，持續(xù)地調(diào)整組織結(jié)構(gòu)。”

當(dāng)企業(yè)向 DevOps 轉(zhuǎn)型時(shí)，企業(yè)中各部門人員的工作內(nèi)容是否會跟隨著發(fā)生變化呢？王金倫表示：“企業(yè)實(shí)踐 DevOps，并不會使得業(yè)務(wù)、需求、開發(fā)、架構(gòu)、開發(fā)、測試、部署、運(yùn)維等人員的核心工作內(nèi)容發(fā)生太大的變化，不過工作方式可能會有所變化，例如業(yè)務(wù)人員應(yīng)該有敏捷的思維，而不再是恪守傳統(tǒng)的業(yè)務(wù)方法；運(yùn)維人員應(yīng)該更好地與開發(fā)人員協(xié)作，將運(yùn)維需求納入到產(chǎn)品待辦事項(xiàng)中等等。”

DevOps 與云平臺

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

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

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

DevOps 的完整路徑及技術(shù)選型

雖然每家企業(yè)都有各自的實(shí)際情況，無法照搬其它人的 DevOps 實(shí)踐，但是我們可以有一個(gè)較為標(biāo)準(zhǔn)、完整的 DevOps 參考架構(gòu)。

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

從理論及實(shí)踐上來講，使用業(yè)界開源工具（例如 Redmine、GitLab、Jenkins 等）打造基本可用的 DevOps 平臺，并不是一件特別困難的事情。但是想要做好 DevOps 平臺的技術(shù)選型并不是一件易事，因?yàn)閾?jù) XebiaLabs 統(tǒng)計(jì)，DevOps 相關(guān)工具有 15 類，120 種之多，種類繁多的同時(shí)，企業(yè)還要考慮可靠性、可用性、性能、安全、集成、持續(xù)升級、異構(gòu)技術(shù)棧等問題。

王金倫以持續(xù)交付流水線、代碼質(zhì)量和移動 App 為例，詳細(xì)介紹了如何做技術(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 等工具進(jìn)行代碼質(zhì)量的檢查，但是他們都不得不面臨不同工具之間的相似規(guī)則如何歸一、多個(gè)工具的檢查結(jié)果如何統(tǒng)一等挑戰(zhàn)。同時(shí)應(yīng)用人工智能 AI 進(jìn)行代碼質(zhì)量分析以及自動修復(fù)已經(jīng)成為一種趨勢，開源工具是否能夠及時(shí)跟進(jìn)以及跟進(jìn)的質(zhì)量如何，也是企業(yè)需要關(guān)注的。
• 移動 App 基本上成為各個(gè)企業(yè)對外服務(wù)系統(tǒng)的標(biāo)配。如何兼容不同類型的移動終端，成為開發(fā)者極為頭疼的問題。雖然移動終端提供了模擬器或者仿真器，但是真機(jī)兼容性測試仍然是不可或缺的一環(huán)。對于此種場景下，自建移動 App 測試平臺并采購型號眾多的移動終端幾乎對于所有企業(yè)來講都是很大的成本負(fù)擔(dān)，企業(yè)可以考慮相關(guān)廠商提供的移動 App 兼容性測試服務(wù)。

DevOps 實(shí)踐的注意點(diǎn)

企業(yè) DevOps 平臺建設(shè)說起來容易，做起來難！王金倫認(rèn)為在實(shí)踐 DevOps 的過程中，企業(yè)應(yīng)該特別關(guān)注以下三點(diǎn)：

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

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

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

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

AIOps 是 DevOps 的下一步嗎？

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

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

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

除此之外，運(yùn)維領(lǐng)域還出現(xiàn)了很多其它新技術(shù)，它們可以幫助提升運(yùn)維效率與效能。例如利用機(jī)器學(xué)習(xí)、大數(shù)據(jù)分析等技術(shù)提升根因分析、故障預(yù)測、自動修復(fù)等運(yùn)維能力；通過 Service Mesh、微服務(wù)等技術(shù)對運(yùn)維平臺架構(gòu)進(jìn)行重構(gòu)，為 DevOps 環(huán)節(jié)提供反饋服務(wù)能力等；采用混沌工程等方法，一方面檢驗(yàn)生產(chǎn)系統(tǒng)的突發(fā)事件應(yīng)對能力，另一方面也可以檢驗(yàn)運(yùn)維平臺應(yīng)對過程提供的價(jià)值等等。