# 告警治理实战：十万条瘦身记 **概述**：凌晨一条光缆被挖断，网管一夜炸出两万多条告警，值班工程师反而漏看了真正致命的那一条——这是每个核心网和无线运维都经历过的「告警海啸」。本文不聊概念，只回答一个问题：告警量到底怎么压下去、压到多少才算健康？文章以 IETF 正式标准 RFC 8632（告警管理 YANG 数据模型）为解读主轴，结合它转引的 EEMUA 191 / ISA-18.2 量化基准和 3GPP TS 32.111-2 告警架构，给出一套可直接落地的「三板斧」治理方案与对账表。 ## 目录 - 凌晨三点，告警海啸淹了值班台 - 一条故障，为啥炸出一万条告警 - 人能看多少条告警？EEMUA 给过死数字 - 标准工具箱：RFC 8632 把告警治理写成了数据模型 - 实战三板斧：梳理、降噪、兜底 - 治理前后对账：数字不会说谎 - 三个坑：告警静默、过期屏蔽单、考核扭曲 - 结语：告警是给「需要动作的人」看的 ## 凌晨三点，告警海啸淹了值班台 先讲一个场景。它不是某一家的确切事故通报，而是我从十八年运维经历里反复见过、把几个省公司的真实夜班拆开重组的复合场景，数字做了模糊化，但每一环都真实发生过： 台风季，凌晨三点，郊区施工队一台旋挖钻机铲断了一根 96 芯光缆。这根光缆承载着一个环网的两条复用段。接下来的十分钟里： - 传输网管先报 2 条信号丢失（LOS）； - 环上 10 台 BBU 相继失步，报 10 条时钟告警； - 挂在下面的 120 个 5G 小区逐一退服，120 条小区退服告警； - 每个 BBU 又因为断电次序、风扇联动、前传链路级联，各补了十几条设备类告警； - 闪断让其中一部分告警反复「产生—清除—再产生」，一条告警能刷出几十条事件。 北向接口的 Trap 洪流冲进综合告警平台，峰值每分钟四千多条。值班台上，大屏滚动得像股票行情。而当晚真正要人命的信息只有一句：**某环网光缆中断，影响 120 个小区**。它被淹没在第两万条附近。抢修队五点到场，六点四十分熔接恢复——但值班工程师真正「看见」这条根因告警，已经是四点二十分，靠的是老师傅直接登录传输网管一台台翻的，没靠告警平台。 第二天复盘会上，所有人都同意该治理了。问题是怎么治。这不是某一家网管的 bug，而是行业性的结构问题。 ## 一条故障，为啥炸出一万条告警 故障和告警之间，从来不是一一对应。IETF 在 2019 年发布的正式标准 RFC 8632《A YANG Data Model for Alarm Management》里写得非常直白：*"One fault may result in several alarms in case the system lacks root-cause and correlation capabilities."*——一个故障在系统缺乏根因与关联能力时，会炸出多条告警。这条一句话，就是告警风暴的全部病理。 具体到通信网，膨胀机制有四种： **1. 级联放大。** 光缆是根因，但它断的那一刻，所有下游资源都会「如实汇报」自己的异常：端口失联、时钟失步、小区退服、用户面会话中断。网络拓扑有多深，告警就放大多少倍。一根骨干光缆的故障，放大出上千条「症状告警」是常态。 **2. 闪断抖动。** 光功率在门限附近徘徊时，告警反复产生、清除。RFC 8632 特意把「告警」定义为资源上的**状态**（state）而不是**通知**（notification）——link-down 和 link-up 两条通知，本来应该归并成同一个 link-alarm 状态的两次翻转。但大量老网管按事件流水记账，一次抖动就是 N 条记录。 **3. 冗余与陪跑。** 同一块板卡故障，电源、温度、业务三个维度各报一条；设备下电了还在报「风扇异常」。RFC 8632 附录 G 把这类统称为 nuisance alarms（滋扰告警），并点名了几种成因：chattering（喋喋不休）、fleeting（稍纵即逝）、redundant（冗余）、cascading（级联），以及「把日志信息当告警发」。 **4. 只加不减。** 维基百科的 Alarm management 词条回顾了这段历史：早年模拟屏时代，每加一个告警要接一根线、占一块面板，加告警是有成本的；进入 DCS 数字系统后，加一条告警变成「填个位置、填个值」的事，于是什么都设了告警——80%、20% 各设一条成了习惯动作。通信网管走了一模一样的路：每出一次事故就加一批告警，从没有人做减法。 ## 人能看多少条告警？EEMUA 给过死数字 「告警太多」是句废话，「多少算多」才是可治理的命题。这个数字不是拍脑袋，流程工业行业在上世纪八九十年代出过血泪教训后，形成了 EEMUA 191《Alarm Systems: A Guide to Design, Management and Procurement》和 ANSI/ISA-18.2 两份权威基准。RFC 8632 的附录 G 把这两份基准原样采纳进了网络运维领域——这是它能当本文主轴的原因：数据出处清晰，可直接对账。 **稳态下的可接受告警速率**（RFC 8632 附录 G，Table 4，转引自 EEMUA）： | 稳态长期告警速率 | 可接受性评价 | | --- | --- | | 每分钟超过 1 条 | 很可能不可接受 | | 每 2 分钟 1 条 | 很可能超出人的负荷 | | 每 5 分钟 1 条 | 勉强可控 | | 低于每 10 分钟 1 条 | 很可能可接受 | **重大网络故障后的突发场景**（同附录 Table 5）： | 故障后 10 分钟内呈现的告警数 | 评价 | | --- | --- | | 超过 100 条 | 明显过量，操作员极可能干脆放弃告警系统 | | 20～100 条 | 难以应付 | | 低于 10 条 | 应该可以应付（若多条都需要复杂操作则仍偏难） | 注意两点。第一，RFC 特别强调这些数字是**一个告警控制台所辖全部网络的总量**，不是单套网管的各自配额——这就是为什么省公司级的综合告警平台必须兜底压缩，而不是把压力下放给值班员。第二，EEMUA 对「好告警」给了八个词的定义：相关、唯一、及时、有优先级、可理解、可诊断、有建议、聚焦。对照一下你家网管里那些内容为「Module 3 exception 0x7f00」的告警文本，八项能占三样就不错了。 拿稳态基准倒推：一个省全网稳态告警如果常年高于每天三百条（约每 5 分钟 1 条）到一千条（约每 1.5 分钟 1 条），值班台就已经处于「不可接受」区间。而绝大多数省级运营商的日均原始告警是十万量级起步——差了两个数量级，中间那道墙，就叫告警治理。 ## 标准工具箱：RFC 8632 把告警治理写成了数据模型 好消息是，告警治理不是玄学，标准已经把该有的机制都写全了。除了 RFC 8632，这条线上还有三个名字：ITU-T X.733（1992 年起的告警上报功能，老网管的祖师爷）、ITU-T G.7710（传送网设备管理，定义了告警屏蔽 ARC）和 3GPP TS 32.111-2（Alarm IRP，移动网管故障管理的集成参考点，最新版对「告警」的定义已与 RFC 8632 基本一致：**告警是资源的一种非预期状态，且需要操作员动作**——注意，需要动作，这是全篇最要紧的限定词）。 RFC 8632 值得每个运维平台开发者精读，它把治理机制做成了可操作的数据模型，我挑四个最有实战价值的： **1. 告警是有主键的状态。** 每条告警用三元组（资源、告警类型、告警类型限定符）唯一标识，产生、清除断、降级、升级都只是同一个状态的变迁记录。按这个模型做，闪断抖动天然收敛——抖一百次，还是那一条告警，历史列表里记一百次状态变化。严重级别沿用 X.733 的五档：indeterminate、warning、minor、major、critical；而「清除」不是级别，是独立布尔位。别小看这个设计，它把「告警清了但人没闭环」「人关了但故障还在」这两件事分开了：资源生命周期（raise/clear）归设备，操作员生命周期（ack/close）归人，各记各的账。 **2. 屏蔽（shelving）是一等公民。** 按资源、按告警类型配置屏蔽规则，被屏蔽的告警不产生通知，但进独立的「已屏蔽列表」继续记录状态变化，并且系统里有个 shelves-active 标志提示「当前有生效的屏蔽」。这就是割接窗口屏蔽告警的标准化做法——不是把告警关掉，是把它请到隔壁房间还开着监控。G.7710 里的告警上报控制（ARC）对应的就是这套机制。 **3. 根因与影响面是告警的字段，不是人脑的推理题。** 模型里有两个可选字段：root-cause-resource（可能的根因资源）和 impacted-resource（可能受影响的资源）。RFC 给的示例非常传神：磁盘满时，应该在磁盘分区上出**一条**告警，并把数据库、应用塞进 impacted-resource 列表，而不是让数据库和应用各报一条。翻译到通信网：光缆断，应该在光缆段上出一条 major，把 120 个退服小区挂进它的 impacted 列表。 **4. 通知可以源头节流。** 模型提供 notify-status-changes 开关：全部状态变化都报 / 只报产生和清除 / 只报跨过某严重级别的变化。很多网络的问题在源头就没管住——把「告警文本变了」也当一条通知发出去，量能不大才怪。标准允许多种实现，具体能力以各厂家网管文档为准，但这三档语义是通用的。 ## 实战三板斧：梳理、降噪、兜底 标准是刀，怎么砍要按省情来。这几年我从几个省的治理项目里沉淀出三步，按顺序做，跳步必翻车： **第一板斧：告警合理性梳理（rationalization）。** 把全网的告警清单拉出来，逐条问 EEMUA 那个祖传问题：**这条告警响了之后，人需要做什么动作？** 答不上来的，降级为事件日志或直接关掉。一个真实经验值：首轮梳理通常能砍掉 30%～50% 的告警定义，剩下的一一配上「处置指引」——RFC 8632 的 alarm inventory（告警清单）机制就是为此设计的：设备必须公布全部可能的告警类型和处置说明，管理系统能据此给每条告警预挂 SOP。这一步最枯燥，也最值钱——后面所有自动化都建立在「每条告警都有意义」之上。 **第二板斧：规则化降噪流水线。** 在告警进值班台之前架四道闸，次序有讲究： | 闸门 | 管什么 | 典型手法 | 失效模式 | | --- | --- | --- | --- | | 状态机去重压缩 | 闪断抖动、重复上报 | 同源同类合并为一个状态，只记变迁 | 清除风暴：故障恢复瞬间清除通知淹没台面 | | 闪断抑制 | 光功率临界抖动 | 加迟滞（hysteresis）与最小持续时间，抖动 N 次才上报 | 阈值太宽，真故障被延迟发现 | | 拓扑根因抑制 | 级联告警 | 依赖配置：光缆中断自动抑制下游小区退服，症状挂到根因之下 | 依赖数据不准会错杀，根因表要随割接维护 | | 割接屏蔽单 | 计划内施工 | 屏蔽单带生效与过期时间，到点自动失效并审计 | 忘删过期屏蔽单，真告警被压 | ```mermaid flowchart TD A["光缆被铲断"] --> B["OTN网元报信号丢失"] A --> C["10台BBU失步"] A --> D["120个小区退服"] B --> E["北向接口告警洪泛"] C --> E D --> E E --> F["峰值每分钟数千条Trap"] F --> G["状态机去重压缩"] F --> H["拓扑根因抑制"] F --> I["割接屏蔽单过滤"] G --> J["根因1条加症状打包归档"] H --> J I --> J J --> K["值班大屏只剩3条"] K --> L["派单抢修约40分钟恢复"] ``` **第三板斧：AI 兜底。** 规则处理「已知模式」快且稳，但总有长尾：历史上有因果关系但从没被录进根因表的告警组合、跨专业（无线+传输+动环）的稀疏关联。这两年各省上马的智能告警关联，本质是用历史工单和告警序列训练关联模型，把「规则没覆盖的关联」补上。大模型进网管之后，又多了自动生成处置建议、自动回填根因报告这类用法。我的建议是把它放第三板斧而不是第一板：AI 的输出必须挂在人工可复核的关联证据上，且永远不要让 AI 直接执行「屏蔽」这类有副作用的动作——先把规则层做扎实，AI 才有干净的训练数据和兜底空间。 ## 治理前后对账：数字不会说谎 给一张对账表。同样是复合示例数据（多家省级项目的量级综合，非某一家公司的披露口径），但结构是照着 RFC 8632 附录 G 的指标搭的，任何团队都能照此自测： | 指标 | 治理前 | 治理后 | 基准出处 | | --- | --- | --- | --- | | 日均原始告警（入库量） | 约 12 万条 | 约 12 万条 | 不变——源头忠实记录 | | 日均进入值班待处理队列 | 约 4,000 条 | 200 条以内 | EEMUA 稳态基准 | | 重大故障 10 分钟突发呈现 | 数千条 | 10 条以内 | RFC 附录 G Table 5 | | 闪断抖动类占比 | 约 60% | 5% 以下 | 自查口径 | | 根因告警平均浮现时长 | 40 分钟以上 | 1 分钟内 | 内部 SLA | | 值班员确认率（点开并处置的比例） | 不足 10% | 90% 以上 | 「告警狼来了」指数 | 两个容易被忽略的点：**原始告警量一条都不该少**。治理压的是「进人眼的量」，入库的是全量——审计、回溯、训练 AI 都靠它，动原始数据等于销毁案发现场。另外，「值班员确认率」是我个人最看重的一个软指标：它直接度量告警系统还活着没有。低于 30%，说明值班台已经在集体「已读不回」，这时任何新增的告警规则都是往深海里扔石头。 ## 三个坑：告警静默、过期屏蔽单、考核扭曲 **坑一：压着压着就成了静默。** 降噪做猛了，真告警被误杀，出了事一查「系统里根本没报」。防线有三：原始数据全量留存可回放；每条抑制规则可一键旁路做灰度验证；对「被抑制告警」本身做统计——被抑制的量级和分布异常波动，本身就是一条应该上报的告警（元告警）。RFC 8632 的安全考虑章节甚至专门警告：对屏蔽配置和告警删除操作的越权访问，会直接破坏告警管理流程——标准作者早就见过有人拿降噪功能干静音的勾当。 **坑二：过期屏蔽单。** 割接屏蔽单是治理工具里最锋利也最危险的。行业通行的三条铁律：屏蔽单必须带自动过期时间（割接窗口外自动失效）；必须有独立审计视图，谁、何时、为什么、屏蔽了什么，一屏看尽；割接完成后的复盘动作里必须有「核对屏蔽单已全部回收」。我在多家现场见过因屏蔽单忘删导致次日凌晨真退服无人知晓的案例，无一例外，复盘时所有人都记得「好像有个单子」。 **坑三：考核扭曲。** 如果考核指标是「值班台告警数量越少越好」，三个月后你会得到一个全世界最安静的网管——因为有人把告警定义批量关了。治理指标必须是组合拳：待处理量下降的同时，漏报率、根因浮现时长、确认率必须同步达标。降噪的 KPI 永远是「该响的都响了，不该响的一声没有」，这不是修辞，是可以用回归测试验证的工程目标——治理规则上线前，拿历史故障样本回放一遍，验证每次重大故障根因告警仍然置顶，这是告警治理版本的「测试用例」。 ## 结语：告警是给「需要动作的人」看的 把整篇收拢成一句话：**3GPP v15 对告警的定义——「需要操作员动作的资源非预期状态」——就是全部治理工作的宪法。** 不需要动作的，是日志；可能需要的，是事件；确定需要的，才配叫告警。 EEMUA 用流程工业几十年的事故换来了那几张速率表，RFC 8632 把它们连同状态机、屏蔽、根因字段一起搬进了网络运维的标准工具箱，剩下的活儿是我们自己的：把告警清单梳理到每条都有人认领，把降噪流水线架在根因数据上，把 AI 放在规则之后而不是之前，再配上组合 KPI 防止治理跑偏。 凌晨三点的告警海啸不会绝迹——光缆还是会被铲断。但下一次，值班工程师打开大屏，应该看到的是一条置顶的根因、一张受影响小区的清单和一个已经开始的抢修工单，而不是两万条滚动刷屏的红色。治理的终极验收标准只有一条：**告警台重新变回一个「看一眼就知道该干嘛」的地方。** ## 参考来源 1. [RFC 8632: A YANG Data Model for Alarm Management](https://www.rfc-editor.org/rfc/rfc8632.html) — IETF 2019 年正式标准（Stefan Vallin、Martin Bjorklund），本文主轴：告警状态机、屏蔽、根因/影响面字段，附录 G 完整转引 EEMUA 191 与 ISA-18.2 的告警速率基准表 2. [Alarm management - Wikipedia](https://en.wikipedia.org/wiki/Alarm_management) — 告警管理发展史：从模拟面板到 DCS 后「告警免费化」导致的泛滥，Honeywell 告警管理任务组（1990）与 ASM 联盟（NIST 资助，1994）背景 3. [3GPP TS 32.111-2 Alarm IRP](http://www.3gpp.org/ftp/Specs/html-info/32111-2.htm) — 3GPP 故障管理第二部分：告警集成参考点（信息模型），v15 起对「告警」的定义与 RFC 8632 一致（链接转引自 RFC 8632 参考文献 [ALARMIRP]） --- > 本文由「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 等场景全覆盖。