建站
咨詢
售后
建站咨詢
新聞中心
作者 | 云昭
創(chuàng)新互聯(lián)建站從2013年成立，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項(xiàng)目成都網(wǎng)站設(shè)計(jì)、成都做網(wǎng)站網(wǎng)站策劃，項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個(gè)夢(mèng)想脫穎而出為使命，1280元納溪做網(wǎng)站,已為上家服務(wù),為納溪各地企業(yè)和個(gè)人服務(wù),聯(lián)系電話:18980820575
Devops作為一種圍繞開(kāi)發(fā)團(tuán)隊(duì)和IT運(yùn)營(yíng)團(tuán)隊(duì)營(yíng)造協(xié)作氛圍的文化，自提出以來(lái)，業(yè)內(nèi)就存在倡導(dǎo)與質(zhì)疑兩種聲音。一方面，在人力成本攀高、市場(chǎng)競(jìng)爭(zhēng)日趨激烈、用戶需求變化頻繁的情況下，DevOps形成了一系列理念、實(shí)踐和工具的結(jié)合，一定程度上提高了企業(yè)在產(chǎn)品和服務(wù)交付的效率，成為了快速上線的組織神器；另一方面，DevOps被很多人調(diào)侃為“系統(tǒng)集成”、“軟件堆砌”，難以實(shí)際落地，甚至有人認(rèn)為：DevOps運(yùn)動(dòng)失敗了。在加快軟件交付上，DevOps的確功不可沒(méi)。它給企業(yè)項(xiàng)目團(tuán)隊(duì)帶來(lái)了高敏捷性、減少人工、高效的跨職能團(tuán)隊(duì)協(xié)作、持續(xù)創(chuàng)新、最小缺陷等優(yōu)點(diǎn)，但“成也蕭何，敗也蕭何”，此時(shí)的DevOps多少有些淪為一種工具的危險(xiǎn)，已非初時(shí)的模樣。
DevOps的初衷：打通部門(mén)墻
說(shuō)起DevOps，就不得不從DevOps之父——Patrick Debois說(shuō)起。2007 年，Patrick參與了比利時(shí)一個(gè)政府下屬部門(mén)的大型數(shù)據(jù)中心遷移項(xiàng)目。在這個(gè)項(xiàng)目中，他分別負(fù)責(zé)測(cè)試和驗(yàn)證的工作。這就意味著他不光有機(jī)會(huì)和開(kāi)發(fā)團(tuán)隊(duì)（Dev）工作，也時(shí)常要和運(yùn)維團(tuán)隊(duì)（Ops）工作。 在開(kāi)發(fā)團(tuán)隊(duì)中，他需要適應(yīng)敏捷交付的節(jié)奏，但在運(yùn)維團(tuán)隊(duì)他又得按照傳統(tǒng)模式，像管理消防隊(duì)員那樣維護(hù)系統(tǒng)。兩種工作氛圍的來(lái)回切換，令他十分沮喪：不同的工作方式、思維方式勢(shì)必存在著巨大差異，所以在這兩者之間工作，到處都是沖突。應(yīng)用程序在實(shí)際生產(chǎn)中會(huì)遇到各種未知且棘手的問(wèn)題，很難及時(shí)處理。這就促使了運(yùn)維等相關(guān)人員在軟件研發(fā)生命周期的早期就需要參與進(jìn)來(lái)。作為敏捷開(kāi)發(fā)的擁躉，Patrick果斷調(diào)整，試圖通過(guò)打通開(kāi)發(fā)和運(yùn)維的這堵部門(mén)墻。而他所開(kāi)展的敏捷管理實(shí)踐就是DevOps發(fā)展的第一個(gè)雛形。
DevOps概念形成有兩個(gè)關(guān)鍵時(shí)刻，一個(gè)是Patrick Debois和Andrew Clay Shafer在多倫多敏捷會(huì)議上的會(huì)面，另一個(gè)便是John Allspaw和Paul Hammond在 Velocity'09的演講。經(jīng)過(guò)探討，DevOps準(zhǔn)確的定義就是Development和Operations的組合，是一組過(guò)程、方法與系統(tǒng)的統(tǒng)稱，用于促進(jìn)開(kāi)發(fā)、技術(shù)運(yùn)營(yíng)和質(zhì)量保障（QA）部門(mén)之間的溝通、協(xié)作與整合。彼時(shí)的概念很樸素：修復(fù)文化。而為了讓“DevOps”取得成功，有分歧的相關(guān)方都需要參與。時(shí)隔十余年，現(xiàn)在看來(lái)，企業(yè)雖然多了“DevOps工程師”的職位，在DevOps會(huì)議上卻失去了這種初衷：大量運(yùn)維、運(yùn)營(yíng)人員參與，而開(kāi)發(fā)人員參加的較少。
DevOps難以落地之謎
隨著DevOps的流行，很多企業(yè)的做法卻相當(dāng)粗暴：將Dev、Ops兩個(gè)團(tuán)隊(duì)合并，或者將運(yùn)維劃歸開(kāi)發(fā)。這是理念上的錯(cuò)誤。此外，在客觀條件上也缺土壤。尤其在微服務(wù)盛行的今天，系統(tǒng)被分成了幾十個(gè)甚至幾百個(gè)服務(wù)組件，如果沒(méi)有敏捷的基礎(chǔ)設(shè)施服務(wù)作為先行條件，做DevOps基本上就是空談。這也是DevOps這些年一直難以落地的主要的兩點(diǎn)原因。下面舉個(gè)真實(shí)的例子。Lee Briggs是一位擁有15年經(jīng)驗(yàn)的云工程技術(shù)的資深專家和創(chuàng)業(yè)者，他曾聊到有關(guān)DevOps的一次感到困惑的經(jīng)歷：一位負(fù)責(zé)開(kāi)發(fā)某產(chǎn)品的董事級(jí)同事在會(huì)上提到他的團(tuán)隊(duì)是“真正的Devops”，卻從未和Briggs談?wù)撨^(guò)他們的運(yùn)維需求，Briggs甚至不知道他們?cè)谧鍪裁矗恢浪麄冊(cè)谑褂肁WS ECS部署應(yīng)用程序。
Briggs感到很困惑：如果連本公司的運(yùn)維團(tuán)隊(duì)都沒(méi)有參與進(jìn)來(lái)，他們?cè)趺纯赡苁恰罢嬲腄evops”？
后來(lái)經(jīng)過(guò)與其團(tuán)隊(duì)中的開(kāi)發(fā)人員的對(duì)話，Briggs才明白整背后的含義：公司的開(kāi)發(fā)人員接管了整個(gè)應(yīng)用程序的生命周期，一條龍?zhí)幚恚恍枰\(yùn)維參與了——他們使用boto3并編寫(xiě)部署腳本來(lái)發(fā)布新版本，并雇傭了精通AWS以及后端業(yè)務(wù)的“全棧工程師”。DevOps初衷純粹是為了讓開(kāi)發(fā)人員能夠更輕松的工作，本意是減少甚至是消除他們?cè)诓渴?、管理部署等在基礎(chǔ)架構(gòu)生命周期的種種繁瑣的操作與困擾。而現(xiàn)在，別人口中侃侃而談“真正的Devops”時(shí)，他們的意思卻是讓開(kāi)發(fā)者把運(yùn)維的工作也包攬了。
開(kāi)發(fā)運(yùn)維全包攬
如今，我們正在用今天的運(yùn)維人員所熟悉的久經(jīng)考驗(yàn)的工具來(lái)給到開(kāi)發(fā)者，其中包括GitLab CI、Terraform（Terraform是一個(gè)IT基礎(chǔ)架構(gòu)自動(dòng)化編排工具，可以用代碼來(lái)管理維護(hù)IT資源），當(dāng)然還有Kubernetes。事情就變成了這樣：“嘿，你應(yīng)該試試使用我們的平臺(tái)！我們已經(jīng)修復(fù)了所有這些Bug，它比原來(lái)的工具要好得多?！薄爸x謝，但我們不感興趣?！薄斑?，為什么？它更可靠、更快，并且是使用業(yè)界標(biāo)準(zhǔn)的工具?！薄笆堑模覀円稽c(diǎn)也不了解他們。我們還是對(duì)自己的東西更熟悉些?！边\(yùn)維人員一直相信自己的方法很管用：畢竟運(yùn)維部門(mén)知道如何在云上運(yùn)行軟件。但開(kāi)發(fā)者往往不買單。Briggs陳述了這段經(jīng)歷——“運(yùn)維人員總是試圖說(shuō)服開(kāi)發(fā)人員來(lái)參加DevOps會(huì)議。一味地解釋自身打造的平臺(tái)做了什么，以及它將如何幫助他們。我在與開(kāi)發(fā)人員的對(duì)話中一直在爭(zhēng)論，拼命想給整個(gè)公司帶來(lái)一種“DevOps”的心態(tài)，而這個(gè)團(tuán)隊(duì)對(duì)這種心態(tài)的回應(yīng)卻是‘我們自己來(lái)做，謝謝?！?/p>
Briggs終于意識(shí)到：DevOps這種改變文化的嘗試失敗了。
現(xiàn)狀：淪為運(yùn)維工具
最終，Briggs對(duì)2022年DevOps的做出了以下總結(jié)：現(xiàn)在的DevOps是更多的站在運(yùn)維角度上，試圖說(shuō)服開(kāi)發(fā)人員按照運(yùn)維的方式做事。原因一目了然，目前市面上幾乎所有被稱為“DevOps”的工具都專注于運(yùn)維層面。如果你瀏覽/r/devops，你會(huì)看到一篇又一篇關(guān)于運(yùn)維或工具的文章。如果您查看DevOps工程師的工作描述，它看起來(lái)與2013年的系統(tǒng)管理員角色非常相似，只不過(guò)其中涉及的不再是原來(lái)的機(jī)架和堆疊著的服務(wù)器，取而代之的是一些容器或云的提供商管理。因此，如果DevOps本應(yīng)致力于改變整體文化，那么它就不能被視為一場(chǎng)成功的運(yùn)動(dòng)?？春眠@場(chǎng)運(yùn)動(dòng)的人可能會(huì)高興地說(shuō)：“我們正在努力！”但其實(shí)他們明白，他們只不過(guò)是局限在運(yùn)維方面在做單方面的努力——而這顯然，有悖于DevOps最初強(qiáng)調(diào)的“一條雙向的道路”。值得記住的是，在任何給定項(xiàng)目或組織中，運(yùn)維的人數(shù)通常至少超過(guò)1/5。試圖說(shuō)服每一位開(kāi)發(fā)人員以“運(yùn)維”和“使用運(yùn)維工具”的方式做開(kāi)發(fā)，最終都將是一件愚蠢的差事。
問(wèn)題所在
歸根結(jié)底，“DevOps”一詞，可能已經(jīng)顯得有些陳舊了?，F(xiàn)在如果還有人向你推銷DevOps，那可能太過(guò)時(shí)了。我們真正希望看到的是，DevOps人在日常角色中的思維方式發(fā)生根本性轉(zhuǎn)變。我們往往忽視了以下兩點(diǎn)：一、DevOps人第一要義是要以運(yùn)維為中心的，角色定位是幫助開(kāi)發(fā)人員將功能交付給客戶（或幫助開(kāi)發(fā)人員實(shí)現(xiàn)其他業(yè)務(wù)目標(biāo)）。二、當(dāng)為開(kāi)發(fā)人員提供產(chǎn)品和功能時(shí)，需要注意：尋找到一條阻力最小的路徑是保持速度的關(guān)鍵，讓開(kāi)發(fā)人員學(xué)習(xí)和維護(hù)所有操作實(shí)踐是不可擴(kuò)展的，也不可行的?；乜碊evOps最初的想法，重點(diǎn)是消除開(kāi)發(fā)人員和運(yùn)維團(tuán)隊(duì)之間的摩擦：讓運(yùn)維者不再一味地對(duì)開(kāi)發(fā)人員說(shuō)“不”，讓開(kāi)發(fā)者不再?gòu)?qiáng)push運(yùn)維人員去上線。這些想法和目標(biāo)仍然是崇高的，企業(yè)今天仍然應(yīng)該追求它們，但DevOps的世界到底是什么樣子的呢？如果我們認(rèn)可“DevOps”是一種試圖將開(kāi)發(fā)人員帶到運(yùn)維世界的嘗試，并且也同意這種嘗試在很大程度上已經(jīng)失敗，那么現(xiàn)在，我們需要一個(gè)新術(shù)語(yǔ)。
Briggs提出了一個(gè)新名詞：“SoftOps”。
SoftOps：軟件開(kāi)發(fā)人員的運(yùn)維
SoftOps，聽(tīng)起來(lái)有點(diǎn)俗套，但理念卻是嶄新的。SoftOps的理念是，重點(diǎn)是讓開(kāi)發(fā)人員更好地工作。運(yùn)維人員不會(huì)告訴他們?cè)撟鍪裁矗菚?huì)問(wèn)他們?cè)谶\(yùn)維方面想做什么，然后讓他們盡可能地輕松。這個(gè)名詞得益于Briggs加入Pulumi后的經(jīng)歷，他通過(guò)一個(gè)不同的視角來(lái)看待這個(gè)世界：以開(kāi)發(fā)者為中心。SoftOps是一種將開(kāi)發(fā)人員作為主要客戶放在首位的想法。構(gòu)建面向開(kāi)發(fā)人員的運(yùn)維實(shí)踐（理論上）應(yīng)該讓開(kāi)發(fā)人員參與進(jìn)來(lái)，以便協(xié)同工作。也許，如果我們只專注于這一目標(biāo)，我們將最終解決DevOps在2009年一直試圖解決的問(wèn)題。在這個(gè)新的理念下，“下載這個(gè)工具，閱讀這個(gè)48頁(yè)的手冊(cè)頁(yè)，告訴你的PM你錯(cuò)過(guò)了sprint的最后期限”的命令開(kāi)發(fā)者的對(duì)話場(chǎng)景將一去不復(fù)返；此外，“把它給我，我會(huì)為你做”開(kāi)發(fā)者包攬運(yùn)維工作的日子也將一去不復(fù)返。
寫(xiě)在最后
今年3月，AbsoluteReports發(fā)布了《全球DevOps平臺(tái)市場(chǎng)2022調(diào)查報(bào)告》，報(bào)告中預(yù)測(cè)，到2028年，全球DevOps平臺(tái)市場(chǎng)規(guī)模將從2021年的67.376億美元增長(zhǎng)到263.70億美元，看起來(lái)2022-2028年的復(fù)合年增長(zhǎng)率為20.7%。從這些數(shù)字可以看出：DevOps作為提高企業(yè)技術(shù)可靠性、保證穩(wěn)定的業(yè)務(wù)增長(zhǎng)的利器，全球企業(yè)DevOps工具的需求愈發(fā)強(qiáng)烈。而從DevOps文化來(lái)看，DevOps在演變成一場(chǎng)讓開(kāi)發(fā)者使用新的運(yùn)維工具的運(yùn)動(dòng)。但這種運(yùn)動(dòng)，無(wú)疑存在“跑偏”的跡象，這也是DevOps難以落地的根本原因：文化的缺失。如果不能改變觀念，即使將員工放在一起，也只是增加兩個(gè)團(tuán)隊(duì)的爭(zhēng)吵而已。換言之，DevOps考驗(yàn)的不僅是一家企業(yè)的技術(shù)，更是管理水平和企業(yè)文化。Briggs提出的“SoftOps”的概念，一改“開(kāi)發(fā)、運(yùn)維全包攬”的現(xiàn)狀，想要重新梳理開(kāi)發(fā)和運(yùn)維流程的規(guī)范，讓開(kāi)發(fā)人員在運(yùn)維初期就給出系統(tǒng)部署的優(yōu)化建議。雖然名詞改變了，但SoftOps與DevOps的初衷卻是一致的：減少開(kāi)發(fā)團(tuán)隊(duì)與運(yùn)維團(tuán)隊(duì)之間的摩擦，而不是某一方強(qiáng)勢(shì)包攬、拒絕溝通，甚至簡(jiǎn)單淪為一種新工具。
參考資料：https://leebriggs.co.uk/blog/2022/06/21/devops-is-a-failure
更多精彩技術(shù)文章盡在技術(shù)精選期刊，下載鏈接：???https://www.51cto.com/journalDetail/6.html???
網(wǎng)頁(yè)題目：DevOps失敗了！
文章來(lái)源：http://m.5511xx.com/article/ccogigd.html
