FA 告警归并：数据验证与分析方法调研

日期：2026-07-03 | 状态：初版调研 | 对应场景全景 Tier 2

---

1. 调研背景

本调研源于对某酒店项目一周告警数据（6/22~6/29，60条）的分析尝试，目标为 Tier 2「多系统告警智能归并与根因推断」提供数据基础和方法论验证。

2. 关键发现：数据典型性不足

2.1 数据量稀疏

时段	告警记录数	说明
6/1~6/21	35条	日均 ~1.7 条
6/22~6/29	60条	其中 59 条集中在 6/28 20:21~20:27
合计	95条	—

2.2 告警类型单一

全部 95 条记录均为同一告警类型——"设备离线"，缺少异质告警的交叉验证场景（如温度异常 + 烟感误报 + 能耗突降 + 设备故障）。

2.3 实际可用的"多系统告警归并"训练/验证数据几乎为零

• 真正的多系统归并需要：BA 告警 + 安防告警 + 能耗告警 + 设备故障告警，且之间存在因果关联
• 当前数据仅覆盖 BA 系统的一个子集（设备离线），无法验证归并逻辑
• 唯一可用的归并案例是 6/28 的大规模停电事件——60 条告警归并为 1 个根因

3. 分析方法论原型（Skill v2.0）

在分析过程中沉淀了一个通用告警 CSV 分析脚本 scripts/alarm_insight_analyzer.py，核心能力：

模块	功能
动态列清洗	自动检测 UUID 列、常量列并删除（非固定规则）
空间解析引擎	从告警源名称 + remark 中提取楼层、塔楼、功能区域
根因推断引擎	基于时间爆发集中度、恢复统一度、设备类型分布做规则打分
受影响设备提取	从 remark 中解析具体设备编码，按告警源汇总
人话版报告	事件概述 → 根因推断 → 空间地图 → 时间线 → 处置建议

该脚本已作为参考原型保存到 scripts/，但不推荐直接用于生产——需要真实的多源告警数据做验证和调优。

4. 对 Tier 2 的启示

4.1 当前阶段最大瓶颈不是算法，是数据

• 告警归并的核心是因果链推理，而构建因果链需要足够多的异质告警共现样本
• 当前样本集中 95 条数据 ≈ 1 个事件 + 零星离线，远不足以训练或验证任何归并模型
• 建议：先拉取目标客户 ≥ 1 个月的完整告警日志（含 BA / 安防 / 能耗多系统），再做数据摸底

4.2 触发机制需要单独设计

三种候选方案：

方案	描述	适用场景
时间窗口聚合	每 N 分钟窗口内的告警做一次归并	爆发式告警（如断电）
设备拓扑驱动	同设备链路或同区域的告警自动关联	设备级联故障
规则 + LLM 混合	规则引擎做第一层过滤，LLM 做第二层归并	高吞吐场景

需要更多实际数据来判断各方案的性价比。

4.3 分析方法论可复用的部分

即使缺乏异质告警数据，当前脚本的以下能力可立即用于产品：

• 空间维度提取：从设备名称/编码中自动识别楼层、区域、塔楼
• 告警聚合：按时间窗口 + 空间节点将散告警聚为"事件"
• 报告生成模板：事件概述 → 影响评估 → 处置建议 的报告结构

5. 附属产出物

文件	位置	说明
alarm_insight_analyzer.py	scripts/	分析脚本原型
download_insight_report.md	01-调研/	基于 60 条数据的示例报告
download.csv	02-数据样本/	原始数据（酒店项目）
download_cleaned.csv	02-数据样本/	清洗后数据