凌晨两点，郊区一条光缆被挖断，最先收到通知的不是用户，而是网管值班室：几分钟内，几千条告警涌上大屏，把一个真实的故障淹没在噪音里。本文回答一个运维老问题：告警为什么会雪崩？值班员如何在风暴里五分钟锁定根因？告警治理压缩、屏蔽、关联三板斧怎么落地？文章以 3GPP TS 32.111 告警规范、工业界 EEMUA 191 告警负荷基准、arXiv 论文 TempOpt 与 Google SRE 工作手册为锚点，把一次典型故障夜的处置和一套告警治理方法讲透。
先说清楚：这不是某一次真实事故的复盘，而是我值了十几年夜班、处理过几十次传输中断之后，把那些夜晚压缩成的一个“典型故障夜”。细节是合成的，机制是真的。
凌晨两点十四分，郊区一段直埋光缆被第三方施工挖断。物理层面发生的事情很简单：一根纤断了，一个环上的几十个站点业务中断。
但值班室大屏上发生的事情要热闹得多。两分钟后，北向告警开始涌入：先是光传输网元的“信号丢失”“光功率异常”，接着是所带基站设备的“传输中断”“小区退服”，再往下是挂在环上的交换、数据设备的“链路不可达”。一分多钟后，平台上开始出现成对的“告警—恢复”闪烁——下游设备检测到断纤后反复重试，每次重试失败就报一次，个别设备还会在临界状态来回横跳。到两点二十五分，这一起故障在综合告警平台上累计的告警条数，已经突破三千条。
而根因，从头到尾只有一条：某个光缆段中断。
这个“三千比一”的比例，就是本文要谈的全部：告警风暴是怎么产生的，值班员凭什么能在五分钟内从三千条里捞出那一条真凶，以及一张网要怎么治理，才能让下一次风暴从三千条变成三十条。
先把故障夜的完整时间线摆出来：
timeline
title 一个典型的传输中断夜
section 事发
凌晨两点十四分 : 一条光缆被挖断
凌晨两点十五分 : 告警开始涌入值班室
凌晨两点二十五分 : 告警量突破三千条
section 响应
凌晨两点半 : 值班按套路归并告警锁定光缆段
凌晨三点整 : 抢修队出发，OTDR定位断点
section 恢复
凌晨五点前后 : 熔接完成，业务逐环恢复
清晨六点半 : 三千条告警归并为一个根因
注意最后一行：熔接完成不代表当晚结束。三千条告警要逐条核对恢复状态，该清的清、该挂的挂，这一步做不干净，第二天的值班室里就会躺着一批“僵尸告警”。
告警风暴不是网元的错，而是网络结构的必然。Sathiyanaryanan Sampath 等人在 arXiv 论文《TempOpt — Unsupervised Alarm Relation Learning for Telecommunication Networks》（arXiv:2508.08814，IEEE INDICON 2024）里把这件事说得很直白：网络节点相互连接，单点故障会在多种节点上触发一连串告警序列；一张网动辄几百个节点、多厂商设备并存，任何时刻的告警总量都可能非常庞大——NOC 工程师很难记住这些告警之间的关系，而找出根因告警（root alarm）恰恰是快速恢复的前提。
具体拆开，风暴的噪音来自五个源头：
第一，拓扑级联。 一根光纤是物理层，上面挂着传输段、基站、小区、承载链路等多个逻辑层。物理层一断，每个逻辑层、每层上的每个网元都按自己的检测周期独立报警。这是告警膨胀的主导项，三千条里通常有八九成来自这里。
第二，重试与重复上报。 网管与网元之间的链路抖动时，网元会重发告警，北向接口会把“同一条告警”的多个副本都递上来。不去重，计数直接翻倍。
第三，闪断（flapping）。 故障边缘状态的设备在“通—断—通”之间振荡，每次跨越阈值都生成一对告警和恢复。一次故障夜里，闪断产生的告警对能占到总数的一到两成。
第四，恢复瀑布。 光缆熔接恢复时，级联产生三千条告警，就要以类似的规模逐级清除三千条恢复通知——风暴是双峰的，断的时候一波，好的时候又一波。
第五，配置类与工程类噪音。 割接窗口里被屏蔽不彻底的告警、新建站点的调试告警、阈值设得过紧的“毛刺告警”，平时涓涓细流，故障夜一齐上线，全部挤进值班员的视野。
理解了这五个源头，就理解了为什么“加人”解决不了问题：你没法用肉眼处理指数级的噪音，只能用工程手段把它压回线性。
顺带补一句标准视角。3GPP 对故障管理有专门的规范族：TS 32.111-1 定义故障管理需求，TS 32.111-2 定义 Alarm IRP（告警集成参考点）信息服务，用于网元与网管之间 Itf-N 接口上的告警监视。这套模型里的每条告警带有感知严重度（indeterminate/critical/major/minor/warning/cleared 六级）、可能原因等属性，还专门设计了用于把关联通知挂接在一起的机制——换句话说，标准早就给“根因关联”留好了钩子，问题在于现网有多少运营者真把它用起来了。具体实现方式标准允许多种选择，各厂家行为以其官方文档为准。
电信圈谈告警，很少谈“人的负荷”。工业过程控制界反而把这个账算得很清楚。
英国工程设备与材料用户协会的 EEMUA 191（《报警系统：设计、管理与采购指南》，英国健康与安全执行局参与制定）是这一领域的标杆文件。它最著名的结论可以追溯到 Braby 与 Jenkinson 1998 年的调研：对操作员而言，平均每 10 分钟 1 条告警（约每小时 6 条）被认为是可接受的负荷；后来的解读普遍补充，10 分钟内不超过 10 条是避免过载的上限。EEMUA 191 的更新材料里还记录过一个反面案例：某工厂告警速率一度超过每小时 300 条，告警洪流直接拖慢并干扰了操作员对关键告警的响应——这正是“风暴杀人”的实证。
| 对比项 | EEMUA 191 目标值 | 电信现网典型情况 | 差距说明 |
|---|---|---|---|
| 人均告警速率 | 约 6 条/小时（每 10 分钟 1 条） | 繁忙平台数百条/小时，故障夜数千条 | 相差两个数量级以上 |
| 峰值负荷 | 10 分钟内不超过约 10 条 | 传输中断 10 分钟内涌入上千条 | 必须靠平台压缩，不能靠人扛 |
| 常亮告警（standing alarms） | 长期挂着的告警越少越好 | 僵尸告警常年无人清理 | 侵蚀值班员对平台的信任 |
| 告警可信度 | 每条告警都值得响应 | 大量毛刺、重复、无动作项 | “狼来了”效应 |
把这张表放到电信值班室，结论很刺眼：告警系统几乎是按“人处理不了”的规模在设计。电信网节点比化工厂更多、拓扑更深、厂商更杂，而多数运营商的告警平台还停留在“全量上报、人工过滤”的阶段。工业界的这套基准未必能照搬，但它给了一个工程师们心里有数却很少明说的判据：告警治理的目标不是“把告警都送达”，而是“把值得人看的告警送达到人”。
风暴来了，值班员怎么办？老值班长教我的规矩，五步，每步一分钟：
第一分钟：看趋势，不看点。 打开告警速率曲线，确认这是一次“突增”而不是“常态毛刺”。突增意味着大概率有物理级根因，不要被任何单条告警带偏。
第二分钟：做 Top-N。 按网元维度和告警类型维度各拉一个 Top-N 排名。三千条告警通常会收敛到一个光缆段上的几十个网元、两三种告警类型——名单一出来，故障面就出来了。
第三分钟：时间对齐。 把告警按首次发生时间排序，最早的那一批里藏着根因。级联告警总是比源头晚若干秒到若干分钟，时间戳就是它们留下的脚印。
第四分钟：核对变更。 查变更工单：过去 24 小时内，这个区域有没有割接、升级、扩容？如果是自己人昨夜动过配置，处置路径就完全不同——先回退，再排查。这一步是无数事故复盘里最痛的教训：忙了一夜修“故障”，天亮才发现是自己的割接没割干净。
第五分钟：定处置，发通报。 传输类根因，直接调 OTDR 测距定位断点、通知抢修；同时给管理层和客户口部门发第一版影响通报——注意，通报里写的是“影响多少基站、多少用户、预计多久”，而不是“平台上有三千条告警”。用户关心的是服务，不是你的噪音。
这套流程的本质，是把“三千条告警”压缩成“一个故障 + 一个影响面 + 一个动作”。五分钟做不到的值班室，缺的不是聪明人，是套路。
值班室里另一件必须立规矩的事，是告警分级。级别分不清，铃声就没有意义：
| 告警级别 | 典型告警举例 | 响应要求 | 通知方式 |
|---|---|---|---|
| 紧急 | 核心网元宕机、光缆中断、业务全阻 | 立即响应，15 分钟内定位通报 | 平台弹窗加电话叫醒 |
| 严重 | 单站退服、板卡故障、冗余失效 | 30 分钟内确认，按预案处置 | 平台弹窗加短信 |
| 一般 | 单板告警、性能越限、闪断 | 2 小时内确认，纳入工单 | 平台列表 |
| 提示 | 日志类、阈值临界、调试类 | 值班记录，例行分析 | 平台列表，不推送 |
分级最大的陷阱是“级别通胀”：什么都设成紧急，等于没有紧急。级别要定期审计，紧急级的入场门槛必须越来越严。
值班套路是“风暴来了怎么办”，治理要回答的是“怎么让风暴小一点”。三板斧，按见效速度排序：
第一斧：压缩与防抖。 在综合平台侧做三件事——同源去重（同一网元同一告警只计数不重复弹）、时间窗归并（把同一时间窗内同源告警合并为一条带计数的通知）、闪断归并（短时间内告警-恢复反复成对的，归并为一条“闪断”记录并标记振荡）。这一斧不依赖任何智能，纯规则就能把噪音砍掉一大半，是所有治理的地基。
第二斧：屏蔽与抑制。 两类场景必须用：一是计划性割接窗口，窗口开始前对目标网元下屏蔽规则，避免几千条“预期内告警”污染平台；二是依赖抑制，父节点已报中断时，下游子告警自动挂靠、不再单独提醒——这和开源监控体系 Prometheus 里 Alertmanager 的 inhibition 机制是同一个思想：根因在场时，症状闭嘴。
屏蔽这一斧最大的风险是“忘恢复”。屏蔽规则必须强制带过期时间，到期自动失效并审计；割接结束后的第一件事，是把屏蔽规则逐条撤干净并核对平台无残留。历史上有的是血的教训——为了维护安静而屏蔽，最后连真故障一起屏蔽掉了。规则：任何屏蔽都有期限，任何期限都有核对。
第三斧：根因关联。 这是三板斧里技术含量最高、也是标准留钩子最早的一斧。传统做法是专家规则：按拓扑关系写“上游中断则抑制下游”的关联表，有效但写不过来，一张省级网络的拓扑规则人工是维护不完的。学术界这些年给出了新的路子。TempOpt 论文提出无监督的告警关系学习方法，在真实网络数据集上验证，能自动学出告警之间的关联，效果优于传统时序依赖方法，且不需要人工标注——这对告警标注数据稀缺的运营商是很实际的好处。更早一点的工作如《An Influence-based Approach for Root Cause Alarm Discovery in Telecom Networks》（arXiv:2105.03092）用影响力传播的思路在告警流里找根因；面向 5G 核心网，也有公开论文把资源与告警数据建立三层关联关系，用专家经验加图神经网络构建告警关联规则库。把这几类方法放到一起看，趋势很清楚：关联规则从“人写”走向“人写骨架、机器填肉”。
值得强调的是，AI 关联不是魔法。论文里验证过的结论只有两条站得住：一是单点故障触发多节点告警序列是普遍规律，机器学习关联有明确的用武之地；二是无监督方法降低了对标注数据的依赖。至于“关联准确率提升多少”，各论文的数据集和口径不同，不能直接换算到你我的网络——先用小规模现网数据回测，再谈上线。
告警从网元到值班员的完整流水线，画出来是这样：
flowchart TD
A["网元产生告警"] --> B["EMS网管接收"]
B --> C["北向接口上报OSS"]
C --> D["综合告警平台"]
D --> E["压缩与防抖"]
E --> F["根因关联引擎"]
F --> G{"是否根因告警"}
G -->|是| H["升级为事件并派单"]
G -->|否| I["挂到根因告警之下"]
H --> J["值班triage定位"]
I --> J
J --> K["现场或远程处置"]
K --> L["恢复验证"]
L --> M["复盘并更新关联规则"]
M --> F
这张图里最容易被省略的一条边，是最下面那条“复盘更新规则”：风暴过后，当晚三千条告警的时间窗、级联路径、闪断清单要回灌给关联引擎，把这次的“人肉归并”变成下一次的“自动归并”。缺了这一步，平台永远学不会你值班室的手艺。
电信运维习惯自成体系，但隔壁互联网行业的可靠性工程已经把告警问题想得非常透，照一照镜子有好处。
Google 的《Site Reliability Workbook》第五章"Alerting on SLOs"专门讲怎么把 SLO 变成告警。它的出发点不是“监控什么”，而是“什么值得打扰一个活人”：页面告警必须紧急、重要、可行动、真实（这四个性质出自《SRE》原书第六章“监控分布式系统”），任何不满足的告警都应该降级为工单甚至直接不报。书里还给出了量化维度：告警要评估查准率（响的警里有几成是真问题）和查全率（真问题里有几成被响了），以及检测时间——三者天然互相牵制，调优就是在其中找平衡点。对应到故障预算上，就是著名的烧钱率（burn rate）策略：错误预算快速燃烧，立即响铃叫人；缓慢燃烧，丢进工单队列明天处理。
这套哲学对电信值班室的三点启发：
其一，症状告警优于原因告警。 SRE 更倾向于对用户可感知的症状（接通率掉了、时延涨了）告警，而不是对每一个可能的原因（某进程重启、某板卡微码异常）都告警。电信网管的传统是“原因告警”铺满全屏，结果症状反而被淹没。把“小区退服”这类直接面向用户感知的告警保住高优先级，把它背后的几十种原因告警降级挂靠，方向立刻就对了。
其二，每一条响铃都必须可行动。 值班员收到一条告警，如果什么动作都不需要做，这条告警就在训练他忽视平台。“可行动”三个字应该写进告警准入评审的标准里：新告警上线前先回答“看到它的人该做什么”，答不上来的不许响铃。
其三，告警也是产品，有召回有误报。 SRE 团队会统计“sender's remorse”——响错了的懊悔率。电信告警平台很少做这种统计，导致误报永远没人负责。给告警规则配上准确率台账，误报高的规则定期下线，平台的信誉就是这么一点点攒回来的。
最后一节讲治理的运营化。告警治理不是一次性工程，而是一本要月月对账的账本，核心科目五项：
告警总量与压缩比。 每天全网原始告警量、经压缩归并后的通知量，两者的比值是平台的基本功指标。压缩比突然恶化，往往预示着网络里有新的异常模式——它本身就是一个元告警。
常亮告警清理率。 长期挂着没人处理的“僵尸告警”要按周清点。每一条常亮告警都在稀释值班室对平台的信任，信任一旦跌破底线，真告警也会被顺手关掉——这是告警系统死亡的方式。
平均确认时长（MTTA）与平均修复时长（MTTR）。 这两个老指标要按告警级别分开统计。紧急级 MTTA 的目标是分钟级；如果紧急级和提示级的确认时长差不开，说明分级形同虚设。
误报率与规则台账。 每条自动关联规则、每个告警阈值都要有台账：谁上的、依据什么、最近一个月误报几次。连续误报的规则降权或下线，和广告投放优化是一个道理。
割接前后告警基线对比。 这是一个很实用的运维技巧：任何割接、升级前后各取 24 小时告警基线做 diff，新增告警就是升级的副作用清单。基线对得平，割接才算真正收尾——这比“业务恢复就算成功”的验收标准严格得多，也科学得多。
把这本账做起来的团队，一两年后的变化是可以预期的：同样一次传输中断，平台涌入的原始告警还是三千条，但推到值班员面前的根因事件只有一条，级联告警整整齐齐挂在它下面，影响面、断点距离、历史处置记录一并附上。值班员要做的，从“大海捞针”变成“按了确认，打电话叫抢修”。
做了这么多年运维，我的体会是：告警是网络说话的方式。网络不会撒谎，但它很啰嗦——一次小小的故障，它会把同一个消息用三千种说法喊给你听。告警治理的全部工作，就是教会这张网“把话说清楚”：级联的说一遍，重复的不说，闪断的标注，根因的放开音量。
标准（3GPP TS 32.111）早就留好了结构，工业界（EEMUA 191）早就量好了人的负荷上限，谷歌的 SRE 手册早就写好了“什么值得叫醒一个活人”，学术界的新论文正在把关联规则从人工搬进机器。电信运维缺的从来不是方法和工具，而是把告警当成正经工程问题来治理的决心——毕竟，下次凌晨两点光缆断的时候，你是想让值班员翻三千条告警，还是只想让他的手机响一声？
本文由「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 等场景全覆盖。