概述：告警系统本该是网络运维的眼睛，但在真正的全网性故障里，它往往最先失明——2022年7月KDDI那次持续约61小时的全国性断网，把“告警风暴淹没值守人员”这个问题摆上了台面。本文回答三个问题：告警为什么会越治越多？一线NOC的降噪漏斗长什么样？静默与屏蔽这两把刀，怎么用才不会割到自己手？文中标准解读以ITU-T X.733与3GPP TS 32.111告警IRP为主轴，案例事实据日本总务省通报与NHK、路透社等当时报道。
先把时间拨回2022年7月2日，日本时间凌晨。
据日本总务省事后通报与NHK、日经、路透社等媒体的持续报道，事故的主线并不复杂：KDDI（au品牌）在7月2日凌晨的维护窗口内，对VoIP交换设备的冗余单元进行替换作业；作业之后，设备内按用户存储的VoIP路由信息缺失，凌晨2时35分左右，部分交换机故障，全国范围语音呼叫开始异常——手机打不出电话，也接不到。
真正把事故推向灾难级的，是接下来的连锁反应：全网终端检测到注册失败后疯狂发起重连，注册与控制面瞬间过载；KDDI启用的拥塞控制反过来拒绝了一部分重连请求，恢复过程被进一步拉长；iOS设备不会自动重连，需要用户手动开关飞行模式，这让“网络恢复了”和“用户恢复了”之间又隔了好几个小时。紧急电话112/119在部分地区一度难以接通，约3915万条线路（含au、UQ mobile、冲绳Cellular及部分MVNO用户，据报道口径）受到影响，直到7月4日17时25分才全部恢复——历时约61小时。事后，总务省依据2022年5月刚生效的修订版《电气通信事业法》，将其认定为“重大事故”，KDDI随后提交了原因报告与整改计划，并拿出约合220亿日元规模的账单减免方案（据当时日媒报道的测算口径）。
作为同行复盘，我关心的不是“设备坏了”这个事实——设备永远会坏——而是坏了之后运维团队为什么花了那么久才看清全局。据当时多家日本媒体报道的复盘细节：故障期间，周边网元的告警大量发生，值守人员疲于应付，整体态势的把握严重滞后；总务省在整改要求里，明确把故障检测与态势把握列为重点方向。即便不抠具体细节，这个结果也完全符合机理：一次波及全国交换与注册系统的故障，意味着数以万计的网元在几乎同一秒向网管倾泻告警——那是典型意义上的告警风暴。
这条时间线值得每个搞运维的人贴在工位上：
| 时间（日本时间） | 事件 |
|---|---|
| 7月2日 01:50前后 | 维护窗口内开始VoIP交换设备冗余单元替换作业 |
| 7月2日 02:35 | 设备故障叠加路由信息缺失，全国语音业务开始异常 |
| 7月2日 白天 | 终端大规模重连引发注册拥塞，数据业务受波及，部分地区紧急电话难以接通 |
| 7月3日 | KDDI协调借用其他运营商网络分流用户；首次记者会未能说清原因，舆论抨击其态势把握迟缓 |
| 7月4日 17:25 | 全网业务恢复，历时约61小时 |
| 7月中下旬 | 总务省认定“重大事故”，KDDI提交报告与整改计划 |
61小时里，真正的分水岭不在设备层，而在“运维人员花了多久从告警堆里爬出来”。这就是本文要谈的告警治理。
告警泛滥不是哪一家的毛病，它刻在网管体系的技术基因里。拆开看，有五个根因。
第一，标准留了字段，没留脑子。 今天全网元通用的告警上报模型，骨架来自1992年的ITU-T X.733《告警上报功能》：网元发生事件，向管理方发一条AlarmReport，带上感知严重级（perceivedSeverity）、可能原因（probableCause）、首末时间等字段。3GPP后来在TS 32.111系列（Alarm IRP，告警集成参考点）里把它继承进移动网管体系。关键在于：X.733从第一天就定义了一个correlatedNotifications（关联通知）字段——标准早就预料到告警之间有因果，需要有人把“这条告警是哪条引起的”填进去。但三十多年过去，绝大多数网元只会填事件本身，拓扑、因果这些上下文，得靠上层系统去补。字段是哑的，脑子在上游，而上游往往没人干这件事。
第二，一个根因，一串衍生。 通信网络的故障天然是级联的：一条传输断了，下挂的几百个基站同时“失联”，每个基站在网管里又是十几个模块级告警的宿主——光模块、载频、传输板、时钟，一个个报上来。物理上是一根线，呈现上是几千条告警，放大倍数一到两个数量级是家常便饭。KDDI那晚的注册拥塞更是极端版：几千万台终端“参与”了故障，每一台重连失败在控制面网元那里都可能翻成告警与异常日志。
第三，虚拟化把“网元”数量翻了两个数量级。 核心网NFV化之后，一个资源池里跑着成百上千个虚机和容器，每个都是潜在的告警来源。容器重建、虚机热迁移、K8s探针抖动，这些在云原生世界里一秒钟发生几十次的事件，放进电信网管的语义里就是一条条“网元异常”。传统的“一个网元一条告警链路”的世界观，在云化网络里彻底碎了。以业内公开分享的普遍口径，国内一个省级网络的日告警量普遍在数万到数十万条量级——这还是治理过之后的数据。
第四，僵尸告警与清除机制失灵。 告警生命周期管理是个苦活：告警要“自动清除”，依赖网元上报清除消息，但对端断线、上报通道本身故障、或者压根没设计清除逻辑的告警，会永远挂在屏上。陈旧告警堆积的直接后果，是新告警被淹没在旧告警里——你盯着的大屏上，一半的“红色”是上个月的遗物。更糟的是运维人员的应对：既然清除不掉，那就屏蔽掉。屏蔽规则一条条攒下来，没人敢删，最后形成“告警黑洞”——真故障发生时，正好落在黑洞里。
第五，变更与告警脱节。 几乎每一次割接都是一次小型告警风暴：端口闪断、进程重启、主备倒换，每个动作都会合法地产生一批告警。成熟的运维体系里，这些应该由工单联动自动静默；而相当多的现场，靠的是值班的“眼疾手快”——记住“今晚有割接，这些告警别理”。凌晨两点的NO C，人本来就困，这恰恰是KDDI事故发生的时段：维护窗口，正是告警最多、人最疲、判断力最差的时刻。
讲了病根，讲药方。成熟NOC的告警处理不是一条线，而是一个逐层收敛的漏斗——治理目标从来不是“零告警”，而是让每一条到达人眼的告警都值得人眼看一次。
flowchart TD
A["网元原始告警<br/>日数万到数十万条"] --> B["采集网关<br/>全量落库留底"]
B --> C["去重合并<br/>同源同因计数"]
C --> D["关联压缩<br/>拓扑时序归因"]
D --> E["静默屏蔽<br/>工单联动窗口"]
E --> F["分级分诊<br/>P1夜班直呼"]
F --> G["根因处置"]
G --> H["复盘调规则"]
H --> D
注意第一层的设计哲学：采集端一刀不动。所有原始告警全量落库保留——降噪发生在呈现与通知链路上，而不是让网元闭嘴。理由很朴素：你今天认为是噪声的规则，三个月后可能就是某次疑难故障唯一的线索。降噪漏斗的每一层，各有各的门道：
| 手段 | 做什么 | 主要风险 | 落地要点 |
|---|---|---|---|
| 去重合并 | 同源同因告警在时间窗内合并为一条，累加计数 | 首/末时间信息丢失 | 必须保留首次发生时刻、最近发生时刻与累计次数 |
| 关联压缩 | 按拓扑与时间序，把衍生告警归并到根因告警之下 | 规则误杀真告警 | 新规则先灰度观察一周，再全量生效 |
| 静默 | 割接工单联动，维护窗口内自动压制相关网元告警 | 忘记恢复、静默期真故障被压 | 到期自动恢复+全程审计留痕 |
| 屏蔽 | 已知问题、低价值告警设超限抑制 | 掩盖劣化趋势 | 屏蔽规则必须带阈值与有效期，周度清理 |
| 分级分诊 | P1–P4分级，P1/P2直达值班负责人 | 分级标准随时间漂移 | 季度校准分级定义，与影响面挂钩 |
关联压缩是漏斗里技术含量最高的一层，也是最容易被神化的一层。工程上有效的做法，至今仍以规则为主：拓扑关联——下层链路断，上挂的所有业务告警自动挂到根因节点下；时序关联——先发生者为因，后发生者为果，时间窗可配置；业务流程关联——这是核心网运维的看家本领，比如一次VoNR呼叫失败，把SIP响应码、PFCP会话状态、DNS解析记录按信令流程串起来，很多“呼叫失败告警”瞬间就能定位到唯一异常环节。机器学习关联当然在进步，各厂商与运营商都有公开案例宣称大幅削减告警量，但一线的共同经验是：规则先落地、ML做增量——规则是白盒可审计的，出问题你知道去哪改；黑盒模型删不掉、说不清，在告警这种高责任场景里只能当副驾驶。这里也说明一句：各网元厂商在X.733字段之上自行扩展告警语义属于标准允许的多种实现，具体行为以各厂家官方文档为准，上层的关联规则必须为每种语义做适配。
降噪做得越狠，越要回答一个尖锐的问题：你压掉的告警里，有没有一条是下一次大故障的首报？
两个公开案例值得对照。第一个就是KDDI：告警风暴把首报淹没在海量衍生告警里，态势把握延迟了几个小时。第二个是2021年10月4日的Facebook全球断网——按Meta官方复盘的说法，一次例行维护命令误撤了骨干路由，DNS服务器从互联网上消失；更要命的是，公司内部工具（包括远程访问通道、甚至办公室门禁系统）依赖同一套基础设施，工程师既“看不见”网络，也“摸不到”设备，最后靠现场人员物理重启设备才逐步恢复，全球瘫痪约六个小时。两起事故，两个经典教训：风暴会淹没眼睛，而监控系统会和被监控对象同生共死。
对应的工程对策，四条，一条都不能少：
心跳兜底，“没有消息才是坏消息”。 告警体系天然只会报“出事了”，不会报“我还活着”。3GPP在TS 32.111告警IRP里定义了心跳通知机制，就是给这个漏洞打的补丁——管理方周期性收到网元活性证明，超时未收到，立刻生成“疑似失联”告警。KDDI那晚，交换机自己报不出来，但“这台设备已经X分钟没有心跳了”这句话，监控系统必须替它说。
风暴模式识别。 告警速率本身要成为被监控对象：当单位时间告警数突增若干倍，系统自动进入“风暴态”——大屏切换呈现模式，只展示根因候选（通常是时间序上最早的告警及其源网元），衍生告警折叠入库。这一步做实了，“凌晨三点从一万条告警里找第一条”就变成“系统已经帮你把第一条顶到最上面”。
首告钉住（first alarm pinning）。 任何一次故障复盘，第一条告警都是主角。我处理过的一个典型案例（细节已模糊化）：某次核心网割接后N6口业务全断，上游几百条业务告警扑面而来，而全链路上真正最早的只有一条——防火墙新建会话数归零。根因是割接漏配了一条ACL。规则很简单但必须制度化：风暴态下按源网元时间序排序，最早者默认置顶。
带外管理独立通道。 监控数据、远程访问与业务流量物理或逻辑隔离，是Facebook事故用六个小时换来的教训。告警上报链路尤其要问一句：如果被监控的网络本身瘫了，告警还出得来吗？出不来，就必须有独立的第二通道。
告警治理最常见的死法，是运动式专项：领导拍板“消灭告警噪声”，突击一个月，告警量降七成；半年后反弹回原点。原因很简单——没有指标、没有责任人、没有持续机制。
可持续的治理要立四个指标：告警预算——每千网元每日有效告警数，超过预算就触发规则评审，这把“总量控制”变成了硬约束；MTTA/MTTR——从告警产生到人响应、到故障恢复的时间，降噪的最终目的就是把这两个数字打下来；冗余占比——抽样分析被合并、被屏蔽的告警里，有多少确实无价值（目标区间的上限之外，说明压过头了）；TopN销项率——每月发布Top10高频告警清单，逐条给出治理动作（修设备、改规则、加屏蔽），下月复查销项。四个数字进例会，治理就从“运动”变成了“运营”。
组织层面还有两件小事，但比任何算法都管用。一是告警规则版本化：所有去重、关联、屏蔽规则像代码一样纳入管理，修改要评审、生效留记录、回滚有路径——规则漂移是告警黑洞的头号成因。二是新业务上线的告警准入：入网评审里加一项“该业务的告警定义与分级说明”，没有告警设计文档的新网元，不许入网。让告警治理前置到设计阶段，比事后清洗便宜一个数量级。
回到KDDI那61小时。设备故障是起点，但把一次技术故障放大成全国性事故、招致监管认定与百亿日元级赔偿的，是运维体系对告警风暴的失守：眼睛被淹住，手就伸不到正确的开关上。告警系统是NOC的神经系统，降噪不是让它闭嘴，而是教会它说话——说人能听懂的话，在最恰当的音量说，并且永远保留一句“我不舒服了就说不出话”的备选方案。X.733在1992年就写下了correlatedNotifications这个字段，等了三十年，等待的从来不是更聪明的算法，而是有人愿意把拓扑、把时序、把业务流程这些上下文，一丝不苟地补进系统里。这份耐心，才是告警治理真正的护城河。
本文由「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 等场景全覆盖。