編譯 | 云昭

軟件開發的工作正在難以想象的速度變得越來越復雜。

從在服務器上的單體架構中構建應用程序，到將它們分解為多個微服務、打包到容器中、與 Kubernetes 編排并托管在分布式云環境中，再加上消費者功能豐富、追求體驗的預期，設計上又需要安全且有彈性，軟件復雜度正在以一種非常快的速度攀升。如果說軟件正在吞噬世界，那么云正在吞噬軟件，而無處不在的“云”端之下，則是運維工作正在慢慢把開發者拖垮。?

新帶來的復雜性正在折磨開發人員。開發和運維專家也許到了重新分開的時刻了。但是，在不重復過去的錯誤的情況下可以做到這一點嗎？

用過了的 DevOps

?隨著敏捷方法和云計算的興起，隨著軟件開始吞噬世界， DevOps 出現了。作為“開發”和“運維”的簡潔組合，DevOps 試圖將兩個先前獨立的負責構建和部署軟件的團隊聚集在一起。這也恰逢軟件工程師需要收緊用戶反饋循環并更頻繁地將更新推送到生產環境，甚至無意中推動了這一點。

雖然許多組織抓住這個機會，將兩組專家聚集在一起，以前所未有的速度解決常見問題，但也有一些組織將 DevOps 的興起作為開發人員負責運維任務的許可證，并試圖建立一個半神話般的超級全棧的開發團隊。

一條推特燃炸情緒

?“在大多數情況下，開發人員不想處理運維問題，” 《DevOps for Dummies》一書的作者、AWS 網絡服務社區參與負責人 Emily Freeman 在推特上寫道。

這一條推特顯然觸動了全球軟件開發者的神經，數百條同樣不想做運維的開發人員的回復紛至沓來。“我是一名開發人員，我不想處理運維問題，”快餐公司 Chipotle 的軟件工程師 Scott Pantall 回答說。

“開發人員和運維人員應該密切合作，同時扮演不同的角色。團隊之間的同理心才是真正的重點，”SUSE 的開發人員布道師 Andrew Gracey 表示。

雖然將更多的運維和安全問題“左移”到軟件開發側這種做法有著明顯的優點，比如可以提高測試效率并提高交付質量，但它也有可能成為帶來危險的瓶頸。

“如果你把開發者拉到太多與他們不匹配的領域，最終會自食苦果。他們擁有不同的技術棧。”Kubernetes 存儲專家、Ondat 的產品負責人 James Brown 。

或者正如 Harness 的現場首席技術官 Nick Durkin 所說，“人們開始意識到我們不會聘請電工來做我們的管道工。”

負荷“大量”增加 

?相信連開發者都想不到，時至今日，同行的“存量”已經變得如此之高，但他們的工作負擔非但沒有下降，反而一路飆升。與之形成鮮明對比的是，技術運維的專業知識在某種程度上已經淡出人們的視線。

正如 DevOps 工程師、前系統管理員 Mathew Duggan在《運維部不是IT研發部》一文中所提及的，雖然運維人員“仍然承擔著以前的所有職責，確保應用程序可用、受監控、安全和合規”，但他們還負責構建和維護軟件交付管道，“在開發人員即使在沒有我們參與的情況下，為快速安全地發布代碼奠定基礎。”

?圖：傳統IT部門由開發、QA、運營團隊組成每個團隊專注于不同的分工和角色。

這些不斷擴大的職責涉及到大規模的再培訓工作，尤其是云工程和基礎設施作為代碼技能變得至關重要。

管理層過高預期 

?“在我看來，情況從未像現在這樣慘淡，”Duggan 寫道。“開發者的職責范圍 (RIP QA) 大幅增加，但管理層對效率的期望卻不切實際，現已變得不堪重負。”下面這個對話體現了這種情況——我：領導，我已經厭倦了，到處都是“鑰匙孔”，太累人了！

領導：我們希望你做開發工作，但這一切都需要放在墻后面，所以你必須跳過障礙才能得到。哦，我們也不會為你提供一種標準化的方式來獲取。

領導：為什么要花這么長時間？我：這不是真正的 DevOps！領導：不要那么消極。與任何宏大的想法一樣，當應用于高度復雜的企業時，這通常都會落空，因為有數百種產品或服務以及各種團隊為每個產品或服務提供自己獨特的流程和技術棧。戴爾科技資本（Dell Technologies Capital）總經理 Tyler Jewell 在一份研究報告中寫道： “要建立一個能夠實現可持續發展組織，是非常具有挑戰性的。隨著系統復雜性的增加和最終用戶反饋的增多，我們越來越難以預測一個改動對于系統可能產生的影響。”

認識到問題 

情況可能不像 Duggan 和其他人認為的那樣絕望，但解決問題的前提是意識到這個問題，盡管它可能需要對工程團隊及其職責進行重大調整。

“目的不是要給開發者增加負擔，而是在正確的時間為開發者提供正確的信息，”Harness 的 Durkin 認為。“他們不想配置所有東西，但他們確實希望在正確的時間從這些系統中獲取信息，以使運營、安全和基礎設施團隊能夠正常工作。除非出現問題，否則開發人員不用關心。”沃爾特·迪斯尼公司（Walt Disney Company）的前董事奈杰爾森（Nigel Simpson）希望公司能認識到這個問題，“應該努力讓開發人員擺脫‘擔憂機器如何工作’的狀態，并回歸到構建軟件，這是他們最擅長的。”重要的是，DevOps 是一個統一體，其實施應該因組織而異。開發人員現在可以做一些運維的工作并不意味著他們應該把運維的活也做了。

開發和運維如何平衡 

?正如 Gartner 分析師 Lydia Leong 所言： “開發人員對基礎設施的控制并不是一個全有或全無的命題。” “在軟件生命周期中做好職責劃分，這樣采可以從‘構建它，然后運行它’中獲益，而不必將開發人員空降到一個未馴服、未知的荒野，然后祝他們好運，因為這已經不是一個‘基礎設施和運維團隊’的問題了。”換句話說，“允許開發人員完全自助訪問開發和測試環境，并將基礎設施構建為生產代碼模板的能力，而不是讓開發者完全負責生產，”Leong 寫道。事實上，根據VMware 的《2022 年 Kubernetes 狀況》報告，776 名受訪者中有 54% 的人表示，更高的開發人員效率是采用 Kubernetes 的關鍵原因，超過三分之一（37%）的人表示他們希望提高運維人員的效率。

Ondat 的 Brown 認為，Kubernetes 的容器編排正在成為這兩個團隊之間的分離層，將兩者的關注點剝離開，以便開發人員可以專注于他們的代碼，而運維可以確保底層基礎設施和管道經過優化以運行它。“讓我們不要回到那些不互相交談的團隊，”Brown 說。Humanitec 的創始人 Kaspar von Grunberg曾在他的電子郵件中寫道：不要相信試圖讓每個人都成為專家的謬論。在高績效團隊中，很少有 Kubernetes 方面的知名專家，并且讓其他成員盡量保持低認知負荷。??

DevOps 已死，SRE接力 

如果 DevOps 的時代真的走到了盡頭，或者其光彩剛剛出現褪色的跡象，那接下來會發生什么？

我們之前在《??DevOps失敗了???》一文中，提到了“SoftOps”的概念，但目前更為被大家認可的是“SRE”（站點可靠性工程）。SRE  是在 Google 遭遇與 DevOps成長的陣痛中誕生的，它已被證明是一種流行的解決方案。

“從根本上說，當你要求軟件工程師設計一個運維功能時，就會發生這種（痛苦的）情況，”谷歌工程副總裁、SRE 教父 Ben Treynor 這句話經常被引用。

以兩家大型金融機構 Vanguard 和摩根士丹利為例，它們在向更多云原生實踐過渡時發現難以平衡開發和運維之間的職責。

在中央運維層和單個開發人員之間插入 SRE 安全緩沖帶，能夠幫助在兩家公司建立信心，在開發人員效率和運維穩定性之間做到恰當的平衡。

然而，SRE 功能也受到了一些批評。正如摩根士丹利的 DevOps和企業技術架構負責人 Trevor Brosnan 所說，建立 SRE 原則“有時被誤解為對運維團隊的品牌重塑”。

“這是一個需要解決的細節問題，”Vanguard 的站點可靠性工程師 Christina Yakomin 說。“引入 SRE 確實會讓人覺得，我們正在再次將運維孤立到這個角色中。”

相反，Yakomin 希望鼓勵 Vanguard 開發人員和運營專家分擔安全責任，并確保擁有共享平臺的團隊為他們承擔全部運營責任。

平臺工程：讓人直呼萬歲 

“內部開發人員平臺”或“平臺工程學科”的想法也已成為組織為開發人員提供所需工具的一種方式，并配有適當的組織護欄以保護開發人員能夠承擔最合適的工作。

內部開發人員平臺通常由代碼投入生產所需的 API、工具、服務、知識和支持組成，并將其結合到由專門的專家團隊或產品所有者維護的公司標準平臺中。“DevOps 已經死了，平臺工程萬歲，”軟件工程師和 DevOps評論員 Sid Palas 在推特上寫道。“開發人員不喜歡與基礎設施打交道，公司在成長過程中需要控制他們的基礎設施。平臺工程使這二者能夠和諧共存。”軟件咨詢公司 Thoughtworks 的技術主管布蘭登·拜爾斯（Brandon Byars）表示，他經常“看到該部門在平臺工程團隊中運作良好，這些團隊為開發人員消除摩擦，同時讓他們可以良好地運轉。”

然而，有利必有弊。他補充說，“缺點是需要開發人員在沒有集中的專業知識和工具支持的情況下完成所有這些工作。”在其工程團隊中，任何致力于實施 DevOps 原則的組織，都將熟悉軟件開發團隊和運維團隊之間的平衡做法。在云原生復雜性時代下，做到這種平衡的難度無異于“高空走鋼絲”。

寫在最后 

云計算的流行和開源軟件運動的結合使得開發人員的“性能可選項”越來越多：可擴展性、彈性、模塊化和可更新等等。這導致許多人質疑這種“可選項”是否對普通軟件開發人員來說是一個凈積極因素。在某些情況下，龐大的可用服務目錄所固有的復雜性，與其說是一種優勢，不如說是一種負擔。

Google Cloud 的首席開發倡導者 Kelsey Hightower 將開發人員“可選擇水平”視為“禮物和詛咒”。“禮物”是可以使用幾乎無限的技術目錄來構建軟件。“詛咒”是指“基礎設施泄漏到開發者的工作流程中的情況"。

現在，隨著許多供應商專注于托管服務和抽象。這種托管無異于開發和運維的二次分裂，在這之前，我們是否應該進行大整合？

或許于開發者而言，正如 Hightower 所說：“（開發者）這個職業不僅僅是寫代碼；這是達到目的的手段。也許我們已經建立了足夠多的東西，可以停下來建造新事物，以便讓我們現有的東西更加成熟，并讓不同崗位回歸到各自的角色。這或許就是在過去十年中，人們所看到的 Devops 和協作運動的美好結局。”

?