关于云时代下运维职业的一些思考

概述

最近我在朋友圈看到过好几篇“炮轰”运维或其子领域工作前景的文章，如《是时候让运维集体下岗了》和《别干运维了，转行吧》《你怎么还在招聘DBA》等，其主要观点大致集中在这几点：

• 公有云的发展和流行直接消灭了很多运维的工作需求和岗位需求。

• 运维的能力不足以完成其所“吹嘘”的职责，其价值低于其成本。

• 研发人员完全有能力搞定云原生时代下剩余的“一点点”运维工作了。

简而言之：“事少了”，“能力不够”，“能够替代”，我对此有一些不同的看法，一家之言，姑且听之。

注：

1. 本文是对我认为的“炮轰”“暴论”的回应，所以难免也会有不少“暴论”掺杂其中，不喜勿喷。

2. 本文观点是从我的知识，技能，认知水平，过往经验，眼界视野总结得出，难免有一些疏漏和错误，欢迎指正，我会非常感谢。

3. 本文存在恰当或不恰当的比喻或类比，不喜勿喷。

4. 本文所有观点仅代表我个人浅薄的水平，不代表其他人。

首先，先说我的结论吧：

• 运维确实是在最近十年间受到新技术的发展带来的巨大冲击，有很多未能持续学习的传统运维失去了活力和市场竞争力；

• 运维并未消亡，可预见的未来也不会消亡；

• 运维需要不断学习和更新自己的知识技能以保持与时代同行。

运维是什么

在讨论运维是否没前途时，我想我们首先要对齐一个概念，就是咱们所谓的“运维”到底是什么，包括哪些具体的岗位。以下几张图分别是从Boss直聘、猎聘网、阿里巴巴招聘官网、字节跳动招聘官网找到的关于运维的岗位招聘需求：

包括2022年中国互联网综合实力TOP10的公司招聘网站我都查看了一遍，其运维通道设置主要分为如下几个细分通道：

• 系统运维：主要是Linux OS及在Linux上部署的开源软件运维

• 业务运维：有些也叫SRE，主要面向业务服务运维及云原生组件、容器云等

• 网络运维：主要包括DCN、DCI及SDN/NFV

• DBA：开源数据库运维管理

• CDN运维：CDN系统

• 运维研发：各类运维系统研发，例如监控、告警、CMDB、作业系统等等

• 基础设施运维：包括IDC、服务器、网络设备

• 网络安全：部分公司会把网络安全归类到运维通道

• 大数据运维：部分公司会将大数据运维归类到运维通道

• IT运维：办公园区网络和资产、Helpdesk、Windows运维、邮箱系统运维等

有意思的是，不同于阿里巴巴和腾讯把运维归类到“技术”大类，字节跳动是将运维归类到“研发”大类，类似的还有快手，其将运维放置在“工程类”（对应的是“算法类”）中。另外需要注意的一点是，除了物理基础设施以外，绝大多数运维相关招聘岗位JD或多或少都有一些对开发的要求，而有些岗位工作量干脆就是已经开发为主，运营维护为辅了。

从这些专业招聘网站及互联网公司招聘官网来看，运维仍然是很多公司的需求岗位，并且是一个单独的技术通道。我们姑且认为运维就是一种IT技术通道，其包含了以上说的各类子通道的岗位。

而前文提到的几篇“炮轰文”中，对运维的理解就很狭隘。咱不是说没做过运维就没资格评价运维，而是你多少也好好研究一下你喷的到底是个啥吧。很好奇作者的年龄多大，给我的感觉感觉是个互联网老古董一样，对运维的理解还停留在“网管”的阶段。

如同研发在不断更新迭代自己一样，运维也是在不断更新自身的职业内涵啊。

就拿web开发来说，二十几年间变了多少，从web 1.0，到web 2.0再到现在的web 3.0，从HTML到CGI，再到PHP，ASP，JSP，再到后面js，ts等等，现在都玩出花来了，那为啥你会觉得运维就是在原地踏步呢？

运维领域，拿我们熟知的网络来说：

• 00年到10年，做网络的基本就是思科那一套：路由交换、Voice、wireless、security等等

• 后面发现，网络厂商去做网络功能，总是不灵活，只能在他们的既定框架下做一个CLI仔，无法定制化需求，迭代周期也很长。SDN/NFV开始慢慢流行起来，有了underlay和overlay分层，在服务器上搞各种NFV，再来个顶层网络编排器进行编排，哇，特别灵活，各种各样的网络功能都可以实现，各家公有云不就是这样来的吗，NATGW，IGW，LB等等

• 再到后来发现，SDN/NFV好用是好用，但是一来性能相比网络设备较差，二来老是死磕服务器CPU。就出现越来越多的加速技术，各种kernel-bypass技术，比如DPDK将网络协议栈上提到用户态，RDMA下沉到网卡硬件上去。再随着智能网卡、DPU的流行，各种offload，datapath卸载还不满足，连control path都卸载，这样可以提供裸金属服务器了。再到后来，P4出现了，直接连数据面转发行为都可以自定义了。仔细想想，一个做网络的运维，是不是也在与时俱进？

• 就算是最传统的数据中心网络，那也是一直在推陈出新啊，我们上学时学到的BGP仅用于大公司，大运营商互联互通，现在根据RFC 7938，BGP在Data Center里面大行其道了。原来最常见的思科752架构，也逐渐被CLOS/Spine-Leaf架构取代。更不用说RDMA网络，IB网络等。

相关岗位案例：

专业的人做专业的事情

社会分工趋势是越来越精细，越来越专业。老一辈的互联网人，既做产品，又做开发，又做运维，甚至连运营、资本、HR、财务、行政的事情都做了，一来是那时候公司小，人人必须身兼多职；二来是那时候市面上符合要求的人才也不多；三来那时候对效率的要求不如现在高，竞争也不如现在激烈。

后来慢慢的，各大职业通道都出现了细分：

• 开发分为了前端开发，后端开发，客户端开发，基架开发，还有更细的，web开发，中间件开发，iOS开发，云原生开发，甚至会按语言再次细分。

• 数据通道慢慢细分出数仓、数开、数分、数据架构、大数据运维等。

不止技术，其他职业通道也是如此，例如：

• HR也细分成六大职能模块：招聘、培训、薪酬、绩效、组织规划、劳动关系管理。

• 设计细分成视觉设计、网页设计、平面设计、3D设计、交互设计、原画师、插画师、漫画师等

总结来说，就是专业的人做专业的事情，其他相关的事情非不能也，实不为也，就好比其实你也会打扫卫生，但是你不会想着让公司把保洁阿姨辞退了，为什么呢？我输出一个暴论：你抢这块的活，恰恰说明这块活有价值。

既然专业细分是一个客观事实，咱们再看看大家在选择职业和岗位时，会考虑哪些内容。一般来说除了会考虑个人能力外，多多少少也会考虑个人兴趣。单从兴趣来说，我想大多数开发者之所以选择开发这个岗位，就是喜欢搞开发，就是喜欢做业务，就是不喜欢和底层资源打交道。如果我是一个开发，我关心的肯定是业务逻辑，服务性能和稳定性，怎么会去关注底层资源的生命周期，水位等呢？你让我去学习公有云文档，去管理底层资源，我愿意吗？即使我愿意了，当业务规模越来越大，IaaS管理的工作量越来越多，占到我工作的全部了，是不是我也完成了岗位的转变，从一个研发变成了一个研发团队内的运维？等到这个工作量大到需要一个团队去做时，该团队是不是变成了一个研发团队内的运维团队？

至于公有云是否可以将运维管理相关工作量降到可忽略不计的地步，开发者是否可以通过阅读公有云文档和借助terraform等IaC工具就能够达到专业运维的大部分能力，接下来我们继续说。

云的使用需要心智

公有云使用有门槛，各家云都有相关认证，比如AWS的，可以看出，虽然公有云确实方便，快捷，但是想用好公有云，还是需要学习的，学习自然就需要心智和精力付出。

甚至，可以这样说，很多运维人员，也不能把公有云用得非常好，所以各家云也都有原厂解决方案架构师SA（Solution Architect）和TAM（Technical Account Manager），甚至还有各产品的产品SA，产品TAM，比如网络SA，网络TAM。这些人算是公有云专家了吧，然而他们就能把自家云的产品全都用好吗？非也，他们收到工单，有时候也得往后透传到产研处理。而这些专家，会经常去给大客户进行培训，一是本身这些就是可以卖钱的，AWS的business support，enterprise support不便宜吧？另外也是赋能用户，增加B端用户黏性。

公有云的文档也是大坑，这个真的用过云，去看过他们文档，照着他们文档做开发时就有感触，不过多说了。

公有云 + terraform等工具不能代表所有

“我用云服务+terraform，只需要28分钟就可以完成满足需求的配置”，问题是我一个运维用“云服务+terraform，也只需要28分钟就可以完成满足需求的配置”啊！前面的“需求输出”的过程你是一点都不提啊！难的从来都不是基本的资源生命周期管理，而是决策过程。

对一个研发人员来说，怎么写出这个IaC脚本(姑且称之为脚本吧)呢，首先你需要了解公有云的基础概念，还要有相关的知识去辅助决策。

• 需要了解VPC是什么吧？AWS的VPC特性，GCP VPC的特性，都是不同的，该怎么选择？

• VPC怎么规划CIDR，怎么规划Subnet，怎么规划安全组，ACL，各类GW？

• 在国内开发，代码怎么push到海外VPC中去？如果被墙了怎么办？

• 要不要做多云容灾？怎么做？

• VPC怎么和其他VPC互通？怎么和其他公有云VPC互通？

• 当我的业务要面向中东用户时，我需要在哪个云的哪个Region创建这个VPC？

• 是否需要上CDN？上动态还是静态CDN，用哪家？

• 用x86还是arm？

• 用Debian系还是Redhat系？

• 新发布了C6实例，新发布了GP3盘，加量降价，要不要升级？

OK，就算这些你都会，那其他研发人员都会吗？即使所有研发都会，都研发一把梭，爽到爆，那么，古尔丹，代价是什么呢？

在一个组织内，如果没有人管理决策，那就必然走向完全地失控：

• 你terraform 的AKSK是谁给的，是所有研发用同一个，还是人手一个？怎么管理？

• 开通资源需要审批吗？每个人有Quota吗？需要定期去review资源利用率吗？需要做账单整理输出吗？

• 每个人的风格不一致，大家都按自己的想法来规划基础设施，后续出现冲突怎么办？比如IP CIDR Overlap问题

• 成本失控怎么办？

当然，这些问题，你可以通过去开发并维护一个IPDB，IPAM、CMDB、FinOps、流程平台之类的系统去进行管控，或者单独设置一个或多个人去管控，那么恭喜你们，你们成功成为一名运维了。

所以要问我公有云+terraform能不能取代运维，我的回答是：现在还不能

就像有些人看了一些自媒体文章或者自己体验了一下ChatGPT之后， 开始无脑跟风：“ChatGPT将取代程序员”，各位研发朋友们听到这个也会会心一笑或者嗤之以鼻吧？为什么会这样呢，我想可能的原因有几个：

• 你会觉得这些人根本就不懂程序员是干嘛的，也并不懂ChatGPT，说这种话只能说明他是个外行，让人笑话

• 即使是程序员要被人工智能替代，那也会是一个相当长的过程，当前的人工智能远未达到那个水平

公有云+terraform等IaC工具取代运维同理。典型的盲目从众谬误。

可能说到这里，有些人要问，你这些问题都可以归结为你的架构不够先进，不够云原生，你如果全部采用云原生，就不会有这些问题。

说到这个，要知道，在任何一家公有云上，云服务器（ECS、EC2、CVM等）都是销售额最大的产品。说明即使是在公有云上，依然有非常多的公司架构没有云原生化。正如这世上没有一个普世价值观，同样也没有一个适用于所有公司所有业务的技术架构。架构的形成是跟很多因素有关，指望上公有云就毕其功于一役太妄想了。

再说了，就算有这样一个完美架构，更新、迭代、演进到该架构难道是不需要成本的吗？那请求你们先把IPv4全部替换成IPv6，把所有HTTP升级到HTTP3.0再说吧。

公有云的问题

坑爹的云计费

除了产品本身使用是有门槛的以外，控制云上费用（FinOps）也需要极大的投入，相信下面这张图很多人都看过

偶尔也能看到一些新闻：“一夜醒来，公司破产了，原因竟是因为它！”之类的，比如下面的新闻：上云2小时烧掉近50万，创始人：差点破产，简直噩梦

我自己也有过这样的经历，开了实例忘记关了之后，等到账户里面开始欠费了才知道。可以说，没在云上计费踩过坑，用云经历是不完整的。

别说我蠢，我想如果一个事情已经有很多人吐槽，甚至形成了表情包等，那肯定不是我蠢，而是它就是有问题的。下面是某位AWS用户总结的AWS数据传输成本示意图，当然，这个图已经是2017年的老图了， 不知道现在AWS各种策略有没有更新，大致能反映出情况来，其关于流量的计费规则很复杂，实际上在和AWS SA交流的过程中，你会发现他们原厂的人也没法全都搞清楚自家的产品计费规则。这也不是孤例，再去看看对象存储的计费规则，看得头疼。。。

不知道各位有没有收到过AWS的月度账单，我收到过，一个60MB大小的Excel文件，约14万行。。。

公有云很贵

两个例子：

其一：AWS 通用型SSD（GP3）存储0.08USD/GB/月，也就是一块1TB SSD，一个月大概570人民币，然而一块三星980 Pro 1TB SSD 699元。。。你跟我说公有云不贵或者是贵有贵的道理？我就问你，如果有一个房子的租售比可以达到1:1（1个月的租金就可以买下这套房子），但是它有不带学位，不能落户，水电费比较贵，没有专人服务等种种缺点，你会不会买？

其二：咱再看看EC2之类的，假设在云上开10000台32 vCPU，128G内存，2TB SSD的云服务器，咱们大致算算在IDC要多少钱：

在AWS上呢？看下面几个图：

按需实例，8978元/台/月，1万台，5年合计53.8亿元

一年SP，3519元/台/月，1万台，5年合计21.1亿元

三年SP，2580元/台/月，1万台，5年合计12.38亿元

你可能想说，我还有商务账单折扣，我还有EDP折上加折，我只能说

• 你敢保证你的折扣会一直保持下去吗？

• 这些折扣没有代价吗？公有云引以为傲的弹性是不是被这些折扣阉割了？

• 我上述计算IDC每一项都按多了算的，实际可以做到更低

• 注意，IDC中提供的是物理CPU哦，如有必要，一套容器云上线，来个1:2超卖，瞬间资源翻一倍，或者是保持虚拟资源不变，资本支出可以少一半。

我们举的这两个例子，其中EC2是每家公有云销售额最大，但利润相对较低的产品，你再想想RDS等产品，那定价，那利润率，只能说啧啧了。

原因是啥？公有云怎么赚钱？时分复用？IDC内私有云到一定体量也可以做到时分复用啊。公有云的工程师薪水多高大家又不是不知道，福报厂光一个基础设施事业群就养上千人，你不会以为这个钱是人家做公益吧？羊毛出在羊身上这个道理总该懂吧。

其实还有很多公有云很贵的例子，很多人论证过了，我不多说，只说几个下云的例子：

• 心脏跳动曾经是福报厂云第一大客户，下云了，内部能力溢出，自己开始做公有云

• 拼夕夕曾经是鹅厂云第一大客户，在下云，把原鹅厂TEG原班人马挖过去了

• 某直播，鹅厂生态内的公司，下云了

• 还有最近的37signal等等

可能你要说，你说的这些不就是因为案例少吗？大家经常看到公有云发的pr文，帮助某某某企业全量上云，而我们确实很少看到有企业说自己下云的news？有没有想过为什么？说到这点不得不说一说公有云的舆论优势了。

公有云本身在这多年以来就一直不断地舆论轰炸，营造一种云=公有云，用云=技术先进、架构领先，不用云=落后、保守、封闭的认知，公有云是有很强的动力去不遗余力的宣传这些的，而对下云的公司来说，宣传这些不仅没什么收益，还可能被公有云的拥趸们口诛笔伐，引来不必要的麻烦，索性就不宣传。

公有云垄断风险

两个案例：

• 某TOP云厂商在2022年，中国区因为内部问题将某超大partner踢出合作清单，给客户2个月时间做决策更换partner，两个月时间，够迁移吗？不够。重新选择partner，那必须得重新进行商务谈判，而你需要注意的是，此时你已经是“老用户”了，不再是从其他云或者IDC迁移来的“尊贵的新用户”，可想而知商务谈判过程有多艰难，在此过程中，确实就有某个大客户把官司打到这家云厂商的Global去了。深耕某家云厂商，做架构深度匹配，用好云？笑死，上赶着去当冤大头我还是第一次见。

• 犹记得2019年的时候，全球供应链硬是找不到SSD，想买几千片都难，一问供应商原因，答曰：某TOP云厂商全球扫货，因为量大，虽然价格比卖给你们低一些，我们也愿意全都供货给他。你就想吧，等公有云更进一步，最极端情况下垄断所有IT基础设施的时候，会是什么场景？你以为供应链降价了，云厂商就会降价？笑死，我敢打赌是吃了上家吃下家，把老客户当韭菜。

终于卷不动了，AWS家的交换机要用6年！

三大云厂商都宣布延长设备使用年限

你看，他们省了几十亿美元成本，给你降价了吗？2006年的残渣，还在薅你羊毛呢。

公有云SLA

另外也想谈谈SLA，有些人总是会说公有云贵有贵的道理，公有云SLA高啊。

SLA重要不重要？身为一个运维，SLA当然重要，那我们为什么不把SLA提高到100%，因为做不到。那为什么我们不把SLA提高到99.99999999999%，因为成本太高，你也知道还有成本这个考虑因素啊？很多中小型公司如果觉得不需要那么高的SLA怎么办？公有云能提供吗？我就在过往工作经历中遇到过两次被要求在夜间把所有服务器全都关机，第二天早上再开机的案例🤣。。。

另外云SLA到底是个什么玩意儿？看看AWS EBS SLA，99.9%，来，感受一下，三个9的暴击，你是否遇到过整个EBS盘不可用， 数据全丢的故障？我遇到过多次。我向AWS SA请教过，这个99.9%的SLA怎么理解？SA答：你买1000块盘，一年允许坏一块。（AWS SA说的，别喷我）

再看看过去几年各大公有云发生的超大型故障，SLA神话已经不攻自破了吧？宣称的SLA达到了，很大程度上是依赖运气：就是恰好在这个期间，基础设施没发生故障而已。我一个普通运维，其实也可以什么都不做，宣称自己的SLA和公有云一致啊，你信不信，有时候确实是可以达到。

另外，公有云SLA承诺，就好比快递保价费一样，真出事儿时没啥用。咱们常说数据是无价的，就好比说生命无价一样，但是实操的时候是有价的。你数据丢了，你出现故障了，公有云承诺的SLA没达到，你去翻翻赔偿标准，看他赔你多少钱。2018年那次某云丢数据已经证实了，只赔“快递费”，“保价费”，你把事情闹大了，再赔一些“人道主义赔偿”，仅此而已。

公有云产品演进

我印象中比较深的还是网络产品，我2014年开始用AWS，当时就有AWS VPC和IDC互通、AWS VPC与GCP VPC互通的需求，当时AWS只有两款用于VPC互通或与外界互通的产品：

• AWS VPC Peering

• AWS IPSec VPN

但是它不能满足我的需求，我要的是如下需求：

• VPC与IDC高速互通

• 星型拓扑结构，多个VPC互通（不要full-mesh）

• 可以自动规避故障，例如GCP VPC1@Tokyo 与 GCP VPC2@SG互通故障时，可能走GCP VPC1@Tokyo ——> AWS VPC1@Tokyo ——> AWS VPC2@SG ——> GCP VPC2@SG路径

致使我不得不在各个公有云上打洞，现在想起来都是泪。

到了2017下半年，AWS终于推出了DX产品，可以跟IDC高速互通了，这个产品2018年才在全球所有region上线。后来又出现了Transit GW产品支持星型拓扑了，后来不知道是否有自动规避故障的产品，我想可能比较难，毕竟是要和其他云联动。

说这个是想说明，云上产品不一定能覆盖所有场景，如果恰好你的业务场景需要某个产品支持，而该云没有怎么办？提需求给他们之后干等着吗？这是不是有点回到了当年网络设备厂商不满足某项网络功能虚拟化功能时，我们向其提需求一样？

运维岗位的发展

云的发展确实对整个运维通道的岗位冲击很大，各位同行们，发挥我们的优势，持续学习，保持竞争力啊：

• 做懂业务的运维

• 做懂研发的运维

• 扩展运维的职能

拿网络运维（因为我最熟悉）来说，现在提到网络，你还只知道VLAN，生成树，还在天天捣鼓OSPF，那你确实没啥竞争力了啊兄弟！不去搞SDN/NFV研发，好歹也学些NetDevOps，看看知乎上的弈心的文章。与时俱进啊兄弟们，人家研发都来砸你饭碗了，还不快觉醒起来！

一些题外话

我其实很不喜欢这种大字报式的炮轰文，因为充满了傲慢与偏见，各种逻辑谬误。

举两个例子：

《别干运维了，转行吧》

这篇文章中的“运维从业者用各种借口延续这个过时岗位的寿命，虽然可以理解，但不是一个明智的选择”，这就是典型的逻辑谬误，首先已经预设了立场：我说的是对的，我代表先进，代表生产力的发展方向，所以你任何反驳我观点的话都是“借口”。再比如那个萨达姆的例子，潜台词无非就是你们运维现在就是萨达姆，你不肯听从我们的苦口良言，善意批评，你就是不愿意接受现实，你最终就会像萨达姆一样灭亡。这难道不是一种傲慢吗？就给我一种很“美国”，很“西方”的感觉。

为什么DBA不是一个好的职业选择

这篇文章最末尾褒OpenAI而贬37signal，这也是一种逻辑谬误，这两家公司的生意和RDS下云有个毛线关系啊，典型的归因错误。就好比美国天天枪战，同时美国GDP一直在增长，所以美国的GDP增长是因为天天枪战。这不扯淡吗。。。。37signal不做下云的事情，他就可以变成OpenAI吗？

另外我也旗帜鲜明的反对这种对服务于中小型企业的公司的贬低，如同人一样，每个组织也是有使命、愿景和禀赋的差异，世界是多元的。我认为一个公司，如果能够为其用户创造价值，为其股东创造利润，为其员工按时按量的发放薪水，能够持续运营下去，那么他就是一个好公司。当然，如果在这个基础上，这个公司还能产出一些对整个人类，整个世界都有意义的价值，那么这是一家伟大的公司。从这个视角来看，我并不认为OpenAI就比37signal高贵。再说了，如果每个公司都去做OpenAI，那么谁来做这些和人类其他需求相关的事情呢？就你是圣人，做和人类基本需求有关的就是low，做人工智能相关的事情就是高大上，就是牛是吗？要知道，人类是社会性动物，必然是有分工的。就好比一场考试中，不可能所有人都高于平均分。

最后，相同的话也送给该作者：身为研发，就好好做研发，要么好好的开发出为公司创造利润的业务，要么好好的开发出ChatGPT这样牛逼的划时代产品，别总盯着别人的仨瓜俩枣，一会干掉这个，一会灭掉那个。