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处罚通报为底稿,还原三起事故的时间线、根因链与处置过程,并回答一个运维团队最该关心的问题:为什么“例行变更”屡屡变成全网灾难?一线工程师能从中带走什么可落地的检查清单?
据FCC公共安全与国土安全局发布的最终报告(2024年9月公布),事故过程大致如下(当地时间,均为美中时区CT):
| 时间 | 事件 |
|---|---|
| 2024-02-22 凌晨约3:05 | 核心网设备变更导致路由/策略异常,全国性业务中断开始 |
| 凌晨-清晨 | 用户大规模失联,社交媒体开始爆发;大量告警未正常上报,网管中心最初按小范围故障处理 |
| 上午 | AT&T确认全国性故障,启动全网恢复;恢复过程中终端集中重注册造成信令压力 |
| 约12小时后(下午) | 网络基本恢复 |
| 2024年3月 | 又发生两次局部911故障,FCC立案 |
| 2024年9月 | FCC公布最终调查报告 |
FCC报告认定的直接根因是“设备修改错误”(equipment modification error):工程师在对核心网设备做扩容时,错误地应用了配置修改——本应只作用于目标设备的变更,被施加到了更大范围的设备上,触发了路由与策略层面的连锁反应,最终演变为全国性中断。
作为干了十几年核心网的“老网管”,我必须说,这个描述翻译成人话就是三句话:
事故后AT&T提交了整改与合规计划,核心动作包括:强化变更管理(增加执行范围护栏与复核)、修复告警上报链路、完善911呼叫的容灾路径、开展跨域故障演练。FCC在最终报告中虽未同步公布罚金数额,但明确将其定性为可预防的人为变更事故,而非不可抗力——这个定性本身就值得每一家运营商截图存档。
2023年11月8日凌晨4:05(澳东时间)起,Optus全国移动与部分固网业务中断,持续约13个小时,影响超过1000万个人用户和40万家企业。更尴尬的是:由于支撑系统与承载网同域,大量用户连1000(Optus客服)都打不通;不少用户重启手机也毫无作用。部分双卡用户靠漫游到对手Telstra的网络保住了基本通信——这在事后成了一个黑色幽默:Optus用户当天唯一的救命稻草,是竞争对手的网络。
Optus随后公布了官方复盘报告(Post Incident Review),根因链条如下:
按官方复盘的描述:
做过IP承载网的读者看到这里会心一笑:这就是教科书级的“路由泄漏/撤路风暴”——一台设备的异常状态被多层对等体放大成全网撤路,和2010年后多起国际BGP事故是同一个物理病根,区别只是这次发生在单一运营商内部,且没有任何一层把它兜住。
如果说2023年那场事故让Optus换了CEO,那2024年9月这次则是真正触碰到底线的事件。
2024年9月18日午夜前后,Optus在一家数据中心内进行计划内的防火墙升级。升级后的问题导致从Optus移动网发起的000紧急呼叫转接失败,故障持续约13个小时才完全恢复。用户手机信号满格、能上网、能打电话——唯独000打不通。这比“没信号”更危险:用户不会意识到自己处于无保护状态。
三起事故放在一起看,规律刺眼地清晰:
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万澳元
把三起事故的根因链叠加,会得到一条几乎完全重合的故障传播路径:
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年核心网运维经验,我把这三起事故的教训压缩成一份可落地的检查清单:
三起事故,两国家、三张网、三种技术路径,剧本却惊人地一致:一次凌晨的例行变更 + 一条没人复核的错误配置 + 一层没有兜住的保护机制 + 一面被静默的告警墙。2026年回看,行业为AI自愈、自智网络投入巨大,但AT&T和Optus用真金白银证明:在自动化的地基——变更护栏、告警治理、容灾演练——夯实之前,任何“智能运维”都只是在流沙上盖楼。对一线工程师而言,最值钱的不是再学一个新协议,而是把上面这份清单逐条对照自己负责的网络,然后问一句:如果今晚凌晨三点那条例行命令出错了,我的防线在哪一层断掉?
注:本文事故数据均以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 等场景全覆盖。
