告警是网络运维的眼睛，但当眼睛里进了沙子，人就会瞎。本文复盘笔者亲历的某省运营商NOC告警治理项目：一次普通的光缆挖断事故在40分钟内制造出2.3万条告警，值班工程师被淹没在屏幕里，真正的根因告警反而被延迟发现。文章拆解了告警被层层放大的机制（网元层、链路层、平台层三层放大），给出可落地的五步压降法、关键参数表和治理前后的KPI对比，并总结五个最容易踩的坑。所有案例数据均来自作者亲历项目，已脱敏取整。本文回答一个问题：为什么你的NOC每天有8万条告警，而真正需要人看的不超过800条？
如果你去任何一个省级运营商的NOC（网络运营中心）转一圈，最震撼的不是大屏，是大屏旁边滚动不息的告警列表。我见过最夸张的一张值班席截图：当前活动告警86,000多条，其中Critical级别4,300条，系统翻页要滚十几分钟才能到底。
值班工程师对这种告警列表的真实态度，是挂在工位旁边的一张纸条：“Critical看心情，Major看运气，Minor直接右键屏蔽。”
这不是段子，这是行业普遍现状。流程工业领域的告警管理标准（EEMUA 191、ISA-18.2）早就给出过基准：一个操作员每小时能从容处理的告警约6条（约150条/天），10分钟内的峰值不应超过10条。通信行业的NOC当然不能完全套用这个标准——网络规模大、告警源异构——但参照系是成立的：当值班席每分钟涌入的告警超过人工可理解量级的10倍以上，告警系统就不再是排障工具，而变成了排障障碍。
我经历过的几个省网，告警日产量普遍在5万到10万条之间。抽样分析下来，结构惊人地一致：
| 告警类别 | 占比（典型值） | 性质 |
|---|---|---|
| 重复/闪断类（同一告警反复产生-清除） | 40%~55% | 噪声 |
| 级联衍生类（一个根因带出几十条子告警） | 25%~35% | 噪声 |
| 长期常驻类（僵尸告警，网元侧早已恢复） | 8%~15% | 噪声 |
| 阈值过敏感类（KPI轻微越限即报） | 5%~10% | 低价值 |
| 真正需要人工介入的 | 约1% | 有效 |
也就是说，超过九成的告警在制造“狼来了”。而代价是真实的：真告警被淹没、MTTR（平均修复时长）被拉长、值班员对告警的信任感归零——当一个告警系统里没有任何人相信告警，这个系统就死了。
治理之前必须搞清楚告警从哪来、在哪一层被放大。根据18年核心网与网管侧的经验，放大发生在三层。
第一层：网元层——告警定义的“生产过剩”。 设备商出厂配置里，告警规则普遍偏保守：一块单板复位报一次，端口CRC误码越限报一次，小区不可用报一次，X2/NG接口中断报一次……单站视角看每条都有道理，但没有任何一条回答“这站是不是彻底断了”。此外，大量告警缺乏自愈边界：进程守护进程每5分钟拉起一次异常进程，就每5分钟报一次新告警（eventTime各不相同），网管侧无法合并。
第二层：链路/拓扑层——一个根因带出一串衍生告警。 这是最典型的放大器。一条光缆中断，拓扑上挂着的每个站点、每块单板、每个小区、每条S1/NG链路都会独立“发现”故障并上报。一次事故产生几百条告警是物理必然，因为告警模型是“谁疼谁喊”，没有人负责把喊声归并到“哪里挨了刀”。
第三层：平台层——采集与规则把噪声二次放大。 北向接口（3GPP TS 32.111系列定义的Alarm IRP、或SNMP Trap）本身有队列与丢包机制：风暴来了，EMS的Trap队列溢出，NMS采到的是残缺的告警流；与此同时，KPI类动态告警（小区掉线率越限、切换成功率越限）往往按15分钟粒度滚动触发，一次真实故障可以连续触发几十个周期，直到网元侧恢复后各KPI陆续恢复，衍生告警才分批清除——收尾比开头还吵。另外，网元侧清了告警但北向Clear报文丢失，NMS侧就成了永不消除的僵尸告警，日积月累污染整个活动告警库。
三层放大叠在一起，就是那个数字：8万条。
这是本文的核心案例。时间、地点、运营商名称已脱敏，数字取整，过程与处置完全真实。
| 时间 | 事件 | 告警侧表现 |
|---|---|---|
| 21:37 | 市政施工挖断某承载环主干光缆，环上12个站点业务中断 | RSL劣化、LOS告警开始进入 |
| 21:38–21:42 | 环保护倒换部分成功，但倒换后备用路由质量劣化，链路反复闪断 | 闪断告警以约每站每3分钟一条的频率反复产生/清除 |
| 21:39–21:50 | 12个站点的3,800多个小区陆续不可用；PTP同步丢失引发下游抖动 | 小区不可用、时钟同步、X2中断类告警爆发 |
| 21:45起 | KPI监控任务命中阈值：掉线率、切换成功率、无线接通率越限 | 动态KPI告警按粒度滚动触发，每15分钟一批 |
| 21:50–22:15 | 40分钟窗口告警总量达到2.3万条 | NOC大屏Critical刷屏，值班员无法定位 |
| 22:07 | 值班长通过光缆资源系统人工比对掉网站点，锁定“光缆中断”为主告警 | 距故障发生已30分钟 |
| 次日01:20 | 抢修完成，业务恢复 | 衍生告警又花了一个多小时才陆续清完，全程未再睡眠 |
这一晚暴露的问题，比任何PPT都清楚：
用时间线图复盘那个夜晚：
timeline
title 那个夜晚：一条光缆到2.3万条告警
section 事故发生
21:37 : 主干光缆被挖断 : 12站点业务中断
21:38 : 环保护倒换后链路闪断 : 闪断告警开始反复产生
section 告警风暴
21:39 : 3800个小区陆续不可用 : 小区/时钟/接口告警爆发
21:45 : KPI越限告警滚动触发 : 每15分钟一批
21:50 : 40分钟累计2.3万条 : 大屏刷屏无法定位
section 定位与恢复
22:07 : 人工比对锁定光缆中断 : 距故障发生30分钟
次日01:20 : 抢修完成业务恢复 : 恢复期告警持续刷屏1小时
事故之后，该省立项做告警专项治理。没有买什么“智能运维大平台”，就是一套朴素的工程方法，跑了六个月，日均新增告警从约8万条降到800条以内。方法只有五步，顺序不能乱。
flowchart LR
A[第一步<br>告警盘点<br>摸清家底] --> B[第二步<br>分级定义<br>谁该被看见]
B --> C[第三步<br>关联与抑制<br>让噪声合并]
C --> D[第四步<br>规则调优<br>参数逐条验证]
D --> E[第五步<br>闭环治理<br>新增告警须审核]
E -->|每月回归| A
第一步：告警盘点（摸清家底）。 导出近90天全量告警流水，按“告警名+网元类型”做聚合统计，回答三个问题：哪些告警占流量最大？哪些告警从未被人处理过（零工单关联）？哪些告警激活时长中位数低于5分钟（纯闪断）？盘点结果通常触目惊心：流量Top 20的告警名占掉总量70%以上，而其中大半“从未触发过任何人工动作”。
第二步：分级定义（谁该被看见）。 给每类告警重新定级，核心原则是按“是否需要人工在多长时间内动作”定级，而不是按设备商默认severity定级。设备商默认配置里，Critical满天飞，但真正要求15分钟内人工响应的（P1）在健康网络里一天不应超过个位数。我们定义了四级响应契约：P1（15分钟响应）、P2（当日处理）、P3（每周批量复盘）、P4（仅记录不呈现）。判定依据写进文档，每条告警一个owner。
第三步：关联与抑制（让噪声合并）。 这是技术核心，四类规则：
第四步：规则调优（参数逐条验证）。 阈值类告警逐条复审：掉线率越限从“超过基线0.1pp即报”改为“超基线30%且持续2个粒度”；常驻告警夜间同步任务上线，每天凌晨比对NMS活动告警表与网元侧getActiveAlarms结果，自动关闭网元侧已恢复的僵尸告警。每改一条规则，都要在测试环境回放历史告警流水验证，确认不会误杀——规则误杀真告警，比告警刷屏更危险。
第五步：闭环治理（新增告警须审核）。 治理最怕回潮。我们立了一条军规：任何网元/平台新上线功能带来的新告警，必须先在测试环境跑一周，由告警owner确认级别、确认会被人处理，才允许进入生产告警库。每月做一次回归盘点，告警总量、重复率、P1占比三个指标上墙。
以下是治理后稳定运行的那套核心参数（供参考起点，各省需按网络规模校准）：
其中“P1日预算”值得多说一句：给P1告警设定每日上限，超了就说明要么网络真出了系统性问题，要么告警定义失真——无论哪种，都值得当晚停下来讨论。这个机制把“告警治理”从一次性项目变成了持续运营的机制。
| 指标 | 治理前 | 治理后 | 变化 |
|---|---|---|---|
| 日均新增告警 | ~80,000条 | ~750条 | -99% |
| 重复/闪断类占比 | ~48% | ~6% | 大幅下降 |
| 真实故障定位时长（同类光缆类故障） | 20~40分钟 | 5分钟内 | 主告警直达 |
| P1告警日均量 | 400+（虚高） | 3~8（真实） | 告警重新可信 |
| 活动告警库常驻量 | 86,000条 | <2,000条 | 僵尸告警清理 |
| 告警关联开工单率 | <2% | ~70% | 告警-工单打通 |
注意最后一行：开工单率（告警触发了真实工单的比例）是检验告警含金量的最好指标。治理前不到2%——98%的告警和运维动作毫无关系；治理后七成告警能落到工单上，告警才重新成为“运维的语言”。
坑一：规则误杀。 上线拓扑抑制的第二周，一次批量断电站告警因“站点脱管”主告警存在而被错误折叠，值班晚发现了一小时。教训：抑制规则必须保留“P1直通”白名单——断电、火警、动环类告警永远独立呈现，不参与任何折叠。
坑二：挂起忘解除。 人工挂起时代的老问题，联动手单系统后大幅缓解，但仍要留一道保险：挂起超时（如4小时）未恢复，自动告警提醒值班班长。挂起本身也是告警，且必须比业务告警更显眼。
坑三：只压总量不压结构。 有兄弟省来取经，问“压到多少条算达标”。错的问题。该问的是：P1是否可信、主告警是否直达、开工单率多高。 总量是结果，不是目标。把总量当KPI去压，最后一定会压出漏告警事故。
坑四：清除路径没治理。 前期只关注告警产生侧，收尾风暴依旧。拓扑折叠 + 清除延时批量释放解决大半，但对账机制（每日对账）才是兜底——Clear报文丢失是常态，对账是唯一可靠的兜底。
坑五：指望一个平台解决一切。 市面上不乏“智能告警治理”产品，但这个项目的六个月里，真正起作用的是数据打通（光缆资源系统、工单系统、网管北向）和规则运营（每条规则有owner、有验证、有回滚）。告警治理是运营问题，不是采购问题。 AI/ML关联分析当然有用，但它建立在第三步那四条朴素规则把量级降下来之后——先做工程，再谈智能。
告警治理是这个行业里最没有光环、却回报最确定的一件事：不增加任何网络能力，却直接决定故障发现速度、值班人员幸福度和整个运维体系的可信度。它不需要立项买大平台，需要的只是——把“哪些告警值得被看见”当作一个严肃的产品问题，一条一条地回答。
如果你所在网络的NOC大屏还在刷屏，从今天就可以开始：导出90天告警流水，做一次Top 20统计。那一张表，就是整个治理项目的立项报告。
注：本文为运维实战复盘，案例数据来自作者亲历项目（已脱敏取整），不对应任何可公开检索的特定事故。以下为文中涉及的标准与基准文件入口：
本文由「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 等场景全覆盖。