掘金 后端 ( ) • 2021-06-22 11:31
.markdown-body{word-break:break-word;line-height:1.75;font-weight:400;font-size:15px;overflow-x:hidden;color:#333}.markdown-body h1,.markdown-body h2,.markdown-body h3,.markdown-body h4,.markdown-body h5,.markdown-body h6{line-height:1.5;margin-top:35px;margin-bottom:10px;padding-bottom:5px}.markdown-body h1{font-size:30px;margin-bottom:5px}.markdown-body h2{padding-bottom:12px;font-size:24px;border-bottom:1px solid #ececec}.markdown-body h3{font-size:18px;padding-bottom:0}.markdown-body h4{font-size:16px}.markdown-body h5{font-size:15px}.markdown-body h6{margin-top:5px}.markdown-body p{line-height:inherit;margin-top:22px;margin-bottom:22px}.markdown-body img{max-width:100%}.markdown-body hr{border:none;border-top:1px solid #ddd;margin-top:32px;margin-bottom:32px}.markdown-body code{word-break:break-word;border-radius:2px;overflow-x:auto;background-color:#fff5f5;color:#ff502c;font-size:.87em;padding:.065em .4em}.markdown-body code,.markdown-body pre{font-family:Menlo,Monaco,Consolas,Courier New,monospace}.markdown-body pre{overflow:auto;position:relative;line-height:1.75}.markdown-body pre>code{font-size:12px;padding:15px 12px;margin:0;word-break:normal;display:block;overflow-x:auto;color:#333;background:#f8f8f8}.markdown-body a{text-decoration:none;color:#0269c8;border-bottom:1px solid #d1e9ff}.markdown-body a:active,.markdown-body a:hover{color:#275b8c}.markdown-body table{display:inline-block!important;font-size:12px;width:auto;max-width:100%;overflow:auto;border:1px solid #f6f6f6}.markdown-body thead{background:#f6f6f6;color:#000;text-align:left}.markdown-body tr:nth-child(2n){background-color:#fcfcfc}.markdown-body td,.markdown-body th{padding:12px 7px;line-height:24px}.markdown-body td{min-width:120px}.markdown-body blockquote{color:#666;padding:1px 23px;margin:22px 0;border-left:4px solid #cbcbcb;background-color:#f8f8f8}.markdown-body blockquote:after{display:block;content:""}.markdown-body blockquote>p{margin:10px 0}.markdown-body ol,.markdown-body ul{padding-left:28px}.markdown-body ol li,.markdown-body ul li{margin-bottom:0;list-style:inherit}.markdown-body ol li .task-list-item,.markdown-body ul li .task-list-item{list-style:none}.markdown-body ol li .task-list-item ol,.markdown-body ol li .task-list-item ul,.markdown-body ul li .task-list-item ol,.markdown-body ul li .task-list-item ul{margin-top:0}.markdown-body ol ol,.markdown-body ol ul,.markdown-body ul ol,.markdown-body ul ul{margin-top:3px}.markdown-body ol li{padding-left:6px}.markdown-body .contains-task-list{padding-left:0}.markdown-body .task-list-item{list-style:none}@media (max-width:720px){.markdown-body h1{font-size:24px}.markdown-body h2{font-size:20px}.markdown-body h3{font-size:18px}}

​​​​​​​​​​​​​​​​摘要:企业运维需求及挑战,来看看华为 AIOps 如何解决!

本文分享自华为云社区《【云驻共创】AIOps?企业运维新力量!》,原文作者:启明。

国际惯例,我们先介绍一下 AIOps 的概念:AIOps,即 ArtificialIntelligence 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. 成本压力

成本压力主要是由前面两个挑战传导而来。前两个挑战导致我们要么面临一个比较复杂的网络,要么就是有更高的要求。如果我们以传统的运维方式去应对的话,必然会导致成本的急剧上升。当然,成本的提高,还有一个因素就是能耗。毕竟,5G 的能耗要远高于 4G 的能耗。

针对上述这些挑战,我们要如何去应对呢?AI 技术是关键。

(二)AI 是提升电信网络自动化和智能化的关键技术

在运维成本方面,有统计显示,90%的运维都需要人工去参与,而 70%的成本就是人力成本。在这种情况下,一个很自然的想法就是能不能使用 AI 的技术来降低人的成本,来提高运维效率。

比如刚才提到 5G 能耗问题,我们能否通过人工智能的技术来去降低能耗呢?从过往的实践经验来看,上述问题的答案是肯定的。

接下来,我们通过三个例子来说明。

1. 基站节能

第一个例子是基站节能。基站的能耗是非常高的。在布网初期,基站用户较少,有时候基站常常是空开。针对这种情况,运营商的解决方案是对话务量做出一些预测。如果我们能精准预测话务量的话,那么,在话务量小的时候,我们就可以把一定量的载波关掉,从而达到节能的目的。据统计,在预测话务量的过程中,通过 LSTM 神经网络来做预测,可以实现节能 10%以上。

2. 核心网 KPI 异常检测

第二个例子,是异常检测。在运营商的核心网部署 KPI 异常检测服务。原有的异常检测服务,是使用固定阈值进行告警通知。而 AI 技术,则更加智能、及时、准确地识别异常。

3. 故障识别及根因定位

通常网络上一旦发生故障,就会触发大量的告警,而系统同时又以高经纬维度进行运维派单。如果多个网员上报多个告警,那么就会出现这种重复派单。也就是说发生了一个故障,多网员上报告警,最后可能导致在多个域(无线域和传输域等)都去派单。

(三)开发 AI 应用仍然面临挑战:开发门槛高、周期长

从上面三个例子我们可以看出,AI 相对来说,还是非常靠谱的。但是既然 AI 如此靠谱,为什么没有得到全面快速的应用呢?因为 AI 的开发还面临着不小的挑战,简单概括就是六个字:门槛高,周期长

上图是 Gartner 的一份研究报告。它从四个维度分析了 AI 应用的主要障碍。其中最主要的 3 点:

  • 人员技能

  • 理解增益与用途

  • 数据范围与质量

这就回到我们说的六个字:门槛高,周期长。

1. 门槛高

此处说的“门槛高”,第一点是指缺乏 AI 算法开发人员。一般的运维团队不会配置专门的 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 框架实现算法流程

以上讲解了整个的算法流程,接下来,我们看看如果使用华为 AIOps 框架去实现算法流程。

1、快速配置数据源,编排流程

配置数据源:将无线、传输、核心网等多个域的告警接入,接入网络拓扑数据;

流程编排:通用已有的原子能力,快速进行流程编排。

经过上述过程,可以完成“事件通知”功能,并将结果保存到记录集(即,数据库),用于大屏展示。效果图如下:

打开其中一条告警,可以看到如下信息:

AIOps 部署建议

根据前述的实践,我们可以总结以下内容:

1、选定成熟场景,循序渐进部署 AIOps

经过长期实践,我们对 AIOps 部署失败的主要原因做了如下总结:

数据上不来:数据分散在各个独立系统之上,缺乏综合采集管理手段。数据缺失,数据质量低下是造成 AIOps 效果欠佳的主要原因;

命令下不去:缺乏自动化运维工具,不能进行主动检测,恢复操作;

模型不智能:不能有效的积累日常运维中的标注信息,不能实现模型自学习。

因此,在部署失败的基础上,我们可以得出,如果要成功部署 AIOps,我们需要:

从具备条件的成熟场景出发,循序渐进推进 AIOps 部署;

  • 数据上的来,全面收集各种运维数据,提高数据质量;

  • 命令下得去,AIOps 后端对接现在自动运维工具,增强诊断手段和自动恢复能力;

  • 有效积累标注数据,让 AIOps 模型能不断收到反馈,具备自学习能力。

2、选择成熟的 AIOps 服务

针对不同类型的企业,AIOps 服务的选择也是不尽相同,具体见下表:

​华为 AlOps 服务降低网络 AI 应用开发门槛,加速网络 AI 应用落地。沉淀了 10+开箱即用的智能 APP,覆盖运营商网络、园区网络、数据中心网络和 IT 应用等应用领域。预集成丰富的 AI 原子能力,覆盖故障预测、检测、诊断、识别等环节。支持用户零编码开发 AI 应用,提升运维效率。

感兴趣就一起来体验一下吧~ www.hwtelcloud.com/products/ai…

点击关注,第一时间了解华为云新鲜技术~