撰稿丨千山
最近，外媒Register發布了一則新聞：分析公司IDC預測，擔任系統管理員和IT運維專職的人數將大幅下降，希望這些從業者重新考慮他們的職業生涯。
孰料，一石激起千層浪，引發了大量爭議。
一、事件回顧：一切始于首個全球xOps普查
IDC公司不久前發布了其首個“全球xOps普查和預測”。該研究預測“未來五年IT專業人員的職責將發生重大轉變”。
該公司斷言：“最純粹的運維角色的IT專業人員正面臨著向更具技術性或更聚焦的角色的過渡，這些角色通常可能涉及一定程度的軟件開發工作。”
因此，IT運維職位在2022年至2027年間將以-8.2%的復合年增長率收縮。同一時期，系統管理員將以7.8%的復合年增長率倒退。
好消息是，IDC在其他職位上看到了非常強勁的增長，預測DataOps工作將增長17.9%，MLOps工作將加速增長20.1%。
IDC將DataOps角色定義為使用“技術和方法論的組合，重點關注質量，以實現一致和持續的數據價值交付，將集成的、面向流程的數據觀點與類似于敏捷軟件工程的自動化和方法論相結合。”
MLOps則被視為“簡化和自動化整個機器學習 （ML） 生命周期”，包括“管理和自動化ML數據和管道、ML代碼和ML模型，從數據引入到模型部署、跟蹤和監視”。這類從業者將采用“應用于機器學習過程的DevOps實踐原則”。
IDC的軟件開發和開源團隊副總裁Al Gillen將上述轉變歸咎于云計算。
“人口普查數據顯示，IT勞動力構成正在發生戲劇性的千載難逢的轉變，”他將不斷變化的工作世界描述為“類似于1997年至2002年期間發生的事情，當時商業互聯網和.com時代的到來顛覆了大部分企業IT建設的優先級，涌現了對于Web開發人員和網絡專家的海量雇傭潮。”
Gillen認為：“云計算的日益普及正在推動當今支持這種現代部署模式的IT團隊發生類似的轉變。”
越來越多的技術人員發現自己處于IDC所描述的“混合角色，將傳統的開發活動與之前運維專業人員相關的活動結合起來。而在過去，這些運維專業人員很少或根本沒有以開發為導向的責任。”
在此前提下，這篇報道呼吁“系統管理員們盡早擦亮代碼技能，因為這關系到未來工作的著落”。
二、群情激憤：槽點滿滿，不知從何說起
由這篇報道引發的爭議主要集中在以下三點：如何定義“更具技術性”；所謂“xOps”是否被濫用了；開發和運維角色的重疊真的是時代所趨嗎。
爭議一：關于技術性。
來自IDC的論斷：“最純粹的運維角色的IT專業人員正面臨著向更具技術性或更聚焦的角色的過渡。”
對此，有人一針見血地揭示了其中隱藏的傲慢：“這聽起來好像他們不認為系統管理員/運維人員是技術性的!”
還有人進行了對比，指出了所謂什么叫“更技術性”。
“按照一份21頁的MS Word文檔安裝Unix服務器和所需的所有軟件，再加上安全加固，仍然是一項相當技術性的工作。”
而“用Jenkins / Ansible(或Puppet/Chef)和你寫的少量Python腳本做同樣的事情是‘更技術性的’。”
更矛盾的是，“這種轉變已經發生了一段時間，這就是為什么很大比例的“系統管理員”角色被DevOps / SRE取代的原因。奇怪的是，他們正在‘預測’一件已經發生的事情。”
爭議二：關于“Ops”的濫用。
IDC將DataOps角色定義為使用“技術和方法論的組合，重點關注質量，以實現一致和持續的數據價值交付，將集成的、面向流程的數據觀點與類似于敏捷軟件工程的自動化和方法論相結合。”
Gartner研究副總裁Nick Heudecker曾表示：“DataOps是一種沒有任何標準或框架的新實踐。”像DevOps一樣，DataOps也不是一成不變的教條，而是一種基于原則的實踐，會影響如何提供和更新數據以滿足組織數據消費者的需求。
因此IDC給出的這個定義被很多網友認為充斥著照本宣科的“盲信”。甚至有人直接“毒舌”道：“IDG公司的人肯定是喝醉了，或者他們是讓ChatGPT編寫的材料？”
還有人指出，這種“xOps”的命名法存在著濫用概念的嫌疑。
“他們所做的只是注意到‘DevOps’這個名字的持續流行，并意識到你也可以把‘Ops’這個詞放在其他東西后面，因此他們開始使用DataOps, MLOps和xOps，不管這是什么不知所云的廢話。看起來他們已經認識到這樣一個事實——如果你在電腦上做一件事，你必須知道如何操作電腦。我可以想象，如果我認識的一些與我年齡相當的DBA被告知他們現在正在做‘DataOps’，因為它更‘現代化’，他們會有什么反應。”
爭議三：開發和運維角色的重疊到底是不是時代發展的必然。
固然IDC信誓旦旦地將開發和運維角色的混合視為必然，甚至將其歸因于云計算的發展。但多數人還是堅持兩者都有其不可替代性，而且有人指出這種混合有人為誘導的因素。
“雖然在過去的5-10年里，開發和運營重疊的部分越來越多，但無論哪一邊都依然具有其專業性。這兩類技能的重疊，如果能導向兩個部門更融洽的合作，那么公司必然會從中受益。而大多數試圖徹底合并或消滅其中一個陣營的公司往往會（在一地雞毛后）發現，為什么這兩個群體的人擁有不同的技能和經驗。”
還有個將自己形容為“有點憤世嫉俗”的網友表達了自己的見解：“一些SRE、DevOps人員的出現在某種程度上可能是一部分管理層或者HR只不過是出于縮減人力成本的想法，強行將2個人的工作歸并給1個人，比如將開發工作丟給已經負擔過重的IT運維人員，或者試圖讓開發人員在他們的空閑時間‘做運維’，通常都是這樣。”
“我相信一定會有一些非常有天賦的人能夠同時做好開發和運維工作，并且同樣有動力高水平地完成這兩項工作。但我懷疑，我們中的許多人更傾向于一邊，在緊要關頭也可以做另一邊，但更愿意把它留給專門從事這方面工作的人。”
“我所認識和共事過的最好的系統管理員可以很好地在一個由多種技術人員組成的團隊中工作——無論他們是開發人員、DBA、網絡管理員、網絡管理員、QA等等。他們通常會放大其他人的生產力。對我來說，成功就是讓別人有可能完成自己的工作，而不是替代別人完成自己的工作。”
其實DevOps這樣的概念已經在爭議中浮沉了許久，以至于我們可以看到不少失敗的案例。有的公司不遺余力搞DevOps，結果是花了大量的資金、人力、時間，卻沒有獲得期許的收獲，有些優秀的IT老兵也在這樣的挫折中迷失方向，事實上公司發展的某些部分也在這樣的實踐中倒退了。正如有位從業者總結的“我想問題（通常情況下）是人，而不是技術，或者是方法論。在我看來，試圖將DevOps概括為事實上的改進并不是一件確定的事情。”
三、為什么DevOps人員難招？
曾經，DevOps被很多公司視為加快交付、加速創新的圣杯，如今IDC的報告又再次將這類“xOps”概念推上風口浪尖。
但是事實上，并沒有多少人可以概述所謂DevOps專家所需的標準技能。這里有個關鍵問題：是否存在真正的DevOps技能短缺？
這一問題甚至在DevOps subreddit上一度成為熱門話題。在眾多開發者、技術專家的討論中，呈現出如下結果：
- 的確存在 DevOps 困境。我們所理解的是DevOps的含義及其實踐對于不同的公司可能有所不同。因此，關于DevOps的定義仍然存在兩難境地。隨著我們進一步挖掘，沒有一套通用原則來實現DevOps。
- 當談到 DevOps 時，許多人不知道從哪里開始，而其他人則無法找到這樣的工作，但那些稱自己為專家的人甚至不知道基本的東西。在某些情況下，由于成熟公司需要維護現有環境和遺留應用程序，因此很難在現有公司中建立 DevOps 實踐。這使得工程師很難掌握現代 DevOps 實踐和工具。
- 對于初創企業來說，DevOps 實踐是可能的，但前提是他們設法讓有能力的技術人員盡早參與進來，并且從一開始就使用正確的工具。
- DevOps 技能組合存在巨大的差距/短缺。希望雇用DevOps工程師的公司尤其感受到這種技能短缺。根據《財富》雜志的一篇文章，對于經驗豐富的DevOps工程師來說，高薪并不罕見，但經驗是關鍵。文章提到，要成為一名成功的DevOps工程師，至少需要五年的各種IT角色經驗。例如，你不可能直接從學校出來就知道如何使用Puppet，Ansible和Docker，也不能知道如何編寫自動化腳本。由于這種體驗非常重要，因此會導致DevOps人才短缺，這也是為什么公司很難找到合格的DevOps工程師候選人。
四、DevOps的終局到底會如何
一方面，DevOps在實踐中的困難客觀存在。今年在CD基金會和SlashData的最新調查中，絕大多數開發人員（84%）表示他們參與了DevOps活動。但盡管如此，在過去的兩年半里，開發人員在進行代碼更改并將其投入生產方面并沒有變得更快。尤其需要注意的是：開發人員使用的自托管工具越多，在事件發生后恢復服務所需的時間就越長。
另一方面，也有人堅持認為，為了在云原生世界中取得成功，組織需要DevOps和SRE，也確實在尋找脫困之法。Puppet的2023年DevOps現狀報告發現，平臺工程使DevOps成功的機會成倍增加。盡管關于平臺工程的定義仍在不斷發展，但平臺工程在設置標準工具和流程以加速開發方面的作用被認為是DevOps從單體式計算過渡到基于微服務的云原生計算的非常有用的橋梁。當然也有人認為，“平臺工程”不過是又一個被營銷誤導的概念。
DevOps到底終局會如何？專業的運維人員到底是否會“轉向”？一切尚需時間的驗證。
參考鏈接：
https://forums.theregister.com/forum/all/2023/06/08/idg_it_jobs_census/
https://thenewstack.io/why-it-is-difficult-to-hire-for-devops/
