“在大多數情況下，開發人員并不想處理運維問題。”亞馬遜云科技社區參與負責人、《DevOps For Dummies》作者 Emily Freeman 在推特上坦言。

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

　　“我就是個開發者，我不想處理運維問題。”快餐公司 Chipotle 軟件工程師 Scott Pantall 直接表示。

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

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

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

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

　　當然，也有開發者人認為，當自己全面負責代碼、基礎設施和監控時，通常會感到自己很有能力。“這就是全才和專家的區別吧。”

　　職責“大量”增加

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

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

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

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

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

　　我：這不是真正的開發操作。

　　領導：別那么消極。

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

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

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

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

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

　　事實上，壓力帶來的惡果正開始顯現。

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

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

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

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

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

　　更重要的是，DevOps 代表一個連續的統一體，其具體實施會因組織而異。現在的開發者能做一點運維，并不代表他們就該每天都承擔運維壓力。

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

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

　　在云計算領域，Kubernetes 容器編排正在成為開發與運維之間的邊界。關注這條邊界，就能讓開發者集中于自己的代碼，并讓運維人員確保底層基礎設施和管理的運行與優化。“但這種獨立是以溝通和理解作為基礎的，并不是以往那種孤島式的各自為戰。”Ondat 公司 Brown 說道。

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

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

　　DevOps 已死

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

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

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

　　有開發者現身說法道，“我們有 SRE，他們為我們構建了很好的工具并維護應用程序的基礎設施。我們仍然自己做幾乎所有的日常部署和運維工作，但是 SRE / 基礎設施團隊已經做得很好了，我們只需要擔心會發生什么而不必擔心要如何做。”

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

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

　　平臺工程才是未來？

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

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

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

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

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

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