首页 › tech › 防火墙夺命:Optus断网一周年

概述

2025年9月18日凌晨4点15分,澳大利亚第二大运营商Optus一次计划内的防火墙软件升级,让全国000应急呼叫中断约13个小时:约600名用户、超过4000次拨打未果,澳媒相继披露三起与求救电话打不通相关的死亡。今天恰好是事故一周年。本文以Optus官方事后声明与ACMA监管通报为轴,按时间线拆解这起“教科书级”变更管理事故:一行软件缺陷如何吞掉一个国家的求救电话?为什么13个小时没人发现、也没人修好?监管重罚、CEO离场之后,又给全行业留下了哪几条用命换来的教训?

目录

一、周年这天:一个国家最忙的号码成了空号

任何一个做过核心网运维的人,都背得出一条铁律:应急呼叫是全网最高优先级。3GPP标准里,紧急呼叫要打上专门的标识;各国的网络设计里,应急路径要冗余、要拨测、要常备预案。000是澳大利亚的全国应急号码,相当于我们的110加120加119。

2025年9月18日,这条铁律被一行软件缺陷击穿了。

据Optus官方事后声明,当天凌晨4点15分左右,Optus按计划在其网络设施内进行一次防火墙软件升级。升级本身“成功”完成,网管上没有红色告警,设备没有重启,链路没有中断。但从那一刻起,Optus网络上用户拨出的000呼叫,开始被这面防火墙悄悄拦下——呼叫出不了Optus的网,到不了Telstra运营的全国应急接警台(ECP)。

更荒诞的是发现方式。这不是任何一台网管、任何一条告警发现的,而是用户“发现”的:一个上午过去,社交媒体上陆续出现“000打不通”的抱怨,Optus才在临近中午时将事件定性为应急通信故障。等到故障彻底排除、000呼叫陆续恢复,已是当天傍晚——距离那个凌晨4点15分,过去约13个小时。

我在运维一线待过18年,割接熬过无数个凌晨。这件事最让我脊背发凉的不是故障本身,而是:全网所有监控都是绿的,而有人正在因为打不出求救电话死去。

二、13小时时间线:每一步都是断层

先看时间线,每一段都值得用运维的放大镜看一遍:

时间(当地时间) 事件 断层在哪
09-18 凌晨04:15 防火墙软件升级按计划开始执行 变更前没有应急呼叫的强制回归测试
04:15起 000呼叫被缺陷拦截,无法送达接警台 呼叫"从未接入",不产生任何告警
上午 用户000拨打失败,投诉开始堆积 监控体系对应急呼叫成功率无感知
临近中午 舆情反馈汇集,Optus定性应急故障 故障发现依赖用户,而不是网络自己
下午 排查定位到防火墙升级引入的缺陷 定位耗时数小时,变更记录成了唯一线索
傍晚约17时后 回退处理完成,000呼叫陆续恢复 全程约13小时

用一张图回顾这13个小时的决策链:

flowchart TD
    A["9月18日 04:15<br/>防火墙升级开始"] --> B["升级完成无告警<br/>000开始被拦"]
    B --> C["整个上午<br/>呼叫失败无感知"]
    C --> D["临近中午<br/>舆情倒逼定性故障"]
    D --> E["下午<br/>锁定防火墙缺陷"]
    E --> F["傍晚5点后<br/>回退完成000恢复"]
    F --> G["当晚起<br/>官方审查与问责启动"]

请记住时间线里最刺眼的一行:04:15起,呼叫失败无感知。这9个小时不是“抢修的13个小时”,而是“盲飞的13个小时”。前半段根本没有“抢修”这个词——因为网络自己根本不知道自己坏了。

三、根因:防火墙怎么“吞”掉一通求救电话

要理解这个故障,得先看懂一通000呼叫的正常旅程。澳大利亚的应急呼叫体系里,所有000呼叫最终都要汇集到全国应急接警台(ECP,由Telstra运营),接警员确认警情后再三方转接到警察、消防或急救。

一通Optus手机用户的000呼叫,路径大致如下:

flowchart TD
    A["用户拨打000"] --> B["Optus移动核心网"]
    B --> C["防火墙安全域"]
    C -->|"缺陷拦截"| D["呼叫困在网内"]
    C -->|"正常放行"| E["Telstra接警台ECP"]
    E --> F["转接警方或消防或急救"]

正常情况下,这通呼叫会被网络打上应急呼叫标识,穿过防火墙安全域,送达到接警台。而这次升级引入的软件缺陷,让防火墙没能正确识别和放行000呼叫——按照Optus在公开声明与议会听证中的说法,升级后呼叫未能被正确标识为应急呼叫,被拦在了Optus网内。

这里藏着三个运维层面最凶险的细节:

第一,故障形态是“静默丢弃”,不是“显式失败”。 被拦的呼叫没有回到用户一声响铃,也不会在信令面留下一条红色告警。设备CPU正常、光功率正常、注册成功率正常——所有以设备为中心的KPI都是绿的。只有“呼叫语义层”的指标(000呼叫接通率)才能看见它,而当时Optus的监控体系里,恰恰没有这道闸门。

第二,故障点在安全域,不在语音域。 防火墙安全策略通常由安全团队维护,语音团队对它既没有变更评审权,也没有故障演练权。这是电信网络组织里典型的“缝隙地带”:安全设备横跨在信令与媒体路径上,却游离于语音网管的拓扑视野之外。变更审批两拨人各签各的字,风险却在同一张网上叠加。

第三,变更窗口选在凌晨4点15分。 行业惯例里,凌晨是“低话务窗口”,但低话务不等于低风险——凌晨的验证手段最弱、跨团队支援最少、工程师最疲惫。而这次变更恰恰缺了最关键的一道闸门:变更完成后,立刻从网内发起测试呼叫验证000全路径。任何一个地市、哪怕一通测试呼叫失败,这个事故都止步于凌晨4点半。

标准对应急呼叫的要求是一致的,但标准管不到“防火墙会不会放行这通呼叫”这种实现细节——这恰恰要靠运营商自己的变更纪律来兜底。这次,兜底的网破了一个洞。

四、为什么整整13个小时没人发现、没人修好

复盘这13个小时,我把它拆成四个断层,每一个都在别的网络上演过:

断层一:探测缺位。 应急呼叫成功率没有分钟级拨测。Optus事后承认,监控没有捕捉到故障,最初是舆情反馈倒逼事件定性。在报警中心视角里,那一整个上午,全网“健康”得像什么都没发生。

断层二:定性迟缓。 用户投诉是发散的、模糊的——“我打不出电话”“手机没信号”,很容易被归因成局部无线故障或终端问题。应急呼叫失效的定性需要专门比对:是所有用户打不通,还是000打不通?是本网打不出,还是全网都打不出?这个比对动作,如果没有预置的“应急呼叫专项排查预案”,就要现场摸索,一磨就是几个小时。

断层三:定位绕远。 故障根因在凌晨那笔变更里,但变更系统、安全域、语音网是三本账。定位时要么靠人肉比对变更记录,要么逐跳trace呼叫路径——防火墙的拦截日志如果没有对000呼叫失败计数的可视化,定位就只能靠穷举。据听证会披露的信息,故障定位花了整整一个下午。

断层四:回退不果断。 凌晨的变更没有预设“abort条件”(比如:任何000测试呼叫失败立即回退),于是回退变成了故障发生后的一场临时决策——要先确认“回退是否影响在网业务”,又要评估“回退本身的风险”。凌晨4点花五分钟决策的事,下午花五个小时也未必决策得出来。

四个断层环环相扣,缺了任何一个,事故都不会是13个小时。这也是为什么我说它是教科书级的案例:它不是某个设备的偶发缺陷,而是变更管理、监控体系、应急预案三条防线的同时失守。

五、三条人命:数字之外

据Optus在议会听证中披露,事故期间约600名用户尝试拨打000,累计超过4000次呼叫未成功。600个家庭里,澳广(ABC)等澳媒相继追踪报道了三起死亡事件:昆士兰州一名女性疑似心脏骤停,家人求救未果;南澳州一名出生仅8周的女婴,母亲回拨求救电话打不通;西澳州一名七旬老人,家属多次呼叫000失败。三起事件随后进入死因研讯程序,与断网事故的关联仍在司法程序中核实。

(注:三起个案的细节以各州死因裁判官的最终认定为准,本文引用的是澳媒基于家属陈述与初步调查的报道。)

写运维文章这么多年,我一直提醒自己一个底线:故障复盘不能停在“影响XX万用户”这种统计口径上。600人、4000次呼叫,摊开是600个具体的、正在经历人生最黑暗时刻的家庭——产妇在流血,老人在抽搐,婴儿没有了呼吸。电话那头的忙音,对他们是不可承受的等待。

这也是这起事故区别于绝大多数运营商事故的地方:Fastly断网49分钟,损失的是钱;Optus这13个小时,欠的是命。应急呼叫一旦失效,故障等级就不是SLA的问题,而是伦理与法律的问题——监管的后续动作,正是沿着这条逻辑展开的。

六、问责与整改:罚款、听证会与CEO离场

事故之后的问责链条,走得比舆论预期快得多:

议会听证。 2025年10月,Optus管理层到参议院环境与通信委员会接受质询,600人、4000次呼叫失败等关键数据正是在听证会上披露的。母公司Singtel的管理层同场致歉,质询的焦点直指变更管理流程与应急呼叫监控缺位。

CEO离场。 据多家澳媒报道,2025年11月初,Optus宣布CEO Stephen Rue离任。从2023年11月全国断网到2025年9月000事故,两起全国级事件后掌门人谢幕,在澳大利亚电信史上极其罕见。

监管出手。 据ACMA(澳大利亚通信与媒体管理局)官方通报,2025年12月,ACMA就000事故对Optus提起联邦法院民事处罚程序——应急呼叫义务是澳大利亚电信监管的红线条款,由监管机构正式诉至联邦法院,是该领域近年罕见的动作。此前,联邦政府通信部长也已宣布对全国000应急体系启动独立审查。

运营商整改。 Optus公开承诺的整改包括:应急呼叫双路由冗余、以000接通率为核心的分钟级监控与告警、变更管理流程收紧、强化变更后应急呼叫回归测试。整改的成色,要等下一次大故障的检验——但至少方向对了:把应急呼叫当成独立的、被持续拨测的业务实体来管,而不是当成语音业务的附属品。

七、11个月摔两跤:Optus两次全国性事故对比

把时间往回拨,2023年11月8日,Optus还摔过更早的一跤:一次全国性断网波及逾1000万用户,手机、宽带大面积瘫痪。据Optus事后复盘报告,那次是一次常规网络升级触发BGP路由大面积撤销,数百万家庭宽带Modem同时掉线重连,重连风暴一度冲到每分钟20万次以上,耗尽CGNAT资源,故障持续了大半天。

两次事故放在一起看,有意思得多:

维度 2023年11月断网 2025年9月000事故
触发点 常规网络升级 防火墙软件升级
根因机制 BGP路由风暴+终端重连雪崩 防火墙缺陷静默拦截应急呼叫
影响面 逾1000万用户通信瘫痪 约600人的求救电话打不出
最痛的点 全网不可用,经济损失 应急失效,三起死亡关联调查
发现方式 大面积投诉爆发 舆情反馈,长达半日无感知
持续时间 大半天 约13小时
后续问责 听证会质询 听证会+联邦法院程序+CEO离场

对比之下你会看到一个残酷的规律:2023年那一跤,Optus摔在“把网络改挂了”这个经典坑里;2025年这一跤,摔在同一类坑的更深处——还是凌晨的升级,还是变更管理失守,只是这一次,被牺牲的是最高优先级的生命线业务。 两次事故相隔不到两年,同一个变更管理的根子上,说明整改的深度远跟不上事故的级别。这也是全球运营商的共同命题:改一次配置只要几分钟,改一个组织的变更纪律要很多年。

八、写给同行的六条血训

最后落到我们自己的网络上。六条教训,每一条都对应着这起事故里一个具体的断点:

1. 给应急路径装上“心电图”。 应急呼叫成功率必须是独立的、分钟级的合成拨测指标:从各省各市的测试终端周期性发起真实应急测试呼叫(用专用测试号段、对接接警台的测试端口),任何一通失败即触发最高级告警。计费话单我们都能做到逐条对账,求救电话没理由做不到。

2. 高危变更必须有应急呼叫回归闸门。 防火墙、安全策略、信令路由、核心网升级——所有横跨语音路径的变更,变更完成的验收标准不是“设备无告警”,而是“000/911/110测试呼叫全路径通过”。没有这道闸门,变更不许关闭。

3. 安全域的变更要过语音团队的桌。 防火墙不是安全团队的自留地,它横在信令与媒体路径上。跨域变更(安全+语音)必须联合评审、联合验证,变更记录两边都留痕——否则定位时就是两本对不上的账。

4. 凌晨4点不是万能安全窗。 低话务窗口适合做变更,但高危变更要配齐“低话务+人员齐备+验证手段完备”三个条件。凌晨做高危变更,等于在最弱的验证环境里做最危险的手术。

5. 变更前写好“abort剧本”。 明确的回退触发条件、回退步骤、决策权限,变更单上逐条写清。事故发生时的回退决策,不该是会议室里的临时辩论,而应该是照着剧本执行的肌肉记忆。

6. 把“应急生命线KPI”当成监管预期来准备。 ACMA把Optus告上联邦法院,传递的信号是全球性的:应急呼叫的可靠性正在从“服务承诺”变成“法定义务”。与其等监管来查,不如先把拨测、冗余、演练做在自己网上——我们对照自查一下:自己的网络里,应急呼叫的接通率有人盯吗?有告警吗?演练过吗?

九、结语:下一次凌晨4点,你的网还好吗

一周年了。Optus的新CEO在位子上刚坐稳,联邦法院的程序还在走,三个家庭的死因研讯还没有结论。而全世界的机房里,今晚依然有无数个凌晨4点的变更窗口,依然有工程师在低话务的深夜按下回车。

这起事故给我最深的一个触动,是一位 Optus 管理层在听证中的表态所折射的现实:网络监控的每一块面板都是绿的,但求救电话就是打不通。运维这个行业修了三十年网络,修硬件、修软件、修链路,但2025年9月18日这一天提醒我们:最难修的,从来不是设备,而是流程的缝隙、组织的盲区,以及“应该不会出事”这五个字。

愿你网里的每一个凌晨4点,都有人为那通可能打不出的求救电话,多设一道闸门。

参考来源

  1. Optus Media Centre(官方声明与整改通报) — Optus关于2025年9月18日000事故的历次官方声明、复盘说明与整改承诺,站内检索"triple-zero"可获取原文
  2. ACMA(澳大利亚通信与媒体管理局)官网 — 检索"Optus triple-zero"可查联邦法院民事处罚程序等监管通报
  3. ABC News(澳广) — 对事故时间线、三起死亡事件与议会听证会的连续深度报道
  4. The Guardian Australia — 参议院听证会细节、600人/4000次呼叫数据及CEO离任报道
  5. Australian Parliament(澳大利亚议会)委员会页面 — 参议院环境与通信委员会对Optus的听证会记录与证词文本

(说明:以上为各机构官方入口,具体报道与通报原文可在各站内以“Optus triple-zero outage”检索定位;文中部分个案细节以死因裁判官最终认定为据。)


本文由「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学通信知识星球海报-扫码加入