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

栏目: 服务器 · 发布时间: 5年前

内容简介:近年来,关于“去运维”的相关话题甚嚣尘上,但似乎没有引起程序员的过多关注或者大范围讨论。近日,程序员论坛 V2EX 上出现一个热议话题“阿里云正在缓慢而稳步地杀死运维行业”,这似乎表明运维人员最终还是感受到了来自云计算发展带来的巨大压力。发帖者认为,“当容器服务集群、跨地域监控与容灾 / 保活、DBA、代码托管与 CI/CD 都能全部依托阿里云产品时,运维已经被踢出 IT 行业”。一石激起千层浪,有人认为这只是杞人忧天,并反问“阿里云自己都刚宕机,还想说不需要运维吗?”,有人则认为英雄所见略同,还有人进一步

云计算正在杀死运维吗?

近年来,关于“去运维”的相关话题甚嚣尘上,但似乎没有引起 程序员 的过多关注或者大范围讨论。近日,程序员论坛 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 来说,可能所有这些都可以由开发人员完成。当然,最理想的情况可能就是运维团队开发工具和平台,开发人员自己运维。

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

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

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

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

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

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

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

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

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

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

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


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

未来简史

未来简史

[以色列] 尤瓦尔·赫拉利 / 林俊宏 / 中信出版集团 / 2017-2 / 68.00元

进入21世纪后,曾经长期威胁人类生存、发展的瘟疫、饥荒和战争已经被攻克,智人面临着新的待办议题:永生不老、幸福快乐和成为具有“神性”的人类。在解决这些新问题的过程中,科学技术的发展将颠覆我们很多当下认为无需佐证的“常识”,比如人文主义所推崇的自由意志将面临严峻挑战,机器将会代替人类做出更明智的选择。 更重要的,当以大数据、人工智能为代表的科学技术发展的日益成熟,人类将面临着从进化到智人以来z......一起来看看 《未来简史》 这本书的介绍吧!

RGB转16进制工具
RGB转16进制工具

RGB HEX 互转工具

HTML 编码/解码
HTML 编码/解码

HTML 编码/解码

UNIX 时间戳转换
UNIX 时间戳转换

UNIX 时间戳转换