編譯 | 云昭

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

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

新帶來(lái)的復(fù)雜性正在折磨開(kāi)發(fā)人員。開(kāi)發(fā)和運(yùn)維專(zhuān)家也許到了重新分開(kāi)的時(shí)刻了。但是，在不重復(fù)過(guò)去的錯(cuò)誤的情況下可以做到這一點(diǎn)嗎？

用過(guò)了的 DevOps

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

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

一條推特燃炸情緒

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

這一條推特顯然觸動(dòng)了全球軟件開(kāi)發(fā)者的神經(jīng)，數(shù)百條同樣不想做運(yùn)維的開(kāi)發(fā)人員的回復(fù)紛至沓來(lái)?！拔沂且幻_(kāi)發(fā)人員，我不想處理運(yùn)維問(wèn)題，”快餐公司 Chipotle 的軟件工程師 Scott Pantall 回答說(shuō)。

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

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

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

或者正如 Harness 的現(xiàn)場(chǎng)首席技術(shù)官 Nick Durkin 所說(shuō)，“人們開(kāi)始意識(shí)到我們不會(huì)聘請(qǐng)電工來(lái)做我們的管道工。”

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

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

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

?圖：傳統(tǒng)IT部門(mén)由開(kāi)發(fā)、QA、運(yùn)營(yíng)團(tuán)隊(duì)組成每個(gè)團(tuán)隊(duì)專(zhuān)注于不同的分工和角色。

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

管理層過(guò)高預(yù)期 

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

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

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

認(rèn)識(shí)到問(wèn)題 

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

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

開(kāi)發(fā)和運(yùn)維如何平衡 

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

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

DevOps 已死，SRE接力 

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

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

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

以?xún)杉掖笮徒鹑跈C(jī)構(gòu) Vanguard 和摩根士丹利為例，它們?cè)谙蚋嘣圃鷮?shí)踐過(guò)渡時(shí)發(fā)現(xiàn)難以平衡開(kāi)發(fā)和運(yùn)維之間的職責(zé)。

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

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

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

相反，Yakomin 希望鼓勵(lì) Vanguard 開(kāi)發(fā)人員和運(yùn)營(yíng)專(zhuān)家分擔(dān)安全責(zé)任，并確保擁有共享平臺(tái)的團(tuán)隊(duì)為他們承擔(dān)全部運(yùn)營(yíng)責(zé)任。

平臺(tái)工程：讓人直呼萬(wàn)歲 

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

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

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

寫(xiě)在最后 

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

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

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

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

?