作者 | 云昭

Devops作為一種圍繞開發(fā)團隊和IT運營團隊營造協(xié)作氛圍的文化，自提出以來，業(yè)內(nèi)就存在倡導(dǎo)與質(zhì)疑兩種聲音。一方面，在人力成本攀高、市場競爭日趨激烈、用戶需求變化頻繁的情況下，DevOps形成了一系列理念、實踐和工具的結(jié)合，一定程度上提高了企業(yè)在產(chǎn)品和服務(wù)交付的效率，成為了快速上線的組織神器；另一方面，DevOps被很多人調(diào)侃為“系統(tǒng)集成”、“軟件堆砌”，難以實際落地，甚至有人認(rèn)為：DevOps運動失敗了。在加快軟件交付上，DevOps的確功不可沒。它給企業(yè)項目團隊帶來了高敏捷性、減少人工、高效的跨職能團隊協(xié)作、持續(xù)創(chuàng)新、最小缺陷等優(yōu)點，但“成也蕭何，敗也蕭何”，此時的DevOps多少有些淪為一種工具的危險，已非初時的模樣。

DevOps的初衷：打通部門墻 

說起DevOps，就不得不從DevOps之父——Patrick Debois說起。2007 年，Patrick參與了比利時一個政府下屬部門的大型數(shù)據(jù)中心遷移項目。在這個項目中，他分別負(fù)責(zé)測試和驗證的工作。這就意味著他不光有機會和開發(fā)團隊（Dev）工作，也時常要和運維團隊（Ops）工作。 在開發(fā)團隊中，他需要適應(yīng)敏捷交付的節(jié)奏，但在運維團隊他又得按照傳統(tǒng)模式，像管理消防隊員那樣維護系統(tǒng)。兩種工作氛圍的來回切換，令他十分沮喪：不同的工作方式、思維方式勢必存在著巨大差異，所以在這兩者之間工作，到處都是沖突。應(yīng)用程序在實際生產(chǎn)中會遇到各種未知且棘手的問題，很難及時處理。這就促使了運維等相關(guān)人員在軟件研發(fā)生命周期的早期就需要參與進來。作為敏捷開發(fā)的擁躉，Patrick果斷調(diào)整，試圖通過打通開發(fā)和運維的這堵部門墻。而他所開展的敏捷管理實踐就是DevOps發(fā)展的第一個雛形。

DevOps概念形成有兩個關(guān)鍵時刻，一個是Patrick Debois和Andrew Clay Shafer在多倫多敏捷會議上的會面，另一個便是John Allspaw和Paul Hammond在 Velocity'09的演講。經(jīng)過探討，DevOps準(zhǔn)確的定義就是Development和Operations的組合，是一組過程、方法與系統(tǒng)的統(tǒng)稱，用于促進開發(fā)、技術(shù)運營和質(zhì)量保障（QA）部門之間的溝通、協(xié)作與整合。彼時的概念很樸素：修復(fù)文化。而為了讓“DevOps”取得成功，有分歧的相關(guān)方都需要參與。時隔十余年，現(xiàn)在看來，企業(yè)雖然多了“DevOps工程師”的職位，在DevOps會議上卻失去了這種初衷：大量運維、運營人員參與，而開發(fā)人員參加的較少。

DevOps難以落地之謎 

隨著DevOps的流行，很多企業(yè)的做法卻相當(dāng)粗暴：將Dev、Ops兩個團隊合并，或者將運維劃歸開發(fā)。這是理念上的錯誤。此外，在客觀條件上也缺土壤。尤其在微服務(wù)盛行的今天，系統(tǒng)被分成了幾十個甚至幾百個服務(wù)組件，如果沒有敏捷的基礎(chǔ)設(shè)施服務(wù)作為先行條件，做DevOps基本上就是空談。這也是DevOps這些年一直難以落地的主要的兩點原因。下面舉個真實的例子。Lee Briggs是一位擁有15年經(jīng)驗的云工程技術(shù)的資深專家和創(chuàng)業(yè)者，他曾聊到有關(guān)DevOps的一次感到困惑的經(jīng)歷：一位負(fù)責(zé)開發(fā)某產(chǎn)品的董事級同事在會上提到他的團隊是“真正的Devops”，卻從未和Briggs談?wù)撨^他們的運維需求，Briggs甚至不知道他們在做什么，只知道他們在使用AWS ECS部署應(yīng)用程序。

Briggs感到很困惑：如果連本公司的運維團隊都沒有參與進來，他們怎么可能是“真正的Devops”？

后來經(jīng)過與其團隊中的開發(fā)人員的對話，Briggs才明白整背后的含義：公司的開發(fā)人員接管了整個應(yīng)用程序的生命周期，一條龍?zhí)幚?，不需要運維參與了——他們使用boto3并編寫部署腳本來發(fā)布新版本，并雇傭了精通AWS以及后端業(yè)務(wù)的“全棧工程師”。DevOps初衷純粹是為了讓開發(fā)人員能夠更輕松的工作，本意是減少甚至是消除他們在部署、管理部署等在基礎(chǔ)架構(gòu)生命周期的種種繁瑣的操作與困擾。而現(xiàn)在，別人口中侃侃而談“真正的Devops”時，他們的意思卻是讓開發(fā)者把運維的工作也包攬了。

開發(fā)運維全包攬 

如今，我們正在用今天的運維人員所熟悉的久經(jīng)考驗的工具來給到開發(fā)者，其中包括GitLab CI、Terraform（Terraform是一個IT基礎(chǔ)架構(gòu)自動化編排工具，可以用代碼來管理維護IT資源），當(dāng)然還有Kubernetes。事情就變成了這樣：“嘿，你應(yīng)該試試使用我們的平臺！我們已經(jīng)修復(fù)了所有這些Bug，它比原來的工具要好得多。”“謝謝，但我們不感興趣?！薄斑?，為什么？它更可靠、更快，并且是使用業(yè)界標(biāo)準(zhǔn)的工具?！薄笆堑?，但我們一點也不了解他們。我們還是對自己的東西更熟悉些?！边\維人員一直相信自己的方法很管用：畢竟運維部門知道如何在云上運行軟件。但開發(fā)者往往不買單。Briggs陳述了這段經(jīng)歷——“運維人員總是試圖說服開發(fā)人員來參加DevOps會議。一味地解釋自身打造的平臺做了什么，以及它將如何幫助他們。我在與開發(fā)人員的對話中一直在爭論，拼命想給整個公司帶來一種“DevOps”的心態(tài)，而這個團隊對這種心態(tài)的回應(yīng)卻是‘我們自己來做，謝謝?！?/span>

Briggs終于意識到：DevOps這種改變文化的嘗試失敗了。

現(xiàn)狀：淪為運維工具 

最終，Briggs對2022年DevOps的做出了以下總結(jié)：現(xiàn)在的DevOps是更多的站在運維角度上，試圖說服開發(fā)人員按照運維的方式做事。原因一目了然，目前市面上幾乎所有被稱為“DevOps”的工具都專注于運維層面。如果你瀏覽/r/devops，你會看到一篇又一篇關(guān)于運維或工具的文章。如果您查看DevOps工程師的工作描述，它看起來與2013年的系統(tǒng)管理員角色非常相似，只不過其中涉及的不再是原來的機架和堆疊著的服務(wù)器，取而代之的是一些容器或云的提供商管理。因此，如果DevOps本應(yīng)致力于改變整體文化，那么它就不能被視為一場成功的運動?？春眠@場運動的人可能會高興地說：“我們正在努力！”但其實他們明白，他們只不過是局限在運維方面在做單方面的努力——而這顯然，有悖于DevOps最初強調(diào)的“一條雙向的道路”。值得記住的是，在任何給定項目或組織中，運維的人數(shù)通常至少超過1/5。試圖說服每一位開發(fā)人員以“運維”和“使用運維工具”的方式做開發(fā)，最終都將是一件愚蠢的差事。

問題所在 

歸根結(jié)底，“DevOps”一詞，可能已經(jīng)顯得有些陳舊了。現(xiàn)在如果還有人向你推銷DevOps，那可能太過時了。我們真正希望看到的是，DevOps人在日常角色中的思維方式發(fā)生根本性轉(zhuǎn)變。我們往往忽視了以下兩點：一、DevOps人第一要義是要以運維為中心的，角色定位是幫助開發(fā)人員將功能交付給客戶（或幫助開發(fā)人員實現(xiàn)其他業(yè)務(wù)目標(biāo)）。二、當(dāng)為開發(fā)人員提供產(chǎn)品和功能時，需要注意：尋找到一條阻力最小的路徑是保持速度的關(guān)鍵，讓開發(fā)人員學(xué)習(xí)和維護所有操作實踐是不可擴展的，也不可行的?；乜碊evOps最初的想法，重點是消除開發(fā)人員和運維團隊之間的摩擦：讓運維者不再一味地對開發(fā)人員說“不”，讓開發(fā)者不再強push運維人員去上線。這些想法和目標(biāo)仍然是崇高的，企業(yè)今天仍然應(yīng)該追求它們，但DevOps的世界到底是什么樣子的呢？如果我們認(rèn)可“DevOps”是一種試圖將開發(fā)人員帶到運維世界的嘗試，并且也同意這種嘗試在很大程度上已經(jīng)失敗，那么現(xiàn)在，我們需要一個新術(shù)語。

Briggs提出了一個新名詞：“SoftOps”。

SoftOps：軟件開發(fā)人員的運維 

SoftOps，聽起來有點俗套，但理念卻是嶄新的。SoftOps的理念是，重點是讓開發(fā)人員更好地工作。運維人員不會告訴他們該做什么，而是會問他們在運維方面想做什么，然后讓他們盡可能地輕松。這個名詞得益于Briggs加入Pulumi后的經(jīng)歷，他通過一個不同的視角來看待這個世界：以開發(fā)者為中心。SoftOps是一種將開發(fā)人員作為主要客戶放在首位的想法。構(gòu)建面向開發(fā)人員的運維實踐（理論上）應(yīng)該讓開發(fā)人員參與進來，以便協(xié)同工作。也許，如果我們只專注于這一目標(biāo)，我們將最終解決DevOps在2009年一直試圖解決的問題。在這個新的理念下，“下載這個工具，閱讀這個48頁的手冊頁，告訴你的PM你錯過了sprint的最后期限”的命令開發(fā)者的對話場景將一去不復(fù)返；此外，“把它給我，我會為你做”開發(fā)者包攬運維工作的日子也將一去不復(fù)返。

寫在最后 

今年3月，AbsoluteReports發(fā)布了《全球DevOps平臺市場2022調(diào)查報告》，報告中預(yù)測，到2028年，全球DevOps平臺市場規(guī)模將從2021年的67.376億美元增長到263.70億美元，看起來2022-2028年的復(fù)合年增長率為20.7%。從這些數(shù)字可以看出：DevOps作為提高企業(yè)技術(shù)可靠性、保證穩(wěn)定的業(yè)務(wù)增長的利器，全球企業(yè)DevOps工具的需求愈發(fā)強烈。而從DevOps文化來看，DevOps在演變成一場讓開發(fā)者使用新的運維工具的運動。但這種運動，無疑存在“跑偏”的跡象，這也是DevOps難以落地的根本原因：文化的缺失。如果不能改變觀念，即使將員工放在一起，也只是增加兩個團隊的爭吵而已。換言之，DevOps考驗的不僅是一家企業(yè)的技術(shù)，更是管理水平和企業(yè)文化。Briggs提出的“SoftOps”的概念，一改“開發(fā)、運維全包攬”的現(xiàn)狀，想要重新梳理開發(fā)和運維流程的規(guī)范，讓開發(fā)人員在運維初期就給出系統(tǒng)部署的優(yōu)化建議。雖然名詞改變了，但SoftOps與DevOps的初衷卻是一致的：減少開發(fā)團隊與運維團隊之間的摩擦，而不是某一方強勢包攬、拒絕溝通，甚至簡單淪為一種新工具。

參考資料：https://leebriggs.co.uk/blog/2022/06/21/devops-is-a-failure

更多精彩技術(shù)文章盡在51CTO技術(shù)精選期刊，下載鏈接：???http://scjtxx.cn/journalDetail/6.html???