編譯 | 云昭

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

從在服務(wù)器上的單體架構(gòu)中構(gòu)建應(yīng)用程序，到將它們分解為多個微服務(wù)、打包到容器中、與 Kubernetes 編排并托管在分布式云環(huán)境中，再加上消費者功能豐富、追求體驗的預(yù)期，設(shè)計上又需要安全且有彈性，軟件復(fù)雜度正在以一種非?？斓乃俣扰噬?strong>如果說軟件正在吞噬世界，那么云正在吞噬軟件，而無處不在的“云”端之下，則是運維工作正在慢慢把開發(fā)者拖垮。?

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

用過了的 DevOps

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

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

一條推特燃炸情緒

?“在大多數(shù)情況下，開發(fā)人員不想處理運維問題，” 《DevOps for Dummies》一書的作者、AWS 網(wǎng)絡(luò)服務(wù)社區(qū)參與負(fù)責(zé)人 Emily Freeman 在推特上寫道。

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

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

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

“如果你把開發(fā)者拉到太多與他們不匹配的領(lǐng)域，最終會自食苦果。他們擁有不同的技術(shù)棧?！盞ubernetes 存儲專家、Ondat 的產(chǎn)品負(fù)責(zé)人 James Brown 。

或者正如 Harness 的現(xiàn)場首席技術(shù)官 Nick Durkin 所說，“人們開始意識到我們不會聘請電工來做我們的管道工?！?/span>

負(fù)荷“大量”增加 

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

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

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

這些不斷擴大的職責(zé)涉及到大規(guī)模的再培訓(xùn)工作，尤其是云工程和基礎(chǔ)設(shè)施作為代碼技能變得至關(guān)重要。

管理層過高預(yù)期 

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

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

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

認(rèn)識到問題 

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

“目的不是要給開發(fā)者增加負(fù)擔(dān)，而是在正確的時間為開發(fā)者提供正確的信息，”Harness 的 Durkin 認(rèn)為。“他們不想配置所有東西，但他們確實希望在正確的時間從這些系統(tǒng)中獲取信息，以使運營、安全和基礎(chǔ)設(shè)施團隊能夠正常工作。除非出現(xiàn)問題，否則開發(fā)人員不用關(guān)心?！蔽譅柼亍さ纤鼓峁荆╓alt Disney Company）的前董事奈杰爾森（Nigel Simpson）希望公司能認(rèn)識到這個問題，“應(yīng)該努力讓開發(fā)人員擺脫‘擔(dān)憂機器如何工作’的狀態(tài)，并回歸到構(gòu)建軟件，這是他們最擅長的?！敝匾氖?，DevOps 是一個統(tǒng)一體，其實施應(yīng)該因組織而異。開發(fā)人員現(xiàn)在可以做一些運維的工作并不意味著他們應(yīng)該把運維的活也做了。

開發(fā)和運維如何平衡 

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

Ondat 的 Brown 認(rèn)為，Kubernetes 的容器編排正在成為這兩個團隊之間的分離層，將兩者的關(guān)注點剝離開，以便開發(fā)人員可以專注于他們的代碼，而運維可以確保底層基礎(chǔ)設(shè)施和管道經(jīng)過優(yōu)化以運行它?！白屛覀儾灰氐侥切┎换ハ嘟徽劦膱F隊，”Brown 說。Humanitec 的創(chuàng)始人 Kaspar von Grunberg曾在他的電子郵件中寫道：不要相信試圖讓每個人都成為專家的謬論。在高績效團隊中，很少有 Kubernetes 方面的知名專家，并且讓其他成員盡量保持低認(rèn)知負(fù)荷。??

DevOps 已死，SRE接力 

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

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

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

以兩家大型金融機構(gòu) Vanguard 和摩根士丹利為例，它們在向更多云原生實踐過渡時發(fā)現(xiàn)難以平衡開發(fā)和運維之間的職責(zé)。

在中央運維層和單個開發(fā)人員之間插入 SRE 安全緩沖帶，能夠幫助在兩家公司建立信心，在開發(fā)人員效率和運維穩(wěn)定性之間做到恰當(dāng)?shù)钠胶狻?/span>

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

“這是一個需要解決的細(xì)節(jié)問題，”Vanguard 的站點可靠性工程師 Christina Yakomin 說?！耙?SRE 確實會讓人覺得，我們正在再次將運維孤立到這個角色中?！?/span>

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

平臺工程：讓人直呼萬歲 

“內(nèi)部開發(fā)人員平臺”或“平臺工程學(xué)科”的想法也已成為組織為開發(fā)人員提供所需工具的一種方式，并配有適當(dāng)?shù)慕M織護欄以保護開發(fā)人員能夠承擔(dān)最合適的工作。

內(nèi)部開發(fā)人員平臺通常由代碼投入生產(chǎn)所需的 API、工具、服務(wù)、知識和支持組成，并將其結(jié)合到由專門的專家團隊或產(chǎn)品所有者維護的公司標(biāo)準(zhǔn)平臺中?！癉evOps 已經(jīng)死了，平臺工程萬歲，”軟件工程師和 DevOps評論員 Sid Palas 在推特上寫道?！伴_發(fā)人員不喜歡與基礎(chǔ)設(shè)施打交道，公司在成長過程中需要控制他們的基礎(chǔ)設(shè)施。平臺工程使這二者能夠和諧共存?！避浖稍児?Thoughtworks 的技術(shù)主管布蘭登·拜爾斯（Brandon Byars）表示，他經(jīng)常“看到該部門在平臺工程團隊中運作良好，這些團隊為開發(fā)人員消除摩擦，同時讓他們可以良好地運轉(zhuǎn)。”

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

寫在最后 

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

Google Cloud 的首席開發(fā)倡導(dǎo)者 Kelsey Hightower 將開發(fā)人員“可選擇水平”視為“禮物和詛咒”?！岸Y物”是可以使用幾乎無限的技術(shù)目錄來構(gòu)建軟件。“詛咒”是指“基礎(chǔ)設(shè)施泄漏到開發(fā)者的工作流程中的情況"。

現(xiàn)在，隨著許多供應(yīng)商專注于托管服務(wù)和抽象。這種托管無異于開發(fā)和運維的二次分裂，在這之前，我們是否應(yīng)該進行大整合？

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

?