撰稿丨千山

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

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

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

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

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

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

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

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

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

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

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

Gillen認為：“云計算的日益普及正在推動當今支持這種現(xiàn)代部署模式的IT團隊發(fā)生類似的轉(zhuǎn)變。”

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

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

二、群情激憤：槽點滿滿，不知從何說起

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

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

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

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

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

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

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

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

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

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

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

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

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

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

爭議三：開發(fā)和運維角色的重疊到底是不是時代發(fā)展的必然。

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

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

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

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

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

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

三、為什么DevOps人員難招？

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

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

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

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

四、DevOps的終局到底會如何

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

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

DevOps到底終局會如何？專業(yè)的運維人員到底是否會“轉(zhuǎ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/