从人肉到智能,阿里运维体系经历了哪些变迁?

机器智能的前提是需要有数据,AIOps的数据从哪里来?如何利用数据代替机器决策、分析?如何利用机器学习算法与基于大数据的业务运维管理平台整合,在告警过滤、异常监测、自动修复等环节发挥效用,真正能把运维同学解放出来提高整体运维效率,降低运维成本。我们认为AIOps是一个长期演进的过程,这也是我们区别于业界,在通往AIOps征途上增加DataOps阶段建设及沉淀的重要原因,而我们接下来聊一聊DataOps时代——运维人才的能力要求。

从人肉到智能,阿里运维体系经历了哪些变迁?

人肉/脚本运维时代(Human/Scripts Ops)

运维工作本身其实是一个需要具备高度综合技能掌握的工种,需要涉及的广度相对别职业属性的要求会更高,以前很多时候大家对运维的认识都停留在发布、变更、接报警、搬机器……其实这个很好理解,所有的互联网大公司都是从小公司成长起来的,在还是小公司的时候,你需要面对的是不停地解决各种奇怪的问题,而由于有公司生存的压力,追求短平快的结果使得大家会沦为一个搬来主义者,从各类技术论坛,甚至是个人blog上去搜索各种各样的解决方案,以求快速workrun解决问题,但对于原理、系统全局上的东西,可能完全不会去深究。

工具化运维时代(Tools Ops)

做过运维的人都知道,运维同学比较喜欢编写各种各样的脚本,比如一键批量发布软件,一键清理、交互式向导执行等等,他们很喜欢通过黑屏上操作刷屏带来成就感。每当我们的运维同学交接工作的时候,新来的运维同学基本上会照着自己的理解重新实现一套。人肉/脚本时代的运维存在大量的效率低下,以及各种各样重复的脚本工具,同时也会带来很多安全风险,回顾互联网的发展史,几乎每隔一段时间就有一些严重事故发生,而每次事故的背后却是一些低级错误,甚至是手误敲错字符带来的巨大代价。这时候大家都意识到,不能再任由运维同学随意发挥了,需要将各式各样的功能脚本收敛到工具里来,通过集成的运维工具迭代来实现复用和能力交接,这体现在DevOps的初级阶段,此时还没有延伸到Dev阶段。

平台型运维时代(DevOps)

随着公司商业上的成功,随之带来的规模的发展,这个时候量变引起质变,今天对大厂的运维来说已经远远不仅仅是上述这些工作,同时这些工作也不仅仅是靠加人手能解决得了的,例如说应用从原来的一个应用变成了几千个、上万个、几十万个,平台规模从原来的几百台扩充到上万&几十万台,硬件由简单的CPU,mem,机械硬盘增加到Gpu,Fpga,Asic,Optan等各类异构硬件平台,软件架构变化,大数据分布式等等,当面对海量的各类汇总数据,需要快速判断业务止损,全局资源优化运营等工作时,人工将会面临非常大的挑战,甚至是不可能完成的任务。这个时期运维的工作职能更多转变为:

● 全局架构规划
● 资源运营与成本优化
● 自动化平台开发
● 稳定性保障
● 海量数据分析
● …….

数据化运维时代(DataOps):

对我们来说由于业务的需求对目前运维能力的要求越来越高,技能的要求上来说不光除了面上的广度还需要一定方向的精度,甚至某些点的深度要非常专深。同时需要通过软件工程化,数据化的运维的思路,围绕数据链建设起整体运维智能化工具链,来解决超大规模分布式集群运维管理问题,提升整体产品的稳定性,效率,成本。这样对现在整个运维人员的综合技能要求会有很大的挑战。

业内随着运维的发展逐步从Ops发展到今天大家业内都比较火热的AIOps,现在运维界现放眼望去大家都太大谈特谈AIOps,认为只要有强大的算法,就能够轻松实现不需要人为干预的智能化,当然这是个理想化,终局化的情况,最终的目标是要做到完全智能化,但这个难度不低于完全自动无人驾驶。在我们看来如果算法是kernel,那么工程化的程度就决定了能否把kernel发挥到极致,能否做到易用和高可靠是我们要着力解决的问题,我们内部我们认为目前还处于DataOps阶段,数据化一切运维对象,以数据驱动运维,工程化落地。与自动化驾驶分级类比:

从人肉到智能,阿里运维体系经历了哪些变迁?

随着大数据时代的逐步发展促进运维人员的技能转型需要具备更为复合性能力:

● 架构能力
● 研发能力
● 运维知识&业务理解
● 基本工程算法
● TPM(技术项目管理能力)

AIOps发展最终本质上还是要落地在公司的各类运维平台&运维产品上,在完成初步构建后仍然需要持续的人力投入以及参与,而在目前的探索发展的投入阶段,有大量的工需要去做,仍然需要专家或者分析师,从不同的维度,从不同的业务口径,组合合适的可视化技术,机器学习技术,大数据分析技术,制定分析场景,平台落地才能够为运维产生持续的洞察,提供最终的业务价值。

从人肉到智能,阿里运维体系经历了哪些变迁?

在不同阶段对于运维团队的技术能力要求及转型是必须历经的过程,同时也是一个痛苦的过程,能力要求的变化自然会带来组织变革,对原有人员的冲击也会比较大,整个部门从维护性部门转变为研发创新型部门,最先带来的冲击是思想上的,在研发思维先有原理,然后逐步工程实现落地,而传统运维是反过来很多东西都是已经存在去维护它的稳定。

这种阵痛也是团队转变需要去面对的,从被动救火式运维向主动精细化转型,从问题驱动向价值驱动转型,从操作运维向运维开发转型,从依靠经验向智能化驱动运维转型,这不仅是技术能力的转型而且是运维系统化思路的转型。时代在变化,唯一不变的只有拥抱变化!


原文发布时间为:2018-09-11

本文作者:大舞

本文来自云栖社区合作伙伴“阿里技术”,了解相关信息可以关注“阿里技术”。

上一篇:Android Studio 遇到 No Debuggable Applications 的解决方案


下一篇:OK335xS Ubuntu 12.04.1 版本 Android 开发环境搭建