“在大多數(shù)情況下，開發(fā)人員并不想處理運維問題,?！眮嗰R遜云科技社區(qū)參與負責(zé)人、《DevOps For Dummies》作者 Emily Freeman 在推特上坦言,。

　　一石激起千層浪,。Freeman 的觀點引起了廣泛共鳴，幾百條抱有同樣觀點的開發(fā)人員紛紛留言回應(yīng),。

　　“我就是個開發(fā)者,，我不想處理運維問題?！笨觳凸?Chipotle 軟件工程師 Scott Pantall 直接表示,。

　　“我確實更喜歡回到只需要掌握特定編程技巧的時候，而不是現(xiàn)在這樣成為一個萬事通,，因為多個責(zé)任分散了我太多精力,。這兩者都是全職工作，而我只能各自投入一半的精力,?！遍_發(fā)者 Mitchell Abbott 說道。

　　SUSE 開發(fā)人員布道師 Andrew Gracey 認為,，開發(fā)人員和運維人員應(yīng)該密切合作,，同時各自扮演不同的角色，能夠讓團隊成員相互理解的同理心才是 DevOps 的真正核心,。

　　“強迫開發(fā)者身兼太多任務(wù),，最終只會搬起石頭砸自己的腳。不同場景對應(yīng)著不同的技能組合,?！盞ubernetes 存儲技術(shù)提供商 Ondat 的產(chǎn)品負責(zé)人 James Brown 表示。

　　“人們慢慢意識到，電工和水管工確實不是同一個職位,?！盚arness 公司專項 CTO Nick Durkin 說道。

　　當(dāng)然,，也有開發(fā)者人認為,，當(dāng)自己全面負責(zé)代碼、基礎(chǔ)設(shè)施和監(jiān)控時,，通常會感到自己很有能力,。“這就是全才和專家的區(qū)別吧,?！?/p>

　　職責(zé)“大量”增加

　　2000 年代后期，DevOps 與敏捷方法隨著云計算的興起而大行其道,。作為將開發(fā)與運維合并起來的新理念,，DevOps 希望打通這兩支以往長期孤立的軟件構(gòu)建與部署力量，實現(xiàn)“1+1>2”的積極效應(yīng),。與此同時,，當(dāng)時的軟件工程師也恰好需要縮短用戶反饋循環(huán)、提升生產(chǎn)環(huán)境下的更新推送頻率,，這也在無形中推進了開發(fā)與運維間的融合,。

　　不少組織敏銳把握住了這個機會，將兩方面的專家匯聚起來,，試圖以前所未有的速度解決種種常見問題,。但也有一些組織把 DevOps 解讀成了“讓開發(fā)人員負責(zé)運維工作”，并據(jù)此描繪出一個白日夢般的超級概念——全棧開發(fā)人員,。

　　但開發(fā)運維受到很多限制,。網(wǎng)友“beall49”表示，“我厭倦了一切東西像是從鑰匙孔里獲取,，它令人筋疲力盡,。”

　　領(lǐng)導(dǎo)：我們希望你做開發(fā)運維,，但我們不會將所有內(nèi)容直接給你,，您必須繞過防火墻才能獲得。哦,，是的,，我們也不會提供一種標準化的方式來訪問某些東西。

　　領(lǐng)導(dǎo)：為什么要花這么長時間,？

　　我：這不是真正的開發(fā)操作,。

　　領(lǐng)導(dǎo)：別那么消極,。

　　“有時，你會得到一臺被公司嚴格鎖定的開發(fā)機器（硬件加速設(shè)置已關(guān)閉并且沒有密碼無法使用,，嚴格的操作系統(tǒng)安全策略禁止你從公司存儲庫以外的任何地方安裝軟件等）,，你不能甚至使用虛擬化，使用這臺機器就是你進入公司網(wǎng)絡(luò)的方式,?！遍_發(fā)者“FloRup”補充道。

　　同時,，隨著企業(yè)軟件開發(fā)者的總體規(guī)模達到歷史新高,，大家對運維側(cè)的關(guān)注度卻始終不高。更可怕的是,，隨著軟件開發(fā)的增長,，運維工作量實際上也始終在同步攀升。

　　正如 DevOps 工程師,、前系統(tǒng)管理員 Mathew Duggan 去年的觀點,，雖然運維人員繼續(xù)承擔(dān)著之前的所有職責(zé)，確保應(yīng)用程序可用,、受控,、安全和合規(guī),，但現(xiàn)在他們還得負責(zé)構(gòu)建和維護軟件交付管道,，確保開發(fā)人員在無需運維介入的情況下，快速安全地發(fā)布代碼,。

　　要干的活越來越重,、要上的再培訓(xùn)課程越來越多，特別是云工程和基礎(chǔ)設(shè)施即代碼技能,，幾乎成為當(dāng)前運維從業(yè)者們的必修課,。

　　“在我看來，情況已經(jīng)惡化到了歷史極點,。運維團隊的職責(zé)范圍大幅增加,，但管理層還是對速度提出不切實際的要求，整個體系已然不堪重負,?！盌uggan 寫道。

　　事實上,，壓力帶來的惡果正開始顯現(xiàn),。

　　戴爾技術(shù)資本董事總經(jīng)理 Tyler Jewell 在一份研究報告中提到，“要想建立一支能夠長期,、和諧保持這種穩(wěn)定迭代水平的團隊,，其實是個巨大的挑戰(zhàn),。隨著系統(tǒng)復(fù)雜度的提升和最終用戶反饋的增加，人們已經(jīng)很難準確預(yù)測某項變更可能給系統(tǒng)造成的影響,?！?/p>

　　“人人都能成為專家”謬論

　　當(dāng)然，情況可能并沒 Duggan 等人描繪的那么糟糕,，但對工程團隊及其職責(zé)做出重大調(diào)整確實非常必要,。

　　“轉(zhuǎn)型的目的不是要給開發(fā)人員增加負擔(dān)，而是在正確的時間為開發(fā)者提供正確的信息,?！盚arness 公司的 Durkin 表示，“開發(fā)者最需要的不是額外的配置任務(wù),，而是在正確的時間能從系統(tǒng)中快速獲取必要信息,，這樣就能支持運維、安全和基礎(chǔ)設(shè)施團隊的正常工作,。除非出現(xiàn)問題,，否則運維元素就不應(yīng)該出現(xiàn)在開發(fā)者的視野當(dāng)中?！?/p>

　　迪士尼公司前企業(yè)技術(shù)戰(zhàn)略總監(jiān) Nigel Simpson 也希望公司能認識到這個問題,，并努力讓開發(fā)人員擺脫對底層基礎(chǔ)設(shè)施的擔(dān)憂，重新回到自己最擅長的軟件構(gòu)建上來,。

　　更重要的是,，DevOps 代表一個連續(xù)的統(tǒng)一體，其具體實施會因組織而異?，F(xiàn)在的開發(fā)者能做一點運維,，并不代表他們就該每天都承擔(dān)運維壓力。

　　Gartner 公司分析師 Lydia Leong 認為,，開發(fā)人員對基礎(chǔ)設(shè)施的控制,，并不是“要么全做、要么徹底不做”的命題,。企業(yè)可以把這部分職責(zé)劃分到整個應(yīng)用程序生命周期當(dāng)中,，只有這樣“誰構(gòu)建、誰運行”才能發(fā)揮積極作用,，而不是把開發(fā)者空降到一個他們既不熟悉,、也難以駕馭的陌生環(huán)境。

　　粗暴把基礎(chǔ)設(shè)施和運維團隊的問題拋給開發(fā)者,，不會帶來任何好處,。Leong 表示，更好的辦法應(yīng)該是放手讓開發(fā)人員自行訪問開發(fā)和測試環(huán)境,，并為他們賦予將基礎(chǔ)設(shè)施構(gòu)建為生產(chǎn)代碼模板的能力,。這才是重點,，而不是讓他們?nèi)尕撠?zé)生產(chǎn)。

　　在云計算領(lǐng)域,，Kubernetes 容器編排正在成為開發(fā)與運維之間的邊界,。關(guān)注這條邊界，就能讓開發(fā)者集中于自己的代碼,，并讓運維人員確保底層基礎(chǔ)設(shè)施和管理的運行與優(yōu)化,。“但這種獨立是以溝通和理解作為基礎(chǔ)的,，并不是以往那種孤島式的各自為戰(zhàn),。”O(jiān)ndat 公司 Brown 說道,。

　　事實上,，根據(jù) VMware 公司發(fā)布的《2022 年 Kubernetes 現(xiàn)狀》報告，776 名受訪者中,，54% 的人采用 Kubertnetes 的關(guān)鍵原因就是要提高開發(fā)者效率,，另有超過三分之一（37%）的受訪者稱是為了提高運維人員的效率。

　　“千萬別相信那種‘人人都能成為專家’的謬論,。在高效團隊中,，其實很少會有所謂專門的 Kubernetes 專家。這些團隊只是通過極高的抽象度著力緩和了每位成員的認知負擔(dān),?！盚umanitec 公司創(chuàng)始人 Kaspar von Grunberg 表示。

　　DevOps 已死

　　如果 DevOps 的時代真的走到了盡頭,，或者至少走過了輝煌時期,、來到新的轉(zhuǎn)折點,，那接下來事情將如何發(fā)展呢,？

　　站點可靠性工程（SRE）誕生自谷歌內(nèi)部，當(dāng)時搜索巨頭遭遇到了 DevOps 希望解決的成長陣痛?，F(xiàn)在來看,，這個職位確實能有效平衡開發(fā)與運維間的矛盾。谷歌工程副總裁,、SRE 之父 Ben Treynor 曾經(jīng)坦言,，“從本質(zhì)上講，如果要求軟件工程師設(shè)計一項運維功能,，那結(jié)果就是 SRE,。”

　　以 Vanguard 和摩根士丹利兩家大型金融機構(gòu)為例,，他們在向著云原生實踐過渡時,，就發(fā)現(xiàn)越來越難以平衡開發(fā)和運維兩端的職責(zé),。而 SRE 就像是緩沖層，把它鋪在集中運維團隊和各開發(fā)者團隊之間,，就能幫助各方建立信心,，感受到既保持良好開發(fā)速度、又獲得穩(wěn)定運營狀態(tài)的可能性,。

　　有開發(fā)者現(xiàn)身說法道,，“我們有 SRE，他們?yōu)槲覀儤?gòu)建了很好的工具并維護應(yīng)用程序的基礎(chǔ)設(shè)施,。我們?nèi)匀蛔约鹤鰩缀跛械娜粘２渴鸷瓦\維工作,，但是 SRE / 基礎(chǔ)設(shè)施團隊已經(jīng)做得很好了，我們只需要擔(dān)心會發(fā)生什么而不必擔(dān)心要如何做,?！?/p>

　　然而，SRE 也受到過不少批評,。摩根士丹利的 DevOps 和企業(yè)技術(shù)架構(gòu)負責(zé)人 Trevor Brosnan 就提到,，建立 SRE 原則“有時會被誤讀為要對運維團隊進行大洗牌?！?/p>

　　“這是個需要解決的微妙問題,。引入 SRE 確實會讓人有種正在再次剝離運維團隊的感覺?！钡聦嵅⒎侨绱?，Vanguard 站點可靠性工程師 Christina Yakomin 就一直在鼓勵公司的開發(fā)者和運維人員分擔(dān)安全責(zé)任，并把運營需求整體交由共享平臺團隊承擔(dān),。

　　平臺工程才是未來,？

　　如今，不少企業(yè)開始嘗試建立內(nèi)部開發(fā)者平臺或者平臺工程部門,，這樣既能給開發(fā)人員提供必要工具,，也能通過適當(dāng)?shù)慕M織護欄隔開其他事務(wù)對開發(fā)和運維造成的影響。

　　內(nèi)部開發(fā)者平臺往往由大量 API,、工具,、服務(wù)、知識和支持所構(gòu)成,，目的是為開發(fā)人員提供代碼生產(chǎn)部署所必需的一切助力,。至于平臺本身，則由公司專門的專家團隊或所有者負責(zé)維護,。

　　軟件工程師兼 DevOps 評論員 Sid Palas 在推特上寫道,，“DevOps 已死，平臺工程才是未來,。開發(fā)者不想跟基礎(chǔ)設(shè)施打交道,，企業(yè)在發(fā)展過程中又需要控制自己的基礎(chǔ)設(shè)施,。只有平臺工程，能將這兩個相互矛盾的命題統(tǒng)一起來,?！?/p>

　　“平臺工程部門的實際表現(xiàn)確實不錯，能夠在消除開發(fā)流程摩擦的同時,，賦予開發(fā)者充分的靈活性,。”軟件咨詢公司 Thoughtworks 的技術(shù)主管 Brandon Byars 表示,，“一旦把這些工作硬塞給缺乏專業(yè)知識和工具支持的開發(fā)者,，情況就會迅速惡化?！?/p>

　　因此面對新的歷史階段,，要想在工程團隊中貫徹 DevOps 原則，組織首先需要了解怎樣在軟件開發(fā)與運維團隊間尋求平衡,。正是因為這一微妙平衡點的存在,，才讓云原生時代的系統(tǒng)復(fù)雜性越來越高。

　更多信息可以來這里獲取==>>電子技術(shù)應(yīng)用-AET<<