无线接入网故障vs智能运维

运营商的网络越来越庞大、复杂。

网络中包含大量的、不同功能、不同业务域、不同厂商、不同型号的设备。各运营商网络的组网协议、拓扑形态也不一样，且各设备数据格式、传输协议、对网络状况的响应也不统一。

受上述种种因素的影响，运营商网络的运维愈发困难。在网络实施、业务编排、可用性保障、安全保障等这些运维事项中， 故障处理是核心 、是保障网络业务持续可用非常重要的一环，同时也是其中最棘手的工作。

图 1 无线接入网示意图

无线接入网场景是故障处理的重中之重，其处理成本甚至占到整个运营商网络维护成本的95%左右。图1为一个典型的无线接入网简单示意图。在该网络中，通常有三个业务域的设备：动力环境域（动环）、无线域、接入传输域。

接入传输域常见的网络结构如下图中绿色标号所示：1、接入环；2、耳朵环；3、汇聚环。机房中电机、电池等动力设备给机房中基站、传输设备供电；基站通过一跳跳的传输设备回传数据到核心网（如图中红色曲线箭头所示）。

无线接入网中故障有如下三个特点：

因此，运维工程师仅仅基于网管收集的告警来直接分析、处理故障非常困难。当网络中产生若干个故障时，工程师能基于其经验去分析、定位并处理。然而现网一直在产生故障，从各设备来的告警源源不断地到达综合网管。过不了一会儿，工程师就看不下去、“拒绝服务”了。典型的“DDOS攻击”套路！

图 2 机房停电故障时，可能产生的告警

面对这样的困境，华为网络人工智能NAIE团队尝试用人工智能技术解决网络运维工程师的困难。

思路是当网络中发生故障后，AI服务基于实时的事件流（如告警、KPI异常事件、日志异常事件等）、拓扑数据，快速地聚合故障相关信息，准确地定界定位故障根因、识别影响，给出故障分析结果及修复建议。

故障处理不是新课题。运维工程师实际处理故障时也不直接面对全量告警。现有的做法通常有两类：

1）白名单过滤，只看重要告警；

2) 基于告警压缩规则压缩，灵活过滤呈现重要告警。

这两种做法本质上还是看告警，而且是过滤后碎片化的告警。如前所述，一个故障对应多种告警。随着拓扑、位置不同，故障还能产生不同的影响。那么过滤后的告警，究竟是属于同一个故障还是多个呢？是原因还是现象呢？工程师还是得凭借自己丰富的经验、基于片段信息来判断。这类做法是治标，如管中窥豹，唯资深运维专家可“猜”一斑。

 图 3 基于故障处理故障

何为治本？基于收集的信息，去还原故障本来的面目。

如图3所示，华为网络人工智能NAIE识别故障、呈现其原因、影响范围，让工程师按图索骥：基于故障本身来修复故障。即，我们不再以告警“压缩率”为目标，而是以工程师便捷、准确地定位、修复故障为目标。让工程师从面向告警转变为面向故障，力图故障处理不重复、不错漏、不“麻烦”！

治本的构想很好，实际怎么来实现呢？

我们在实践过程中总结有两个关键点：其一，一定要从业务问题本身出发去抽象、建模，屏蔽不同局点、不同组网等对算法方案带来的影响；其二，制定统一的处理范式，匹配落地合适算法。

算法是工具，实际业务问题才是着手点。各运营商网络的不同（设备、协议、组网、厂商等）和复杂性就注定其故障分析较困难。我们要从业务出发去抽象，屏蔽不同，抽取算法需求。例如，告警达到网管无序、故障持续时长不定（随类型、位置、拓扑而不同），那我们应该动态预测故障时长，保障故障信息聚合准确。例如，有的局点拓扑成环、有的为树形，那我们的算法不应嵌入具体拓扑形状信息，而应适用不同拓扑形状。例如有的局点有独立的动环系统、有的则无，那我们为每个机房都虚拟一个动环网元，保证后续处理一致。只有当我们把这些不同屏蔽好，我们的算法方案才是通用的。

图 4 故障智能分析处理范式

基于上述抽象后的业务问题，我们定义了一套处理范式，如图4所示。故障智能分析过程含4个主要步骤：

1.     去噪：初步的信息过滤。例如施工区域告警屏蔽、震荡、闪断告警识别过滤等。

其中关键步骤在于故障聚合以及识别定位。聚合要根据拓扑、时间等信息将一个故障可能相关的事件数据打包在一起，其准确性是后续识别定位准确的基础。由于网络延迟等因素，聚合还要能容忍一定的时间不准确以及乱序问题。这其中涉及一些聚类、拓扑图搜索、流式数据处理等算法。识别定位可以当作分类问题来处理。即，其中预测聚合的数据中哪个网元、哪个告警是根因。然而很多客户并不喜欢这种黑盒处理的方式，且无标注良好的样本数据。此时，基于故障传播图的白盒化故障分析则更合适。上述4步，每步都可以有若干算法可以尝试。在实际的故障分析项目中，我们应该根据实际需求落地合适算法，一味的追求某种技术往往适得其反。