赵成的运维体系管理课
赵成
《进化: 运维技术变革与实践探索》作者
37829 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 49 讲
开篇词 (1讲)
效率和稳定性最佳实践 (20讲)
赵成的运维体系管理课
15
15
1.0x
00:00/00:00
登录|注册

39 | 云计算和AI时代,运维应该如何做好转型?

人力认知范畴
场景驱动
机器学习算法应用
岗位和技术门槛变化
业务逻辑开发
PaaS产品体系完善
数据分析和改进
落地应用工具平台
产品PRD的雏形
标准化约定
串联流程
实现完整的业务功能
Python、PHP或Go
运维和开发能力结合
招聘具备开发能力的人员
自动化提升效率
转型去做效能工具研发
运维工作由开发承担
"去PE"组织架构调整
微服务和分布式架构
开发人员自助化运维
对技术发展趋势的敏锐性
学习和技能提升
价值空间和成长空间有限
岗位收敛
岗位和技能转型
AI
云计算
提升技术运营意识
提升产品意识
代码开发建议
学会写代码
个人团队的模式
阿里的模式
Netflix的模式
总结
云计算和AI带来的挑战
应用运维的转型
云计算和AI时代
运维转型

该思维导图由 AI 生成,仅供参考

今天我们来聊一聊,在云计算和 AI 时代,运维应该如何做好转型?今天的内容可以说是我们前面运维组织架构和协作模式转型的姊妹篇。针对运维转型这个话题,谈谈我的思考和建议。
我们先来看业界的三个典型案例,一个来自国外,一个来自国内,最后一个是我自己团队的案例,都非常具有代表性。
先看国外 Netflix 的模式
Netflix 从一开始就强调开发人员进行自助化运维。我们第一篇文章中就介绍到,Netflix 内部的运维工作全部都由开发人员完成,平台也由开发自己完成,只保留极少的 Core SRE 角色专门响应和处理严重等级的故障。类似的还有亚马逊,无论是其电商业务,还是 AWS 公有云服务,全部都由开发搞定。
这样的团队因为其技术前瞻性,微服务以及分布式这样的技术架构早已落地,再加上其超强的技术能力,所以可以从一开始就这样来做。
再看国内阿里的模式
阿里技术团队在 2016 年左右,也开始进行“去 PE”的组织架构调整,原来需要 PE 完成的运维工作,全部由开发承担。原来的 PE 要么转岗去做工具平台开发,要么作为运维专家做产品规划和设计,还有一部分无法适应调整的 PE 就只能离开了。之前在业务稳定性保障过程中起到核心作用的 PE,随着各类工具平台的逐步完善,在高度自动化之后,最终也只能面临职业和技能上的转型。
这种模式,与 Netflix 正好相反,也就是一开始技术能力无法满足要求的时候,能靠人就先靠人,然后过程中不断完善各类自动化平台。
最后,再说说我自己的团队,发展过程中的模式。
我大致回顾了一下,发现从去年年初到目前,将近两年的时间里,我自己的团队也没有招聘新的应用运维人员了。并不是没有合适的人,我总结了一下主要有两个原因。
第一个原因,随着自动化逐步完善,效率不断提升,单个 PE 能够支持的业务变得越来越多;同时,很多事情开发都可以自助完成。
第二个原因,我有意识地招聘具备开发能力的人员,他们入职后一方面参与各类平台的开发,另一方面还要定期轮岗做一些运维工作。后来我发现,只要有效进行引导,同时具备运维和开发能力是不成问题的。
所以,结果就是,应用运维的岗位需求已经没有这么强烈了。从趋势上看,跟阿里的发展过程非常相似。不过这个过程,我从来没有刻意地设计过,基本算是顺其自然。
从上面的这几个案例来看,无论哪种情况,就运维来说,随着日常重复的人工操作被逐步自动化之后,如果还是固守原有的工作模式和思路,能做的事情、能够提供的价值,一定会越来越少。终究有一天,我们会面临和阿里 PE 同样的转型问题,而且这个转型是在可预见的短期内就会到来。
既然预见到了趋势,那下面我们就来谈谈应该如何面对。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

在云计算和人工智能时代,运维领域面临着巨大的挑战和转型。本文通过分析典型案例,提出了运维转型的思考和建议。首先介绍了亚马逊和Netflix等公司强调开发人员自助化运维的模式,以及阿里进行的“去PE”组织架构调整。作者还分享了自己团队的发展模式,强调随着自动化逐步完善,运维岗位需求减少的趋势。针对运维的转型,作者建议运维人员学会写代码,并提出了具体的建议,如从简单的语言开始学习代码开发,提升产品意识和技术运营意识等。文章强调了运维人员需要具备代码开发能力,并且需要转变思维,从被动响应转向主动创新,以适应云计算和人工智能时代的发展趋势。文章内容丰富,为运维人员提供了实用的转型建议,帮助他们适应新的技术环境。在新时代下,机遇和挑战并存,运维人员需要不断学习和提升自己的技能,保持对技术发展趋势的敏锐性,及时做出调整和应对,才是根本的解决之道。整体而言,本文为运维人员提供了有益的思考和指导,帮助他们应对技术转型的挑战。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《赵成的运维体系管理课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(8)

  • 最新
  • 精选
  • luoweiro
    技术的发展和业务的发展就像火车头和轨道的关系,业务发展快要车头带,业务发展边界取决于车轨铺设范围,而平衡两者才决定商业价值最大化。 反过来看运维和开发,其实运维体现的是一种能力,开发体现的是实现工具,和火车头&车轨有相似之处,在基础设施建设方面运维更像车头发动机,工具开发相当于铺设车轨,两者都能发挥最大效应才会有更高的效能,所以对于运维开发来说两方面的能力均需要具有。 对于跨界轮岗,转岗其实也是一种好的培养综合能力的方式,当然阿里运维转开发虽是16年提出,但是这种综合能力培养其实是从早几年就开始了,达到一定点后自然爆发了。 从运维开发的角度来看,未来一定是:“会写几行代码的运维,能自助运维的开发” 的格局。

    作者回复: 这个比喻很棒!

    2018-01-19
    5
  • Geek_52c17a
    老师您好,听了您的课,受益良多,我39,专科一直做java一线开发很多年,您在课里说现在运维岗需求量也在逐步收紧,我之前很想转运维,现在看来是否可行,大数据门槛又高,或者说可以往哪个方向转,我现在跟迷茫,期望得到您的指点

    作者回复: 运维岗位收紧是现状,但是这是针对传统运维的情况,如果你既会开发,又懂运维,那这个市场就大了,无论是DevOps还是SRE,都是需要具备这两种能力的。 开发是一项技能,运维是一个专业方向,两者并不矛盾。

    2020-03-04
    3
  • 黄无由
    阿里去pe的文章哪里可以找到?

    作者回复: s.geekbang.org 搜索 阿里巴巴运维体系变迁史

    2018-01-20
    3
  • haormj
    现在个人负责的内容不是直接和用户业务逻辑挂钩,而是和平台建设相关的一些内容,因为目前公司处于发展阶段,规模也比较小,所以想建立公司自己的DevOps平台。 之前的系统,对应用的管理没有结合kubernetes和docker,系统现在也不稳定,所以想转变思路,跟上潮流,对于应用配置的管理还有困惑,还有就是不知道如何管理不同云平台的服务,例如redis。希望能够多多交流

    作者回复: 建议先把应用体系建起来,redis的实例一定是某个应用使用的实例,从申请的时候就把他们关联起来,再从生命周期的角度去看有哪些运维场景。 套路就是这样的,可以先一点点来。

    2018-01-17
    3
  • 赵成
    从实际情况看,无时无刻不在经历变化,而且不仅仅是运维。 跟上趋势的唯一办法,就是不断更新自己的知识和技能体制。
    2018-01-18
    15
  • 橙汁
    专栏写的真tm好
    2023-01-05归属地:北京
  • 怀揣梦想的学渣
    文中提到公有云的成熟产品对运维和运维开发的职位挑战。目前如果是面对不能完全信任公有云的公司,这些岗位不仅存在,还很重要,他们要负责实现不依赖公有云,但又要满足业务新增需求的诸多功能。我遇到的有机械、冶金、油气、电力等,这类公司大多是有重要的生产资料,严格内部保密,农林类反而相对宽松,甚至敢于尝试多家云平台,但对于化肥种子等掌握专有生产数据的,对自建数据中心和自运维的需求是保持旺盛的。
    2022-03-17
  • 技术修行者
    现在AIOps已经在很多大厂落地了,以后从事运维工作,需要站在一个更高的维度来看待,是一个综合性的多技能相结合的岗位。
    2020-05-28
收起评论
显示
设置
留言
8
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部