<!-- title: AT&T与Optus断网事故复盘 -->

# 一台路由器的错误配置，如何放倒一亿部手机——AT&T与Optus三次重大断网事故复盘

## 概述

2023年11月8日，Optus全国断网13小时，超千万人失联；2024年2月22日，AT&T全美断网约12小时，约1.25亿台设备掉线、超9.4万通911呼救失败；2024年9月18日，Optus再次因一次计划内防火墙割接，导致2745通000紧急呼叫未接通，并最终在联邦法院吃到1200万澳元罚单。三起事故没有一起是“天灾”——全部源自一次看似平常的计划内变更。本文以FCC最终报告、Optus官方复盘报告和ACMA处罚通报为底稿，还原三起事故的时间线、根因链与处置过程，并回答一个运维团队最该关心的问题：为什么“例行变更”屡屡变成全网灾难？一线工程师能从中带走什么可落地的检查清单？

---

## 案例一：AT&T“2·22”全美断网——一次扩容施工放倒94%的流量

### 时间线

据FCC公共安全与国土安全局发布的最终报告（2024年9月公布），事故过程大致如下（当地时间，均为美中时区CT）：

| 时间 | 事件 |
|---|---|
| 2024-02-22 凌晨约3:05 | 核心网设备变更导致路由/策略异常，全国性业务中断开始 |
| 凌晨-清晨 | 用户大规模失联，社交媒体开始爆发；大量告警未正常上报，网管中心最初按小范围故障处理 |
| 上午 | AT&T确认全国性故障，启动全网恢复；恢复过程中终端集中重注册造成信令压力 |
| 约12小时后（下午） | 网络基本恢复 |
| 2024年3月 | 又发生两次局部911故障，FCC立案 |
| 2024年9月 | FCC公布最终调查报告 |

### 根因：变更范围失控 + 告警盲区 + 恢复期风暴

FCC报告认定的直接根因是**“设备修改错误”（equipment modification error）**：工程师在对核心网设备做扩容时，错误地应用了配置修改——本应只作用于目标设备的变更，被施加到了更大范围的设备上，触发了路由与策略层面的连锁反应，最终演变为全国性中断。

作为干了十几年核心网的“老网管”，我必须说，这个描述翻译成人话就是三句话：

1. **变更审批没拦住“波及面”**。扩容割接的执行脚本/配置模板没有严格的范围校验，一个参数错误被放大到不该碰的设备上。
2. **自愈机制没有按设计生效**。报告指出网络原有的保护和自愈设计并未按预期工作——这几乎是所有重大故障的标配剧本：容灾机制“平时从来没用过”，真出事时第一反应不是接管，而是自己也懵了。
3. **告警系统把“火灾”过滤成了“施工”**。FCC报告指出，关键的严重告警未能正常上报到网管中心，一线监控在相当长时间内没有意识到这是全国性故障，延误了发现与定界。这是最让人后背发凉的一条——不是没有告警，而是告警被当成例行维护噪声吞掉了。

### 影响评估

- 约**1.25亿台**无线设备受影响（FCC报告口径），相当于AT&T约94%的网络流量中断；
- 超**9.4万通**911紧急呼叫未能接通——这是本次事故中最严重的社会代价，FCC专门以此认定AT&T违反了网络可靠性相关规定；
- 社会影响面极广：电商平台无法收款、物流司机失去调度、大量依赖手机号的二次验证服务瘫痪。事故当天恰逢周四工作日，直接经济损失难以精确统计，但“半亿级用户失联半天”这个量级，放在任何国家的运营商都是年度级事故。

### 处置与整改

事故后AT&T提交了整改与合规计划，核心动作包括：强化变更管理（增加执行范围护栏与复核）、修复告警上报链路、完善911呼叫的容灾路径、开展跨域故障演练。FCC在最终报告中虽未同步公布罚金数额，但明确将其定性为可预防的人为变更事故，而非不可抗力——这个定性本身就值得每一家运营商截图存档。

---

## 案例二：Optus 2023-11-08 全国断网——一台互联路由器升级引发的“路由坍缩”

### 时间线与影响

2023年11月8日凌晨4:05（澳东时间）起，Optus全国移动与部分固网业务中断，**持续约13个小时**，影响超过**1000万个人用户和40万家企业**。更尴尬的是：由于支撑系统与承载网同域，大量用户连1000（Optus客服）都打不通；不少用户重启手机也毫无作用。部分双卡用户靠漫游到对手Telstra的网络保住了基本通信——这在事后成了一个黑色幽默：Optus用户当天唯一的救命稻草，是竞争对手的网络。

Optus随后公布了官方复盘报告（Post Incident Review），根因链条如下：

### 根因链：路由升级 → 默认参数错误 → 多层对等网互相撤路由

按官方复盘的描述：

1. 凌晨例行对悉尼核心机房的一台**互联路由器**做软件升级；
2. 升级过程中该设备收到了错误的路由信息，并向外传播；
3. Optus网络内部多层的**路由对等网络（Routing Peering Network, RPN）**因默认配置参数错误，彼此进入隔离/重置状态，并纷纷向全网**撤回路由**；
4. 路由大规模坍缩后全网业务中断；
5. 更致命的是：保护机制的设计逻辑是“需要人工确认才能恢复”，而在13小时的恢复过程中，终端集中重连造成的**过载又拖慢了每一步恢复动作**。

做过IP承载网的读者看到这里会心一笑：这就是教科书级的“路由泄漏/撤路风暴”——一台设备的异常状态被多层对等体放大成全网撤路，和2010年后多起国际BGP事故是同一个物理病根，区别只是这次发生在单一运营商内部，且没有任何一层把它兜住。

### 代价

- 事故后确认有**部分000紧急呼叫失败**，另有需依赖网络的心脏监护等家用医疗设备用户报告风险（澳媒广泛报道）；
- Optus对后付费用户提供200GB补偿流量、对中小企业提供现金/流量补偿，成本不菲；
- **2023年11月20日，上任仅一年半的CEO Kelly Bayer Rosmarin辞职**，母公司Singtel集团CEO公开道歉——一场技术事故直接烧掉了最高管理层，这在运营商史上都不多见。

---

## 案例三：Optus 2024-09-18 000中断——割接失败，代价是3条人命与1200万澳元

如果说2023年那场事故让Optus换了CEO，那2024年9月这次则是真正触碰到底线的事件。

### 经过

2024年9月18日午夜前后，Optus在一家数据中心内进行**计划内的防火墙升级**。升级后的问题导致从Optus移动网发起的**000紧急呼叫转接失败**，故障持续约13个小时才完全恢复。用户手机信号满格、能上网、能打电话——唯独000打不通。这比“没信号”更危险：用户不会意识到自己处于无保护状态。

### 影响与问责

- Optus先后多次修正口径，最终确认约**2745通000呼叫未能接通**，涉及上千个家庭；
- 澳媒关联报道了**至少3起死亡个案**（包括一名婴儿和一名昆士兰女性），南澳等地启动死因研讯。需要说明：个案与故障的因果关系由司法程序认定，但“2745通呼救失败”这个数字本身已足够沉重；
- 通信监管机构ACMA将Optus诉至联邦法院。**据2025年公开通报，Optus被处以1200万澳元罚款**，为ACMA历年来同类处罚中金额最高的一次；
- 2025年Optus又发生了两起000相关故障（据公开报道），直接推动澳政府启动000体系改革，方向是强制性的**"fail-safe"机制**：当网络检测到本网应急呼叫失效时，必须自动跨网兜底转接——换句话说，监管要用制度逼每家运营商给自己配上“对手网络的容灾”。

三起事故放在一起看，规律刺眼地清晰：

```text
timeline
    title 三起重大事故时间线
    2023-11-08 : Optus全国断网
              : 凌晨4:05互联路由器例行升级出错
              : 多层路由对等网互相撤路，全网坍缩13小时
              : 超千万用户受影响，CEO辞职
    2024-02-22 : AT&T全美断网
              : 凌晨3:05核心网扩容变更错误
              : 约1.25亿台设备失联约12小时
              : 超9.4万通911失败，FCC出最终报告
    2024-09-18 : Optus 000中断
              : 午夜数据中心防火墙割接失败
              : 000呼叫失败约13小时
              : 2745通呼救未接通，联邦法院罚款1200万澳元
```

---

## 共性规律：四次失守，环环致命

把三起事故的根因链叠加，会得到一条几乎完全重合的故障传播路径：

```mermaid
flowchart TD
    A["例行计划内变更<br>缺乏范围护栏与灰度"] --> B["错误配置/异常状态扩散<br>保护机制未按预期生效"]
    B --> C["路由/信令层面坍缩<br>演变为全网性中断"]
    C --> D["严重告警被过滤或误判<br>发现与定界延迟"]
    D --> E["回滚与恢复<br>终端集中重注册"]
    E --> F["恢复期过载<br>二次拥塞拖慢恢复"]
    C -.-> G["911/000应急呼叫失效<br>技术事故升级为社会事件"]
```

**第一失守：变更管控形同虚设。** 三起事故都发生在凌晨维护窗口的“例行操作”里。凌晨割接本是为了风险最小，但如果变更范围没有硬性校验（只能碰哪些设备、哪些参数），凌晨反而是监控最薄弱、人员最疲惫的时刻。AT&T是扩容改配置改错了范围，Optus是升级触发异常传播——注意，两次都不是“大胆操作”，都是日常动作。

**第二失守：保护机制从未被真正演练。** 路由对等网“设计上应该隔离故障”，结果彼此撤路；自愈机制“设计上应该接管”，结果失效。容灾设计的最大敌人是“从未在生产环境真实验证过”。纸面容灾约等于没有容灾。

**第三失守：告警治理欠账。** 两家运营商都出现了关键告警未及时进入值班视野的问题。在大网里，一次变更触发上万条告警是常态，于是运维团队本能地做抑制、做归并、做“维护窗口静默”——一旦抑制规则写错，全国性故障在网管大屏上看起来就像一次普通施工。

**第四失守：应急呼叫是最后防线，却常常是单点。** 911/000这类应急通道在社会上不可替代，但在网络架构里往往依赖同一条承载链路、同一套转接逻辑。Optus用户“信号满格却打不了000”是最危险的状态——用户没有任何感知预警。

---

## 给一线工程师的实操清单

结合18年核心网运维经验，我把这三起事故的教训压缩成一份可落地的检查清单：

1. **变更范围硬护栏**：任何批量配置下发必须带设备清单白名单 + 参数边界校验，超范围自动熔断，不依赖人的自觉。
2. **灰度先行，全网靠后**：核心网变更先在单点/孤岛环境验证，再同构复制，两批之间留观察期。“测试环境通过”不等于“生产网络兼容”。
3. **维护窗口 ≠ 告警豁免区**：割接期间的告警抑制必须在割接结束后自动解除，且严重级告警（应急呼叫、注册成功率、路由表规模突变）永远不进抑制名单。
4. **把“路由表规模/注册成功率”做成红线指标**：路由前缀数量骤降、附着成功率跳水，这两个指标比任何单设备告警都更接近“全网性灾难”的真相，应触发一键拉起应急决策。
5. **割接必须带回滚预案与“回滚也过载”的预案**：恢复期终端集中重注册造成的信令风暴是第二场事故，限流、分片放通、优先保障语音与应急呼叫的QoS要预先写进预案。
6. **应急呼叫独立验证**：每次重大变更后，从真实终端发起911/000测试呼叫（各地监管多有允许的测试号段机制），而不是假设“网络通了应急就通了”。
7. **对监管口径保持敬畏**：FCC和ACMA的处理思路已经非常一致——“可预防的人为事故”就是要追责的，罚单只会越来越重。把合规要求前置到变更流程里，比事后写复盘报告便宜得多。

---

## 结语

三起事故，两国家、三张网、三种技术路径，剧本却惊人地一致：**一次凌晨的例行变更 + 一条没人复核的错误配置 + 一层没有兜住的保护机制 + 一面被静默的告警墙**。2026年回看，行业为AI自愈、自智网络投入巨大，但AT&T和Optus用真金白银证明：在自动化的地基——变更护栏、告警治理、容灾演练——夯实之前，任何“智能运维”都只是在流沙上盖楼。对一线工程师而言，最值钱的不是再学一个新协议，而是把上面这份清单逐条对照自己负责的网络，然后问一句：如果今晚凌晨三点那条例行命令出错了，我的防线在哪一层断掉？

---

## 参考来源

1. [FCC Releases Final Report on AT&T Network Outage（FCC最终调查报告发布页）](https://www.fcc.gov/document/fcc-releases-final-report-att-network-outage) — FCC官方报告：根因为设备修改错误，约1.25亿台设备受影响、超9.4万通911呼叫失败
2. [FCC Lays Out Why AT&T's Network Fell Over Last Year（Light Reading）](https://www.lightreading.com/security/fcc-lays-out-why-att-s-network-fell-over-last-year) — 行业媒体对FCC报告的深度解读：变更范围失控与告警盲区分析
3. [Optus Post Incident Review（Optus官方媒体中心）](https://www.optus.com.au/about/media-centre/media-releases/2023/optus-post-incident-review) — 2023年11月8日全国断网官方复盘：互联路由器升级与多层路由对等网撤路
4. [ACMA Media Releases（澳大利亚通信与媒体管理局官方通报）](https://www.acma.gov.au/media-releases) — ACMA对Optus 000事故的联邦法院诉讼及2025年1200万澳元罚款通报（罚款金额据公开报道）
5. [C114通信网·海外运营商动态](https://www.c114.com.cn) — Optus 000事故后续、澳政府"fail-safe"改革动向的中文报道汇总

> 注：本文事故数据均以FCC最终报告、Optus官方复盘及ACMA通报口径为准；个别细节（如关联死亡个案的因果关系认定）仍处司法程序中，以官方结论为准。

---
> 本文由「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)
