<!-- title: 两大全国断网案核心网复盘 -->

# 深水区断网复盘：Three UK软件缺陷与Telstra存储双失效，核心网最痛的两课

## 概述

大多数被反复讨论的全国级断网（AT&T 2024、KDDI 2022、Rogers 2022）都指向同一个词：变更。但2022–2023年还有两起性质完全不同的全国级事故值得每一个核心网工程师逐帧研究——2022年5月澳大利亚Telstra的约40小时全国数据业务劣化，根因是数据中心内两套SAN存储阵列**同时**硬件失效并叠加数据损坏；2023年12月英国Three UK全国数据业务中断约18小时，根因是核心网迁移后的**软件缺陷**，且出现了“语音活着、数据全断”的罕见分域故障形态。本文按时间线拆解两起事故的故障传播链、恢复期次生灾害（重附着信令风暴）、监管动作与补偿，并给出一份可直接落地的核心网深水区检查清单。

---

## 案例一：Telstra 2022年5月——当“双活”变成“双亡”

### 事故概貌

Telstra是澳大利亚最大的移动运营商，移动用户约2000万。2022年5月10日下午（AEST），Telstra全国范围内4G/5G数据业务出现大面积劣化，部分用户完全无法上网，语音与短信部分受影响，持续约40小时后才全面恢复。这是Telstra史上持续时间最长的一次移动网故障，而它最出名的地方在于：**Telstra罕见地发布了一份技术细节相当坦白的公开复盘**（发表于其官方博客Telstra Exchange，由当时的网络执行董事Nikos Katinakis署名）。

### 时间线

```mermaid
timeline
    title Telstra 2022年5月事故时间线（据官方复盘与公开报道整理）
    section 5月10日
        下午 : 一号数据中心SAN阵列A发生硬件失效
        紧接着 : 按设计本应兜底的SAN阵列B随即失效<br>双活架构双双失守
        傍晚 : SIM服务器（签约数据/鉴权数据）数据损坏<br>全国数据业务大面积劣化
        深夜 : 确认备份恢复无法直接使用<br>启动SAN重建
    section 5月11日
        全天 : 重建存储、修复数据、逐批重同步签约数据<br>业务维持降级运行
    section 5月12日
        上午 : 数据重同步完成<br>业务全面恢复，历时约40小时
```

### 根因：教科书没写的那一页

按高可用设计的初衷，SIM签约数据（HSS/签约数据库）落地在两个数据中心的SAN存储上互为备份，**任何一套失效都不应影响业务**。但Telstra复盘披露的实际情况是：

1. **第一击**：一套SAN阵列发生硬件失效——这属于设计范围内的故障，双活本应无损接管。
2. **第二击**：另一套SAN阵列**在极短时间内也发生失效**。两套独立冗余域在同一时间窗内先后倒下，超出了设计假设。
3. **第三击（最致命）**：失效过程伴随着**数据损坏**。这意味着“切换到备份”这条路走不通了——备份上的数据本身已经不干净，不能贸然加载，否则可能把脏数据写回全网签约库。
4. 因此恢复路径被迫走最保守也最慢的一条：**重建存储环境→从干净副本恢复→逐条重同步签约数据→终端批量重附着**。

### 故障传播链

```mermaid
flowchart TD
    A[SAN阵列A硬件失效] --> B[设计假设: 阵列B无损接管]
    A2[SAN阵列B同时失效] --> C[双活双双失守<br>超出冗余设计假设]
    C --> D[SIM签约数据损坏<br>不能直接切换/回滚]
    D --> E[MME鉴权与位置更新失败<br>签约数据读写受阻]
    E --> F[全国4G/5G数据业务劣化<br>部分000应急呼叫受阻]
    F --> G[恢复: 重建SAN+干净副本]
    G --> H[签约数据逐批重同步]
    H --> I[终端批量重附着<br>信令洪峰风险]
    I --> J[限流/分批放通<br>防止二次雪崩]
```

### 影响与处置评估

- **业务面**：数据业务全国性劣化约40小时而非“全断”，一个重要的客观原因是Telstra当时仍有3G网络作为部分兜底，且故障点在签约数据层而非全部网元——不同用户、不同区域、不同业务的受害程度呈“梯度分布”，这恰恰是**核心网深水区故障的典型形态**：告警面上千条，根因只有一个。
- **应急呼叫**：Telstra承认部分用户的000应急呼叫一度失败。在澳大利亚，应急呼叫可达性是监管红线，此事直接触发了监管机构的问询与整改要求。
- **恢复期**：签约数据重同步完成后，数百万终端在同一时间窗内发起重附着，信令洪峰随时可能把刚站起来的核心网再次压垮。Telstra采取了分批放通与限流措施。这印证了核心网运维的老经验：**故障恢复的最后一公里，往往比故障本身更危险**。
- **透明度**：这份复盘的价值在于它没有停在“设备故障，已恢复”的套话上，而是承认了三个设计层面的尴尬事实——双活可以双亡、备份可以带毒、监控看得见硬件告警却看不清业务影响面。

---

## 案例二：Three UK 2023年12月——一次迁移引发的18小时

### 事故概貌

Three UK是英国第四大移动运营商，用户约900万。2023年12月7日16:30（GMT）前后，Three UK全国4G/5G数据业务大规模中断，大量用户手机显示有信号但无法上网、无法收发数据；部分用户的语音与短信也受影响，但相当多用户**语音仍可用**。数据业务以分区域滚动方式恢复，到12月8日中午前后大部分用户恢复，整体持续约18小时。据公开报道，事后Three UK向受影响用户提供了账单补偿，英国监管机构Ofcom随后启动了正式调查；截至本文写作，最终处罚结果未见官方公布，此处不做揣测。

### 时间线与关键现象

| 时间（GMT） | 事件 |
|---|---|
| 12月7日 16:30前后 | 全国4G/5G数据业务大面积中断，用户有信号无数据 |
| 12月7日晚 | 社交媒体涌现海量投诉；Three承认核心网故障，声明根因是“核心网计划内工作之后的软件错误” |
| 12月7日夜间—8日凌晨 | 工程团队定位缺陷、准备修复版本，语音类业务在部分用户侧维持可用 |
| 12月8日 | 分区域滚动恢复，中午前后大部分用户数据业务回归；约18小时 |
| 事后 | 受影响用户获补偿；Ofcom立案调查 |

### 根因与“语音活着、数据死了”的分域形态

Three UK官方对根因的表述是：**计划内核心网工作（网络整合/迁移）之后引入的软件缺陷**。这句话信息量很大：

- 它不是配置改错（变更子弹型），而是**迁移后的新环境里潜伏的软件缺陷**——变更过程本身“成功”了，缺陷在后续运行中被触发。这类故障在割接评审中几乎无法用传统核对单拦住，因为它不是“改错了”，而是“改对了但代码有病”。
- 故障呈现明显的**分域特征**：数据业务（PS域/EPC承载）大面积瘫痪，而相当比例的语音通过传统电路域/IMS路径继续工作。这暴露出Three UK当时网络中语音与数据的承载路径并未完全同源——平时这是冗余，故障日这成了“意外的降级保护”。同期英国正在推进2G/3G退网与VoNR化，语音数据全面走向同源同域，这种“意外保护”未来将不复存在，**语音数据同源化之后，核心网一次缺陷就是全业务归零**，这是所有运营商都该从这次事故里读出的前瞻风险。

### 恢复期：滚动放通与投诉洪峰

Three UK采取分区域滚动恢复而非一次全开，这与Telstra的分批放通思路一致，本质都是在对抗同一头怪兽——**重附着风暴**。数百万终端从“有信号无数据”状态恢复后，会立刻发起大规模并发附着/服务请求，若核心网（MME/AMF、鉴权、签约数据层）不限流，刚恢复的网络会被信令洪峰二次打瘫。两次事故、两家运营商、两个大洲，恢复期打法如出一辙，这不是巧合，而是核心网故障恢复的客观规律。

---

## 两案对比：不同根因，同一深水区

| 维度 | Telstra（2022.05） | Three UK（2023.12） |
|---|---|---|
| 持续时长 | 约40小时（劣化为主） | 约18小时（数据业务中断） |
| 用户规模 | 约2000万 | 约900万 |
| 根因类别 | 硬件双失效+数据损坏 | 迁移后软件缺陷 |
| 故障点 | 数据中心SAN存储层/签约数据 | 核心网（EPC）软件层 |
| 触发方式 | 无预兆硬件故障 | 计划内迁移工作后的潜伏缺陷 |
| 故障形态 | 全国梯度劣化 | 语音/数据分域，数据全断 |
| 恢复手段 | 重建SAN+干净副本+重同步签约数据 | 修复缺陷+分区域滚动放通 |
| 恢复期风险 | 重附着信令洪峰，分批限流 | 分区域滚动恢复，控制洪峰 |
| 应急呼叫 | 部分000呼叫受阻（监管红线） | 据报道部分用户紧急呼叫受影响 |
| 监管动作 | 监管问询+整改要求 | Ofcom正式立案调查 |
| 事故的“独特价值” | 证明双活可双亡、备份可带毒 | 证明割接成功≠没有变更事故 |

---

## 深层机理：为什么这两案比“变更子弹”更值得研究

### 1. 冗余的真实含义是“独立”，不是“备份”

Telstra案的第一个教训常被误读为“设备会坏，没办法”。错。**两套SAN在同一时间窗内双双失效，大概率说明它们之间的独立性是名义上的**：同一机房、同一供电与冷却域、同一批固件、同一套管理平面——只要共享任何一个维度，就存在共因失效（Common Cause Failure）通道。真正的冗余评估不是数副本数量，而是逐项审计副本之间的**故障域隔离度**：供电、制冷、固件版本、管理网络、运维操作窗口。三副本分三地，每副本独立固件批次与独立管理面，才是能扛住Telstra式连环击穿的设计。

### 2. 数据损坏让所有RTO/RPO承诺失效

传统容灾演练回答的问题是“切过去要多久”（RTO）和“丢多少数据”（RPO）。但Telstra案揭示的是第三种状态：**副本存在、但数据不可信**。此时无论RTO多短、副本多少都没有意义，因为任何一条恢复路径都要先回答“哪份数据是干净的”。这要求核心网签约数据库具备：跨时间点的多版本快照、快照完整性校验、以及**带毒数据不回写的准入机制**。存储层故障演练必须包含“数据损坏”场景，而不是只演练“阵列拔盘”。

### 3. 迁移割接的风险不在当天，而在其后30天

Three UK案对割接管理的颠覆性启示是：变更事故的窗口不只是变更当天。迁移后的新环境是一个**未被生产流量充分检验过的新生物**，缺陷可能潜伏数日甚至数周才被特定触发条件激活。务实的做法是把“大迁移后30天”整体划为高危期：冻结其他变更、提升监控粒度、对核心网关键进程异常（进程重启、消息异常码、话务模型突变）设置更敏感的阈值，并准备好缺陷回退预案——包括回退到旧环境的**数据面一致性**验证，而不只是配置回退。

### 4. 恢复期信令风暴必须写入应急预案

两案的恢复期共同指向一个可量化、可演练的威胁：终端批量重附着。核心网侧的对抗手段应预先固化在预案里，包括：MME/AMF侧附着与业务请求限流、按区域/号段分批放通、鉴权与签约数据层的过载保护参数预置、以及把**恢复期监控大屏单独做一版**（看的指标与故障期完全不同：附着成功率、鉴权时延、S1/NG接口信令QPS）。凡是没有做过“恢复期专项演练”的网络，都等于在故障尾声埋了第二颗雷。

### 5. 语音数据同源化是未来的最大变量

Three UK的“语音活着”是当时网络分域架构的意外馈赠。而全行业正在走向2G/3G退网、VoNR全覆盖、签约数据统一收口UDM，语音与数据将共享同一套核心网与同一套签约数据库。这意味着下一次同等量级的核心网故障，**将是真正的全业务归零**，应急呼叫可达性的监管压力将成倍放大。运营商现在就该做的两件事：应急呼叫路径的独立冗余度复核（哪怕业务全断，110/119/000/911路径要有独立生命线设计），以及核心网重大缺陷的分钟级应急广播能力（短信/小区广播通道在故障下的可用性保障）。

---

## 给核心网工程师的深水区检查清单

1. **故障域隔离审计**：列出签约数据层每个副本，逐项核对供电/制冷/固件批次/管理面/操作窗口独立性，任何一项共享都记为共因失效隐患。
2. **带毒数据准入机制**：签约数据库的恢复流程中必须存在“完整性校验通过才允许加载”的强制卡点，演练一次“副本已损坏”场景。
3. **多版本快照与校验**：跨时间点快照≥3个，且每个快照可独立校验。
4. **迁移后30天高危期制度**：大迁移后冻结变更、加密监控、预置回退数据一致性方案。
5. **恢复期预案成文化**：限流参数、分批放通顺序、恢复期专用监控视图，全部预置并纳入年度演练。
6. **应急呼叫独立生命线**：模拟“核心网全归零”场景，验证应急呼叫路径与小区广播通道的可用性。
7. **分域故障形态预案**：语音通数据断（或反之）时，客服话术、舆情口径、故障定位入口是否有专用预案——Three UK当晚的海量投诉，一半是“有信号为什么没网”的沟通成本。

---

## 结语

这两起事故没有戏剧性的黑客，没有离谱的误操作，有的只是核心网最诚实的两个真相：**冗余会被共因失效击穿，成功割接也可能带着病毒落地**。Telstra用40小时证明了备份不可迷信，Three UK用18小时证明了变更事故的窗口比我们以为的长得多。而两案不约而同的分批放通恢复，则给所有运营商提了同一个醒：故障的最后一公里是信令风暴，预案里没有它，前面抢回来的每一分钟都可能白费。核心网运维的上限，从来不在故障发生时的反应速度，而在故障发生前对“独立性、数据可信度、恢复期”这三个深水区问题的工程化程度。

---

## 参考来源

> 注：本文写作环境临时无法联网核验，以下为相关机构与报道的公开入口；文中数字均来自事故后运营商官方复盘及主流媒体公开报道，个别时间与细节以官方最终报告为准。

1. [Telstra Exchange 官方博客](https://www.telstra.com.au/exchange) — Telstra公开发布的2022年5月故障技术复盘（Nikos Katinakis署名）所在地，罕见的高透明度运营商自曝
2. [Ofcom 英国通信管理局](https://www.ofcom.org.uk) — 对Three UK 2023年12月断网立案调查的监管机构官网，可查询调查声明
3. [Reuters 科技频道](https://www.reuters.com/technology/) — 两起事故的即时报道与运营商声明转载入口
4. [ACMA 澳大利亚通信与媒体管理局](https://www.acma.gov.au) — Telstra应急呼叫受阻事件的监管方，发布相关问询与整改信息
5. [BBC News 科技版](https://www.bbc.com/news/technology) — Three UK断网当日英国本土报道最完整的媒体之一

---
> 本文由「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学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)
