# 一条光缆，三千条告警：值班室里的告警风暴治理实战 ## 概述 凌晨两点，郊区一条光缆被挖断，最先收到通知的不是用户，而是网管值班室：几分钟内，几千条告警涌上大屏，把一个真实的故障淹没在噪音里。本文回答一个运维老问题：告警为什么会雪崩？值班员如何在风暴里五分钟锁定根因？告警治理压缩、屏蔽、关联三板斧怎么落地？文章以 3GPP TS 32.111 告警规范、工业界 EEMUA 191 告警负荷基准、arXiv 论文 TempOpt 与 Google SRE 工作手册为锚点，把一次典型故障夜的处置和一套告警治理方法讲透。 ## 目录 - 一、凌晨两点十四分：值班室屏幕先炸了 - 二、告警为什么会雪崩：一次故障，一串告警 - 三、六条一小时：人到底能看多少告警 - 四、值班室五分钟：Triage 的老规矩 - 五、治理三板斧：压缩、屏蔽、关联 - 六、谷歌的镜子：SRE 怎么管告警 - 七、让风暴变少：告警治理的账本 - 结语：让网络把话说清楚 ## 一、凌晨两点十四分：值班室屏幕先炸了 先说清楚：这不是某一次真实事故的复盘，而是我值了十几年夜班、处理过几十次传输中断之后，把那些夜晚压缩成的一个“典型故障夜”。细节是合成的，机制是真的。 凌晨两点十四分，郊区一段直埋光缆被第三方施工挖断。物理层面发生的事情很简单：一根纤断了，一个环上的几十个站点业务中断。 但值班室大屏上发生的事情要热闹得多。两分钟后，北向告警开始涌入：先是光传输网元的“信号丢失”“光功率异常”，接着是所带基站设备的“传输中断”“小区退服”，再往下是挂在环上的交换、数据设备的“链路不可达”。一分多钟后，平台上开始出现成对的“告警—恢复”闪烁——下游设备检测到断纤后反复重试，每次重试失败就报一次，个别设备还会在临界状态来回横跳。到两点二十五分，这一起故障在综合告警平台上累计的告警条数，已经突破三千条。 而根因，从头到尾只有一条：某个光缆段中断。 这个“三千比一”的比例，就是本文要谈的全部：告警风暴是怎么产生的，值班员凭什么能在五分钟内从三千条里捞出那一条真凶，以及一张网要怎么治理，才能让下一次风暴从三千条变成三十条。 先把故障夜的完整时间线摆出来： ```mermaid 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） | 长期挂着的告警越少越好 | 僵尸告警常年无人清理 | 侵蚀值班员对平台的信任 | | 告警可信度 | 每条告警都值得响应 | 大量毛刺、重复、无动作项 | “狼来了”效应 | 把这张表放到电信值班室，结论很刺眼：**告警系统几乎是按“人处理不了”的规模在设计**。电信网节点比化工厂更多、拓扑更深、厂商更杂，而多数运营商的告警平台还停留在“全量上报、人工过滤”的阶段。工业界的这套基准未必能照搬，但它给了一个工程师们心里有数却很少明说的判据：告警治理的目标不是“把告警都送达”，而是“把值得人看的告警送达到人”。 ## 四、值班室五分钟：Triage 的老规矩 风暴来了，值班员怎么办？老值班长教我的规矩，五步，每步一分钟： **第一分钟：看趋势，不看点。** 打开告警速率曲线，确认这是一次“突增”而不是“常态毛刺”。突增意味着大概率有物理级根因，不要被任何单条告警带偏。 **第二分钟：做 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 关联不是魔法。论文里验证过的结论只有两条站得住：一是单点故障触发多节点告警序列是普遍规律，机器学习关联有明确的用武之地；二是无监督方法降低了对标注数据的依赖。至于“关联准确率提升多少”，各论文的数据集和口径不同，不能直接换算到你我的网络——先用小规模现网数据回测，再谈上线。 告警从网元到值班员的完整流水线，画出来是这样： ```mermaid 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 ``` 这张图里最容易被省略的一条边，是最下面那条“复盘更新规则”：风暴过后，当晚三千条告警的时间窗、级联路径、闪断清单要回灌给关联引擎，把这次的“人肉归并”变成下一次的“自动归并”。缺了这一步，平台永远学不会你值班室的手艺。 ## 六、谷歌的镜子：SRE 怎么管告警 电信运维习惯自成体系，但隔壁互联网行业的可靠性工程已经把告警问题想得非常透，照一照镜子有好处。 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 手册早就写好了“什么值得叫醒一个活人”，学术界的新论文正在把关联规则从人工搬进机器。电信运维缺的从来不是方法和工具，而是把告警当成正经工程问题来治理的决心——毕竟，下次凌晨两点光缆断的时候，你是想让值班员翻三千条告警，还是只想让他的手机响一声？ ## 参考来源 1. [TempOpt — Unsupervised Alarm Relation Learning for Telecommunication Networks (arXiv:2508.08814)](https://arxiv.org/abs/2508.08814) — arXiv 论文，提出无监督告警关系学习方法 TempOpt，在真实网络数据集上验证单点故障触发多节点告警序列的根因识别问题 2. [EEMUA Publication 191 — Alarm Systems: A Guide to Design, Management and Procurement](https://www.eemua.org/products/publications/digital/eemua-publication-191) — 工业界告警管理标杆指南，给出操作员告警负荷基准（约每小时 6 条）与告警风暴案例 3. [The Sense and Nonsense of Alarm System Performance KPIs (ProcessVue)](https://www.processvue.com/downloads/Alarm_system_performance_KPIs_V1_0.pdf) — 梳理 EEMUA 191 告警 KPI 的由来，追溯“每 10 分钟 1 条”基准至 Bransby 与 Jenkinson 1998 年调研 4. [Google SRE Workbook — Chapter 5: Alerting on SLOs](https://sre.google/workbook/alerting-on-slos/) — 谷歌官方免费在线手册，讲述把 SLO 转化为可行动告警的方法与查准率/查全率权衡 5. [3GPP TS 32.111-1 — Telecommunication management; Fault Management; Part 1: 3G fault management requirements](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1855) — 3GPP 官方故障管理需求规范，配套的 TS 32.111-2 定义 Alarm IRP 告警信息服务 --- > 本文由「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 等场景全覆盖。