“在大多數(shù)情況下,，開發(fā)人員并不想處理運(yùn)維問題,。”亞馬遜云科技社區(qū)參與負(fù)責(zé)人,、《DevOps For Dummies》作者 Emily Freeman 在推特上坦言,。

　　一石激起千層浪。Freeman 的觀點(diǎn)引起了廣泛共鳴,，幾百條抱有同樣觀點(diǎn)的開發(fā)人員紛紛留言回應(yīng),。

　　“我就是個(gè)開發(fā)者,，我不想處理運(yùn)維問題?！笨觳凸?Chipotle 軟件工程師 Scott Pantall 直接表示,。

　　“我確實(shí)更喜歡回到只需要掌握特定編程技巧的時(shí)候，而不是現(xiàn)在這樣成為一個(gè)萬事通,，因?yàn)槎鄠€(gè)責(zé)任分散了我太多精力,。這兩者都是全職工作，而我只能各自投入一半的精力,?！遍_發(fā)者 Mitchell Abbott 說道。

　　SUSE 開發(fā)人員布道師 Andrew Gracey 認(rèn)為,，開發(fā)人員和運(yùn)維人員應(yīng)該密切合作,，同時(shí)各自扮演不同的角色，能夠讓團(tuán)隊(duì)成員相互理解的同理心才是 DevOps 的真正核心,。

　　“強(qiáng)迫開發(fā)者身兼太多任務(wù),，最終只會(huì)搬起石頭砸自己的腳。不同場(chǎng)景對(duì)應(yīng)著不同的技能組合,?！盞ubernetes 存儲(chǔ)技術(shù)提供商 Ondat 的產(chǎn)品負(fù)責(zé)人 James Brown 表示。

　　“人們慢慢意識(shí)到,，電工和水管工確實(shí)不是同一個(gè)職位,。”Harness 公司專項(xiàng) CTO Nick Durkin 說道,。

　　當(dāng)然,，也有開發(fā)者人認(rèn)為，當(dāng)自己全面負(fù)責(zé)代碼,、基礎(chǔ)設(shè)施和監(jiān)控時(shí),，通常會(huì)感到自己很有能力?！斑@就是全才和專家的區(qū)別吧,。”

　　職責(zé)“大量”增加

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

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

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

　　領(lǐng)導(dǎo)：我們希望你做開發(fā)運(yùn)維,，但我們不會(huì)將所有內(nèi)容直接給你,，您必須繞過防火墻才能獲得。哦,，是的,，我們也不會(huì)提供一種標(biāo)準(zhǔn)化的方式來訪問某些東西。

　　領(lǐng)導(dǎo)：為什么要花這么長(zhǎng)時(shí)間,？

　　我：這不是真正的開發(fā)操作。

　　領(lǐng)導(dǎo)：別那么消極,。

　　“有時(shí),，你會(huì)得到一臺(tái)被公司嚴(yán)格鎖定的開發(fā)機(jī)器（硬件加速設(shè)置已關(guān)閉并且沒有密碼無法使用，嚴(yán)格的操作系統(tǒng)安全策略禁止你從公司存儲(chǔ)庫(kù)以外的任何地方安裝軟件等）,，你不能甚至使用虛擬化,，使用這臺(tái)機(jī)器就是你進(jìn)入公司網(wǎng)絡(luò)的方式?！遍_發(fā)者“FloRup”補(bǔ)充道,。

　　同時(shí)，隨著企業(yè)軟件開發(fā)者的總體規(guī)模達(dá)到歷史新高,，大家對(duì)運(yùn)維側(cè)的關(guān)注度卻始終不高,。更可怕的是，隨著軟件開發(fā)的增長(zhǎng),，運(yùn)維工作量實(shí)際上也始終在同步攀升,。

　　正如 DevOps 工程師、前系統(tǒng)管理員 Mathew Duggan 去年的觀點(diǎn),，雖然運(yùn)維人員繼續(xù)承擔(dān)著之前的所有職責(zé),，確保應(yīng)用程序可用、受控,、安全和合規(guī),，但現(xiàn)在他們還得負(fù)責(zé)構(gòu)建和維護(hù)軟件交付管道,，確保開發(fā)人員在無需運(yùn)維介入的情況下，快速安全地發(fā)布代碼,。

　　要干的活越來越重,、要上的再培訓(xùn)課程越來越多，特別是云工程和基礎(chǔ)設(shè)施即代碼技能,，幾乎成為當(dāng)前運(yùn)維從業(yè)者們的必修課,。

　　“在我看來，情況已經(jīng)惡化到了歷史極點(diǎn),。運(yùn)維團(tuán)隊(duì)的職責(zé)范圍大幅增加,，但管理層還是對(duì)速度提出不切實(shí)際的要求，整個(gè)體系已然不堪重負(fù),?！盌uggan 寫道。

　　事實(shí)上,，壓力帶來的惡果正開始顯現(xiàn),。

　　戴爾技術(shù)資本董事總經(jīng)理 Tyler Jewell 在一份研究報(bào)告中提到，“要想建立一支能夠長(zhǎng)期,、和諧保持這種穩(wěn)定迭代水平的團(tuán)隊(duì),，其實(shí)是個(gè)巨大的挑戰(zhàn)。隨著系統(tǒng)復(fù)雜度的提升和最終用戶反饋的增加,，人們已經(jīng)很難準(zhǔn)確預(yù)測(cè)某項(xiàng)變更可能給系統(tǒng)造成的影響,。”

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

　　當(dāng)然,，情況可能并沒 Duggan 等人描繪的那么糟糕,，但對(duì)工程團(tuán)隊(duì)及其職責(zé)做出重大調(diào)整確實(shí)非常必要。

　　“轉(zhuǎn)型的目的不是要給開發(fā)人員增加負(fù)擔(dān),，而是在正確的時(shí)間為開發(fā)者提供正確的信息,。”Harness 公司的 Durkin 表示,，“開發(fā)者最需要的不是額外的配置任務(wù),，而是在正確的時(shí)間能從系統(tǒng)中快速獲取必要信息，這樣就能支持運(yùn)維,、安全和基礎(chǔ)設(shè)施團(tuán)隊(duì)的正常工作,。除非出現(xiàn)問題，否則運(yùn)維元素就不應(yīng)該出現(xiàn)在開發(fā)者的視野當(dāng)中,?！?/p>

　　迪士尼公司前企業(yè)技術(shù)戰(zhàn)略總監(jiān) Nigel Simpson 也希望公司能認(rèn)識(shí)到這個(gè)問題，并努力讓開發(fā)人員擺脫對(duì)底層基礎(chǔ)設(shè)施的擔(dān)憂,，重新回到自己最擅長(zhǎng)的軟件構(gòu)建上來,。

　　更重要的是,，DevOps 代表一個(gè)連續(xù)的統(tǒng)一體，其具體實(shí)施會(huì)因組織而異?，F(xiàn)在的開發(fā)者能做一點(diǎn)運(yùn)維,，并不代表他們就該每天都承擔(dān)運(yùn)維壓力。

　　Gartner 公司分析師 Lydia Leong 認(rèn)為,，開發(fā)人員對(duì)基礎(chǔ)設(shè)施的控制,，并不是“要么全做、要么徹底不做”的命題,。企業(yè)可以把這部分職責(zé)劃分到整個(gè)應(yīng)用程序生命周期當(dāng)中,，只有這樣“誰構(gòu)建、誰運(yùn)行”才能發(fā)揮積極作用,，而不是把開發(fā)者空降到一個(gè)他們既不熟悉,、也難以駕馭的陌生環(huán)境。

　　粗暴把基礎(chǔ)設(shè)施和運(yùn)維團(tuán)隊(duì)的問題拋給開發(fā)者,，不會(huì)帶來任何好處,。Leong 表示，更好的辦法應(yīng)該是放手讓開發(fā)人員自行訪問開發(fā)和測(cè)試環(huán)境,，并為他們賦予將基礎(chǔ)設(shè)施構(gòu)建為生產(chǎn)代碼模板的能力,。這才是重點(diǎn)，而不是讓他們?nèi)尕?fù)責(zé)生產(chǎn),。

　　在云計(jì)算領(lǐng)域,，Kubernetes 容器編排正在成為開發(fā)與運(yùn)維之間的邊界。關(guān)注這條邊界,，就能讓開發(fā)者集中于自己的代碼，并讓運(yùn)維人員確保底層基礎(chǔ)設(shè)施和管理的運(yùn)行與優(yōu)化,?！暗@種獨(dú)立是以溝通和理解作為基礎(chǔ)的，并不是以往那種孤島式的各自為戰(zhàn),?！監(jiān)ndat 公司 Brown 說道。

　　事實(shí)上,，根據(jù) VMware 公司發(fā)布的《2022 年 Kubernetes 現(xiàn)狀》報(bào)告,，776 名受訪者中，54% 的人采用 Kubertnetes 的關(guān)鍵原因就是要提高開發(fā)者效率,，另有超過三分之一（37%）的受訪者稱是為了提高運(yùn)維人員的效率,。

　　“千萬別相信那種‘人人都能成為專家’的謬論。在高效團(tuán)隊(duì)中,，其實(shí)很少會(huì)有所謂專門的 Kubernetes 專家,。這些團(tuán)隊(duì)只是通過極高的抽象度著力緩和了每位成員的認(rèn)知負(fù)擔(dān),。”Humanitec 公司創(chuàng)始人 Kaspar von Grunberg 表示,。

　　DevOps 已死

　　如果 DevOps 的時(shí)代真的走到了盡頭,，或者至少走過了輝煌時(shí)期、來到新的轉(zhuǎn)折點(diǎn),，那接下來事情將如何發(fā)展呢,？

　　站點(diǎn)可靠性工程（SRE）誕生自谷歌內(nèi)部，當(dāng)時(shí)搜索巨頭遭遇到了 DevOps 希望解決的成長(zhǎng)陣痛?，F(xiàn)在來看,，這個(gè)職位確實(shí)能有效平衡開發(fā)與運(yùn)維間的矛盾。谷歌工程副總裁,、SRE 之父 Ben Treynor 曾經(jīng)坦言,，“從本質(zhì)上講，如果要求軟件工程師設(shè)計(jì)一項(xiàng)運(yùn)維功能,，那結(jié)果就是 SRE,。”

　　以 Vanguard 和摩根士丹利兩家大型金融機(jī)構(gòu)為例,，他們?cè)谙蛑圃鷮?shí)踐過渡時(shí),，就發(fā)現(xiàn)越來越難以平衡開發(fā)和運(yùn)維兩端的職責(zé)。而 SRE 就像是緩沖層,，把它鋪在集中運(yùn)維團(tuán)隊(duì)和各開發(fā)者團(tuán)隊(duì)之間,，就能幫助各方建立信心，感受到既保持良好開發(fā)速度,、又獲得穩(wěn)定運(yùn)營(yíng)狀態(tài)的可能性,。

　　有開發(fā)者現(xiàn)身說法道，“我們有 SRE,，他們?yōu)槲覀儤?gòu)建了很好的工具并維護(hù)應(yīng)用程序的基礎(chǔ)設(shè)施,。我們?nèi)匀蛔约鹤鰩缀跛械娜粘２渴鸷瓦\(yùn)維工作，但是 SRE / 基礎(chǔ)設(shè)施團(tuán)隊(duì)已經(jīng)做得很好了,，我們只需要擔(dān)心會(huì)發(fā)生什么而不必?fù)?dān)心要如何做,。”

　　然而,，SRE 也受到過不少批評(píng),。摩根士丹利的 DevOps 和企業(yè)技術(shù)架構(gòu)負(fù)責(zé)人 Trevor Brosnan 就提到，建立 SRE 原則“有時(shí)會(huì)被誤讀為要對(duì)運(yùn)維團(tuán)隊(duì)進(jìn)行大洗牌,?！?/p>

　　“這是個(gè)需要解決的微妙問題。引入 SRE 確實(shí)會(huì)讓人有種正在再次剝離運(yùn)維團(tuán)隊(duì)的感覺?！钡聦?shí)并非如此,，Vanguard 站點(diǎn)可靠性工程師 Christina Yakomin 就一直在鼓勵(lì)公司的開發(fā)者和運(yùn)維人員分擔(dān)安全責(zé)任，并把運(yùn)營(yíng)需求整體交由共享平臺(tái)團(tuán)隊(duì)承擔(dān),。

　　平臺(tái)工程才是未來,？

　　如今，不少企業(yè)開始嘗試建立內(nèi)部開發(fā)者平臺(tái)或者平臺(tái)工程部門,，這樣既能給開發(fā)人員提供必要工具,，也能通過適當(dāng)?shù)慕M織護(hù)欄隔開其他事務(wù)對(duì)開發(fā)和運(yùn)維造成的影響。

　　內(nèi)部開發(fā)者平臺(tái)往往由大量 API,、工具,、服務(wù)、知識(shí)和支持所構(gòu)成,，目的是為開發(fā)人員提供代碼生產(chǎn)部署所必需的一切助力,。至于平臺(tái)本身，則由公司專門的專家團(tuán)隊(duì)或所有者負(fù)責(zé)維護(hù),。

　　軟件工程師兼 DevOps 評(píng)論員 Sid Palas 在推特上寫道,，“DevOps 已死，平臺(tái)工程才是未來,。開發(fā)者不想跟基礎(chǔ)設(shè)施打交道,，企業(yè)在發(fā)展過程中又需要控制自己的基礎(chǔ)設(shè)施。只有平臺(tái)工程,，能將這兩個(gè)相互矛盾的命題統(tǒng)一起來,。”

　　“平臺(tái)工程部門的實(shí)際表現(xiàn)確實(shí)不錯(cuò),，能夠在消除開發(fā)流程摩擦的同時(shí),，賦予開發(fā)者充分的靈活性?！避浖稍児?Thoughtworks 的技術(shù)主管 Brandon Byars 表示,，“一旦把這些工作硬塞給缺乏專業(yè)知識(shí)和工具支持的開發(fā)者，情況就會(huì)迅速惡化,。”

　　因此面對(duì)新的歷史階段,，要想在工程團(tuán)隊(duì)中貫徹 DevOps 原則,，組織首先需要了解怎樣在軟件開發(fā)與運(yùn)維團(tuán)隊(duì)間尋求平衡。正是因?yàn)檫@一微妙平衡點(diǎn)的存在,，才讓云原生時(shí)代的系統(tǒng)復(fù)雜性越來越高,。

　更多信息可以來這里獲取==>>電子技術(shù)應(yīng)用-AET<<