# 一夜2.3万条告警：一个省网NOC的告警压降实战复盘 ## 概述 告警是网络运维的眼睛，但当眼睛里进了沙子，人就会瞎。本文复盘笔者亲历的某省运营商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万条。 ## 三、复盘：一次光缆挖断，40分钟2.3万条告警 这是本文的核心案例。时间、地点、运营商名称已脱敏，数字取整，过程与处置完全真实。 ### 事件时间线 | 时间 | 事件 | 告警侧表现 | |---|---|---| | 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都清楚： 1. **主告警（光缆中断）与衍生告警（小区/链路/KPI）在同一个列表里平权呈现**，根因被完全淹没； 2. **闪断类告警没有合并机制**，备用路由每抖一次就刷两条（raise+clear）； 3. **KPI告警与网元告警没有关联**，明明根因已知，KPI告警还在按粒度机械触发； 4. **清除阶段同样制造噪声**，恢复期的收尾告警比事故中段还密集。 用时间线图复盘那个夜晚： ```text 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条 事故之后，该省立项做告警专项治理。没有买什么“智能运维大平台”，就是一套朴素的工程方法，跑了六个月，日均新增告警从约8万条降到800条以内。方法只有五步，顺序不能乱。 ```mermaid flowchart LR A[第一步
告警盘点
摸清家底] --> B[第二步
分级定义
谁该被看见] B --> C[第三步
关联与抑制
让噪声合并] C --> D[第四步
规则调优
参数逐条验证] D --> E[第五步
闭环治理
新增告警须审核] E -->|每月回归| A ``` **第一步：告警盘点（摸清家底）。** 导出近90天全量告警流水，按“告警名+网元类型”做聚合统计，回答三个问题：哪些告警占流量最大？哪些告警从未被人处理过（零工单关联）？哪些告警激活时长中位数低于5分钟（纯闪断）？盘点结果通常触目惊心：流量Top 20的告警名占掉总量70%以上，而其中大半“从未触发过任何人工动作”。 **第二步：分级定义（谁该被看见）。** 给每类告警重新定级，核心原则是**按“是否需要人工在多长时间内动作”定级，而不是按设备商默认severity定级**。设备商默认配置里，Critical满天飞，但真正要求15分钟内人工响应的（P1）在健康网络里一天不应超过个位数。我们定义了四级响应契约：P1（15分钟响应）、P2（当日处理）、P3（每周批量复盘）、P4（仅记录不呈现）。判定依据写进文档，每条告警一个owner。 **第三步：关联与抑制（让噪声合并）。** 这是技术核心，四类规则： - **去重合并**：按（网元ID+告警名+ probableCause）做键，重复raise只累加计数并刷新最后发生时间，不产生新条目； - **闪断合并**：同一键60秒内反复raise/clear超过5次，合并为一条“闪断”告警并附统计，而不是N条独立告警； - **拓扑关联抑制**：这是压降最大的一刀。接入光缆资源/拓扑数据，当“光缆中断/站点脱管”主告警存在时，其下挂站点的小区不可用、接口中断、时钟类告警自动折叠为主告警的子项，默认不单独呈现。主告警清除后30分钟，折叠子项批量释放或直接关闭； - **维护模式挂起**：割接工单系统与告警系统打通，割接窗口内受影响网元的告警自动挂起并打标，窗口结束自动恢复。这一条专门治“凌晨两点割接告警刷屏”。 **第四步：规则调优（参数逐条验证）。** 阈值类告警逐条复审：掉线率越限从“超过基线0.1pp即报”改为“超基线30%且持续2个粒度”；常驻告警夜间同步任务上线，每天凌晨比对NMS活动告警表与网元侧getActiveAlarms结果，自动关闭网元侧已恢复的僵尸告警。**每改一条规则，都要在测试环境回放历史告警流水验证**，确认不会误杀——规则误杀真告警，比告警刷屏更危险。 **第五步：闭环治理（新增告警须审核）。** 治理最怕回潮。我们立了一条军规：任何网元/平台新上线功能带来的新告警，必须先在测试环境跑一周，由告警owner确认级别、确认会被人处理，才允许进入生产告警库。每月做一次回归盘点，告警总量、重复率、P1占比三个指标上墙。 ## 五、关键参数表：可以直接抄的作业 以下是治理后稳定运行的那套核心参数（供参考起点，各省需按网络规模校准）： 其中“P1日预算”值得多说一句：**给P1告警设定每日上限，超了就说明要么网络真出了系统性问题，要么告警定义失真**——无论哪种，都值得当晚停下来讨论。这个机制把“告警治理”从一次性项目变成了持续运营的机制。 ## 六、治理前后：六个月的KPI变化 | 指标 | 治理前 | 治理后 | 变化 | |---|---|---|---| | 日均新增告警 | ~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统计。那一张表，就是整个治理项目的立项报告。 ## 参考来源 > 注：本文为运维实战复盘，案例数据来自作者亲历项目（已脱敏取整），不对应任何可公开检索的特定事故。以下为文中涉及的标准与基准文件入口： 1. [ITU-T X.733 Alarm reporting function](https://www.itu.int/rec/T-REC-X.733) — 电信网告警上报功能的国际标准，北向告警接口的源头规范 2. [3GPP TS 32.111系列（Fault Management）](https://www.3gpp.org/dynareport/32111.htm) — 3GPP故障管理/告警IRP规范，PerceivedSeverity与告警通知模型定义 3. [EEMUA 191: Alarm Systems](https://www.eemua.org) — 流程工业告警管理指南，"每操作员每小时约6条告警”基准的出处 4. [ISA-18.2: Management of Alarm Systems for the Process Industries](https://www.isa.org) — 告警全生命周期管理框架，本文五步法的跨行业参照 5. [TM Forum](https://www.tmforum.org) — TMF长期维护告警管理与告警关联相关最佳实践专题 > 本文由「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 等场景全覆盖。