# 贝尔加拿大借谷歌云自治网络框架，把故障平均修复时间砍掉四分之一
## 一、案例背景：北美最大运营商为什么必须上 AIOps
贝尔加拿大（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）**之上。理解这个框架，是理解贝尔案例的关键。
### 2.1 核心架构：用"图数据库数字孪生"重建整张全国网
这套框架的技术栈，与传统厂商网管有本质区别，其灵魂是**Cloud Spanner / Spanner Graph**。谷歌云在官方博客里把它描述为：一个全球分布式数据库，扮演整张国家网络的**实时虚拟副本（digital twin，数字孪生）**，并以**时序图（temporal graph）**的形式存储。
通俗讲：它不再是把网元数据一行行塞进关系型表，而是把基站、链路、端口、用户、业务、工单统统建为"节点"，把它们之间的拓扑、依赖、承载关系建为"边"，并打上时间戳。这样，当某条链路抖动时，系统可以沿着图上的边，毫秒级算出"这次抖动影响了哪些基站、哪些小区、多少在网用户、哪些高价值专线客户"。
### 2.2 完整数据流水线
贝尔的 AIOps 解决方案由以下谷歌云组件拼装而成（来自官方新闻稿与框架博客）：
- **Pub/Sub**：负责海量遥测数据、告警、日志、性能指标（PM）的实时接入与缓冲，做事件流的解耦。
- **BigQuery + BigQuery ML**：数据湖仓，存放历史趋势数据；工程师可以直接用 SQL 调用 BigQuery ML，甚至用 SQL 唤起 Vertex AI 上的 Gemini 能力，门槛极低。
- **Cloud Spanner / Spanner Graph**：整张全国网的图数字孪生，支撑实时拓扑查询与客户影响计算。
- **Gemini 多模态大模型（经 Vertex AI）+ 专门的图神经网络（GNN）模型**：负责"推理"环节——理解网络复杂且不断演进的连接关系。
- **GKE（Google Kubernetes Engine）**：承载整个 AIOps 平台的容器化运行。
下面这张图刻画了从"数据采集"到"故障自愈闭环"的完整工作流：
```mermaid
flowchart TD
subgraph 数据采集[数据采集层 Observe]
A1[网元遥测/PM指标]:::src
A2[告警/事件流]:::src
A3[工单/变更日志]:::src
A4[客户体验QoE数据]:::src
end
subgraph 数据底座[数据底座层]
B1[Pub/Sub 实时事件总线]
B2[BigQuery 湖仓+历史趋势]
B3["Spanner Graph 全国网数字孪生
(时序图)"]
end
subgraph AI推理[AI推理层 Reason]
C1["图神经网络GNN
拓扑级异常/影响分析"]
C2["Gemini多模态大模型
(Vertex AI)
根因推断/历史检索/厂商文档"]
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;
```
### 2.3 "观察—推理—行动"三段式与自愈闭环
框架遵循电信自动化经典的 **Observe → Reason → Act** 范式：
1. **观察（Observe）**：Pub/Sub 持续把全网的 PM、告警、变更、QoE 喂入 Spanner Graph，维持数字孪生的"鲜活度"。BigQuery 同步沉淀历史，做趋势对比。
2. **推理（Reason）**：这是区别于传统网管的核心。当异常出现，**GNN 沿着图结构做影响传播分析**（一条传输链路故障如何在图上"涟漪式"扩散到下游小区）；同时 **Gemini 多模态模型做三件事**——快速事件分析、历史上下文检索（"三个月前类似故障怎么处理的"）、以及把厂商设备文档（PDF/手册）变成可问答的知识库，让一线工程师不用再翻几百页手册。最后由"客户影响评分"把结果排序：高话务站点的同等级故障，优先级被显著拉高。
3. **行动（Act）**：低风险、高置信度的处置（如重置进程、倒换冗余链路、重启板卡）进入**闭环自动执行**；高危动作（如大面积割接、核心网网元重启）则推送建议方案交人工确认，形成"人在回路（human-in-the-loop）"。
贝尔网络高级副总裁 **Mark McDonald** 评价："借助谷歌云的 AI，我们在识别和解决网络/服务异常的准确度和速度上都有了显著提升，加速了迈向自治网络的进程。"
### 2.4 生态：Amdocs + Accenture + Capgemini
值得强调的是，这不是贝尔和谷歌两家"裸奔"。谷歌云框架明确列出了 ISV 与 GSI 生态：**Amdocs Network AIOps 解决方案**（含多个网络智能体）跑在谷歌云 AI 基础设施上，提供预测分析、自动化工作流和闭环运营能力；**Accenture（埃森哲）和 Capgemini（凯捷）** 作为 GSI 充当执行手臂，负责把这套能力在运营商组织内部落地并规模化推广。这意味着贝尔拿到的不是一个 PoC，而是一条"云平台 + ISV 产品 + GSI 实施"的成熟交付链。
## 三、效果数据：四个硬指标验证价值
贝尔在新闻稿中给出了上量后的实际成绩（截至 2025 年 2 月），谷歌云框架博客则补充了 MTTR 这一最具代表性的指标。汇总如下：
| 指标维度 | 改造前（传统运维） | 改造后（AI Ops） | 变化幅度 | 数据来源 |
|---|---|---|---|---|
| 平均修复时间 MTTR | 基线（高，依赖人工关联） | 显著下降 | **降低 25%** | 谷歌云框架官方博客 |
| 客户主动报障率 | 基线 | 大幅下降 | **降低 25%** | 贝尔官方新闻稿 |
| 软件交付生产力 | 基线 | 明显提升 | **提升 75%** | 贝尔官方新闻稿 |
| 数据可用性与及时性 SLA 达成率 | — | 稳定 | **99.8%** | 贝尔官方新闻稿 |
四个数字背后是同一条逻辑链：
- **MTTR 降 25%**：Spanner Graph 让根因定位从"人工跨系统拼图"变成"图查询毫秒级命中"，Gemini 让处置方案生成从"翻文档"变成"秒级问答"，自然拉短整个修复链条。
- **客户报障降 25%**：这是"主动维护"的直接证据——因为系统能在客户感知到之前优先识别并处置高影响故障，投诉量随之下降。用贝尔的话说，网络管理从 reactive（被动）转向 proactive（主动）。
- **软件交付生产力提升 75%**：这是 AIOps 之外、但同属谷歌云合作的整体红利——CI/CD、GKE 上的自动化流水线把网络功能（容器化 NF）的发布周期压缩，这也间接支撑了 AIOps 模型自身的快速迭代。
- **99.8% SLA**：说明这套平台自身足够稳，没有因为引入 AI 反而制造新的不稳定。
## 五、深度追问：为什么 Spanner Graph 是胜负手
贝尔这套方案里，最值得通信工程师深挖的是 **Spanner Graph**。很多 AIOps 项目失败，不是模型不够强，而是"数据没准备好"——告警、拓扑、客户、工单散落在几十个系统里，模型拿到的是割裂的、滞后的快照，自然无法准确推理。
Spanner Graph 解决的就是这个"数据底座"问题：
1. **实时一致性**：Spanner 是全球分布式且强一致的，意味着数字孪生可以跨国/跨域保持毫秒级一致，避免"东岸的图更新了、西岸还没更新"的撕裂。
2. **时序能力（temporal graph）**：网络是随时间演进的（割接、扩容、故障都改变拓扑），时序图能回答"昨天 14:00 那次故障发生时，拓扑长什么样"这种回溯问题，对根因分析至关重要。
3. **与 BigQuery 的联邦查询**：图上的实时拓扑可以和大历史的趋势数据直接 JOIN，无需 ETL 搬运，大幅降低数据工程负担。
4. **天然适配 GNN**：图结构数据直接喂给图神经网络，比把拓扑拍扁成表格再喂给传统模型，能捕获多跳依赖关系——这正是"一根光纤抖动 → 影响哪些小区"这类传播分析所需要的。
可以这样说：**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 自治网络。
## 参考来源
1. [Bell Canada launches AI-powered network operations solution built on Google Cloud](https://www.prnewswire.com/news-releases/bell-canada-launches-ai-powered-network-operations-solution-built-on-google-cloud-302385987.html) — 贝尔官方新闻稿，给出 75% 生产力提升、25% 客户报障下降、99.8% SLA、Spanner Graph/Gemini/GKE/BigQuery 技术栈及高管表态。
2. [Autonomous Network Operations framework: Unlock predictable and high-performing networks (Google Cloud Blog)](https://cloud.google.com/blog/topics/telecommunications/the-autonomous-network-operations-framework-for-csps) — 谷歌云官方框架博客，明确 MTTR 降低 25%、Spanner 图数字孪生、GNN+Gemini 架构、Amdocs/Accenture/Capgemini 生态及 Telstra 案例。
3. [BCE Inc. 官方新闻发布页](https://vld-www.bce.ca/news-and-media/releases/show/bell-canada-launches-ai-powered-network-operations-solution-built-on-google-cloud) — BCE 集团（贝尔母公司）官方存档，交叉印证客户影响优先级与 Spanner Graph 描述。
4. [Cloud Spanner Graph Telecom: Essential Guide to autonomous networks](https://arcadianfiber.com/articles/cloud-spanner-graph-telecom-autonomous-networks) — 第三方技术解读，阐释 Spanner Graph 如何统一碎片化数据、支撑自治网络与"以客户体验为中心"的影响分析。
5. [#mwc #autonomousnetworks #googlecloud — The Stack 报道](https://www.linkedin.com/posts/stackpublishing_mwc-autonomousnetworks-googlecloud-activity-7434891369497870336-Okkl) — MWC 现场第三方报道，提及"网络数字孪生以时序图存储于 Spanner Graph + GNN"的混合技术组合。
---
> 本文由「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 等场景全覆盖。
