凌晨三点四十七分，一条汇聚层光缆被第三方施工挖断。十分钟后，网管大屏上挂出了四千多条告警。值班工程师盯着满屏的红色，要在其中回答一个问题：真正断的，到底是哪一根？ 这不是虚构的极端案例，而是每一个维护过传输网、承载网、核心网的工程师都经历过的日常。一个物理故障会在几分钟内衍生出海量连锁告警，业界常说的“故障与告警放大效应”就来自这里——根因只有一处，告警却铺满全屏。而今天要聊的，是AI怎么接下这个夜班：从告警瘦身、根因推理，一直到大模型直接给出处置建议的完整闭环。这也是全球运营商“自智网络”（Autonomous Networks）演进路线里，最接近商用落地的一段。 ## 目录 - 一、告警风暴：网管值班席的第一杀手 - 二、自智网络：TM Forum的六级标尺 - 三、告警瘦身流水线：从四千条到一条根因 - 四、大模型进NOC：能读懂3GPP规范的AI - 五、人工值守与L2/L3/L4自治方案对比 - 六、落地三道坎：数据、信任与考核反噬 - 七、工程师怎么办：从看告警到养模型 - 八、结语 ## 一、告警风暴：网管值班席的第一杀手 先看一场典型的告警风暴是怎么炼成的。以一个省公司规模的承载网为例，公开报道中常见的原始告警量级是每天数万条，逢割接窗口和恶劣天气还会翻倍。这些告警里，真正的“根因告警”往往只占极小比例——大量是衍生告警：光缆断了，跑在上面的几十条业务通道同时报LOS，下游的端口、板卡、保护倒换状态跟着一起报警，再叠加网元之间心跳超时的次生告警。 放大链条通常是这样的：一处物理中断，直接触发上游设备的信号丢失；每一条经过该链路的业务路径各报一条；网管系统对每条业务再做阈值判断，又各派生若干条性能告警。三到四层放大之后，一个根因变成数千条告警，是行业里反复被验证的现象。 对值班工程师来说，痛点不在“看不过来”本身，而在三个更隐蔽的地方： **第一，跨网管的命名鸿沟。** 同一根光缆，在传输网管里叫某个光路编号，在IP承载网管里是某个端口down，在.cmdb（配置管理数据库）里又是另一个资产编码。要把这四千条告警归并到同一个物理根因，得先跨系统对齐拓扑——这是所有告警治理项目真正的地基。 **第二，告警的时序陷阱。** 衍生告警的到达顺序受轮询周期、上送队列影响，未必和因果顺序一致。“谁先到”不等于“谁是因”，纯靠时间戳排序做归并，准确率的天花板很低。 **第三，夜间人力断档。** 告警风暴高发时段（割接窗口、雷雨夜）恰恰是值班人力最薄的时段。高级工程师不可能天天值夜班，而告警处置偏偏最吃经验。 这三条决定了：规则引擎能解决一部分问题，但解决不干净。这也是AI被寄予厚望的原因——不是替代人看告警，而是把“归并、定根因、出处置建议”这条链路自动化。 ## 二、自智网络：TM Forum的六级标尺 聊AI运维绕不开一个行业框架。TM Forum（全球电信管理论坛）在其自治网络（Autonomous Networks）项目里，把网络自治水平划分为L0到L5六个等级，这已经成为全球运营商评估AI运维进展的通用标尺（项目主页见文末参考来源[1]）。这一框架的推广与中国移动密切相关——据公开资料，中国移动2019年在业界率先提出“自智网络”构想，并推动分级理念进入TM Forum等行业组织，其公开路线图设定了“2023年整体达到L3、2025年在重点场景迈向L4”的目标。 六个等级的准确含义，工程师容易记混，列成表更清楚： | 等级 | 名称 | 核心特征 | 人的角色 | |------|------|----------|----------| | L0 | 人工运行 | 无自动化，纯手工操作 | 全部决策与执行 | | L1 | 工具辅助 | 单点脚本与工具，碎片化 | 人主导，工具辅助 | | L2 | 部分自治 | 具备感知与执行能力，闭环规则预设 | 人做判断，系统执行 | | L3 | 有条件自治 | 特定专业场景内AI闭环，关键决策人工确认 | 人监督，场景内自治 | | L4 | 高度自治 | 跨场景跨专业闭环，人只定规则与例外 | 人定期审核例外 | | L5 | 完全自治 | 全域自演进，无需人工干预 | 行业普遍视为愿景 | 两个容易被误读的点：一是L3的“自治”是有边界的——它发生在单个专业域（比如仅传输、仅无线）的单个场景（比如仅告警根因）内，出了场景就要交还人工；二是L4的关键不是“更聪明”，而是**跨域协同**——无线、传输、核心的AI各管一段不算L4，能把跨域告警串成一条因果链才是。目前全球头部运营商的公开口径普遍处于“整体L2.7到L3、重点场景冲击L4”的阶段（据TM Forum及各运营商公开发布的表述），L5在可预见的规划期内没有任何一家给出时间表。 ## 三、告警瘦身流水线：从四千条到一条根因 回到那四千条告警。一套达到L3水平的AI告警治理系统，处理流程大致是一条流水线。标准允许多种实现，各厂商产品形态有差异，但功能分段高度趋同，华为iMaster NCE、诺基亚AVA、爱立信Service Automator、中兴uSmartNet等公开材料描述的架构都可以映射到这条流水线上（具体能力口径以各厂家官方文档为准）： ```mermaid flowchart TD A[网元与链路] --> B[告警采集网关] B --> C[标准化与去重] C --> D[关联归并引擎] D --> E[告警风暴识别] E --> F[根因推理AI] F --> G{置信度判定} G -->|高置信| H[自动处置动作] G -->|中置信| I[生成建议工单] G -->|低置信| J[人工值班席] H --> K[处置结果校验] I --> K K -->|验证通过| L[闭环归档] K -->|验证失败| J L --> M[知识库回填] M --> D ``` 逐段拆开看，每一段都有讲究： **标准化与去重。** 把不同网管、不同厂商网元的告警统一成标准模型（TM Forum的告警信息模型是常见基础）。这一段是最枯燥也最决定成败的——某省项目上线三个月效果不佳，最后排查发现是同一板卡在两套网管里的序列号写法不同，导致去重失效。AI救不了脏数据。 **关联归并。** 基于拓扑和时间窗，把衍生告警挂到疑似根因下面。传输网里这部分相对成熟，因为光路拓扑是静态可知的；无线网难得多，一个小区退服可能是馈线、电源、传输、板卡四类原因，拓扑线索弱。 **根因推理。** 这是AI真正的用武之地。主流做法是图推理+历史案例匹配：把告警、拓扑、工单历史建成图谱，用图算法定位因果链源头，再用历史处置记录校准置信度。华为、诺基亚等厂商在公开材料中普遍以“告警压缩率90%以上”作为这类产品的宣传口径——这是厂商营销数据，实际效果高度依赖现网数据质量，采购时务必要求POC实测而非只看PPT。 **置信度门限与闭环。** 这是L3与L2的分水岭：L2系统做完归并就停，人来做判断；L3系统对高置信事件直接触发预设动作（如端口倒换、板卡复位），中置信生成建议工单，低置信转人工。每次闭环的结果回填知识库，形成越用越准的正循环。 ## 四、大模型进NOC：能读懂3GPP规范的AI 流水线解决的是“结构化告警”，但运维工作里还有大量非结构化知识：3GPP规范、设备手册、历史故障复盘、老师傅脑子里的经验。2023年以来，这一块被大语言模型（LLM）补上了。 一个标志性的学术工作是TelecomGPT。据arXiv:2307.09548论文（中国移动等机构研究者，2023年发布，见参考来源[2]），研究者以通用大模型为底座，用3GPP规范、电信教材、行业问答等语料做增量预训练与指令微调，构建了面向电信领域的模型框架和基准测试。论文报告其在电信专业问答、规范条文理解等任务上显著优于同规模的通用大模型——这一结论来自论文作者的自行评测，但它验证了一条路径：通用大模型不懂的“NAS层”、“邻区漏配”、“ANR”，垂直领域模型是可以补课的。 国内运营商的落地同样在推进。据中国移动公开发布，其“九天”人工智能大模型体系已把网络运维列为重点应用方向，典型场景包括智能告警分析、故障处置建议、运维知识问答等。国外方面，各大设备商也纷纷把LLM能力嵌入运维产品线，形态大多是“值班Copilot”：工程师用自然语言提问，系统基于规范、拓扑和历史工单生成处置方案与操作步骤，人确认后执行。 大模型在NOC里真正干得好的三件事，从各厂商公开演示中反复出现： 1. **告警解释**——把一条晦涩的设备告警翻译成人话，关联规范条文解释其含义与风险等级； 2. **处置预案生成**——结合当前拓扑和历史类似故障，给出带步骤、带回退方案的处置单； 3. **值班报告自动化**——夜班结束自动汇总告警趋势、处置结果、遗留问题，生成交接班文档。 同样要泼一盆冷水：大模型不适合直接做闭环执行。它擅长的语言推理恰恰伴随幻觉风险，让LLM直接下发网元命令，等于让一个偶尔会一本正经胡说的人握住割接终端。目前行业的共识做法是LLM只出建议，执行由确定性脚本或人完成——这正是第五节方案对比里L3和L4的边界设计逻辑。 ## 五、人工值守与L2/L3/L4自治方案对比 把三种典型值班模式放到一张表里，差异一目了然（基于TM Forum分级框架的工程化解读）： | 维度 | 人工值守（L0-L1） | 场景自治（L3） | 跨域自治（L4） | |------|-------------------|----------------|----------------| | 告警初筛 | 人肉刷屏 | 系统归并压缩90%以上（厂商口径） | 跨域关联后按业务影响排序 | | 根因定位 | 老师傅经验+逐段排查 | 单域内AI图谱推理，分钟级 | 跨无线/传输/核心端到端推理 | | 处置执行 | 人工登录网元操作 | 高置信场景自动执行+人工确认 | 例外上报，常规动作全自动 | | 夜班人力 | 每席数人轮值 | 值班人力减半常见（各局数据差异大） | 向“日班审核制”演进 | | 主要风险 | 依赖个人经验，人走经验走 | 误判闭环引发次生故障 | 规则错误被批量放大 | | 适用阶段 | 小规模网络、过渡期 | 单专业域，当前主流商用形态 | 头部运营商试点中 | 表里“主要风险”一行值得多说一句。L3的误判闭环是真实发生过的事故类型：AI把一次短暂的瞬时抖动判定为“可自愈事件”自动复位，恰好赶上设备已知软件缺陷，复位触发级联故障。这就是为什么成熟的落地路径一定是灰度的——先只开放“读”类动作（查询、定位、出建议），再开放低风险“写”类动作（日志采集、性能复位），高风险动作（倒换、复位、割接）永远留人工确认。 ## 六、落地三道坎：数据、信任与考核反噬 跟一线做过的工程师聊，AI运维项目“上线容易、用好极难”，坎集中在三处： **第一道坎：数据质量。** 前面提过CMDB脏数据的坑，再补一个更普遍的——告警文本不规范。同一类故障，不同批次设备上送的告警描述措辞各异，正则和模板难以穷举。这决定了告警治理项目60%以上的工作量其实在数据治理而非算法，预算和工期要按这个比例排。 **第二道坎：信任建立。** 值班工程师凭什么信AI说的根因？实践中的有效做法是“可解释性展示”：系统给出根因结论时，同时呈现因果链证据（哪几条告警、哪段拓扑、哪几个历史案例支撑了这个判断）。工程师可以像审同事的判断一样审它。凡是只给结论不给证据的系统，最终都会被一线绕开——这是无数AIOps项目烂尾的第一原因。 **第三道坎：考核反噬。** 告警压缩率是个危险的KPI。只考核压缩率，系统会学会把难归类的告警一压了之——压缩率很漂亮，漏掉的真故障也很致命。成熟的考核必须是成对指标：压缩率之外必须配漏报率（被压缩告警中事后被证实与故障相关的占比），有的局还加了根因命中率（TOP1根因命中真实原因的比例）。单一KPI驱动AI运维，跑偏只是时间问题。 ## 七、工程师怎么办：从看告警到养模型 岗位冲击是这个话题绕不开的一层。直说结论：告警压缩消灭的是“人肉刷屏”这类工作，但网络规模在涨、网元复杂度在涨，运维总盘子并没有缩小，变的是岗位技能结构。 正在出现的几类新角色：**预案工程师**——写和维护AI可执行的处置预案库，要求既懂网络又懂自动化编排；**数据治理专员**——维护CMDB和告警模型质量，从前没人愿干的脏活正在变成项目成败的手；**AI稽核岗**——抽查AI闭环案例、标注错判、校准置信度门限，相当于给AI配质检员。 技能迁移的路径也比较清晰：信令分析和故障定位的底层功力不会过时——AI给出根因建议，判断它对不对，依然需要懂协议的人。变化在于工具面：多学一门SQL和Python数据处理的性价比，已经明显高于多背一套网管快捷键。用一句一线的话概括：过去拼谁看告警快，以后拼谁把AI教得好。 ## 八、结语 回到凌晨三点四十七分那条被挖断的光缆。在L2的网络里，它意味着值班工程师的通宵；在L3的网络里，它是一条已经自动定位根因、预案待确认的工单；在L4的网络里，它可能只是第二天早上日报里的一行字——“夜间汇聚环光缆中断，系统已自动倒换，业务无感知，请安排抢修”。 行业今天真实的坐标是：L3在单域场景批量落地，L4在头部试点，大模型负责补上“读懂规范、说清人话”的最后一环。对工程师而言，这不是“AI抢不抢饭碗”的问题，而是“下一个夜班，你想刷四千条告警，还是审一条AI给出的因果链”。答案不言自明。 --- ## 参考来源 1. [TM Forum Autonomous Networks 自治网络项目](https://www.tmforum.org/autonomous-networks) — L0-L5自治等级框架的官方出处，TM Forum持续发布自治网络年度进展报告，是本文分级体系的权威依据。 2. [TelecomGPT: A Framework and Benchmark to Build Telecom-Space Large Language Models (arXiv:2307.09548)](https://arxiv.org/abs/2307.09548) — 面向电信领域的垂直大模型框架与基准测试论文，验证了通用大模型在电信语料上增量训练的技术路径。 3. [Autonomous network - Wikipedia](https://en.wikipedia.org/wiki/Autonomous_network) — 自治网络概念与TM Forum分级体系的背景词条，可作为概念溯源的辅助阅读。 （注：文中厂商产品能力数字多为厂商公开宣传口径，实际效果因现网数据质量差异较大；中国移动自智网络路线图与“九天”大模型信息来自其公开发布，具体进展以其官方口径为准。） --- > 本文由「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 等场景全覆盖。