GMTC北京站|50+大厂技术专家现场分享,12个大前端方向热门专题,戳此查看 了解详情
写点什么

宕机的阿里云们正在杀死运维?

  • 2019 年 3 月 06 日
  • 本文字数:3155 字

    阅读完需:约 10 分钟

宕机的阿里云们正在杀死运维?

当运维工作都能托管在云平台上解决时,运维还有以后吗?


云计算正在杀死运维吗?

近年来,关于“去运维”的相关话题甚嚣尘上,但似乎没有引起程序员的过多关注或者大范围讨论。近日,程序员论坛 V2EX 上出现一个热议话题“阿里云正在缓慢而稳步地杀死运维行业”,这似乎表明运维人员最终还是感受到了来自云计算发展带来的巨大压力。发帖者认为,“当容器服务集群、跨地域监控与容灾/保活、DBA、代码托管与 CI/CD 都能全部依托阿里云产品时,运维已经被踢出 IT 行业”。


一石激起千层浪,有人认为这只是杞人忧天,并反问“阿里云自己都刚宕机,还想说不需要运维吗?”,有人则认为英雄所见略同,还有人进一步将未来的运维阐述成“云维”。


技术的发展不能缺少埋头苦干的人,但也少不了抬头看路的人。针对这个问题,我们想跟大家聊聊,究竟云计算的发展,是否会造成运维岗位的消亡?


没有运维的 Netflix 和运维转研发的阿里巴巴

Netflix 的运维模式

Netflix 从一开始就强调开发人员进行自助化运维,他们的理念是:谁构建,谁运维。其运维工作全部由开发人员完成,只保留极少的 Core SRE 角色专门响应和处理严重等级的故障。


类似的还有亚马逊,无论是电商业务还是 AWS 公有云业务,都由开发负责。


在 Netflix 看来,建立起独立运维团队的主要助益,在于当一切进展顺利时,开发人员不致因运维任务的介入而分神。然而,当工作进展遭遇阻碍时,成本就会快速叠加起来。开发人员与 SRE 之间的沟通与知识转移往往存在严重损耗,且需要额外的往来以实现问题调试或解答合作伙伴的疑问。


由于运维团队对需要部署的变更本身缺少直接了解,因此问题部署通过会带来更长的检测与解决周期。当时在代码完成到部署之间的时间断档要远远长于当前,发布时长往往需要数周而非数天。这方面反馈主要来源运维人员,他们大多亲身经历过诸如警报 / 监控缺失或者性能问题以及延迟增加等挑战,而这些问题最终又会被转移至开发人员手中。


为此,Netflix 从 DevOps 运动的基本原则中汲取灵感,提出了“谁构建,谁运维”这一理念,旨在鼓励系统开发团队同时负责系统的运维与支持工作,从而真正将 DevOps 引入实践。


阿里巴巴的运维模式

阿里技术团队在 2016 年左右开始了一次大的组织架构调整,即把日常的运维工作交给研发做。原来的 PE(Production Engineer)要么转岗去做工具平台开发,要么作为运维专家做产品规划和设计,还有一部分无法适应的只能黯然离开。


这是阿里运维从工具化到自动化最重要的一个过程。集团性公司支撑的 BU 一般非常多,导致运维团队基本都是在干脏活、杂活。从组织层面上做出这样的调整后,运维团队的大多数人更多的时间是投入在研发工作上,而不是投入在日常的杂事上。这是 DevOps 真正意义上被彻底执行。


随着公司规模的逐渐扩大,从人肉运维到工具化运维再到自动化运维乃至 AI 时代的智能化运维,对于运维能力的要求是越来越高,对于运维人手的要求却越来越小。无怪乎有人发出这种论断:云计算(AI)正在杀死运维!


所以,运维如何逃过这场“追杀”?

随着自动化的逐步完善,单个 PE 能够支持的业务变得越来越多,很多事情似乎都可以通过自助完成,很多公司可能在潜移默化中就降低了对应用运维岗位的需求,逐渐以一种类似阿里的发展方式运行,似乎用不了多久,运维岗位就会被普遍“杀死”,运维人员应该如何做好转型和过渡呢?


运维人员如何做好转型?

根据科技发展的历史,每次技术革新都会丢掉一部分旧工作,并带来更多更有价值的新职位,某位互联网圈内云计算专家在接受 InfoQ 采访时表示:


云厂商确实在运维层面做了很多工作,但这部分工作并不是运维最看重的。换句话说,这些工作都不能体现运维人员的核心竞争力。过去,运维相当于黄包车车夫,累死累活半天可能也就绕着二环跑了两圈;现在,云平台可以免押金租给他们一辆汽车,轻松一天往返五次机场,你觉得哪种司机挣得多呢?


在云时代,运维人员并不是没有价值,而是会变得更加重要。云计算承诺高弹性、高可用、高性能、智能化,但公有云的 SLA 真不是目前的 AIOps 和运维自动化工具可以独立承担的


专家认为,运维团队的实力也是云计算服务商的核心竞争力,云计算要求更高的运维能力,能够保障大规模基础设施和业务稳定运行。对于企业用户而言,底层基础设施的运维工作确实可以甩给第三方公有云服务商统一负责,但上层应用的运维工作还需要企业自己来承担,比如环境配置,不过更多的是 DevOps。


因此,运维人员必须学会适当的角色转变。今后,运维领域的发展倾向于具备开发能力,尤其是产品能力,足以设计好的运维工具和平台的技术人才,这种观点也基本得到运维领域技术专家的认可。


采访中,某一线互联网公司运维负责人表示:


未来,运维岗位不会被淡化,相反会发展的越来越好。现在,之所以会有很多人担忧运维的未来,是因为如今大多数公司的运维其实就是打杂的,这主要归因于基础设施不够完善,需要运维手工补齐短板,所以运维需要承担很多脏活、累活。当基础设施短板补齐,运维可以在上面做更多业务侧的工作。从大公司和公有云角度来看,他们确实不需要这么多运维,但是市场体量将会变大,运维人员的需求也会随之增加。


当企业逐渐云化,运维岗位可能会适当精简,但是不会被完全取代,企业仍然需要人员负责资源管理、应用部署升级、监控和故障处理。按照 DevOps 来说,可能所有这些都可以由开发人员完成。当然,最理想的情况可能就是运维团队开发工具和平台,开发人员自己运维。


无论如何,应用运维可能都需要适当转型,极客时间《赵成的运维体系管理课》的专栏作者赵成曾在文章中提及:


无论是做运维转型还是做其他技术转型,具备代码开发能力都已经成为一项必备技能。


他建议,如果对开发工作缺乏自信,可以先从 Python、PHP 和 Go 这些上手比较简单的语言开始,这不是指写脚本,而是一定要能够实现完整的业务功能或流程;其次,需要提升产品意识,这并不是要求所有运维同事都成为优秀的产品经理,或者具备很强的产品设计能力,而是一定要有产品意识,这一点小转变就可能带来很大不同;最后,提升技术运营意识,简单来说就是可以根据需求把承载标准化和规范体系的工具平台真正落地应用。在这个过程中,通过问题收集和一定数据分析,再回到产品设计和需求流程中进行改进,从而形成良性闭环。


留给运维人员的时间还有多少?

好在,目前这项进程的转变步伐不算很快。一位与传统大型企业打了十多年交道的技术专家认为:


虽然云计算以及人工智能吸引了很多企业尝鲜,但目前并没有看到这些新服务真正落地并为传统企业带来很大价值,大部分应用还停留在表层,这项技术所能带来的潜力还没有被最大化挖掘。就实际应用而言,目前市场上的公有云服务成本依旧普遍偏高,易用性也不足以达到单凭传统企业的技术能力就可以短时间内学会的程度。


因此,虽然云计算和人工智能是未来的重要发展趋势,但短期内还存在很多问题需要解决,企业需要具备专业的技术团队来更好得将云服务落地,并保证服务的可用性和可靠性。目前,很多企业尚处于混合云阶段,数据的流转、计算等环节都需要技术和运维人员的存在。短期内,运维人员仍然在公司中具有重要地位。


另一方面,我们必须承认云计算和人工智能所带来的挑战。如今,企业已经从单纯选用 IaaS 服务向 PaaS 和 SaaS 层过渡,这些产品基本都在公有云平台内部经历了长时间的磨练和运行,这让不少新兴企业只需要专注业务逻辑,而无需自研纯技术产品。这种情况下,企业非但不需要应用运维这些基础岗位,就连门槛较高的分布式中间件研发岗位可能也会大量缩减。


面对这些改变,运维人员唯一的办法就是不断学习和提升自己的技能,保持自身的与时俱进,及时做出相应调整和改变,这才是应万变的根本之道。


回到最初的问题,你觉得阿里云们正在杀死运维行业吗?欢迎在评论区分享你的看法。


彩蛋:流浪地球里,运维工程师没活下来,开发活下来了。


2019 年 3 月 06 日 21:3014468
用户头像
小智 前 InfoQ 主编

发布了 409 篇内容, 共 348.3 次阅读, 收获喜欢 1906 次。

关注

评论 4 条评论

发布
用户头像
文章对运维的理解比较浅,运维的核心价值是Troubleshooting和系统架构的合理性保证。开发、测试、运维擅长的领域与技能并不相同,公有云只是对一些产品的SLA有保证。见过光有开发的公司,各种系统层面的漏洞,然后招入运维后把原始的系统架构干掉重来。
2019 年 03 月 25 日 10:22
回复
用户头像
说白了就是需要全家桶的人员
2019 年 03 月 14 日 17:44
回复
用户头像
运维和开发势必会合二为一的
2019 年 03 月 13 日 14:40
回复
用户头像
说白了, 所有的岗位都需要开发的技能.
测试, 运维都会因为软件复杂度飙升导致不得不借助开发的能力来解决问题
2019 年 03 月 12 日 15:42
回复
没有更多了
发现更多内容

@DateTimeFormat 注解 和 @JsonFormat 注解

乌龟哥哥

4月月更

软件工程学习之道

乌龟哥哥

4月月更

Docker 实战教程之从入门到提高 (六)

Jerry Wang

Docker 容器 docker image 容器镜像 4月月更

谈谈客户体验管理有效实施

龙国富

客户体验 CEM CXM 客户体验管理

亚马逊云科技 2022 年 3 月新服务新功能强势来袭

亚马逊云科技 (Amazon Web Services)

服务 亚马逊

4月28日,一场为IT工程师们准备的盛宴

观测云

云原生 可观测性 IT 直播 产品发布会

java培训Mybatis动态Sql处理解析

@零度

sql mybatis JAVA开发

设计消息队列存储消息数据的 MySQL 表格

浪飞

CityClub游览随笔记录

耳东@Erdong

InfoQ InfoQ写作社区2周年 City Club

「架构实战营」模块八 消息队列存储设计

hxb

「架构实战营」

Linux驱动开发-内核共享工作队列

DS小龙哥

4月月更

入驻快讯|欢迎小红书技术团队正式入驻 InfoQ 写作社区!

InfoQ写作社区官方

入驻快讯

云图说丨云数据库 RDS for MySQL一键开通读写分离,轻松应对业务高峰期

华为云开发者联盟

MySQL 华为云 读写分离 云数据库 rds for mysql

攻克编译器技术

刘旭东

编程语言 编译器原理 4月月更

web前端培训React基础知识点的梳理

@零度

前端开发 React

设计消息队列存储消息数据的MySQL 表格

Geek_8d5fe5

「架构实战营」

面试突击40:线程休眠的方法有几种?

王磊

Java java面试

企业如何才能发挥出知识管理真正的价值

小炮

知识管理 企业知识管理

建信金科在中国建设银行物联网平台项目的实践

EMQ映云科技

物联网 IoT 金融 银行 emq

5 月亚马逊云科技培训与认证课程,精彩不容错过!

亚马逊云科技 (Amazon Web Services)

架构师 培训 认证

OpenHarmony 3.1 Beta样例:使用分布式菜单创建点餐神器

OpenHarmony开发者社区

OpenHarmony OpenHarmony应用开发 点餐

从玄学走向科学:在字节跳动广告投放这么干

字节跳动数据平台

大数据 字节跳动 广告系统 ab测试

重学架构之消息队列存储消息数据的 MySQL 表格

陈华英

架构实战营 「架构实战营」

spring-cloud-kubernetes背后的三个关键知识点

程序员欣宸

java 4月月更

EasyRecovery2022全功能数据恢复介绍

茶色酒

EasyRecovery15

加速OpenHarmony生态繁荣,华为使能OpenHarmony发行版厂商

科技汇

宕机的阿里云们正在杀死运维?_云计算_小智_InfoQ精选文章