贝尔加拿大（Bell Canada）是加拿大规模最大的通信运营商，隶属 BCE 集团，1880 年创立于蒙特利尔，业务覆盖宽带、无线、电视、媒体和企业通信。但"最大"也意味着"最复杂"——一张全国性的多域网络（无线接入、传输、核心、IP骨干、家庭宽带）每天产生的告警量是海量的，传统网管体系在 2024–2025 年的数据洪流面前已经力不从心。
问题的本质可以用三个痛点概括：
第一，被动救火（reactive troubleshooting）。 传统网管（NMS/EMS）依赖人工设定的阈值和规则触发告警，故障往往是"用户先投诉、运维才发现"。贝尔在新闻稿中直言：遗留系统"依赖被动方式和人工流程，导致效率低下、业务中断和客户体验受损"。
第二，告警风暴与人工关联。 一根主干光纤抖动，可能在接入、传输、核心三层同时炸出上百条告警，工程师要在多个厂商网管（爱立信、诺基亚、思科、华为等）之间来回切换，手工拼凑根因，平均定位时间长、且高度依赖老师傅的经验。
第三，缺乏"以客户体验为中心"的优先级。 一个偏远基站的小故障和一个体育场馆高话务站点的小故障，在传统告警系统里严重程度相同，但实际影响天差地别——没有实时把网络事件与单个用户/业务的体验质量（QoE）挂钩，优先级排序是失真的。
这三点叠加，直接拖累了两个核心指标：平均修复时间（MTTR）居高不下，客户主动报障率（customer-reported issues）偏高。对一家把"可靠性"作为品牌承诺的运营商来说，这是必须用 AI 解决的结构性问题。2025 年 2 月 26 日，贝尔在 MWC（世界移动大会）前夕正式发布基于谷歌云（Google Cloud）的网络 AIOps 解决方案，并宣布已在现网成功部署、初见成效。
贝尔这套 AIOps 不是一个单一产品，而是架在谷歌云 2025 年 6 月正式对外发布的自治网络运营框架（Autonomous Network Operations framework）之上。理解这个框架，是理解贝尔案例的关键。
这套框架的技术栈，与传统厂商网管有本质区别，其灵魂是Cloud Spanner / Spanner Graph。谷歌云在官方博客里把它描述为：一个全球分布式数据库，扮演整张国家网络的实时虚拟副本（digital twin，数字孪生），并以时序图（temporal graph）的形式存储。
通俗讲：它不再是把网元数据一行行塞进关系型表，而是把基站、链路、端口、用户、业务、工单统统建为"节点"，把它们之间的拓扑、依赖、承载关系建为"边"，并打上时间戳。这样，当某条链路抖动时，系统可以沿着图上的边，毫秒级算出"这次抖动影响了哪些基站、哪些小区、多少在网用户、哪些高价值专线客户"。
贝尔的 AIOps 解决方案由以下谷歌云组件拼装而成（来自官方新闻稿与框架博客）：
下面这张图刻画了从"数据采集"到"故障自愈闭环"的完整工作流：
flowchart TD
subgraph 数据采集[数据采集层 Observe]
A1[网元遥测/PM指标]:::src
A2[告警/事件流]:::src
A3[工单/变更日志]:::src
A4[客户体验QoE数据]:::src
end
subgraph 数据底座[数据底座层]
B1[Pub/Sub 实时事件总线]
B2[BigQuery 湖仓+历史趋势]
B3["Spanner Graph 全国网数字孪生<br/>(时序图)"]
end
subgraph AI推理[AI推理层 Reason]
C1["图神经网络GNN<br/>拓扑级异常/影响分析"]
C2["Gemini多模态大模型<br/>(Vertex AI)<br/>根因推断/历史检索/厂商文档"]
C3[客户影响评分]
end
subgraph 闭环动作[闭环动作层 Act]
D1[自动编排/工单]
D2[配置下发/重启/隔离]
D3[人工确认高危动作]
end
A1 & A2 & A3 & A4 --> B1
B1 --> B2
B1 --> B3
B2 -.关联.-> B3
B3 --> C1
B2 --> C2
C1 --> C3
C2 --> C3
C3 --> D1 --> D2
D2 -->|高危| D3
D2 -.反馈学习.-> B2
classDef src fill:#e8f0fe,stroke:#1a73e8;
框架遵循电信自动化经典的 Observe → Reason → Act 范式：
贝尔网络高级副总裁 Mark McDonald 评价："借助谷歌云的 AI，我们在识别和解决网络/服务异常的准确度和速度上都有了显著提升，加速了迈向自治网络的进程。"
值得强调的是，这不是贝尔和谷歌两家"裸奔"。谷歌云框架明确列出了 ISV 与 GSI 生态：Amdocs Network AIOps 解决方案（含多个网络智能体）跑在谷歌云 AI 基础设施上，提供预测分析、自动化工作流和闭环运营能力；Accenture（埃森哲）和 Capgemini（凯捷） 作为 GSI 充当执行手臂，负责把这套能力在运营商组织内部落地并规模化推广。这意味着贝尔拿到的不是一个 PoC，而是一条"云平台 + ISV 产品 + GSI 实施"的成熟交付链。
贝尔在新闻稿中给出了上量后的实际成绩（截至 2025 年 2 月），谷歌云框架博客则补充了 MTTR 这一最具代表性的指标。汇总如下：
| 指标维度 | 改造前（传统运维） | 改造后（AI Ops） | 变化幅度 | 数据来源 |
|---|---|---|---|---|
| 平均修复时间 MTTR | 基线（高，依赖人工关联） | 显著下降 | 降低 25% | 谷歌云框架官方博客 |
| 客户主动报障率 | 基线 | 大幅下降 | 降低 25% | 贝尔官方新闻稿 |
| 软件交付生产力 | 基线 | 明显提升 | 提升 75% | 贝尔官方新闻稿 |
| 数据可用性与及时性 SLA 达成率 | — | 稳定 | 99.8% | 贝尔官方新闻稿 |
四个数字背后是同一条逻辑链：
贝尔这套方案里，最值得通信工程师深挖的是 Spanner Graph。很多 AIOps 项目失败，不是模型不够强，而是"数据没准备好"——告警、拓扑、客户、工单散落在几十个系统里，模型拿到的是割裂的、滞后的快照，自然无法准确推理。
Spanner Graph 解决的就是这个"数据底座"问题：
可以这样说：Gemini 负责"说人话"的根因解释和方案生成，GNN 负责"算图"的影响传播，而 Spanner Graph 是两者共同的高质量数据底座。 三者缺一不可，这也解释了为什么贝尔不单买一个大模型就完事——没有图数字孪生，大模型在复杂网络故障面前一样会"幻觉"。
贝尔案例对国内三大运营商推进"自智网络 / L4 自治"有三个直接启示：
启示一：数据底座先行，再谈大模型。 国内不少运营商在做"网络大模型"，但如果告警、拓扑、客户、工单的数据没有先打通成一张统一的图，大模型再强也只是"无米之炊"。贝尔用图数据库做数字孪生、把数据治理做在前面，是值得借鉴的工程顺序。
启示二：用客户影响来给故障排队，而不是用设备等级。 贝尔的"高话务站点优先"逻辑，本质上是用 QoE 重塑了运维的优先级体系。国内运营商的派单系统仍多以设备/告警等级为准，引入客户影响评分能显著提升资源投放效率。
启示三：开放底座 + ISV + GSI 的交付链更抗锁定。 贝尔没有把 AIOps 全押在某一设备厂商上，而是用云厂商开放底座 + Amdocs 产品 + 埃森哲/凯捷实施。国内运营商在做自智网络时，"解耦"和"自主可控"同样是核心诉求，可参考这种分层解耦的架构。
贝尔加拿大用一套基于谷歌云自治网络运营框架的 AIOps 方案，把网络故障的平均修复时间（MTTR）压降 25%、客户主动报障减少 25%、软件交付生产力提升 75%、SLA 达成率稳定在 99.8%。其技术内核是"Spanner Graph 图数字孪生 + GNN 图学习 + Gemini 多模态推理"的"三件套"，配合 Amdocs 与埃森哲/凯捷的交付生态，完成了从被动救火到主动自愈的范式跃迁。
对于通信行业而言，这个案例的真正价值不在于某一项数字，而在于它验证了一条清晰的技术路径：先把网络建成一张可查询、可回溯的实时图，再让大模型和图神经网络在这张图上做推理与自愈。 这条路径，比单纯堆叠大模型更扎实，也更可能真正触达 TM Forum 定义的 L4 自治网络。
本文由「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 等场景全覆盖。