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

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

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

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

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

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

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

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

　　職責“大量”增加

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

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

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

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

　　領導：為什么要花這么長時間？

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

　　領導：別那么消極。

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

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

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

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

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

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

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

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

　　當然，情況可能并沒 Duggan 等人描繪的那么糟糕，但對工程團隊及其職責做出重大調整確實非常必要。

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

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

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

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

　　粗暴把基礎設施和運維團隊的問題拋給開發(fā)者，不會帶來任何好處。Leong 表示，更好的辦法應該是放手讓開發(fā)人員自行訪問開發(fā)和測試環(huán)境，并為他們賦予將基礎設施構建為生產(chǎn)代碼模板的能力。這才是重點，而不是讓他們全面負責生產(chǎn)。

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

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

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

　　DevOps 已死

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

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

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

　　有開發(fā)者現(xiàn)身說法道，“我們有 SRE，他們?yōu)槲覀儤嫿撕芎玫墓ぞ卟⒕S護應用程序的基礎設施。我們仍然自己做幾乎所有的日常部署和運維工作，但是 SRE / 基礎設施團隊已經(jīng)做得很好了，我們只需要擔心會發(fā)生什么而不必擔心要如何做?！?/p>

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

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

　　平臺工程才是未來？

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

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

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

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

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

　更多信息可以來這里獲取==>>電子技術應用-AET<<