撰稿丨千山
最近，外媒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/
