首页 › tech › AI修网:故障自愈商用实录

概述

故障自愈(Self-Healing)喊了十几年,到底落地了没有?本文回答一个问题:当网络半夜告警时,AI 究竟能不能代替工程师“下刀”。文章以 3GPP 自愈标准和 TM Forum 自智网络分级为坐标,拆解自愈闭环的六个环节,对照三个真实样本——企业网的 Juniper Mist/Marvis、大网的 Vodafone×Google Cloud、学术界验证的 TelecomGPT,并给出一张“哪类故障适合自动修、哪类必须等人拍板”的分级表,以及运维团队的五步落地路线图。

目录


一、自愈不是新词:50 毫秒倒换才是祖师爷

先泼一盆冷水:自愈从来不是 AI 时代的发明。

传输网的保护倒换,几十年前就把“自愈”做成了硬指标——SDH 的复用段保护、光传送网的环网保护,标准要求倒换时间 50 毫秒以内。光缆被挖断的瞬间,业务在用户毫无感知的情况下已经绕道走了。这算不算自愈?当然算,而且是最高级的自愈:确定性预案、毫秒级执行、零人工介入。

核心网同理。MME Pool、AMF Pool 这种资源池机制,本质上就是核心网的自愈设计:一个 MME 宕机,附着在该池内其他节点上的用户通过 NAS 重分配机制被重新分配到存活节点,用户只觉得稍微慢了一下,绝不会收到“网络故障”的提示。IMS 双中心容灾也是同一个思路。

无线侧更不必说。3GPP 从 R8 开始就把 SON(自组织网络)标准化成三大支柱:自配置、自优化、自愈合(Self-Healing)。新基站上电自动开通、邻区自动优化、小区退服自动补偿——这些在 4G 时代就已经是规模商用的功能。

所以今天的“AI 自愈”,牛不是吹在“自愈”两个字上,而是吹在它能覆盖设计时没想到的故障上。50 毫秒倒换再快,它只能处理“链路断了”这一种病;而真实网络每天夜间告警里,大量是长尾故障:license 过期、磁盘写满、信令风暴导致的 CPU 飙高、配置下发冲突、虚拟机僵死、证书到期……这些病没有一个统一的“保护倒换”能兜住,过去只能靠告警把人从床上薅起来,靠老工程师的脑子定位,靠一双手敲命令修复。

AI 自愈要攻下的,就是这块长尾阵地。这是全文所有讨论的前提。

二、今天谈的“AI 自愈”,闭环到底长什么样

TM Forum 的自智网络(Autonomous Networks)分级框架把自动化分成 L0 到 L5 六级(官方页面见文末参考来源[2]):L3 是“条件自愈”——系统给出处置建议、人按确认键;L4 要求在大多数场景实现闭环自愈;L5 才是全场景无人化。这个框架本身不复杂,复杂的是闭环的每一环都有坑。

一个真正能落地的自愈闭环,至少包含六个环节:

  1. 发现:从指标异常里提前察觉(而不仅仅是等告警触发);
  2. 收敛:把一场软硬件抖动产生的成百上千条告警,压缩成一条“根因告警”;
  3. 定位:结合拓扑、工参、历史工单,推断故障根因;
  4. 决策:查预案库,判断“能不能自动修”——这是 L3 和 L4 的分水岭;
  5. 执行:调用 runbook 自动执行预案;
  6. 验证与回滚:执行后做健康检查,失败则自动回滚并转人工。

用一张图把闭环画出来:

flowchart TD
  A["指标与告警输入"] --> B["异常检测"]
  B --> C["告警收敛与关联"]
  C --> D["根因定位"]
  D --> E{"预案库是否命中"}
  E -->|低风险可逆| F["自动执行预案"]
  E -->|高风险不确定| G["生成处置建议"]
  G --> H["人工确认执行"]
  F --> I["健康检查验证"]
  H --> I
  I -->|成功| J["关闭工单并归档"]
  I -->|失败| K["自动回滚"]
  K --> L["转人工处置"]
  L --> M["复盘沉淀新预案"]
  M --> E
  J --> M

行业现状一句话概括:检测端已经很强,执行端是短板。异常检测和告警压缩这些“看得见病”的环节,各家 AIOps 平台磨了五六年,误报率已经压得不错;但“下不了刀”——真正的自动执行环节,绝大多数网络仍停留在 L3 的人机协同。原因不是算法不行,而是没人敢为 AI 的自动动作兜责。这个痛点怎么解,第八节细说。

三、标准已经铺路:从 SON 到 TS 32.541

别以为自愈是厂商营销词,标准组织早有布局,而且给了明确的技术边界。

3GPP TS 32.541(自愈合管理 OAM,规范库见参考来源[1])在 4G 时代就定义了两类经典自愈用例:小区退服管理(Cell Outage Management,检测到小区下线后自动做邻区补偿或重启恢复)和单板更换自愈(Board Swap,换板后自动恢复配置数据)。注意它的设计哲学:每类用例都有明确的触发条件、有限的动作集合、明确的验证手段——这就是“可自愈”的模板。

5G 时代,管理面的积木更全了:TS 23.288 定义的 NWDAF(网络数据分析功能)让核心网第一次有了标准化的“网元级分析大脑”,可以向各 NF 提供切片负载、终端行为等分析结果;TS 28.312 定义了意图驱动管理(Intent-driven Management),让运维语言“保证切片速率不低于 XX”可以翻译成网络配置。O-RAN 联盟的 RIC 架构则把闭环下沉到无线侧:非实时 RIC 上的 rApp 跑分钟级优化,近实时 RIC 上的 xApp 处理 10 毫秒到 1 秒级的快速调整,两者通过 A1 接口下发策略。开源侧,Linux 基金会的 ONAP 从第一天就把“闭环自动化”(Closed Loop)作为核心架构,DCAE 负责采集分析,Policy 引擎负责决策执行。

需要说明的是,标准允许多种实现方式,具体行为和默认策略以各厂家官方文档为准。但标准的信号很清楚:自愈不是一个功能,而是一套“触发-决策-执行-验证”的架构规范。

四、实录一:企业网先跑通——Juniper Mist 的 Marvis

大网还在“建议+确认”阶段打转,企业网却已经把自动修复做成了卖点。这个反差本身就是最有价值的行业观察。

Juniper 收购 Mist Systems 后推出的 Mist AI 平台,官方长期宣传的口径是:借助 AI 排障,网络工单最多可减少 90%(Juniper 官方产品页口径,见参考来源[5],属厂商营销数据,非第三方实测)。它最值得拆解的不是口号,而是两块具体设计:

第一块是 SLE(服务等级期望)分类器。 当用户抱怨“连不上 WiFi”,Mist 不是把一堆告警甩给管理员,而是把“连接失败”这个模糊症状拆解成几十个失败类别——DHCP 失败、认证失败、漫游乒乓、信噪比过低、AP 负载过高……每个类别挂一个机器学习分类器自动逐一定位。本质上,这是把老工程师脑中的排障决策树,固化成了可执行的代码。

第二块是 Marvis Actions——真的会动手。 Marvis 这个对话式虚拟网络助手不只是回答问题,它的 Actions 模块能对特定故障直接执行修复动作:终端 stuck(卡死在错误连接状态)时自动触发重连、DHCP 异常时自动处理,修复结果还会回报给管理员确认。

为什么企业网敢做、大网不敢做?三个条件使然:网络规模小,爆炸半径有限,修错了一栋楼的 WiFi 受影响;动作可逆,终端重连、AP 重启,失败了重来就行,不存在“不可恢复”的操作;场景可枚举,企业接入网的故障模式就那么多,预案库写得完。而一张几百万网元的公网,一个自动动作失误可能波及千万用户,谁来兜责?

所以别笑话企业网案例“小儿科”——它恰恰证明了自愈在技术上完全可行,剩下的问题全是工程治理问题。

五、实录二:大网在路上——Vodafone 牵手 Google Cloud

运营商大网的自愈路径,和想象中不太一样:第一课不是“自动修”,而是“提前修”。

2023 年初,Vodafone 与 Google Cloud 扩大合作(细节以双方新闻稿为准,新闻室入口见参考来源[4]),方向有两个:一是把网络工作负载和分析放在 Google Cloud 上,用云上 AI 对网络数据做预测性维护——目标是在故障影响用户之前就发现并消除它,把“深夜被动抢修”变成“白天计划内维护”;二是弹性网络切片(Elastic Network Slice),让切片资源可以按需伸缩。Vodafone 公开披露的动机很务实:减少现场出勤(truck roll)、降低用户感知到的故障率。截至成稿,双方没有公开过独立第三方验证的规模化“自愈率”数据,这一点如实说明。

这条路径的聪明之处在于风险递进:预测性维护的 AI 只做两件事——发现问题、建议动作,执行者仍然是熟悉的工单流程和人工窗口。它不碰权限红线,却实打实改变了 MTTR 的结构:把故障消灭在用户投诉之前,比修得快更进一步。对大网而言,“自动修”是最后一公里,但“自动发现+自动定位+自动派单”是必须先走完的九百米。

国内运营商的路径大同小异。据公开报道,中国移动九天大模型、中国电信星辰大模型、中国联通元景大模型都已进入网络运维域试点,典型落地形态是告警智能解读、根因辅助定位、故障报告自动生成——同样是先“参谋”后“操盘手”的稳妥打法。

六、实录三:大模型的入场——TelecomGPT 与运维知识层

前两个案例讲的是“AI 看网”,大模型补上的是“AI 懂行”。这里有一个扎实的学术锚点。

2024 年,墨尔本大学与华为的研究团队发布了 TelecomGPT(arXiv:2404.15090,见参考来源[3])。这篇论文做的事概括起来是:把 3GPP 规范等电信专业语料喂给大模型做继续预训练和微调,再配上电信领域指令数据,让模型掌握“通信行话”。评测结果显示,TelecomGPT 在电信领域的问答、术语翻译等任务上显著优于同尺寸的通用大模型。它的价值不在刷分,而在验证了一条路线:通用大模型 + 电信语料 = 懂 3GPP 的运维助手,这条路线此后被业界广泛复制。

这里必须把“论文讲了什么”和“我的判断”分清楚:论文验证的是知识问答与文本任务,没有验证“让大模型直接操作网元”。而我对大模型在自愈闭环中位置的判断是——它该当参谋,不该当操盘手。理由有三:

换句话说,大模型把自愈闭环里最贵的资源——资深工程师的判断力——从每次故障中都“蒸馏”了一份进预案库。这是它对自愈真正的贡献。

七、哪些故障适合自愈:一张分级表

写了十几年故障工单,我的经验是:能不能自动修,不看故障多复杂,看三个指标——爆炸半径(修错了波及多大)、可逆性(修错了能不能退回来)、预案确定度(处置步骤是否唯一且经过验证)。按这三把尺子,把常见故障分四级:

故障类别 典型案例 建议自动化级别 理由
链路/通道类 光衰缓慢劣化、端口误码率抬升 全自动:切保护路由,事后留痕 确定性预案,秒级可逆,爆炸半径可控
资源耗尽类 license 过期、磁盘写满、CPU 飙高 全自动:扩容/清理+工单留痕 高发、预案成熟、动作标准化
单网元异常类 进程僵死、虚拟机漂移、单板告警 半自动:AI 重启建议+人确认 需判断业务窗口,重启有时掩盖真问题
配置差错类 参数改错、路由策略冲突 仅建议:AI 生成分析+人工执行 影响面难自动评估,回滚成本高
未知/跨域类 疑似软件缺陷、跨网联动故障 仅诊断:自动出分析报告 预案不存在,自动执行等于赌博

这张表可以直接当验收清单用:宣称支持自愈的平台,拿每一行去问“这类故障你的系统会做什么”,答不出动作细节的都是 PPT 自愈。

八、三个真坎:权限、回滚、信任

第一坎:权限。 自愈系统需要网元的写权限,这是所有问题的死结。我的建议是三条铁律:自愈账号用最小权限模型,只能执行预案库白名单里的动作模板,禁止自由命令;每个自动动作带数字留痕(谁授权的预案、什么触发的、执行了什么命令);高危预案设双人复核,哪怕是数字化的“双人”。行业里不止一次的教训是:自动化系统自己的缺陷,反而成为事故放大器——自动化的错误传播速度比人快一万倍。

第二坎:回滚。 没有回滚预案的自动动作等于裸奔。执行前必须满足三个条件:变更前配置已备份且恢复路径验证过;该动作有明确的“健康检查失败”判定标准;回滚动作本身也被测试过。我的经验规则:没被回滚演练过的预案,不许进全自动清单。

第三坎:信任,要双向校准。 老运维不信 AI,是因为早期误报太多、狼来了喊多了;管理层信过头,一刀切关闭人工通道,则更危险。正确姿势是设立并行运行期:AI 给建议、人来执行,同时记录两本账——AI 建议被采纳率、AI 与人工处置结果差异率。这里给出我个人经验建议的放行门槛(注意:这是经验值,不是任何标准):某一类故障的 AI 建议准确率连续一个季度不低于 95%、误执行带来的二次故障率低于千分之五,才允许该类故障进入全自动清单,并且每季度审计一次自愈动作日志。信任不是喊出来的,是用台账一笔一笔挣出来的。

九、给运维团队的五步路线图

结合上面所有讨论,给正在推进 AIOps 的团队一条可执行的路径:

第一步:runbook 化——把老师傅脑子里的排障决策树写成文档和脚本。
        没有预案库,AI 只是加速器, accelerates 不了不存在的东西。
第二步:只诊断、不开方——上异常检测+根因定位+自动派单,
        先把 MTTR 里的"发现+定位"时间砍掉。
第三步:挑 10 类高发低风险故障(对照第七节表格)做半自动闭环:
        AI 出预案,人按按钮,全程统计准确率。
第四步:灰度放开全自动——先 1% 的网元、先维护窗口内执行,
        每季度审计自愈日志,逐步扩大清单。
第五步:建知识飞轮——每次人工处置的复盘,强制回流成新预案,
        让系统"越用越会修"。

第五步最容易被忽略,却决定成败。自愈系统的上限不在算法,在于预案库的覆盖度;预案库的成长速度,取决于人工处置经验能不能低成本沉淀回来。

十、结语:最好的自愈,是没人知道发生过故障

回头看这三十年的网络演进,会发现一条清晰的线:50 毫秒保护倒换解决了链路断,核心网 Pool 解决了节点宕,SON 解决了小区退服——每一代自愈技术,都是把一类故障从“人的领域”搬进“机器的领域”。今天的 AI 自愈,本质上是同一件事的延续:把长尾故障从手工业抢修,变成工业化处置。

短板从来不在算法。异常检测、根因定位这些年的进步有目共睹,大模型又补上了知识层的缺口。真正的瓶颈是预案库的贫瘠、权限治理的缺位、回滚机制的侥幸心理。2026 年回头看,自愈的竞争已经不在“谁的 AI 更聪明”,而在“谁的预案库更厚、谁的治理更硬”。

对一线工程师,我最后说一句宽心话:自愈不会抢走你的饭碗,它抢走的是凌晨三点的告警电话。而把故障经验写成预案、给 AI 立规矩、替自动动作把最后一道关——这些活,反而更值钱了。传输网用五十年证明了这一点:最好的自愈,是用户根本不知道网络生过病。剩下的事,轮到 AI 接着干了。


参考来源

  1. 3GPP TS 32.541 规范库(Self-healing management, OAM) — 3GPP 自愈管理标准,定义小区退服管理、单板更换自愈等经典自愈用例
  2. TM Forum Autonomous Networks — TM Forum 自智网络 L0-L5 分级框架官方页面,业界自动化分级的事实坐标
  3. TelecomGPT: A Framework to Build Telecom-Space Large Language Models (arXiv:2404.15090) — 墨尔本大学与华为团队的电信域大模型论文,验证 3GPP 语料微调路线
  4. Vodafone Newsroom(2023 年初 Vodafone×Google Cloud 合作公告入口) — AI 预测性维护与弹性切片合作,细节以双方新闻稿原文为准
  5. Juniper Mist AI 产品页 — Marvis 助手与自动修复功能官方说明,“工单最多减 90%”为厂商官方口径

本文由「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 等场景全覆盖。

51学通信知识星球海报-扫码加入