凌晨两点的网管大厅，投影墙上告警刷新的速度比值班员翻页的速度还快——这不是电影桥段，而是无数运营商NOC（网络运营中心）的日常。告警风暴（Alarm Flood）是运维行业最古老、也最被低估的顽疾：故障来临时，真正需要人动手的告警被淹没在上万条衍生告警里。本文以一次典型告警风暴之夜为线索，对照EEMUA 191、ISA-18.2、ITU-T X.733、3GPP TS 32.111 与 IETF RFC 8632 五份权威文献给出的量化标准与数据模型，拆解告警风暴的成因、人的处理极限，以及一套可以直接落地的“定义—归并—屏蔽”三板斧治理方法。
先讲一个案例。为避免对号入座，案例细节已做脱敏与典型化处理，但每一个环节都是国内运营商网络里反复真实发生的场景。
事情发生在某省NOC的一个周四凌晨。23:40，承载网一对核心汇聚路由器在做软件升级回退，回退过程中BFD会话抖动。23:41开始，该 Pair 下挂的两台汇聚、十几对上联端口集体报 Link Down/Link Up 翻转；23:45起，靠这对汇聚接入的三百多个基站回传中断，无线侧 OMC-R 开始疯狂上报小区退服、S1 断链、X2 不可用；0:10，附着在这批基站上的 VoLTE 用户开始拨测失败，核心网侧信令 proces alarm 也跟着冒出来。到 1:30 事件收敛时，北向接口累计入库告警约两万条，其中与根因直接相关的“一对路由器回退失败”只有一条。
值班员小周当晚的动作很有代表性：前五分钟还在逐条确认，十分钟后屏幕刷新速度已经超过人眼阅读速度，他做的唯一正确动作是拉起电话叫醒了传输班长——而他判断根因靠的不是告警系统，而是自己的记忆：“这对路由器昨晚在割接。”告警系统在他眼里，那时候只是一面噪音墙。
把这一晚画成时间线，是这样的：
| 时间 | 事件 | 告警表现 |
|---|---|---|
| 23:40 | 核心汇聚路由器割接回退 | 设备级告警十余条（真正的根因） |
| 23:41 | BFD/端口翻转开始 | 链路告警数百条，抖动型告警反复翻转 |
| 23:45 | 下挂基站回传中断 | 小区退服、S1断链告警数千条（级联告警） |
| 00:10 | VoLTE用户感知 | 拨测/MOS类质量告警（衍生告警） |
| 01:30 | 人工定位根因，暂停回退 | 告警停止增长 |
| 02:00+ | 恢复完成后 | 两万条告警等待人工翻牌确认 |
两万条告警里，该看的其实只有第一条。这就是告警风暴的本质：信息总量爆炸，有效信息密度趋近于零。
要理解告警为什么失控，得先看告警体系是怎么建起来的。这一段历史，RFC 8632（IETF 2019年9月发布的《A YANG Data Model for Alarm Management》，作者Stefan Vallin与Martin Bjorklund）在附录F里做过系统梳理，非常值得读。
电信网管告警的祖师爷是1992年发布的 ITU-T X.733《告警上报功能》。它定义了我们今天熟悉的一切：严重级别（indeterminate/warning/minor/major/critical）、事件类型（通信告警、QoS告警、设备告警、环境告警等）、可能原因（probable cause）枚举。3GPP后来在 TS 32.111 系列里把它演进成 Alarm IRP，成为所有运营商网管北向接口的事实基础。
但X.733有个先天设计取向：它把告警建模为一条条独立的通知（notification），而不是资源的状态（state）。这正是问题开始的地方。RFC 8632 在附录F里点破了这个区别：X.733的告警列表是“通知的流水账”，而新一代模型认为“告警是资源上的一个状态”——（资源， 告警类型）这个组合就是一个告警实例，后续的通知只是对这个实例的更新（升级、降级、清除），而不是新开一条记录。
这个区别为什么致命？看一个每个无线维护工程师都见过的场景：某RRU的驻波告警因为天馈进水，一晚上翻转了几百次。在“通知流水账”模型下，这就是几百条告警记录；而在“状态”模型下，它只是一个告警实例带一个状态变更历史。RFC 8632 为状态变更历史给了个默认上限——32条（max-alarm-status-changes 默认值），超出就滚动覆盖，等于官方都默认“别指望翻流水账”。
雪上加霜的是三件事：
告警治理不是玄学，工业界早就给出了量化标准。最有分量的是英国 EEMUA（工程设备与材料用户协会）的 EEMUA 191《告警系统：设计、管理与采购指南》，以及美国 ISA 的 ANSI/ISA-18.2-2016《流程工业告警系统管理》（后者已转化为国际电工标准 IEC 62682）。
关键在于，RFC 8632 的作者做了一件对通信人特别友好的事：把这两份工业标准的量化要求原封不动搬进了 RFC 的附录G，作为网络设备告警接口的“可用性要求”。两张表值得全文照录：
稳态告警速率的可接受度（源自 EEMUA 191，转引自 RFC 8632 表4）：
| 稳态告警速率 | 可接受度 |
|---|---|
| 高于每分钟1条 | 很可能不可接受 |
| 每2分钟1条 | 很可能超出负荷 |
| 每5分钟1条 | 可以管理 |
| 低于每10分钟1条 | 很可能可接受 |
重大故障后10分钟内的告警爆发（RFC 8632 表5）：
| 10分钟内告警数 | 可接受度 |
|---|---|
| 超过100条 | 绝对过量，操作员很可能就此放弃使用告警系统 |
| 20–100条 | 难以应付 |
| 少于10条 | 应可应对 |
注意两点。第一，这些数字是整个网络汇聚到一个告警终端上的总和——RFC特别强调“每个系统、每个NMS都在向这个总数贡献告警”。把每10分钟1条换算一下，就是一台值班终端一天最多消化一百多条告警；对照我们开头案例里“一晚两万条”，超标了三个数量级。第二，RFC作者补了一句诛心之论：操作员在风暴中放弃告警系统，不是态度问题，是系统设计的失败。
EEMUA 同样给出了“一条好告警”的八个特征（RFC 8632 表3）：相关（非虚假、非低价值）、唯一（不与别的告警重复）、及时、有优先级、可理解、可诊断、可行动、聚焦。拿这八条去审计任意一家运营商的在网告警清单，能全过的告警恐怕不到一半——大量告警既说不清该干什么，也没有对应的处置动作，唯一的用途是“出事后能查到记录”。
标准摆在这里，落到运营商网络上，治理方法可以收敛成三板斧。以下把方法论和 RFC 8632 的数据模型一一对应，说明每一步“标准早就给你留好了钩子”。
第一板斧：重新定义什么配叫告警。 3GPP Alarm IRP 在 v15 之后采用了和 RFC 8632 一致的定义：“告警 signifies 资源的一种非期望状态，且需要操作员采取行动”。反过来说，不需要人动的不配叫告警，应该降级成事件或日志。具体动作是组织一次“告警合理化审计”（alarm rationalization，ISA-18.2的核心流程）：把全网告警类型清单（RFC 8632 里对应 alarm-inventory，系统必须发布全部可能的告警类型）拉出来，每一条问四个问题——需要人动手吗？动手动作写了吗？能自动清除吗？文本能让人看懂吗？四个问题有两个答不上来，这条告警就该降级或删除。
第二板斧：状态机归并与拓扑关联。 把“通知流水账”改造成“状态列表”：同一 （资源， 告警类型， 告警限定符） 三元组只允许存在一个告警实例，翻转一百次只是状态历史加一百行。这是 RFC 8632 告警列表的主键设计。在此基础上做两级关联：设备内关联，利用模型自带的 root-cause-resource（根因资源）、impacted-resource（受影响资源）、related-alarm（关联告警）三个字段——RFC给的例子非常直白：磁盘满的告警应该挂在磁盘分区上，把数据库和应用列进“受影响资源”，而不是让三个资源各报一条。跨网元关联，则要靠网管侧维护拓扑依赖（光缆—网元—板卡—端口），自下而上传播，只在最上层保留根因告警并计数下游影响面。标准允许各系统在关联能力上自主取舍，具体实现细节以各厂家官方文档为准，但“告警收敛比”这个指标——原始告警数除以呈现给值班的告警数——是任何实现都绕不开的验收线。
第三板斧：屏蔽与静默。 割接窗口内的大量“计划内告警”，不应进入值班视野，但也不该粗暴删除。RFC 8632 给的标准答案是 shelving（搁置）：按资源、告警类型匹配规则把告警分流到独立的“已搁置列表”，不发通知、不占主列表，但状态照常维护，割接结束取消搁置规则即可全部回看。与之配套的是上报控制（notify-status-changes）：可以配置为只报“发生与清除”（raise-and-clear），或只在跨越某严重级别时上报——这直接对应 ITU 的 Alarm Reporting Control（ARC）老功能。开源网管工具里，这套模型已经有标准实现：Zabbix、OpenNMS 等平台的告警语义设计都参考了 RFC 8632 的同源工作（作者Stefan Vallin本人就是OpenNMS告警模块的长期贡献者）。
三板斧的流水线可以画成这样：
flowchart TD
NE["网元产生告警"] --> EMS["网管北向上报"]
EMS --> GW["采集网关归一化"]
GW --> INV["告警清单校验拦截未登记类型"]
INV --> STM["状态机归并同源合并"]
STM --> COR["拓扑关联根因收敛"]
COR --> SHELVE["屏蔽库过滤计划内静默"]
SHELVE --> SEV["级别校准与降级重定义"]
SEV --> DESK["值班台呈现"]
SEV --> TIC["自动生成工单"]
INV --> ARCH["全量留档供复盘"]
STM --> ARCH
方法论要活下来，得变成工具链里的日常动作。按18年运维的切身经验，四件事投入产出比最高。
第一件：告警清单审计脚本。 每季度跑一次，从各专业网管导出告警类型清单和近90天告警流水，自动出三张报表：TOP20抖动告警（chattering，翻转次数排行）、常驻告警榜（standing alarms，从不清除的“钉子户”）、零动作告警榜（从未有工单关联的告警类型）。这三张表就是下一轮降级、删除、整改的原料。ISA-18.2把审计列为告警系统生命周期的常规环节，通信网完全适用。
第二件：割接静默自动化。 把“割接工单—影响资源清单—shelving规则”做成自动流转：割接审批通过即自动按工单里的网元清单下发屏蔽规则，割接完成超时自动解除并推送“本次窗口内被屏蔽告警摘要”。开头案例里那种割接回退风暴，值班台本可以只看到一条“割接异常”的红灯。
第三件：收敛比看板。 在告警汇聚层统计三根曲线：原始告警速率、归并后速率、根因告警数。对照 EEMUA 的阈值线（稳态每10分钟1条、故障期10分钟10条）画参考线。这根参考线一画出来，治理进度就不用吵架了——数字说话。
第四件：把“好告警八特征”写进工程验收。 新设备入网、新网管上线验收时，抽检20条典型告警，逐条对照八特征打分，并要求厂商交付每类告警的处置指引。告警文本写得让人看不懂，这是工程问题，不是文风问题——RFC 8632 明确要求 alarm text 必须包含“足够操作员理解问题并解决的信息”。
把前文收敛成一张可执行清单（表中目标值为按 EEMUA 阈值折算的治理目标示例，供参考设定，非实测数据）：
| 治理动作 | 执行频率 | 责任角色 | 目标示例 |
|---|---|---|---|
| 告警清单合理化审计 | 每季度 | 网管/各专业维护 | 零动作告警占比降至10%以下 |
| 抖动告警专项整改 | 每月 | 专业维护 | TOP20抖动告警全部闭环 |
| 割接静默自动化 | 每次割接 | 割接负责人 | 计划内告警零进入值班台 |
| 收敛比与速率看板 | 实时 | NOC | 稳态速率低于每10分钟1条 |
| 新告警八特征验收 | 每次入网/升级 | 工程验收 | 抽检合格率100% |
| 风暴复盘归档 | 每次重大故障 | NOC值班长 | 根因链路全程可回放 |
顺带回应一个常见的疑虑：把告警降级、屏蔽，会不会漏掉真故障？工业界的答案很干脆——EEMUA 对告警的定义是“操作员必须知晓并响应的事件”，一条从来没有人响应、响应了也没动作的告警，留在值班台上的唯一作用是训练值班员学会忽略告警。真正该担心的不是删掉了垃圾，而是垃圾挤占了带宽。当然，屏蔽规则的变更本身要纳入变更管理和审计——RFC 8632 的安全考虑一节专门点名：对 shelving 配置和严重级别映射的未授权修改，会直接破坏告警管理流程。
回到开头那个凌晨。那晚之后该省公司做的事，就是本文的全部内容：三个月告警合理化审计，砍掉和降级了一批零动作告警；半年上了割接静默和拓扑关联；一年后重大故障时值班台上的告警条数终于进入了“10分钟20条以内”的量级。整个过程没有用任何时髦的词，没有大模型，没有“自智网络”，靠的是三十年前工业界用血泪换来的量化标准、九十年前的老道理——给人看的系统，必须按人的认知带宽设计。
三条经验送给同行。第一，告警治理的第一性原理是“告警需要行动”，凡是不产生动作的告警都是负债，用 EEMUA 的速率阈值给治理定硬指标。第二，别急着上AI：先把状态机归并、拓扑关联、屏蔽静默这些确定性规则做扎实，模型化的告警流水是任何智能算法的前提，垃圾进垃圾出。第三，标准早就在那里——X.733管语义，TS 32.111管接口，RFC 8632管数据模型，EEMUA/ISA-18.2管人的极限，把它们串起来读一遍，胜过十场解决方案宣讲会。
告警系统的最高境界，是让值班员在风暴来临时，第一眼看到的永远是那条该看的告警。
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。