百度智能云将大模型引入网络故障定位的智能运维实践

百度Geek说

于 2024-07-16 10:00:16 发布

阅读量497

点赞数 17

文章标签：百度运维 dubbo

本文链接：https://blog.csdn.net/lihui49/article/details/140457985

版权

物理网络中，某个设备发生故障，可能会引起一系列指标异常的告警。如何在短时间内从这些告警信息中找到真正的故障原因，犹如大海捞针，对于运维团队是一件很有挑战的事情。

在长期的物理网络运维工作建设中，百度智能云通过各种平台数据的综合分析实现了快速故障定位。近期，更是将大模型成功引入物理网络的故障定位中。相比过去传统的定位分析方法，大模型给网络故障定位的能力建设带来了很多改变。

接下来我们将简单介绍百度智能云在物理网络故障定位的发展历程，然后详细分享如何基于大模型进行故障定位的最新实践。

1 物理网络故障定位发展历程

在多年的网络运维工作实践中，百度智能云建设起了各类指标监控分析平台：

白盒监控：基于交换机日志的故障发现和定位平台；
黑盒监控：基于自探测的故障发现平台；
多平面监控：基于骨干网平面的监控，可以提供骨干网设备级别的告警和故障定位；
流量监控：基于流量突变的故障发现平台；
传输监控：提供传输网络的监控告警；
变更单平台：变更操作平台，可以查询变更记录；
AAA 审计平台：提供身份认证和审计的平台，可以查询操作人和操作命令。

1.1 人工定位

这些监控平台都有独立的故障发现和告警能力。他们之间的数据相互独立，没有实现很好的联动。同时，单个的故障发现平台不可能达到 100% 的定位的准确率，在大规模实践中容易出现误判的现象。

假设单个平台的准确率是 80% 的话，两个平台（假定他们不相关）同时定位到同一个设备，那么故障定位的准确性可以达到 96%，如果三个不相关的平台都定位到同一个设备，那么这个设备故障的可能性高达 99.2%。所以综合多个平台的定位结果，可以极大的提高定位的准确性。

所以，在过去一段时间，如果遇上单个监控平台无法提供明确定位信息的情况，我们还会人工收集各个监控平台的数据，然后借助运维人员的经验进行研判以保证定位的准确性。

1.2 综合定位

2024 年初，我们围绕物理网络运维「发现-定位-止损」的三大步骤，实现了故障处理流程的自动化操作。其中，「后羿故障定位」平台综合了白盒监控、黑盒监控、流量监控、传输监控、变更单记录、trace 2.0、多平面监控等各种信号源，通过算法进行「综合定位」，实现了故障定位的自动化，并提高了故障定位的准确性。

同时，由于「综合定位」对定位准确性的进一步提高，我们还构建起了「自动止损」能力，做到了快速排除业务故障，将故障对业务的影响时间大幅缩短。

其中，「综合定位」基于黑盒的告警触发。后羿平台会收集各个信号源的数据，基于时空的关联将可疑的信号捞取出来，按照算法进行分析。比如发生交换机的板卡故障的时候，黑盒会监控到丢包现象，这时候后羿平台就会检查白盒中是否存在板卡故障事件、流量监控中是否存在突降告警、trace 路径上是否出现无回包的现象、某个特定平面是否会丢包等数据，然后综合这些信号源判定有否故障发生。

我们在后羿平台上实现了面向多信号源的综合分分析和故障定位能力，流程和算法大致如下：

根据黑盒告警，确定故障域，将故障的范围尽可能地缩小；
基于这个故障域，查询各个平台时空关联度强的告警，得到一批「候选」的故障设备；
同时触发实时定位的工具如 traceroute、流统等，也将得到一批「候选」的故障设备；
在这些「候选」的故障设备的基础上，结合告警类型的优先级、设备的频次、设备的层级等，推断出故障的设备或者网络链路；
推出定位结果，比如事件单平台、告警电话等，并联动自动止损功能。

1.3 AI 定位

但是，虽然「综合定位」可以大幅提高定位精度，但是也存在一些局限：

为了提高准确率，需要付出更多分析和设计，逻辑复杂度变成指数级的的增长；
复杂度的增大增加了代码维护的难度；
不方便加入新的故障定位逻辑，涉及代码的更改和部署上线；
运维同学期望平台能够给出每次故障的推理过程，而使用代码难以把复杂的分析过程描述清楚。

由于大语言模型非常适合进行推理和分析，所以如果我们在故障定位中成功引入大数据模型，可以预见的好处是：

基于 LLM 的强大的推理能力，可以从各种信号源中找到最有可能的故障设备或者故障链路；
LLM 可以给出推理细节，详细介绍为什么故障分析会推断到某个设备，而代码缺少这种能力；
便于维护和演化，一旦推理错误，我们可以及时且方便调整推理策略，立即发布和执行；
更方便测试，我们可以直接将提示词在文心一言等大模型应用中测试和优化。

接下来将大家介绍在「后羿故障定位平台」中，我们如何采用结构化提示词和多智能体方式逐步调优 LLM 的推理和定位。

2 基于 AI 进行网络故障定位实践

当前，我们基于文心大模型（ernie-4.0-8k）进行 AI 定位。在定位结果中同时提供综合定位和 AI 定位的结果进行效果对比。

在进行 AI 定位前，我们需要对数据进行预处理。首先，我们对告警的数据进行归一化的处理，剔除重复的数据，不合理的告警等。然后定义各种告警的权重，比如常态有设备 CRC 的告警，我们就会将其权重降低；有些低级别的白盒基础事件权重就很小。这样我们就能保证 AI 能够依据告警优先级进行推理。

2.1 结构化提示词的应用

结构化的提示词可以充分发挥大模型的潜力。我们面向物理网络故障定位场景，摸索出了一套合适的结构化提示词模版。

角色

首先假定 AI 的角色，假定它是某个领域的专家。

你是一位网络监控和分析定位专家，擅长从各种告警信号中识别出故障设备或光缆故障。

任务

要给它明确的任务，让它清晰地知道做什么事。

以下提供一组设备故障时的报警信息，你需要根据这些报警信息，找出故障设备或光缆故障。

奖赏

据说加上奖赏后 AI 会更加卖力，所以可以尝试加上奖赏的结构。

年底会给你最高的绩效，并且我每次定位的支付费用会翻 100 倍。

输入格式（示例）

需要明确提供数据的格式，最好能够提供示例。

每条报警信息包含三个字段：报警类型、故障设备、故障描述（可为空）。字段之间用逗号分隔。每行包含一条报警信息，例如：

white_box_event,HD-M2NJ-111111.Int,流量下降

white_box_event,HD-M2NJ-222222.Int,

white_box_event,HD-M2NJ-33333.Int,流量下降

white_box_event,HD-M2NJ-44444.Int,

B1_mutiple_plane,光缆故障,

B1_mutiple_plane,光缆故障,

规则

你可以给 AI 一定的规则，让 AI 在这个规则内进行推理。比如下面的优先级规则：

优先级规则如下：

1. 每种报警类型的优先级不同，优先级越高，设备故障的可能性越大，但是这些告警都要综合考虑。

2. 同一设备的不同报警类型越多，该设备故障的可能性越大，但同一类型的报警只算一次。

3. 同一类型的光缆故障只算一次。

…

7. 不管怎么样，最终结果务必给出一个结论。

输出格式

你可以指定输出的格式，方便处理结果。比如下面的格式要求 AI 只输出定位结果:

只需要按照下面的格式输出推断结果，一定不要输出推理逻辑：\n 故障设备: {故障设备}

你还可以让 AI 输出推理过程，分析 AI 是怎么推理出这个结果的，方便后续的优化：

按照下面的格式输出推断结果：\n 故障设备: {故障设备}\n 推断逻辑: {推断逻辑}

2.2 一个 AI 定位的例子

按照这个结构化提示词的模版，加上各种处理过后的信号源，我们就可以为每一个告警事件构建相关的提示词，然后通过百度智能云的千帆大模型平台，调用文心大模型（ernie-4.0-8k）进行推理分析。大模型故障定位的结果如下：

2.3 AI 定位和综合定位的结果对比

通过跟踪每天的告警，我们可以比较「综合定位」的结果和「AI 定位」的结果：

比如编号 171728 这个故障，「综合定位」研判它是 BD-XXXXXX-LE-1-XXXXXX 设备抖动，它是一台 LEAF 设备。AI 定位研判它是 BD-XXXXXX-LE-1-XXXXXX 和 BD-XXXXXX-SP-4-XXXXXX 这两台设备的抖动。通过比较可以发现，「AI 定位」比「综合定位」多定位出了一台 SPINE 设备。

实际上，故障就是是这台 SPINE 设备和这台 LEAF 设备之间的链路抖动，影响了这条链路的两头的端口，所以「AI 定位」能够报出这两台设备，这说明他在故障定位中会更准确一些。