网络故障根因定位

1客户嘴上要的

「网管中心每次大故障都有几千条告警，监控员找根因要很久。上一个大模型，读告警，自动定位根因。」

这是症状或现成方案，不一定是真问题。下面看两种做法。

2照字面做，会怎么烂

3好 FDE 的实际走法

共 6 周，分 5 个阶段。带三角标记的是这一步最容易踩的坑。

1. 1

   第 1 周在监控大厅看两次真实故障

   • 跟省网管中心 3 个监控员各坐一个班，正好遇到两次故障。看他们怎么做：先按经验在综合网管里筛告警，再到资源管理系统查光缆、传输电路和基站的连接关系，判断哪个是源头。
   • 发现：一次光缆中断产生约 2000 条告警，涉及传输、无线、核心多个专业。监控员会推理，但资源系统的拓扑不可靠：抽查 100 条电路，约 20% 和现网不一致，原因是割接后没有及时更新。监控员只好打电话问地市维护人员。
   • 真问题不是「推理能力」，是「拓扑数据不准，告警无法自动关联」。成功标准改成：一次故障的告警压缩成 ≤ 20 个关联事件；派单时定位到正确专业和站点的比例 ≥ 85%；故障定位时长 30 分钟 → 10 分钟。
2. 2

   第 2 周定范围 + 推动资源数据治理

   • 砍范围：只选一个地市的传输和无线网络做试点。
   • 资源数据归网络部资源管理中心，日常更新靠地市维护人员。好 FDE 的动作是：用两次故障复盘的数据，请网络部负责人定一条规则——割接完成后必须在规定时间内更新资源系统，并对试点地市的电路做一次集中核查。
   • 踩坑不要试图用算法「猜」出正确拓扑。数据错了就修数据，修不了的范围先不做。
3. 3–4

   第 3–4 周原型：规则关联 + 模型写摘要

   • 关联用规则：根据核查后的拓扑，把同一时间窗内、有上下游关系的告警归成一个事件，并标出最上游的告警作为疑似根因。
   • 大模型只做两件事：把事件写成派单用的故障摘要（影响范围、疑似根因、相关告警）；从历史故障案例库中找相似案例，附上当时的处理方法。
   • evals：取试点地市近一年 50 次影响较大的故障（如光缆中断、传输环网中断），回放告警，比对系统给出的疑似根因和实际故障单里的根因，要求一致率 ≥ 85%。
   • 踩坑不同厂商网管的告警名称和级别不同。先建一张告警标准化对照表，否则同一类故障会被拆成多个事件。
4. 5

   第 5 周Demo + 并行运行

   • 在监控大厅并行运行 3 周。监控员本人按原方法处理故障，同时看系统结果，事后标记「对 / 错 / 有帮助」。
   • 并行第一周，有 3 次故障系统给错了根因。复盘发现原因相同：那几条电路割接后还没更新进资源系统。这反过来证明了第 2 周那条规则的必要性，网络部据此加快了试点地市的核查。
5. 6

   第 6 周交接交接

   • 并行运行在交接后继续 2 周，FDE 每周看一次结果。并行结束时，由下面的监控值班长按成功标准验收：告警是否压缩到 ≤ 20 个事件、派单定位正确率是否 ≥ 85%、定位时长是否到 10 分钟，再决定是否作为正式派单依据。
   • 交接给网管中心一位监控值班长：负责关联规则和告警对照表的维护；资源管理中心负责拓扑数据质量，每月发布试点地市的核查结果。运行手册写清：系统给出的根因和实际不符时，先查拓扑是否已更新。

4这个案例教给你的可复用判断