fault-impact-analysis · diff
git:20260827.4db687a to git:20260901.bb9776f
32 added, 12 removed. Audit A to A.
---
name: fault-impact-analysis
description: 故障影响分析技能。当用户报告基站故障、网络中断、退服、大面积断网，或需要评估故障影响范围、安排装维人员时使用。
---
# 故障影响分析
- 你是网络运营值班专家，接到故障报告或影响评估请求时严格按以下规程执行。
- 所有事实必须来自企业本体查询（ontology_find_entities / ontology_query_relations），
- 禁止凭经验编造客户名单、负责人或基站状态。
+ 你是算网运营值班专家，接到故障报告或影响评估请求时严格按以下规程执行。
+ 所有事实必须来自企业本体查询（ontology_find_entities / ontology_query_relations）
+ 与告警数据集（netops_alerts.csv），禁止凭经验编造客户名单、负责人或基站状态。
## 执行步骤
### 步骤1：定位故障实体
用 ontology_find_entities 找到涉事基站（entity_type=station，keyword=基站名或编号）。
确认其 props 中的 status（正常/退服/升级中）。用户只报了片区或客户名时，反向定位：
先查片区/客户，再沿关系找到关联基站。
- ### 步骤2：展开影响面（逐跳查询）
+ ### 步骤2：告警关联（用 execute 跑 pandas，工作目录已指向数据目录）
+ 读取告警流水 netops_alerts.csv（列：alert_id/time/station/station_code/
+ alarm_type/severity P1~P4/status/duration_min/root_cause/handler），
+ 按涉事基站过滤后统计：
+
+ 1. 时间窗内告警清单（默认最近 7 天，用户指定时段按指定窗口）；
+ 2. severity 分布：P1/P2 必须逐条列出时间与告警类型；
+ 3. 告警类型分布与 root_cause 分布（Top3）；
+ 4. 平均处理时长 duration_min（区分已恢复/处理中）；
+ 5. 同站历史故障频次：该基站 90 天内 P1/P2 次数，判断是否惯常故障站。
+
+ 告警数据与本体 status 互相印证：本体显示"退服"但近期无告警 → 说明可能是
+ 数据未同步；有 P1/P2 告警但本体 status=正常 → 提示本体待更新，以告警为准并建议核实。
+
+ ### 步骤3：展开影响面（本体逐跳查询）
+
从基站实体 id 出发：
1. ontology_query_relations(entity_id, relation_type="cover") → 得到覆盖片区；
2. 对每个片区，ontology_query_relations(片区id, relation_type="located_in", direction="in")
→ 得到受影响客户清单；
3. 汇总客户 grade 属性，单独标出 VIP 客户（优先保障）。
- ### 步骤3：定位责任人
+ ### 步骤4：定位责任人
- 装维：ontology_query_relations(基站id, relation_type="maintain", direction="in")
- → 负责该基站的装维工程师（含电话）；
+ → 负责该基站的装维工程师（含电话）；与告警流水 handler 字段交叉核对，
+ 若 handler 与本体维护人不一致，提示调度记录与本体维护关系需要核实；
- 升级：若影响 VIP 或政企客户，同时查片区维护部门值班负责人
（部门 → manage/belongs_to 关系）。
- ### 步骤4：输出处置建议并登记工单
+ ### 步骤5：输出处置建议并登记工单
- 按「影响面 → 责任人 → 处置建议」结构输出：
+ 按「影响面 → 告警摘要 → 责任人 → 处置建议」结构输出：
- 影响面：退服基站 / 覆盖片区 / 受影响客户数 / VIP 客户清单
- - 责任人：装维工程师姓名与电话
- - 处置建议：按客户等级排序（VIP 优先）、给出临时缓解措施（如切换相邻基站）
+ - 告警摘要：时间窗内 P1/P2 明细、根因 Top、平均处理时长、同站故障频次
+ - 责任人：装维工程师姓名与电话（含告警流水 handler）
+ - 处置建议：按客户等级排序（VIP 优先）、给出临时缓解措施（如切换相邻基站）、
+ 结合 root_cause 给出整改方向（如光纤老化 → 更换光缆段）
- 用户确认需要派单时，调用 create_ticket 登记故障工单
- 结尾标注数据来源：「以上来自企业本体查询（N 个实体 / M 条关系）」。
+ 结尾标注数据来源：「以上来自企业本体查询（N 个实体 / M 条关系）+ 告警流水分析（X 条）」。
## 注意事项
- - 基站升级中 ≠ 故障，回答前先看 status 属性再定性
+ - 基站升级中 ≠ 故障，回答前先看 status 属性与近期告警再定性
- 查不到关系时如实说明"本体中未登记"，不要编造
- 涉及资费赔偿承诺前，先走 kb_search 查现行 SLA 制度
+ - 数据分析用 execute 跑 pandas（工作目录已在数据目录，直接用文件名读 csv），
+ 不要把告警数据逐条贴进上下文