開發者強烈表示:「我們根本不想做運維!」

【CSDN 編者按】軟體開發工作越來越複雜,”誰創建,就誰來運維 “的要求也在折磨著開發人員,或許現在又到了開發和運維人員應該分開的時刻了。但是,這能在不重蹈覆轍的情況下做到嗎?

原文連結:https://www.infoworld.com/article/3669477/devs-don-t-want-to-do-ops.html

聲明:本文為CSDN翻譯,轉載請註明來源。

編譯 | 孫若楠

「誰創建,就由誰來負責運維」的要求讓開發者們逐漸感到吃力,此外,運維團隊也壓力倍增。現在已經到了開發和運維再次分離的時候了嗎?

2000年代末,軟體開始吞噬世界,DevOps與敏捷方法論隨著雲端運算的興起大行其道。作為「開發」和「運維」的組合,DevOps試圖將先前負責構建和部署軟體的兩個獨立團隊聚集在一起。與此同時,軟體工程師需要縮短使用者反饋循環,提升生產環境下的更新頻率,他們的這類需求也在無形中推動了開發和運維之間的結合。

許多組織抓住了這個機會,將兩方面的專家聚集在一起,嘗試以前所未有的速度解決問題。但也有一些組織將Devops的興起視為對開發人員負責運維任務的許可,並試圖建立由全棧開發人員組成的超級團隊。

我們不想做運維

我們不想做運維

「在大多數情況下,開發人員不想處理運維問題。」《Devops for Dummies》作者、亞馬遜網路服務社區參與負責人Emily Freeman在Twitter上寫道。

這條Twitter顯然觸動了全球軟體開發者的神經,數百條同樣抱有同樣觀點的開發人員的回覆紛至沓來。

「我是一名開發人員,我並不想處理運維問題。」快餐公司Chipotle的軟體工程師Scott Pantall表示。

SUSE的開發者佈道者Andrew Gracey認為,開發和運維應該緊密合作,同時扮演不同的角色,團隊之間的共鳴才是真正的重點。

雖然將更多的運維和安全問題 “左移”到軟體開發領域的做法具有顯著優勢,但它也有可能造成一個危險的瓶頸。

「如果將開發人員拉到太多不同的領域,最終會自食其果。」Kubernetes儲存專家Ondat的產品負責人James Brown說道。

Harness的現場技術長Nick Durkin表示,人們現在開始逐漸意識到,電工和管道工確確實實是不同的職業。

職責「大量」增加

職責「大量」增加

雖然企業軟體開發人員的規模達到了歷史新高,但大家對運維的關注度始終不高,即使運維的工作量正在不斷地增加之中。

正如Devops工程師、前系統管理員Mathew Duggan去年所說,「運維方依舊承擔著之前職責,確保應用程序可用、受控、安全及合規,但是現在他們還需要額外負責構建和維護軟體交付管道,保證開發人員在沒有運維參與的情況下能夠快速安全地發佈程式碼。」

這些不斷擴大的責任會涉及到大規模的再培訓工作,其中雲工程和基礎設施作為程式碼的技能變得至關重要。

「在我看來,情況從未像現在這樣慘淡過。運維團隊的職責在不斷增加,而管理層依舊對速度有著不切實際的期望,現已經完全不堪重負。」Duggan寫道。

戴爾技術資本的董事總經理Tyler Jewell在一份研究報告中說到:「要建立一個能夠長期可持續發展的組織非常具有挑戰性。隨著系統複雜性和終端使用者反饋的增加,人們很難準確預測某項變更可能對系統帶來的影響。」

認識到問題

認識到問題

情況可能並不像Duggan和其他人認為的那樣毫無希望,但需要對工程團隊及其職責做出重大調整。

「轉型的目的並不是要給開發者增加負擔,而是讓其在正確的時間獲得正確的資訊」,Harness公司的Durkin說,”比起配置所有的東西,開發者最希望在正確的時間從系統中獲得有效資訊,以使運維、安全及基礎設施團隊能夠正常工作。除非出現問題,否則開發人員無需關心運維工作。”

Walt Disney公司的前企業技術戰略總監Nigel Simpson也希望公司能夠認識到這個問題,並努力讓開發人員擺脫「擔憂機器應如何工作」的狀態,迴歸到他們最擅長的構建軟體上來。

更重要的是,Devops是一個連續的過程,具體的實施會因組織而異。開發人員可以做一些運維工作,但並不意味著他們應該始終承擔運維的壓力。

Gartner分析師Lydia Leong表示,開發人員對基礎設施的控制並不是一個全有或全無的命題,這部分職責可以劃分到整個程序生命週期中,只有這樣才能從「誰構建,誰運維」中獲益,而無需將開發者空降到一個他們並不熟悉的未知領域。

正如Ondat的Brown所表態的,Kubernetes的容器編排正在成為開發和運維之間的分界線,關注這條分界線,能夠讓開發人員專注於自己的程式碼,並且讓運維團隊確保底層基礎設施的最佳化與運行。「不要讓我們的團隊回到各自分離、互不交談的狀態。」Brown說。

事實上,根據VMware的《2022年Kubernetes現狀》報告,776 名受訪者中有 54% 表示提高開發人員效率是採用Kubernetes的關鍵原因,此外有超過三分之一 (37%) 的受訪者表示是為了提高運維人員效率 。

Humanitec的創始人Kaspar von Grunberg在電子郵件中表示,「不要相信每個人都成為專家的謬論,在高效團隊中,很少有Kubernetes方面的知名專家。」

DevOps已死

DevOps已死

如果DevOps的時代真的走到了盡頭,或者說其光彩已經開始褪色,那麼接下來會發生什麼呢?

站點可靠性工程 (SRE)是 Google在遭遇與Devops相關的成長陣痛中誕生的,它已被證明是一種流行的解決方案。Google工程副總裁、SRE之父Ben Treynor坦言,「從根本上說,當你要求軟體工程師設計一個運維功能時,就會發生這種情況(誕生SRE)。」

以兩家大型金融機構Vanguard和摩根士丹利為例,他們在向雲原生實踐過渡時發現難以平衡開發和運維之間的責任。此時,SRE就像開發團隊和運維團隊之間的過渡帶,有助於公司建立信心,同時實現良好的開發速度和穩定的運營狀態。

然而,SRE也受到了一些批評。 摩根士丹利的DevOps和企業技術架構負責人Trevor Brosnan說,建立SRE原則有時會被誤解為要對運維團隊的重塑。

「這是一個需要解決的微妙問題,引入SRE確實讓人們覺得我們正在分離運維團隊。」Vanguard的站點可靠性工程師Christina Yakominn始終鼓勵Vanguard的開發人員和運維人員分擔安全責任,並確保擁有共享平臺的團隊承擔全部的運維責任。

平臺工程是未來

平臺工程是未來

內部開發人員平臺已成為組織為開發人員提供所需工具的必要方式,也能通過配備適當的組織護欄隔離其他業務的影響,為開發人員提供更好的工作環境。

內部開發人員平臺通常由API、工具、服務、知識和支持組成,並由專門的專家團隊或產品所有者對其進行維護。

軟體工程師兼Devops評論員Sid Palas在Twitter上寫道,「DevOps已死,平臺工程才是未來。開發人員不喜歡與基礎設施打交道,而公司在成長過程中又需要控制自己的基礎設施,只有平臺工程才能使這二者統一共存。」

軟體諮詢公司Thoughtworks的技術主管Brandon Byars表示,「平臺工程團隊的良好運作能夠在消除開發人員摩擦的同時,讓開發人員具備更高的靈活性。」

任何組織若想在工程團隊中實施Devops原則,都必須明白如何在軟體開發和運維團隊之間的保持平衡。正是這種微妙平衡的存在,使得雲原生時代的複雜性越來越高。

相關文章

CNNVD通報Oracle多個安全漏洞

CNNVD通報Oracle多個安全漏洞

近日,CNNVD通報Oracle多個安全漏洞,其中Oracle產品本身漏洞60個,影響到Oracle產品的其他廠商漏洞247個。包括Orac...

最強 AI ChatGPT 真要取代程式設計師?

最強 AI ChatGPT 真要取代程式設計師?

【CSDN 編者按】ChatGPT 一出,「程式設計師要失業了」、「程式設計師要下崗了」之聲不絕於耳,引得程式設計師們不由得一陣驚慌,最強 ...

InsCode:下一代應用開發平臺?

InsCode:下一代應用開發平臺?

作者 | Aresn 責編 | 夏萌 對於一些初、中級程式設計師,想開發並部署一個中小應用(如開源項目的文件、個人部落格、個人網站、線上簡歷...

CNNVD 通報微軟多個安全漏洞

CNNVD 通報微軟多個安全漏洞

近日,CNNVD(國家資訊安全漏洞庫)正式通報微軟多個安全漏洞,其中微軟產品本身漏洞77個,影響到微軟產品的其他廠商漏洞8個。包括Micro...