撰稿丨千山

最近，外媒Register發(fā)布了一則新聞：分析公司IDC預(yù)測(cè)，擔(dān)任系統(tǒng)管理員和IT運(yùn)維專職的人數(shù)將大幅下降，希望這些從業(yè)者重新考慮他們的職業(yè)生涯。

孰料，一石激起千層浪，引發(fā)了大量爭(zhēng)議。

一、事件回顧：一切始于首個(gè)全球xOps普查

IDC公司不久前發(fā)布了其首個(gè)“全球xOps普查和預(yù)測(cè)”。該研究預(yù)測(cè)“未來五年IT專業(yè)人員的職責(zé)將發(fā)生重大轉(zhuǎn)變”。

該公司斷言：“最純粹的運(yùn)維角色的IT專業(yè)人員正面臨著向更具技術(shù)性或更聚焦的角色的過渡，這些角色通?？赡苌婕耙欢ǔ潭鹊能浖_發(fā)工作。”

因此，IT運(yùn)維職位在2022年至2027年間將以-8.2%的復(fù)合年增長(zhǎng)率收縮。同一時(shí)期，系統(tǒng)管理員將以7.8%的復(fù)合年增長(zhǎng)率倒退。

好消息是，IDC在其他職位上看到了非常強(qiáng)勁的增長(zhǎng)，預(yù)測(cè)DataOps工作將增長(zhǎng)17.9%，MLOps工作將加速增長(zhǎng)20.1%。

IDC將DataOps角色定義為使用“技術(shù)和方法論的組合，重點(diǎn)關(guān)注質(zhì)量，以實(shí)現(xiàn)一致和持續(xù)的數(shù)據(jù)價(jià)值交付，將集成的、面向流程的數(shù)據(jù)觀點(diǎn)與類似于敏捷軟件工程的自動(dòng)化和方法論相結(jié)合?！?/p>

MLOps則被視為“簡(jiǎn)化和自動(dòng)化整個(gè)機(jī)器學(xué)習(xí) （ML） 生命周期”，包括“管理和自動(dòng)化ML數(shù)據(jù)和管道、ML代碼和ML模型，從數(shù)據(jù)引入到模型部署、跟蹤和監(jiān)視”。這類從業(yè)者將采用“應(yīng)用于機(jī)器學(xué)習(xí)過程的DevOps實(shí)踐原則”。

IDC的軟件開發(fā)和開源團(tuán)隊(duì)副總裁Al Gillen將上述轉(zhuǎn)變歸咎于云計(jì)算。

“人口普查數(shù)據(jù)顯示，IT勞動(dòng)力構(gòu)成正在發(fā)生戲劇性的千載難逢的轉(zhuǎn)變，”他將不斷變化的工作世界描述為“類似于1997年至2002年期間發(fā)生的事情，當(dāng)時(shí)商業(yè)互聯(lián)網(wǎng)和.com時(shí)代的到來顛覆了大部分企業(yè)IT建設(shè)的優(yōu)先級(jí)，涌現(xiàn)了對(duì)于Web開發(fā)人員和網(wǎng)絡(luò)專家的海量雇傭潮?！?/p>

Gillen認(rèn)為：“云計(jì)算的日益普及正在推動(dòng)當(dāng)今支持這種現(xiàn)代部署模式的IT團(tuán)隊(duì)發(fā)生類似的轉(zhuǎn)變?！?/p>

越來越多的技術(shù)人員發(fā)現(xiàn)自己處于IDC所描述的“混合角色，將傳統(tǒng)的開發(fā)活動(dòng)與之前運(yùn)維專業(yè)人員相關(guān)的活動(dòng)結(jié)合起來。而在過去，這些運(yùn)維專業(yè)人員很少或根本沒有以開發(fā)為導(dǎo)向的責(zé)任?！?/p>

在此前提下，這篇報(bào)道呼吁“系統(tǒng)管理員們盡早擦亮代碼技能，因?yàn)檫@關(guān)系到未來工作的著落”。

二、群情激憤：槽點(diǎn)滿滿，不知從何說起

由這篇報(bào)道引發(fā)的爭(zhēng)議主要集中在以下三點(diǎn)：如何定義“更具技術(shù)性”；所謂“xOps”是否被濫用了；開發(fā)和運(yùn)維角色的重疊真的是時(shí)代所趨嗎。

爭(zhēng)議一：關(guān)于技術(shù)性。

來自IDC的論斷：“最純粹的運(yùn)維角色的IT專業(yè)人員正面臨著向更具技術(shù)性或更聚焦的角色的過渡?！?/p>

對(duì)此，有人一針見血地揭示了其中隱藏的傲慢：“這聽起來好像他們不認(rèn)為系統(tǒng)管理員/運(yùn)維人員是技術(shù)性的!”

還有人進(jìn)行了對(duì)比，指出了所謂什么叫“更技術(shù)性”。

“按照一份21頁的MS Word文檔安裝Unix服務(wù)器和所需的所有軟件，再加上安全加固，仍然是一項(xiàng)相當(dāng)技術(shù)性的工作?！?/p>

而“用Jenkins / Ansible(或Puppet/Chef)和你寫的少量Python腳本做同樣的事情是‘更技術(shù)性的’?！?/p>

更矛盾的是，“這種轉(zhuǎn)變已經(jīng)發(fā)生了一段時(shí)間，這就是為什么很大比例的“系統(tǒng)管理員”角色被DevOps / SRE取代的原因。奇怪的是，他們正在‘預(yù)測(cè)’一件已經(jīng)發(fā)生的事情。”

爭(zhēng)議二：關(guān)于“Ops”的濫用。

IDC將DataOps角色定義為使用“技術(shù)和方法論的組合，重點(diǎn)關(guān)注質(zhì)量，以實(shí)現(xiàn)一致和持續(xù)的數(shù)據(jù)價(jià)值交付，將集成的、面向流程的數(shù)據(jù)觀點(diǎn)與類似于敏捷軟件工程的自動(dòng)化和方法論相結(jié)合。”

Gartner研究副總裁Nick Heudecker曾表示：“DataOps是一種沒有任何標(biāo)準(zhǔn)或框架的新實(shí)踐?！毕馜evOps一樣，DataOps也不是一成不變的教條，而是一種基于原則的實(shí)踐，會(huì)影響如何提供和更新數(shù)據(jù)以滿足組織數(shù)據(jù)消費(fèi)者的需求。

因此IDC給出的這個(gè)定義被很多網(wǎng)友認(rèn)為充斥著照本宣科的“盲信”。甚至有人直接“毒舌”道：“IDG公司的人肯定是喝醉了，或者他們是讓ChatGPT編寫的材料？”

還有人指出，這種“xOps”的命名法存在著濫用概念的嫌疑。

“他們所做的只是注意到‘DevOps’這個(gè)名字的持續(xù)流行，并意識(shí)到你也可以把‘Ops’這個(gè)詞放在其他東西后面，因此他們開始使用DataOps, MLOps和xOps，不管這是什么不知所云的廢話?？雌饋硭麄円呀?jīng)認(rèn)識(shí)到這樣一個(gè)事實(shí)——如果你在電腦上做一件事，你必須知道如何操作電腦。我可以想象，如果我認(rèn)識(shí)的一些與我年齡相當(dāng)?shù)腄BA被告知他們現(xiàn)在正在做‘DataOps’，因?yàn)樗F(xiàn)代化’，他們會(huì)有什么反應(yīng)。”

爭(zhēng)議三：開發(fā)和運(yùn)維角色的重疊到底是不是時(shí)代發(fā)展的必然。

固然IDC信誓旦旦地將開發(fā)和運(yùn)維角色的混合視為必然，甚至將其歸因于云計(jì)算的發(fā)展。但多數(shù)人還是堅(jiān)持兩者都有其不可替代性，而且有人指出這種混合有人為誘導(dǎo)的因素。

“雖然在過去的5-10年里，開發(fā)和運(yùn)營(yíng)重疊的部分越來越多，但無論哪一邊都依然具有其專業(yè)性。這兩類技能的重疊，如果能導(dǎo)向兩個(gè)部門更融洽的合作，那么公司必然會(huì)從中受益。而大多數(shù)試圖徹底合并或消滅其中一個(gè)陣營(yíng)的公司往往會(huì)（在一地雞毛后）發(fā)現(xiàn)，為什么這兩個(gè)群體的人擁有不同的技能和經(jīng)驗(yàn)?！?/p>

還有個(gè)將自己形容為“有點(diǎn)憤世嫉俗”的網(wǎng)友表達(dá)了自己的見解：“一些SRE、DevOps人員的出現(xiàn)在某種程度上可能是一部分管理層或者HR只不過是出于縮減人力成本的想法，強(qiáng)行將2個(gè)人的工作歸并給1個(gè)人，比如將開發(fā)工作丟給已經(jīng)負(fù)擔(dān)過重的IT運(yùn)維人員，或者試圖讓開發(fā)人員在他們的空閑時(shí)間‘做運(yùn)維’，通常都是這樣。”

“我相信一定會(huì)有一些非常有天賦的人能夠同時(shí)做好開發(fā)和運(yùn)維工作，并且同樣有動(dòng)力高水平地完成這兩項(xiàng)工作。但我懷疑，我們中的許多人更傾向于一邊，在緊要關(guān)頭也可以做另一邊，但更愿意把它留給專門從事這方面工作的人?！?/p>

“我所認(rèn)識(shí)和共事過的最好的系統(tǒng)管理員可以很好地在一個(gè)由多種技術(shù)人員組成的團(tuán)隊(duì)中工作——無論他們是開發(fā)人員、DBA、網(wǎng)絡(luò)管理員、網(wǎng)絡(luò)管理員、QA等等。他們通常會(huì)放大其他人的生產(chǎn)力。對(duì)我來說，成功就是讓別人有可能完成自己的工作，而不是替代別人完成自己的工作?！?/p>

其實(shí)DevOps這樣的概念已經(jīng)在爭(zhēng)議中浮沉了許久，以至于我們可以看到不少失敗的案例。有的公司不遺余力搞DevOps，結(jié)果是花了大量的資金、人力、時(shí)間，卻沒有獲得期許的收獲，有些優(yōu)秀的IT老兵也在這樣的挫折中迷失方向，事實(shí)上公司發(fā)展的某些部分也在這樣的實(shí)踐中倒退了。正如有位從業(yè)者總結(jié)的“我想問題（通常情況下）是人，而不是技術(shù)，或者是方法論。在我看來，試圖將DevOps概括為事實(shí)上的改進(jìn)并不是一件確定的事情?！?/p>

三、為什么DevOps人員難招？

曾經(jīng)，DevOps被很多公司視為加快交付、加速創(chuàng)新的圣杯，如今IDC的報(bào)告又再次將這類“xOps”概念推上風(fēng)口浪尖。

但是事實(shí)上，并沒有多少人可以概述所謂DevOps專家所需的標(biāo)準(zhǔn)技能。這里有個(gè)關(guān)鍵問題：是否存在真正的DevOps技能短缺？

這一問題甚至在DevOps subreddit上一度成為熱門話題。在眾多開發(fā)者、技術(shù)專家的討論中，呈現(xiàn)出如下結(jié)果：

1. 的確存在 DevOps 困境。我們所理解的是DevOps的含義及其實(shí)踐對(duì)于不同的公司可能有所不同。因此，關(guān)于DevOps的定義仍然存在兩難境地。隨著我們進(jìn)一步挖掘，沒有一套通用原則來實(shí)現(xiàn)DevOps。
2. 當(dāng)談到 DevOps 時(shí)，許多人不知道從哪里開始，而其他人則無法找到這樣的工作，但那些稱自己為專家的人甚至不知道基本的東西。在某些情況下，由于成熟公司需要維護(hù)現(xiàn)有環(huán)境和遺留應(yīng)用程序，因此很難在現(xiàn)有公司中建立 DevOps 實(shí)踐。這使得工程師很難掌握現(xiàn)代 DevOps 實(shí)踐和工具。
3. 對(duì)于初創(chuàng)企業(yè)來說，DevOps 實(shí)踐是可能的，但前提是他們?cè)O(shè)法讓有能力的技術(shù)人員盡早參與進(jìn)來，并且從一開始就使用正確的工具。
4. DevOps 技能組合存在巨大的差距/短缺。希望雇用DevOps工程師的公司尤其感受到這種技能短缺。根據(jù)《財(cái)富》雜志的一篇文章，對(duì)于經(jīng)驗(yàn)豐富的DevOps工程師來說，高薪并不罕見，但經(jīng)驗(yàn)是關(guān)鍵。文章提到，要成為一名成功的DevOps工程師，至少需要五年的各種IT角色經(jīng)驗(yàn)。例如，你不可能直接從學(xué)校出來就知道如何使用Puppet，Ansible和Docker，也不能知道如何編寫自動(dòng)化腳本。由于這種體驗(yàn)非常重要，因此會(huì)導(dǎo)致DevOps人才短缺，這也是為什么公司很難找到合格的DevOps工程師候選人。

四、DevOps的終局到底會(huì)如何

一方面，DevOps在實(shí)踐中的困難客觀存在。今年在CD基金會(huì)和SlashData的最新調(diào)查中，絕大多數(shù)開發(fā)人員（84%）表示他們參與了DevOps活動(dòng)。但盡管如此，在過去的兩年半里，開發(fā)人員在進(jìn)行代碼更改并將其投入生產(chǎn)方面并沒有變得更快。尤其需要注意的是：開發(fā)人員使用的自托管工具越多，在事件發(fā)生后恢復(fù)服務(wù)所需的時(shí)間就越長(zhǎng)。

另一方面，也有人堅(jiān)持認(rèn)為，為了在云原生世界中取得成功，組織需要DevOps和SRE，也確實(shí)在尋找脫困之法。Puppet的2023年DevOps現(xiàn)狀報(bào)告發(fā)現(xiàn)，平臺(tái)工程使DevOps成功的機(jī)會(huì)成倍增加。盡管關(guān)于平臺(tái)工程的定義仍在不斷發(fā)展，但平臺(tái)工程在設(shè)置標(biāo)準(zhǔn)工具和流程以加速開發(fā)方面的作用被認(rèn)為是DevOps從單體式計(jì)算過渡到基于微服務(wù)的云原生計(jì)算的非常有用的橋梁。當(dāng)然也有人認(rèn)為，“平臺(tái)工程”不過是又一個(gè)被營(yíng)銷誤導(dǎo)的概念。

DevOps到底終局會(huì)如何？專業(yè)的運(yùn)維人員到底是否會(huì)“轉(zhuǎn)向”？一切尚需時(shí)間的驗(yàn)證。

參考鏈接：

https://forums.theregister.com/forum/all/2023/06/08/idg_it_jobs_census/

https://thenewstack.io/why-it-is-difficult-to-hire-for-devops/