<!-- title: 防火墙夺命：Optus断网一周年 -->

## 概述

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

## 目录

- 一、周年这天：一个国家最忙的号码成了空号
- 二、13小时时间线：每一步都是断层
- 三、根因：防火墙怎么“吞”掉一通求救电话
- 四、为什么整整13个小时没人发现、没人修好
- 五、三条人命：数字之外
- 六、问责与整改：罚款、听证会与CEO离场
- 七、11个月摔两跤：Optus两次全国性事故对比
- 八、写给同行的六条血训
- 九、结语：下一次凌晨4点，你的网还好吗

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

任何一个做过核心网运维的人，都背得出一条铁律：应急呼叫是全网最高优先级。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个小时的决策链：

```mermaid
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呼叫，路径大致如下：

```mermaid
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（官方声明与整改通报）](https://www.optus.com.au/about/media-centre) — Optus关于2025年9月18日000事故的历次官方声明、复盘说明与整改承诺，站内检索"triple-zero"可获取原文
2. [ACMA（澳大利亚通信与媒体管理局）官网](https://www.acma.gov.au) — 检索"Optus triple-zero"可查联邦法院民事处罚程序等监管通报
3. [ABC News（澳广）](https://www.abc.net.au/news) — 对事故时间线、三起死亡事件与议会听证会的连续深度报道
4. [The Guardian Australia](https://www.theguardian.com/australia-news) — 参议院听证会细节、600人/4000次呼叫数据及CEO离任报道
5. [Australian Parliament（澳大利亚议会）委员会页面](https://www.aph.gov.au/Parliamentary_Business/Committees) — 参议院环境与通信委员会对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学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)
