在前两篇文章中,我们分别谈到了下一代运维AIOps智能简述以及知识图谱的引入对于智能运维进一步发展的意义与价值,从运维的发展与变迁可以看出,每一代运维的落地并不是一蹴而就的,而是会随着市场大环境的需求、公司架构的变化以及新技术的不断应用而做出调整与优化,AIOps也一样,一直在融合新的技术和理念以求更好地适应市场需求。
今天的文章,则想从最近十分火热的“中台”概念出发,再来谈一谈“中台”对于AIOps的适用性,以及AIOps从嵌入式改良演变为中台核心的价值与实例。
什么是“中台”
“中台”并不算一个全新的概念,国内最早在2015年就被阿里巴巴提出并加以运用,但是对于非从业者来说却并不一定熟悉,因此,在谈论AIOps从嵌入式改良到中台核心之前,我们首先简单理解一下中台的概念。
中台概念的来源
根据搜索引擎的搜索指数显示,“中台”这个关键词一直到今年5月份之前都热度平平,关于这个关键词网友搜索排行前三的问题依次是“数据中台”、“中台系统”以及“什么是中台系统”。由此可见,对于“中台”概念,大部分人都是比较陌生的,处于一个不甚了解的状态。
图 | 中台关键词近半年的搜索指数
而中台概念今年5月份的突然火爆,则归功于腾讯公司于2019年5月21日召开的全球数字生态大会,在大会中腾讯提出了“开放中台能力,助力产业升级”的概念,并宣布腾讯将进一步开放业界领先的包括用户中台、内容中台、应用中台等在内的数据中台,以及包括通信中台、AI中台、安全中台等在内的技术中台,以便企业与开发者应用。
得益于腾讯公司的推动,“中台”开始进入大家的视线。
但事实上,这并不是中台概念第一次被提出,阿里巴巴早在2015年便提出了中台的概念并在运营过程中将其用于实践,而阿里巴巴关于中台的灵感则是受到游戏公司Supercell的启发——Supercell公司将游戏开发过程中公共和通用的游戏素材和算法整合起来,并积累了非常科学的研发工具和框架体系,构建了一个功能非常强大的中台。这样强大的中台可以支持若干个小团队在短时间内开发出一款新的游戏。Supercell也因此成为了当时首屈一指的游戏公司。
图 | 阿里巴巴中台
在此基础上,阿里对公司的组织架构进行了调整,将组织架构全面升级,整合阿里产品技术和数据能力的强大中台,组建“大中台,小前台”的组织和业务体制,这一升级也成为了行业内谈论到“中台”时津津乐道的案例。
中台的定义
说完中台概念的来源,下面再简单谈一下中台的定义。
对于中台的定义有很多,目前比较为人所接受的中台的定义是——企业级能力复用平台,虽然只有短短几个字,但却解释了中台于前后台区分、中台划分方式、中台分辨方式以及中台建设方式等大部分问题。
下面我们将这个定义以单词的形式分开来解读。
企业级:定义了中台的范围。中台一定得是企业级的,这里的企业级不是说难度而是指范围,这一定义区分开了单系统的服务化与微服务;
能力:定义了中台的主要承载对象。企业的能力可能包含多个维度,常见的例如计算能力,技术能力,业务能力,数据能力,AI能力,运营能力,研发能力……其中大部分的能力还可以继续细化和二次展开,从而形成一张多维度的企业能力网。能力的抽象解释了各种各样中台的存在;
复用:定义了中台的核心价值。传统的平台化对于易复用性并没有给予足够的关注,中台的提出和兴起,让人们通过可复用性将目光更多的从平台内部转换到平台对于前台业务的支撑上;
平台:定义了中台的主要形式。区别于传统的应用系统拼凑的方式,通过对于更细力度能力的识别与平台化沉淀,实现企业能力的柔性复用,对于前台业务更好的支撑。
对“中台”有了一个较为明确的定义后,关于中台建设以及中台化的意义也就有了合理的解读,如果说中台是”企业级能力复用平台”的话,中台建设就是“建设企业级能力复用平台以区别原有的平台”,中台化就是”利用平台化手段发现、沉淀与复用企业级能力的过程”。
中台的价值
在中台概念出现以前,传统企业大多是“前台+后台”的平台化架构,这样的架构在今天看来缺点十分明显。由于多数企业的在创建后台系统之初的目标,更多的是为了实现后端资源的电子化管理,解决企业管理的效率问题,而不是主要服务于前台系统创新,因此后台系统大多版本老旧,定制化困难,与前台兼容性不够好。
为了解决这一困难,有人提出新建一个前台友好型的后台系统,但事实上由于后台系统管理的是企业的关键核心数据,需要考虑到企业安全、审计、合规、法律等限制,哪怕是新建的系统通常也无法被前台系统直接使用,或是受到各类限制,无法快速变化,以支持前台快速的创新需求。
此时的前台和后台就像是两个不同转速的齿轮,前台由于要快速响应前端用户的需求,讲究的是快速创新迭代,所以要求转速越快越好;而后台由于是对的是相对稳定的后端资源,而且往系统陈旧复杂,甚至还受到法律法规审计等相关合规约束,所以往往是稳定至上,越稳定越好,转速也自然是越慢越好。
随着企业业务的不断发展,这种“前台+后台”的齿轮速率“匹配失衡”的问题也越来越严重与明显,直到中台概念的提出与构建,这种矛盾才得以缓和。
图 | 中台像一个齿轮,对前后台进行调和
中台就像是在前台与后台之间添加的一组“变速齿轮”,将前台与后台的速率进行匹配,在前台与后台之间加起了一座缓冲的桥梁。
可以说,中台就是为前台而生的。
中台易于前台使用,可以将后台资源顺滑流向用户,响应用户。有了中台作为缓冲,用户一方面可以将早已臃肿不堪的前台系统中的稳定通用业务能力“沉降”到中台层,为前台减肥,恢复前台的响应,另一方面又可以将后台系统中需要频繁变化或是需要被前台直接使用的业务能力“提取”到中台层,赋予这些业务能力更强的灵活度和更低的变更成本,从而为前台提供更强大支撑。
中台的分类
目前,中台已经被各大企业作为架构转型的目标,中台根据功能的不同被细分为不同的类型,阿里人将“中台战略”形象地比喻成陆海空三军立体化协同作战,大致包括如下几类:
业务中台,提供重用服务,例如用户中心、订单中心之类的开箱即用可重用能力,为战场提供了空军支援能力,随叫随到,威力强大;
数据中台,提供数据分析能力,帮助从数据中学习改进,调整方向,为战场提供了海军支援能力;
算法中台,提供算法能力,帮助提供更加个性化的服务,增强用户体验,为战场提供了陆军支援能力,随机应变,所向披靡;
技术中台,提供自建系统部分的技术支撑能力,帮助解决基础设施,分布式数据库等底层技术问题,为前台特种兵提供了精良的武器装备;
研发中台,提供自建系统部分的管理和技术实践支撑能力,帮助快速搭建项目、管理进度、测试、持续集成、持续交付,是前台特种兵的训练基地;
组织中台,为项目提供投资管理、风险管理、资源调度等,是战场的指挥部,战争的大脑,指挥前线,调度后方。
建设中台核心的AIOps平台
前文讲到了中台的定义与价值,那么对于AIOps来说,由嵌入式改良演变为中台核心的转变是否能推动智能运维的进一步落地与实践呢?答案是肯定的。
运维的发展与挑战
我们首先来回顾一下运维的基本定义——通常情况下我们所说的运维,指的是对产品及其上运行的系统的运营和维护,运维工作人员会根据业务需求来规划信息、网络、服务,通过网络监控、事件预警、业务调度、排障升级等手段,使服务处于长期稳定可用的状态。
随着企业规模逐渐增大,企业架构也在不断升级,数据中心规模和容量都在成倍增长,随之而来的运维管理复杂度和难度也越来越大,对运维的要求自然也逐渐提高。
IT运维发展到现在,大致历了人工运维——自动化运维——智能运维(AIOps)三个阶段。
早期的运维模式是人工运维,顾名思义,此阶段的运维工作大部分是由运维人员手工完成,这种运维模式不仅低效,也消耗了大量的人力资源。
随着运维工具不断完善与成熟,工程师开始利用工具来实现大规模和批量化的运维操作,自动化运维极大地减少了人力成本,降低了操作风险,提高了运维效率。
但自动化运维的本质依旧是人与自动化工具相结合的运维模式,通过插件与运维工具辅助工程师完成运维工作,受限于人类自身的生理极限以及认识局限,无法持续地面向大规模、高复杂性的系统提供高质量的运维服务。
在智能运维诞生以前,传统运维模式主要面临以下三大挑战:
(1)安全运行的挑战。
保障系统安全稳定运行是运维工作最基础也最重要的工作,而目前业务功能一般涉及多个系统与应用,所采用的事后处置为主的运维模式,存在异常定位困难、处理效率低等缺陷,这种过于被动异常响应模式已经不能满足异常快速定位和处理的需求。
(2)人力紧缺的挑战。
目前的技术系统运维由于工作量大、工作内容重复且枯燥,运维岗位特别是值班岗位的吸引力逐渐降低。运维需求与人力资源紧缺的矛盾,已经成为技术系统发展中无法避免的矛盾。
(3)远程运维的挑战。
从单数据中心向多数据中心发展过程中,传统的现场运维方式也因数据中心地点偏僻、现场巡检工作繁琐重复等困难而导致运维成本和压力增大,如何实现远程运维来解决数据中心发展的问题是运维面临的另一大挑战。
人工智能技术在运维领域的应用打破了这一窘境,智能运维(AIOps)的概念最早由Gartner提出,智能运维是指通过机器学习等人工智能算法,从海量运维数据中自主学习并总结规则,从而主动做出决策的运维方式。智能运维能快速分析处理海量数据,并得出有效的运维决策,执行自动化脚本以实现对系统的整体运维,能有效运维大规模系统。
短短几年,智能运维已经在电信、金融等域取得了不错的成果,作为运维领域最新技术,智能运维虽然在技术成熟度上仍有待提升,但并不妨碍智能运维所产生的强大生产力。
中台核心的AIOps平台
智能运维平台虽然功能强大,但目前依旧存在一些不足之处。对于一个智能运维平台来说,用户应该始终是放在第一位,运维平台需要跟随用户的实际情况与实际需求去做出适应与调整,但当前智能运维平台面对的是多种领域的业务需求,对于不同领域的用户,运维的前台系统有明显的多样性和个性化特征,哪怕是针对同样的场景、不同的IT组织也可能有完全不同的实现要求。
这些不同的要求加大了前后端的开发难度,大大降低了系统的复用性,严重影响了AIOps的工作效率。
中台概念的应用恰好能缓解这个问题。通过将智能运维系统的核心技术沉淀到中台,从而在应对前台多样化的需求的同时,不会过分增加后台负担。
智能运维是基于机器学习等人工智能算法,分析挖掘运维大数据,并利用自动化工具实施运维决策的过程。因此,智能运维的核心技术主要包括运维大数据平台、智能分析决策组件以及自动化工具三部分。
其中,运维大数据平台如同眼一样,能采集、处理、存储、展示各种运维数据。智能分析决策组件如同大脑,它以眼睛感知到的数据作为输入,作出实时的运维决策,从而驱动自动化工具实施操作。自动化工具如同手一样,能根据运维决策,实施具体的运维操作,如重启、回滚、扩缩容等。将这些核心功能沉淀到中台,在不影响后台的情况先,能进一步提高前台的运行效率。
1、运维大数据平台
运维大数据平台用于对各种运维数据进行采集、处理、存储、展示的统一平台。运维数据包含监控数据、日志数据、配置信息等。
大数据平台所存储的数据,按照所更新的频率可分为静态数据和动态数据。
静态数据主要包含CMDB数据、变更管理数据、流程管理数据、平台配置信息数据等。此类数据一般情况下在一定时间范围内是固定不变,主要是为动态数据分析提供基础的配置信息。对此类数据的查询操作多,增删改操作较少。
动态数据主要包含各类监控指标数据、日志数据以及第三方扩展应用所产生的数据。此类数据一般是实时生成并被获取,并作为基础数据,需要通过数据清洗转换成可使用的样本数据。
2、智能分析决策组件
智能运维是利用人工智能算法,根据具体的运维场景、业务规则或专家经验等构建的组件,类似于程序中的API或公共库,具有可重用、可演进、可了解的特性。智能运维组件按照功能类型可分为两大类,分别是运维知识图谱类和动态决策类。
(1)运维知识图谱类组件
运维知识图谱类的组件是通过多种算法挖掘运维历史数据,从而得出运维主体各类特性画像和规律,以及运维主体之间的关系,形成运维知识图谱。
(2)动态决策类组件
动态决策类组件则是在已经挖掘好的运维知识图谱的基础上,利用实时监控数据作出实时决策,最终形成运维策略库。实时决策主要有异常检测、故障定位、故障处置、故障规避等,如下图所示:
动态决策类组件一般是对当前的日志或事件进行分析,对其作出及时响应与决策,甚至判断未来一段时间内系统运行状态进行预测。可以将异常发现、故障定位、异常处置作为一种被动的运维,异常规避则是一种主动主动异常管理的方式,准确度高的预测能提高服务的稳定性。
以故障预测为例,预测是基于历史经验的基础上,使用多种模型或方法对现有的系统状态进行分析,判断未来某一段时间内发生失效的概率。
3、自动化工具
自动化工具是基于确定逻辑的运维工具,对技术系统实施诸如运行控制、监控、重启、回滚、版本变更、流量控制等系列操作,是对技术系统实施运维的手段,用以维护技术系统的安全、稳定、可靠运行。自动化工具是自动化运维的产物,也是智能运维组件作出决策后,实施具体运维操作所依赖的工具。
自动化工具按照功能可分为两类:监控报警类自动化工具、运维操作类自动化工具。监控报警类自动化工具是对各类IT资源(包括服务器、数据库、中间件、存储备份、网络、安全、机房、业务应用、操作系统、虚拟化等)进行实时监控,对异常情况进行报警。并能对故障根源告警进行归并处理,以解决特殊情况下告警泛滥的问题,例如机房断网造成的批量服务器报警。
运维操作自动化工具主要是把运维一系列的手工执行繁琐的工作,按照日常正确的维护流程分步编写成脚本,然后由自动化运维工具按流程编排成作业自动化执行,如运行控制、备份、重启、版本变更与回滚、流量控制等。
根据Gartner的预测,在接下来的5年内,AIOps平台事实上将扩展成为以AIOps功能交付的形式,而不是将AIOps的功能嵌入在APM、NPMD或ITIM等监控工具中。
中台核心的AIOps价值与实例
中台核心的AIOps的价值
中台核心的AIOps以数据为基础,以算法为支撑,以场景为导向,应用人工智能、大数据等技术,通过轻量级、低入侵、松耦合的立体化监控与管理工具,打破了传统运维前台业务应用与后台支撑系统之间的信息断层和管理断层,向上提供数据与能力支撑,在快速响应前台的变化和创新需求的同时,向下保障系统稳定可靠运行,进而实现互联网级的数字化运维高效管控。
对于从信息化时代一路走来的中大型企业,以运维为突破口的中台核心的AIOps,能够充分利用企业原有业务系统、管理系统和IT系统生成的海量数据,同时IT部门作为企业中距离数字化最近的部门,有利于数字化转型的单点突破和小范围试错,逐步建立数字化运营管理体系,赋予业务快速迭代、创新和试错能力,进而带来管理效能的提升。
面对不同行业和不同应用场景,中台核心的AIOps可以提供如下价值:
1、提供数据与技术支撑
中台核心的AIOps能够整合分析历史数据和系统运行的实时流式数据,实现业务运行的跨系统追踪和基于机器学习的趋势预测,降低IT故障带来的经营风险。
同时可以提炼各条业务线的共性需求,打造成组件化的资源包,然后以接口的形式提供给前台各种业务形态使用,可以使产品在更新迭代、创新拓展的过程中快速试错,快速扩展业务,打破平台数据隔阂,最大限度地减少重复产生带来的资源浪费。
2、提升业务聚合能力
企业基础公用服务,如会员、交易结算等功能,中台核心的AIOps使用统一的业务指标体系快速发现前台业务的发展瓶颈和运营风险,用可视化手段全面提升整个组织的管理效率。这相当于在企业原有业务平台基础上的平台化改造,让其成为可以进行统一管理、统一调度、灵活调配的“中控平台”。
3、灵活调度资源组织
企业发展到一定程度,组织架构和层级必然不断膨胀扩张,在强调分权、各业务独立发展的组织模式下不可避免地会出现“大企业病”,这也需要在公司内部构筑平台,让各部门保持相对的独立和分权的同时,用一个强大的中台来对这些部门进行总协调和总支持,以平衡集权和分权的成本,同时比较灵活地为新业务、新部门留下接口。
中台核心的AIOps实例
中台核心的AIOps是从传统的嵌入式改良运维的进一步优化,在不影响后台稳定运行的情况下,同时对前台业务表现出更灵活的适应性。
构建中台系统后,后台核心数据与功能会先通过中台系统处理后再辐射到前台,然后根据前台用户的实际需求实现不同的功能。
在实际使用过程中,不同用户可以根据不同需求、不同场景定制不同的运维功能面板,从而进一步提高运维效率。
在功能部分,中台核心的AIOps系统功能齐全,根据用户的需求去定制与调用不同模块,通过中台核心保证运行的稳定性与流畅性。其主要功能模块包括如下几部分。
配置管理(CMDB)
配置管理(CMDB),也称资源管理模块,默认是预置的资源模型和拓扑关联关系,而智能资源模型可根据业务需求动态调整,如新增模型、新增模型属性、关联关系等。
与数据中台相比,二者都是数据能力的传导平台,核心职责都是整合数据、加工数据、输出数据。但CMDB和运维数据中台在数据范围方面却有区别,数据中台是全域数据(包括配置、告警、指标、工单、操作),而CMDB只有静态的配置数据。
从数据覆盖范围看,数据中台涵盖了CMDB的数据,CMDB可以定位成数据中台的主数据管理模块,管理主要的静态数据,而其他数据则交给中台去处理,保障后台系统的稳定运行。
智能运维
智能运维是AIOps的主要功能模块,相当于运维系统的大脑,为AIOps提供主要功能,智能运维模块下主要功能包括如下几部分。
(1)速查工具
速查工具功能提供了一个强大的资料库,用户可以根据系统运行过程中产生的错误号查询相关的错误原因以及解决方式,同时可以查到类似错误关联的帖子,帮助用户进一步学习于解决问题。
(2)自愈管理
自愈策略在检测到系统异常指标时,会出发告警时间,经运维人员确认故障后,智能运维系统将通过机器学习算法定位故障,然后根据运维人员制定的自愈策略,调用相应的自动化运维工具执行相应的修复操作,从而实现故障自愈。
(3)诊断管理
此功能旨在为运维工作提供一个关联性强、灵活度高以及功能全面的系统诊断,从应用的整体、运维对象出发,分析其内在的关联,找到问题的源头并针对性解决,避免南辕北辙的请款发生。同时,通过多方面的数据采集与分析,在分析过程中也不断自身调整,让结果更加准确全面。
(4)根因分析
故障根因分析基于准确的异常报警基础上,分析查找异常的发生原因,定位故障并修复是对故障失效传播链、智能异常检测、异常报警聚合的综合运用,当异常被检测时,通过异常报警聚合缩小异常的范围,然后通过故障失效传播链找到可能的发生故障原因。在此过程中,采用机器学习的方法,将所有可能的故障进行模拟,依据已有的失效传播链建立学习模型,根据实际检测的异常指标进一步缩小故障的范围。
(5)知识图谱
建立运维知识图谱,通过离线的数据挖掘等方式,从运维历史数据中得出各个运维主体的运行规律、各个主体之间的关联关系,如建立故障失效传播链,用以对失效进行回本溯源的分析,查找引起该失效的故障原因。
(6)工单管理
在实际运维过程中因为现场情况的不确定性,可能遇到一些新的bug,通过工单管理功能,工程师可以主动提交运维过程中遇到的bug,经由系统整理分类后归档,再通过大数据分析找到与之关联的数据与可能的解决方案。同时,此功能也可为同类问题后续进一步分析提供数据支持。
随着时代的变迁和技术能力的不断成熟,原本默默无闻的技术可能会焕发新的活力;一些优秀的概念在各领域专家的不断探索下,也时刻给其他领域的进步带来启发与指导。AIOps系统在探索更合适的落地模式的同时,也在不断吸收与接纳新的技术与概念,以求更好地适应市场,早日实现实现全面落地。
该贴被huang.wang编辑于2019-10-9 9:58:57