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