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

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

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

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

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 定位」能够报出这两台设备，这说明他在故障定位中会更准确一些。

2.4    让 LLM 给出故障定位的推理逻辑

甚至，我们还可以让 LLM 告诉他的故障定位的推理过程。

如果使用代码把推理过程写出来，还是比较困难的，因为代码基本就是 if-else 流程。但是如果是 LLM ，就容易多了。我们可以在提示词输出格式中加上「推理逻辑：{推理逻辑}」，也就是告诉 LLM 需要把推理过程输出出来。看一个例子：

在上图这个例子中，整个故障包含了流量下降和白盒日志等事件，这些事件都涉及 BD-XXXXXXXXX-SC-XXXXXXXXX-37.Int 这台设备，所以这台设备出现故障的可能性很大，同时没有传输告警等其它事件的干扰，能够进一步确定是这台设备出现了故障。

实际上，我们可以使用各种大语言模型进行推理，不限于文心，比如 Llama 2。

所以我们还可以采用多智能体的方式，进一步提高故障定位的准确率。比如为每一款 LLM 大语言模型制作一个智能体，多个智能体同时进行定位，然后综合多个智能体的结果进一步定位。

2.5    多智能体辅助定位

在实践中，我们采用了双智能体的方式，主智能体是文心大模型（ernie-4.0-8k），辅助智能体是 Llama\_2\_70b。

1. 首先，我们让文心大模型推理出一个结果 L1；
2. 然后，让 Llama 2 模型推理出一个结果 L2 和推理过程 R1；
3. 对比 L1 和 L2 结果。如果两者一样，说明两个大模型的推理是一致的，返回这个结果；
4. 否则， 把 L2 和 R1 扔给文心大模型，并告诉它这是 Llama 2 的推理结果和推理过程，让它再一次推理，得到结果 L3；
5. 最后返回 L3。

比如下面的一个故障， 是上述过程 3 的一个展示。

下面这个例子是上述过程 4 和 5 的展示。第一次定位，文心大模型和综合定位的结果相同，但是和 Llama2 的结果不同，所以将 Llama2 的结果和推理逻辑扔给文心大模型后再次定位，得到了和 Llama2 相同的结果，这也和实际情况相同：

针对多智能体辅助定位这个功能，我们做成了一个按需调用的工具，只是用来做观察和调优。如果发现文心大模型的单次 AI 定位不准确的话，我们就会使用这种多多智能体辅助定位的方式，以便优化文心大模型的单次定位效果。

3    总结与展望

目前，百度智能云已经在骨干网网络质量监控中引入了 AI 定位的能力，并且取得了不错的效果。我们正在将这个能力推广到机房的物理网络故障定位、网关的故障定位等场景。

同时，我们的 AI 定位能力还可以进一步优化，比如为大模型提供网络的拓扑信息、增加更多的告警来源等，让 AI 定位更精准。

——————END ——————

推荐阅读

彻底解决网络哈希冲突，百度百舸的高性能网络 HPN 落地实践

百度Feed业务数仓建模实践

大模型时代数据库技术创新

低代码组件扩展方案在复杂业务场景下的设计与实践

通过搭建 24 点小游戏应用实战，带你了解 AppBuilder 的技术原理