AIOps(企业运维新力量!)
摘要:企业运维需求及挑战,来看看华为AIOps如何解决!本文分享自华为云社区《【云驻共创】AIOps?企业运维新力量!》,原文作者:启明。
国际惯例,我们先介绍一下AIOps的概念:AIOps,即 Artificial Intelligence for IT Operations,智能运维,将人工智能应用于运维领域,基于已有的运维数据(日志、监控信息、应用信息等),通过机器学习的方式来进一步解决自动化运维没办法解决的问题。
Gartner预测,当前的IT应用程序会发生剧变,而且管理整个IT生态系统的方式也会改变。这些变化的关键是Gartner所称的AIOps平台。
我们今天要讨论的,就是AIOps的需求挑战,以及我们通过怎么样的方式去应对这种挑战。
AIOps需求及挑战 (一)新技术、新挑战,呼唤高度智能的电信网络
近年来,以5G为代表的新技术在电信网络中得到了快速的应用。新技术的应用,给我们带来了很多的收益,比如大连接、低时延、高速率等等。5G的发展,让这些数据都至少有一个数量级的提升。
文章图片
但是,数据量级的提升,伴随着的,是运维难度的增加,从而给运维带来了如下挑战:
1. 网络复杂性: 数据量级的增大,让网络变得更加复杂:新技术得到了快速应用,旧技术却没有同步退出,导致我们每引入一项新技术,都需要在原来的复杂度上做一个加法。而在某些场景式,甚至要去做乘法。
比如,在无线领域,2G/3G/4G/5G,“四代同堂”;在核心网,PS/CS/MS物联网等等十域并存......如此高的网络复杂度势必会给运维带来相当大的挑战。
2. 2B新需求 运维的第二个挑战是To B的新场景,也就是企业应用。5G的应用推动了智能制造,网络也逐步融入到了企业的生产制造流程当中。在这种情况下,对网络可靠性的要求必然会提高,毕竟网络一旦出问题,生产流程就可能会受影响,甚至会中断,这样造成的损失将会非常大。3.
3. 成本压力 成本压力主要是由前面两个挑战传导而来。前两个挑战导致我们要么面临一个比较复杂的网络,要么就是有更高的要求。如果我们以传统的运维方式去应对的话,必然会导致成本的急剧上升。当然,成本的提高,还有一个因素就是能耗。毕竟,5G的能耗要远高于4G的能耗。
针对上述这些挑战,我们要如何去应对呢?AI技术是关键。
(二)AI是提升电信网络自动化和智能化的关键技术
在运维成本方面,有统计显示,90%的运维都需要人工去参与,而70%的成本就是人力成本。在这种情况下,一个很自然的想法就是能不能使用AI的技术来降低人的成本,来提高运维效率。
比如刚才提到5G能耗问题,我们能否通过人工智能的技术来去降低能耗呢?从过往的实践经验来看,上述问题的答案是肯定的。
接下来,我们通过三个例子来说明。
文章图片
1. 基站节能 第一个例子是基站节能。基站的能耗是非常高的。在布网初期,基站用户较少,有时候基站常常是空开。针对这种情况,运营商的解决方案是对话务量做出一些预测。如果我们能精准预测话务量的话,那么,在话务量小的时候,我们就可以把一定量的载波关掉,从而达到节能的目的。据统计,在预测话务量的过程中,通过LSTM神经网络来做预测,可以实现节能10%以上。
2. 核心网KPI异常检测 【AIOps(企业运维新力量!)】第二个例子,是异常检测。在运营商的核心网部署KPI异常检测服务。原有的异常检测服务,是使用固定阈值进行告警通知。而AI技术,则更加智能、及时、准确地识别异常。
3. 故障识别及根因定位 通常网络上一旦发生故障,就会触发大量的告警,而系统同时又以高经纬维度进行运维派单。如果多个网员上报多个告警,那么就会出现这种重复派单。也就是说发生了一个故障,多网员上报告警,最后可能导致在多个域(无线域和传输域等)都去派单。
(三)开发AI应用仍然面临挑战:开发门槛高、周期长
从上面三个例子我们可以看出,AI相对来说,还是非常靠谱的。但是既然AI如此靠谱,为什么没有得到全面快速的应用呢?因为AI的开发还面临着不小的挑战,简单概括就是六个字:门槛高,周期长。
文章图片
上图是Gartner的一份研究报告。它从四个维度分析了AI应用的主要障碍。其中最主要的3点:
- 人员技能
- 理解增益与用途
- 数据范围与质量
小标题
- 门槛高
此处说的“门槛高”,第一点是指缺乏AI算法开发人员。一般的运维团队不会配置专门的AI算法开发人员,这样必然导致AI技能的缺失。
最关键的,也就是我们说的第二点,算法与业务结合难。如果要想把一个应用做好,最好的是从业务出发,根据业务的实际情况选择合适的算法,这样才能把应用做好。但在实际操作过程中,首先,我们需要有一个业务专家对运维要有深刻的理解;其次,还需要有一个精通AI的算法专家。在这之后,需要他们有充足的时间和意愿坐下来深入的交流。在这里,时间和意愿都会成为阻碍。
第三点是数据。数据包含两个问题:工程问题和标注问题。即,开发一个AI应用实际上是相当大的工程量,因为首先需要接入海量的多模态的数据去完成模型的训练和推理,最后还要去完成结果的展示,包括去对接一些现有的系统。因此除了前面需要的运维专家和算法专家,还需要很多工程开发人员。
2. 周期长 开发门槛高,就决定了开发周期长,毕竟有这么高的门槛,如果不能很好的解决的话,那么周期必然会特别长。开发周期长会导致:
第一,理解增益和用途。怎么理解呢?也就是说,如果我们长时间拿不到结果,那么企业决策人员就可能对AI能产生的效果会表示怀疑;
第二,时间越长,大家对项目的期望就会越高。假设同样是做一个东西取得了同样的效果,比如说故障修复时长降低5%,两年做出来的和一个月做出来的,得到的评价可能就完全不一样。
针对AIOps落地过程中遇到的挑战,华为推出的AIOps服务!现在我们一起来看看AIOps服务具体是什么,以及它是如何解决我们前面面临的挑战的。
华为AIOps服务
文章图片
上图是AIOps服务的整体框架。AIOps从下到上分成了四层:
第一层:数据的采集和治理。数据采集治理,听上去容易,做起来难,为什么呢?因为要面对的数据类型多,接口和数据类型也不统一。光去适配这些数据,都有可能累的焦头烂额。相对来说,华为AIOps服务首先支持通用的接口,然后对一些常见的设备都已经预置完成,最后能达到自动对接,数据自动治理的一个水平。
第二层:AI原子能力。华为AIOps共有二十多个原子能力,覆盖检测、预测、识别、诊断四大场景。原子能力不仅仅是AI算法的一个实现。每一个原子能力都经过实际局点数据的检验,针对具体的运营场景做过优化。同时,每一个原子能力也都融入了华为以前的运维经验,某些原子能力甚至能做到不训练可以直接使用。
第三层:编排能力。包括流程的编排和大屏的编排,还有RPA的编排。原子能力是AIOps智能运维的基础组件,流程编排操作简单灵活,只需从组件库中拖拽数据及AI运维能力进行组合,即可完成命令场景端到端的图形化编排,真正支撑合作伙伴拉低开发门槛,高效率的构建AI应用编排框架。
第四层:行业AI app。针对最典型的场景开箱即用。通过丰富的2D和3D可视化组件,如提供了超过30个图表控件,覆盖折线、拓扑、列表、柱形等样式,并提供多个地图控件、交互控件及媒体控件搭建。运维效果大屏时只需从组件库里拖拽出各类控件,按需组合自由布局、灵活配置应用的各种报表,辅助监控和分析,例如DIY微服务健康监控大厅,使其能够可视化,展示接口平均成功率、接口平均时延、接口失败率、接口调用次数等。同时提供KPI告警列表,为运营人员提供故障预警参考依据,拖拽所需控件号,对控件的样式,数据及交互进行个性化定制,使其满足展示要求。后端数据还可使用app组合流程里定义的各类中间数据。配置完成后即可一键预览和发布运维效果,大屏展示接口,平均成功率,接口平均时延,接口失败率,接口调用次数等,快速实现DIY可视化大屏。
(一)RPA助力AIOps对接现有运维系统
除了展示位,推理结果必须能够帮助进行故障的恢复。现阶段一般是对接现有的系统,比如工单系统(需要工单邮箱的人要去处理)、自动回复和问题单。如果通过人工去对接,费时费力并且容易出错。因此机器人流程自动化,也就是RPA服务,水到渠成。RPA服务可以完成数据的对接、搬运及工单的发放等等,减少人力投入,降低出错成本。
文章图片
(二)10+开箱即用的App,支持快速部署
针对一些最典型的场景,华为云AIOps把编排能力都已经提前准备好,也即,有十多种开箱即用的App,如园区网络、DC网络、IT应用、运营商网络等等场景全覆盖;灵活部署,支持公有云、HCS部署、On Premise部署、及云地协同等;开放生态,支持合作伙伴开发行业App,并将AI应用发布到AI市场,合作共赢,共建网络AI生态。
下面我们以“KPI异常检测”App来演示一下如何使用一个开箱即用的App。
第一步:导入网元列表;
第二步:配置性能、告警数据源;
第三步:数据源关联到App;
第四步:启动App;
第五步:查看大屏,分析故障。
文章图片
AIOps使能园区网络智能运维 那么AIOps是如何解决园区中实际运维的呢?
(一)园区网络建维模式
文章图片
上图为园区网络的两种建维模式:
2B和2C共用大网的OMC:当前的主流模式。企业去租用运营商的无线设备及其他的一些设备。这种模式的问题在于,终端由企业维护,网络由运营商维护,那么出现问题的时候很难分清责任;另外一个问题是,运营商侧的运维能力和组织构筑大网2C的O域,难以支撑企业内网高SLA,强化客户诉求。
2B和2C分开OMC(EMS):企业采购5G CPE、无线、核心网等全部设备进行维护,具备端到端的视图。从工信部发文、VDF、奥迪园区及企业SLA保障来看,企业租用运营商频谱或专用频谱自建5G网络会逐步成为主流。
(二)业务场景和痛点分析:园区客户需要简单易用、多域融合的网络运维
1. 典型网络现状
文章图片
上图是一个园区比较常见的一个视频检测的业务。我们可以看到,即便是一个最常见的业务,也大概十来个网元都会参与到其中,从5G的无线到传输到边缘计算,甚至是核心网,都会去参与其中。
2. 园区应用
文章图片
上图列出了园区里面常见的一些应用,包括边缘的AI检测、智能物流、室内定位等。所有的这些业务其实都和上一张图类似,即任何一个简单的业务都要涉及到多个域的参与。
那么园区与运营商运维的差异是什么呢?主要有以下三点:
用户:缺乏专业的通信知识,网络运维能力弱;
网络:组网相对简单,但涉及多域、无线、传接、数通、IT等;
SLA:生产系统网络端到端SLA合同要求高,7X24小时,99.99%。
因此,客户如果是园区运维的话,有如下痛点:
技能:5G 2B引入使得网络更加复杂,企业工程师缺乏相关技能,运维困难;
工具:缺乏有效的运维工具,复杂网络问题定位需要跨域专家现场会诊,成本高,耗时长。
总结来说,园区网络跨域设备需要实现数据融合,支撑端到端分析及呈现,最终实现企业ICT基础设施的统一运维。而园区网络涉及网络设备多,边界模糊,需要有统一的跨域定界定位能力,加速生产网络问题定位。
(三)传统人工、工具化运维不能满足园区网络新需求,急需智能化转型
文章图片
根据上图的数据,我们可以看到:
被动式运维:75%的问题都是由用户发现而非主动检测,如果由用户发现,那么用户很可能就会投诉;
自动化程度低:企业成本中70%的运营成本属于人力成本,成本激增;
故障解决困难:90%故障的恢复时间是用来做问题定位的,真正的问题修复时间占比非常小。
这样看来,无论是从效率还是效果这两方面去考虑,都有一个诉求就是引入人工智能去解决问题,使能网络运维的预测、分析、决策的自动化闭环。
(四)跨域故障定位算法流程
文章图片
上图是跨域故障定位的算法流程。整个流程如下:
输入:
- 告警:设备上报的告警;
- Topo:组网Topo结构;
- 故障传播图:告警间的影响关系。
- 降噪:过滤原始告警中的闪断、震断等数量多又无效告警;
- 聚合:对告警进行划分,将Topo不相关的告警分开,可能相关(属于同一故障)的告警聚合到一起,得到多个告警组;
- 识别定位:结合Topo、故障传播图,对每个告警组进行分析,识别出每个告警组中有几个故障,每个故障的根因网元和根因告警;
- 诊断:对于每个故障告警诊断出故障的类型,例如:电源中断。
- 故障的根因
- 故障设计的告警
- 故障类型
- 故障恢复建议
以上讲解了整个的算法流程,接下来,我们看看如果使用华为AIOps框架去实现算法流程。
1、快速配置数据源,编排流程 配置数据源:将无线、传输、核心网等多个域的告警接入,接入网络拓扑数据;
流程编排:通用已有的原子能力,快速进行流程编排。
文章图片
经过上述过程,可以完成“事件通知”功能,并将结果保存到记录集(即,数据库),用于大屏展示。效果图如下:
文章图片
打开其中一条告警,可以看到如下信息:
文章图片
AIOps部署建议 根据前述的实践,我们可以总结以下内容:
1、选定成熟场景,循序渐进部署AIOps
经过长期实践,我们对AIOps部署失败的主要原因做了如下总结:
数据上不来:数据分散在各个独立系统之上,缺乏综合采集管理手段。数据缺失,数据质量低下是造成AIOps效果欠佳的主要原因;
命令下不去:缺乏自动化运维工具,不能进行主动检测,恢复操作;
模型不智能:不能有效的积累日常运维中的标注信息,不能实现模型自学习。
因此,在部署失败的基础上,我们可以得出,如果要成功部署AIOps,我们需要:
从具备条件的成熟场景出发,循序渐进推进AIOps部署;
- 数据上的来,全面收集各种运维数据,提高数据质量;
- 命令下得去,AIOps后端对接现在自动运维工具,增强诊断手段和自动恢复能力;
- 有效积累标注数据,让AIOps模型能不断收到反馈,具备自学习能力。
针对不同类型的企业,AIOps服务的选择也是不尽相同,具体见下表:
文章图片
文章图片
华为AlOps服务降低网络AI应用开发门槛,加速网络AI应用落地。沉淀了10+开箱即用的智能APP,覆盖运营商网络、园区网络、数据中心网络和IT应用等应用领域。预集成丰富的AI原子能力,覆盖故障预测、检测、诊断、识别等环节。支持用户零编码开发AI应用,提升运维效率。
感兴趣就点击此处一起来体验一下吧~
点击关注,第一时间了解华为云新鲜技术~
推荐阅读
- 尽力
- Shell-Bash变量与运算符
- 2019-04-01|2019-04-01 幸运
- 人工智能|干货!人体姿态估计与运动预测
- 原来幸运一直都在
- 排序(归并排序)
- 你的善良里,藏着自己的运气
- 剑指|剑指 Offer 13. 机器人的运动范围(dfs,bfs)
- 日亚运营笔记--如何不花钱找差评()
- 野万的眼泪