凌晨两点，告警墙三分钟刷了一遍屏。值班工程师看了眼右下角的计数器，冲了杯咖啡，回来时又多了一千多条。这不是断网，网络其实只断了一根光缆——剩下三万条告警，全是“伴生噪声”。本文回答一个问题：运营商NOC（网络运维中心）里那些海量的告警是从哪来的、为什么九成以上不值得看、一套成熟的告警治理体系是怎么把“三万条”压回“三条”的。本文以Google SRE经典著作的告警章节与ITU-T X.733/3GPP TS 32.111故障管理标准为解读主轴，结合脱敏后的省级NOC实战场景展开；工业报警管理的EEMUA 191基准作为跨行业参照。文中案例细节已脱敏合成，基准数据均注明出处。 ## 目录 - 一、凌晨两点：一根光缆如何刷爆告警墙 - 二、告警到底是什么：X.733给了它一张身份证 - 三、洪水的物理学：告警放大链解剖 - 四、治理三板斧：源头减量、规则归并、分级路由 - 五、跨行业镜子：EEMUA 191与Google SRE的告警观 - 六、把告警当资产管：指标、考核与清零战役 - 七、一份可以直接抄的告警治理SOP - 八、经验教训：告警系统的本质是注意力管理 ## 一、凌晨两点：一根光缆如何刷爆告警墙 先交代场景（细节已脱敏合成，机制全部真实）：某省NOC，周三夜班。22:47，市政施工挖断了一条汇聚层光缆。这本该是一条“critical”级别的告警加一通电话就能解决的事。 实际发生的是：3分钟内，值班大屏涌入了超过3000条告警；到凌晨1点，累计超过3万条。值班工程师的第一个动作不是修光缆——是先把E-mail告警通知关掉，因为邮箱已经被撑爆，再不关，第二天所有告警邮件都没法看了。 时间线大致如下： | 时间 | 事件 | 告警表现 | |---|---|---| | 22:47 | 光缆被挖断 | OTN线路板LOS（信号丢失）告警1条 | | 22:47-22:50 | 两个汇聚环设备失联 | 每台设备1条“通信中断”告警 | | 22:48-23:10 | 62个基站失联 | 每基站：通信中断+小区退服，1800余个小区各1条 | | 22:48起 | 基站间链路断 | S1/X2链路告警、时钟丢失告警成批出现 | | 23:00起 | 话务迁移 | 周边存活基站话务拥塞、接通率跌，衍生性能类告警 | | 23:10 | 网管北向接口 | 上述全部告警涌向省级NMS，形成刷屏 | 真正的根因告警是第22:47那1条LOS。后面三万条，全部是它在拓扑上的“回声”。 这就是NOC圈子的老话：“**告警响一千声，病往往只有一个。**”问题在于，告警系统不会替你数这个。 ## 二、告警到底是什么：X.733给了它一张身份证 要看懂告警为什么容易泛滥，得先看它的出身。电信网管的告警模型源头是ITU-T X.733建议书（Systems Management: Alarm Reporting Function，1992年发布，至今仍是全球网管系统的地基）。3GPP SA5工作组在其上构建了3GPP的故障管理体系——TS 32.111系列的Alarm IRP（Integration Reference Point），把告警建模搬进了3GPP时代，后续又演进出TS 28.532等治理框架。今天你看到的任何一家网管的告警列表，字段都长着同一张脸，因为它们都是X.733的后代。 X.733定义的一条告警通知，核心字段包括： | 字段 | 含义 | 实战意义 | |---|---|---| | perceivedSeverity | 严重级别 | critical/major/minor/warning/indeterminate，决定要不要半夜打电话 | | probableCause | 可能原因 | 枚举表：信号丢失、通信中断、拥塞、板卡故障…… | | specificProblem | 具体问题 | probableCause不够用时的补充说明 | | eventType | 告警类型 | 通信类、服务质量类、环境类、设备类、处理失败类 | | managerObjects | 告警对象 | 哪个网元、哪块板、哪个小区 | | acknowledgedState | 确认状态 | 有人看过没有 | | clearedFlag | 是否清除 | 故障恢复后告警要不要“熄灯” | 注意最后两个字段——**这两个字段的存在本身，就说明标准制定者三十年前就知道告警会被大量产生、大量忽略**。它们是给“管理洪水”预留的钩子：确认状态用来记录“谁看过”，清除标志用来支持“已恢复告警自动归档”。 但X.733只定义了“一条告警长什么样”，没有定义“一万条告警怎么管”。后者是每个NOC自己的修行，也是本文的主题。顺带说明：告警在网管间同步、清除后保留还是删除等行为，标准允许多种实现，具体以各厂家官方文档为准。 ## 三、洪水的物理学：告警放大链解剖 为什么一根光缆能变成三万条告警？因为告警在拓扑上是**级联放大**的，每一层都会“负责任地”喊一嗓子。 ```mermaid flowchart TD A["22:47 光缆被挖断"] --> B["OTN线路板LOS告警"] B --> C["两台汇聚设备失联"] C --> D["62个基站通信中断"] D --> E["1800个小区退服"] D --> F["S1与X2链路断"] D --> G["时钟丢失"] D --> H["话务溢出"] E --> I["北向接口涌向NMS"] F --> I G --> I H --> I I --> J["值班大屏3分钟刷屏"] ``` 拆开看，放大发生在四个环节： **第一层：一变多（设备层冗余上报）。** 一个基站失联，网元管理系统（EMS）会针对它下属的每个对象分别报：每个小区1条退服、每条SCTP链路1条断链、每块需要时钟的板子1条时钟丢失。一个三扇区五载波的5G基站，失联一次就是十几条告警。62个基站，乘出来就是一千多条起步。 **第二层：重复上报（时间维度振荡）。** 传输闪断时，链路“断—通—断—通”，每抖一次就产生一对“告警+清除”。夜里一次光缆抢修过程中的反复熔接，能让同一条告警重复出现上百次。这类“闪断告警”是NOC噪声的大头——**它们最终都会自己恢复，但在恢复之前的几个小时里，它们一直占着屏幕**。 **第三层：衍生告警（因果链误报）。** 上游断了，下游的一切都会喊疼：基站的GPS时钟丢了喊一条、传输保护倒换喊一条、话务倒灌到邻区后拥塞告警又喊一条。这些告警单看每条都“真实”，合起来全是废话——**它们不是独立的故障，是同一个故障的涟漪**。 **第四层：多级网管转发。** EMS报一遍，省级NMS收一遍，集团级系统再收一遍。每次转发如果不去重，计数再翻番。很多省的NOC同时接五六张网（无线、传输、核心、动环、家宽），每张网一个告警格式、一套级别语义，“critical”在不同厂家网管里的分量并不总是一样——这本身也是洪水的一部分。 运维圈的常见经验值是：一个中等规模省网，未经治理的日均原始告警在数万条量级，其中真正需要人工介入的“有效告警”占比常年低于5%，夜班真正需要立即行动的往往是个位数。这个数字来自一线经验而非任何官方统计，各家网络差异很大，但数量级判断业内高度一致。 ## 四、治理三板斧：源头减量、规则归并、分级路由 告警治理没有魔法，成熟的做法就是三板斧，一层漏斗把三万条压回三条： ```mermaid flowchart TD A["原始告警 日均数万条"] --> B["工程屏蔽 割接窗口抑制"] B --> C["闪断抑制 短时自清不上抛"] C --> D["同类合并 同对象同告警码"] D --> E["根因归并 按拓扑收敛"] E --> F["分级路由 critical才叫人"] F --> G["值班可看 每晚个位数"] ``` **第一板斧：源头减量——不该出生的告警别让它出生。** - **工程屏蔽（维护窗口抑制）**：割接前在网管上挂“工程态”，窗口期内该网元的告警只记录不上抛。这是性价比最高的一招——大量夜间告警风暴其实是自己割接割出来的，本就不该去吓值班的人。 - **闪断抑制（延迟上报）**：对历史数据显示30秒内必然自清的告警类型（如部分传输抖动类），设一个观察窗，窗口内自清的只记日志、不上抛。等价于SRE圈说的“给告警加去抖”。 - **清除即归档**：已清除的告警自动移出活动列表。听起来天经地义，但现实中大量NOC的活动告警列表里躺着几个月前的“僵尸告警”——它们的作用只有一个：把真正的新告警埋掉。 **第二板斧：规则归并——把回声折回声源。** - **同类合并**：同对象+同告警码在窗口内重复出现，只显示一条并累加计数（“已发生47次”）。屏幕从一万行变成一千行。 - **根因归并**：基于拓扑做衍生抑制——当传输段A失联时，其下挂的所有基站告警自动折叠为“A失联的衍生告警”分组。值班看到的是“光缆断，影响62站”一条结论，而不是62×N条碎片。归并规则靠拓扑数据支撑，这也是为什么告警治理项目做到一半往往会变成“资源/拓扑数据治理项目”——**拓扑不准，归并就是乱配**。 **第三板斧：分级路由——让对的告警找到对的人。** - critical级短信/电话立即叫人，major级进值班队列，minor及以下进日间工单，warning类只进报表。 - 关键配套是**告警升级**：一条告警30分钟无人确认，自动升级重发。这防止了“分级路由”退化成“分级遗忘”。 - 值班大屏只放critical+major，其余全部收进二级界面。屏幕上永远只放“需要现在做的事”，这是治理的最后一道闸。 三板斧做完，值班工程师夜里看到的告警从三万条变成个位数——**不是告警少了，是废话被折叠了**。 ## 五、跨行业镜子：EEMUA 191与Google SRE的告警观 告警洪水不是电信独有的病。工业过程控制行业（炼化、电力）早在上世纪就把它研究透了，两个权威参照值得每个通信运维人看看。 第一个是**EEMUA 191**（英国工程设备与材料用户协会发布的报警系统指南，被公认为工业报警管理的标杆，与美国的ISA-18.2标准体系相互呼应）。据EEMUA 191给出、被业界广泛引用的基准：每个操作员位平均告警速率应控制在每天约150条以内（折合每10分钟约1条），任何10分钟窗口内峰值不宜超过10条，超过10条/10分钟即进入“告警洪水（alarm flood）”状态——超过这个状态，操作员的认知已经跟不上，只能随机处理。对照一下：电信NOC一场夜班的告警量是工业红线的几百倍。当然，电信网的自动化程度更高、告警的“单条处置成本”不同，不能机械套用，但**“洪水阈值”这个概念本身极具启发：超过阈值后，人对告警的响应质量会断崖式下跌**。 第二个是**Google SRE**。Google的《SRE：Google运维解密》一书专门有Alerting章节（可在sre.google免费阅读，本文参考来源给出链接），其核心论点用一句话概括：**每一个需要人来响应的告警，都应该对应一个“真实发生、紧急、需要人、且现在就需要人”的问题；凡是机器能自动修的、可以等到天亮的，都不配成为page**。SRE反复警告告警疲劳（alert fatigue）的代价链：告警太多→工程师开始无视→真正重要的page被淹没→事故响应延误。这条因果链与NOC里“狼来了”的故事一模一样。SRE给出的解法之一——按“症状”（用户可感知的劣化）而不是“原因”（每一层设备的絮叨）来告警——与电信告警治理里的“根因归并、衍生抑制”在哲学上完全同构：**上报结论，不上报过程**。 两个行业、两套术语，殊途同归，说明这不是某家设备商或某个网络的问题，而是**告警系统作为“人机接口”的普遍规律**：告警系统的本质不是记录故障，而是分配人的注意力。 ## 六、把告警当资产管：指标、考核与清零战役 治理不能靠运动，要靠指标长期运营。一个省NOC告警治理的典型指标基线（示意性目标值，供参考）： | 指标 | 治理前（典型） | 治理后目标 | 说明 | |---|---|---|---| | 日均原始告警条数 | 数万条 | 同左（不减产生量） | 源头不压抑记录，保留全量用于审计 | | 值班可见活动告警 | 数千条 | <100条 | 经归并/抑制后进入值班视图的量 | | 有效告警占比 | <5% | >80% | 需要人工动作的告警/值班可见告警 | | 平均确认时长MTTA | 小时级 | <15分钟 | 从上抛到有人点确认 | | 闪断告警上抛率 | 无控制 | <10% | 观察窗内自清的告警不上抛 | | 告警零条天数 | 从未达成 | 每周≥1天 | “清零战役”结果，衡量积压治理 | 其中最反直觉的是第一行：**治理的目标不是让告警“变少”，而是让值班“看到的变少”**。全量告警必须继续入库——它们是网络健康的原始心电图，事后复盘、容量分析、故障回溯全靠它们。压掉的是呈现，不是记录。 “告警零条”值得一提：一些省公司搞“告警清零”考核，要求活动告警列表每日归零。考核本意是逼着处理积压，但异化得很常见——工程师为了清零去批量确认、甚至临时关掉爱产生告警的监测点，这等于把烟雾报警器拆了来消除警报。正确的清零是“清除”（故障真修好了），不是“确认”（我看过了）或“屏蔽”（我不听了）。**考核告警治理时，一定要同时考核“告警功能在线率”，否则清零运动会亲手制造盲区。** ## 七、一份可以直接抄的告警治理SOP 把前文收拢成一个可落地的清单，按优先级排序： 1. **先清僵尸**：把活动告警列表里超过30天的“常亮告警”逐条定性——该修的修，该转隐患库的转隐患库，历史遗留无法清除的建白名单单独存放。这一步不产生任何新能力，但直接提升值班视图信噪比，一周末见效。 2. **割接全走工程态**：所有割接/升级作业必须有维护窗口抑制，纳入割接审批检查项。杀灭“自产告警”。 3. **给闪断类告警加观察窗**：挑出历史上自清率最高的Top 10告警类型（用全量历史数据统计），逐类设置延迟上报窗口，上线后监控“漏报真实故障”次数并回调。 4. **建根因归并规则Top 20**：不必贪多。把过去一年夜间告警风暴复盘一遍，提炼发生频率最高的20条因果链（传输断→基站退服；时钟丢失→切换劣化；动环停电→传输与无线连环退服……），按拓扑配置衍生抑制。剩余长尾留给值班人工判断。 5. **重定级别语义**：和值班团队坐下来，把critical重新定义为“需要现在起床”，major为“今夜要处理”，minor为“明天要处理”。级别语义以值班人员的真实行为为准，而不是设备商默认值。 6. **加告警升级机制**：未确认超时自动升级，防止分级路由变成分级遗忘。 7. **月度复盘告警有效性**：每月抽值班告警，统计“响了但不用动”（误报）与“该响没响”（漏报）各占比，持续修正规则。AIOps类告警归并工具（各设备商与独立软件商均有产品）可以在这一步介入，帮助从历史数据里自动挖掘归并规则——但规则的可解释性要保留，值班人员需要知道“为什么这几条被折在一起”。 这套SOP不含任何黑科技，全部是工程纪律。告警治理最难的部分从来不是算法，是**说服所有人：屏幕上的告警越少，网络越安全**。 ## 八、经验教训：告警系统的本质是注意力管理 最后回到那根光缆。那晚真正的故障22:47发生，22:52就被传输班确认并开始抢修——抢修本身只用了平时的时间。真正拖到凌晨四点才收尾的，是告警善后：三万条告警的逐条确认、清除、归档，以及第二天被撑爆的邮箱和被误触发的一堆工单流程。**噪声没有改变故障的进程，但吃掉了运维组织的全部剩余注意力。** 几条值得带走的判断： - **告警系统是注意力分配系统**。它消费的不是日志空间，是值班工程师的清醒时间。评估告警系统时问的问题不是“它能不能报出来”，而是“它报出来的东西，我敢不敢不看”。 - **回声要折回声源**。任何一条值班可见告警，理想状态是一条结论+一个影响面+一个动作，而不是一片涟漪。拓扑数据是归并的地基，拓扑不准，一切归并都是赌博。 - **洪水有阈值**。EEMUA的“10条/10分钟”红线未必适用于电信，但“超过阈值响应质量断崖下跌”这条规律普适。值班设计要按洪水位考虑，按平时水位考虑的设计在风暴夜必然失效。 - **治理是运营不是项目**。告警规则会随网络演进腐化——新设备上线带来新告警类型，旧规则悄悄失配。要有月度复盘机制让规则跟着网络长。 一张安静的大屏，比一张热闹的大屏值钱得多。 ## 参考来源 1. [Google SRE Book — Alerting章节](https://sre.google/sre-book/alerting/) — Google官方免费公开的SRE圣经告警章节，告警疲劳与“告警必须紧急、真实、需要人”原则的出处 2. [Google SRE Book — Alerting on SLOs](https://sre.google/sre-book/alerting-on-slos/) — 按症状而非原因告警的工程化方法论 3. [Wikipedia: Alarm management](https://en.wikipedia.org/wiki/Alarm_management) — EEMUA 191与ISA-18.2报警管理基准（告警速率目标、洪水定义）的综述条目 4. [ITU-T Recommendation X.733](https://www.itu.int/rec/T-REC-X.733) — 电信管理告警上报功能与严重级别模型的源头标准 5. [3GPP Specifications](https://www.3gpp.org/specifications) — 3GPP SA5故障管理体系（TS 32.111系列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 等场景全覆盖。