<!-- title: 防火墙升级放倒澳洲急救电话 -->

# 一次例行防火墙升级，如何演变成2.5亿澳元的诉讼：Optus“000断网”全复盘

## 概述

2025年9月18日刚过午夜，澳大利亚第二大运营商Optus的一次例行防火墙升级，导致南澳、西澳、北领地和西新南威尔士州的Triple Zero（000，澳大利亚急救电话）呼叫被持续阻断近14小时。Schott独立审查报告显示：期间共有605名用户尝试拨打000，仅150人接通，约455次救命电话石沉大海，最终确认与断网相关的死亡为2人。2025年12月18日，Optus董事会发布含21条整改建议的独立审查报告；2026年7月30日，监管机构ACMA将其告上联邦法院——指控1005项违规、单项最高罚款25万澳元，总敞口超过2.5亿澳元，成为澳大利亚电信史上最大的执法案件之一。本文以核心网工程师视角，拆解这次“低级变更”如何击穿应急通信底线的完整链条。

## 一、事发：一条错误的变更指令

**直接的引爆点简单到令人发指。** 据Schott报告披露，这是一次由Optus和诺基亚联合实施的“例行防火墙升级”。变更过程中，Optus提供给诺基亚网络工程师的指令本身就是错误的，而诺基亚照单执行——结果阿德莱德Regents Park交换机房的网关被锁死，常规语音和000应急呼叫同时被切断。

接下来发生的事情，暴露了这张网络在韧性设计上的两面性：

- **普通语音呼叫很快恢复了。** 因为语音业务存在多条迂回路由，网络自动把呼叫绕开了被锁的网关，用户基本无感；
- **000应急呼叫持续被阻断。** 应急呼叫的选路逻辑与普通呼叫不同，它没有享受到同样的迂回路径，被防火墙规则持续拦截。

“普通电话能打、急救电话打不通”——这种故障形态恰恰是最危险的：网络侧的KPI看起来一切正常，话务量没有断崖，告警台上风平浪静。报告的措辞毫不留情：**“一次标准防火墙升级搞成这样，是不可原谅的（inexcusable）”**。

## 二、14小时灾难时间线

| 时间（当地时间） | 事件 |
|---|---|
| 9月18日 00:00刚过 | 防火墙变更实施，指令有误；Regents Park（南澳）网关被锁 |
| 9月18日 凌晨起 | SA/WA/NT/西NSW的000呼叫开始失败；普通语音经迂回路由陆续恢复 |
| 9月18日 上午~午后 | 至少5名用户致电Optus呼叫中心投诉无法呼出；呼叫中心不知情，未升级工单 |
| 9月18日 ~13:50之后 | Optus与诺基亚才意识到问题，回退变更，网关解锁（发现耗时约13小时） |
| 9月18日 14:30 | 危机管理机制才被激活，且仅限于“知道有个问题”的粒度 |
| 9月18日 20:00 | 才首次确认约有100例000失败呼叫 |
| 9月19日 17:30 | Optus召开新闻发布会通报死亡案例；各州州长在此**之后**才获通报 |
| 9月19日~20日 | 警方通报4例死亡纳入调查：南澳68岁女性、西澳49岁与74岁男性、南澳8周大男婴 |
| 2025年12月18日 | Optus董事会发布Dr Kerry Schott独立审查报告，21条整改建议 |
| 2026年7月30日 | ACMA向联邦法院提起诉讼：1005项违规指控，最高罚款敞口超2.5亿澳元 |

（注：4例死亡中，8周大男婴的死亡后被警方认为与断网无关；截至ACMA起诉时，公开报道口径为“与断网相关的死亡2人”。）

```text
timeline
    title 从一条变更到2.5亿澳元诉讼
    section 2025-09-18 断网日
        刚过午夜 : 防火墙变更实施<br/>指令有误，网关被锁
        凌晨~午后 : 000呼叫被阻断近14小时<br/>普通语音迂回恢复掩盖了故障
        14:30 : 危机管理机制才激活
        13:50之后 : 回退变更恢复<br/>发现问题耗时约13小时
        20:00 : 才确认约100例失败呼叫
    section 2025-09-19~20
        17:30 : 先开发布会<br/>州长之后才获通报
        次日 : 4例死亡纳入调查<br/>最终确认相关2人
    section 2025-12-18
        Schott报告发布 : 21条整改建议<br/>直指外包失控与组织孤岛
    section 2026-07-30
        ACMA起诉 : 1005项违规指控<br/>最高罚金超2.5亿澳元
```

## 三、根因深挖：真正的问题是“发现不了故障”

干了十几年核心网的人都明白：**割接出点差错不稀奇，稀奇的是差错能存活13个小时而无人察觉。** Schott报告把这次事故的失败拆成了至少十层叠加的错误，比防火墙本身更值得复盘的是检测与升级链路的全面失灵。

**第一层：变更管理形同虚设。** 给供应商的指令写错了，供应商没有质疑、照单执行，执行前没有做应急呼叫打通验证（或者验证了没被当回事）。一个涉及语音网关承载面的防火墙变更，竟然没有被强制要求做“000测试呼叫通过”这样的准出检查项。

**第二层：失败呼叫没有可观测性。** 000呼叫失败在这张网上**不产生任何有效告警**——用户拨了、被防火墙丢了、什么痕迹都没留下来。报告建议5专门要求“加快建设可更快追踪语音和000失败呼叫者细节的系统”，说明事故当时Optus连“哪些呼叫失败了”都要事后慢慢倒查。直到当晚8点才确认100例失败呼叫，就是这个能力缺失的直接后果。

**第三层：呼叫中心与网络两张皮。** 断网期间有5位用户打进Optus客服抱怨电话打不出去，客服按标准流程排查用户侧问题，因为没有人告知他们网络正在故障，这5次宝贵的前哨预警被全部浪费。这暴露的是组织孤岛（silo）问题：信息在公司内部流不动。

**第四层：危机管理迟钝、通知顺序颠倒。** 14:30才启动危机管理，且信息粒度粗糙；两名高管等待“更准确的信息”，但他们掌握的信息竟然与网络团队不同步；先开发布会、后通知州政府——公共沟通的优先级被排在了政府应急协同之前，这在政治层面引爆了Optus的信誉危机，总理都公开表示“Optus可能要有人头落地”。

**第五层：为什么多数手机没能“跳网”求生？** 这是技术层面最扎心的问题。按设计，本网打不通000时，终端应当重新选网（camp-on）到其他运营商网络完成紧急呼叫。但报告发现：设备camp-on通常需要40~60秒——紧急情况下人们往往等不了这么久；**同一型号的设备，有成功跳网的也有失败的**，行为不一致；而且2G/3G退网后，原本依赖旧制式的应急呼叫路径也没了。Optus事后把“应急超时”机制调整到了600秒，报告还专门建议持续监测这个值是否合适。这给全行业提了个醒：**VoLTE时代，应急呼叫的“最后防线”必须被实测验证，而不是默认它存在。**

```mermaid
flowchart TD
    A[例行防火墙升级变更单] --> B[Optus下达错误指令给诺基亚]
    B --> C[诺基亚照单执行<br/>Regents Park网关被锁]
    C --> D[普通语音: 迂回路由恢复<br/>话务指标正常, 告警沉默]
    C --> E[000应急呼叫: 持续被拦截<br/>失败呼叫无告警无监测]
    E --> F[5起用户投诉进呼叫中心<br/>不知情, 未升级]
    E --> G[无失败000实时追踪能力]
    F --> H[故障存活约13小时]
    G --> H
    H --> I[回退变更, 网络恢复]
    H --> J[危机管理滞后14:30才启动]
    H --> K[先开发布会后通知政府<br/>信誉二次崩塌]
```

## 四、Schott报告：21条整改，刀刀砍向组织而非设备

2025年12月18日发布的独立审查（主持人：Dr Kerry Schott）共21条建议，覆盖网络、呼叫中心、000系统、公司治理、对外通报和董事会六个层面。剥离细节，主线有四条：

1. **把外包出去的能力收回来。** 报告罕见地直接点名：Optus将网络运维和呼叫中心大量外包（含离岸）后，**失去了对关键作业的有效控制**，是"loss of control"式事故的温床。整改方向包括“尽快把整个运维中心（Operations Centre）迁回本土”（建议3）、呼叫中心部分7×24职能回迁（建议7），以及重新审视“零和式”供应商合同管理——对复杂关键业务，对抗式合同只会让供应商“照单执行”而不是“发现问题就喊停”。董事长Scott Perkins随后放话：相关责任人可能面临解雇和经济处罚。

2. **重建三道防线。** 报告认定网络条线的第一道风险防线在事故中“不可见”（not evident），第二道（内控风险团队）资历能力不足，第三道（内审）需要加强。这是很典型的“业务跑在风控前面”的大公司病。

3. **演练，而不是文件。** 事故和危机管理流程虽然刚刚更新，但报告强调网络部门需要的是**演练和实战推演**——尤其要学会判断“什么时刻应该把本地处理的网络事件上交公司级管理”。例行事件演变成需要全公司协同的危机，是这个行业最经典的黑天鹅剧本。

4. **000系统需要行业级改革。** 包括配合政府与监管研究终端跳网行为（建议8）、研究000数据化改造（建议9）、推动全行业开展“用户自测手机能否打通000”的倡议（建议10）。事故暴露的不是一家运营商的洞，而是整个应急呼叫体系的代际欠账。

## 五、监管重拳：从1200万和解到2.5亿诉讼

| 对比项 | 2023年11月全国断网 | 2025年9月000断网 |
|---|---|---|
| 影响范围 | 全国超1000万用户 | SA/WA/NT/西NSW应急呼叫 |
| 持续时间 | 约12小时（数据+语音） | 近14小时（000阻断） |
| 死亡关联 | 无 | 确认相关2人 |
| 执法方式 | 侵权通知（infringement notices）和解 | 联邦法院正式诉讼 |
| 罚款金额 | 超1200万澳元 | 指控1005项违规，单项最高25万澳元，敞口超2.5亿澳元 |
| 附加后果 | CEO Kelly Bayer Rosmarin辞职 | Schott报告21条整改、责任人或被解雇 |

ACMA主席Nerida O'Loughlin的表态说得很直白：**“2023年断网后这么快又发生一次影响应急呼叫的重大故障，正是ACMA决定直接上法院的原因之一。”** 从合规视角看，这次指控依据的是《1999年电信（消费者保护与服务标准）法》下的《2019年应急呼叫服务裁定》第15条（赋予用户应急呼叫接入）和第19条（确保呼叫被传送至终接点）两项义务，各被指控违反1005次——监管把“每一通失败的呼叫”都变成了独立的违规计数，这个执法思路本身就值得所有运营商法务和网优部门研究。

一个耐人寻味的注脚：就在ACMA起诉Optus前几周，Telstra也发生了一次影响支付、铁路和部分000呼叫的大故障，根因是一台**约20年机龄、价值约3万澳元、一直没被替换的时间同步服务器**，同样面临最高3000万澳元的处罚风险。澳大利亚监管对“应急呼叫可用性”的执法强度，已经进入顶格时代。

## 六、给国内同行的六条镜鉴

这起事故如果发生在国内语境下，对应的可能是一次“防火墙策略下发错误导致IMS接入侧信令被拦截”的应急呼叫故障。以18年核心网运维的经验看，有六条是可以直接抄回去落地的：

1. **涉及语音承载面的防火墙/ACL变更，准出检查必须包含端到端应急呼叫测试**（本网110/119/120模拟拨打+异网跳网验证），而不是只看策略命中数和CPU；
2. **给供应商的变更指令要有双人复核+供应商确认闭环**——“指令错了、厂商照做”这个链条上，双方都默认对方校验过；
3. **失败呼叫必须可观测**：应急呼叫的接通率要从信令面（SIP响应码分布、被网关丢弃计数）单独监控并设独立门限，不能混在普通语音接通率里被平均掉；
4. **客服热线是故障发现的传感器**：建立客服工单关键词（“打不出电话”" SOS"“打不通110”）向网络值守的分钟级推送通道，5起投诉就是5次机会；
5. **外包不免责**：离岸运维可以降本，但变更审批权、应急决策权必须留在有授权、懂现网的自有团队手里；
6. **终端跳网能力要定期路测**：2G/3G退网后，紧急呼叫的兜底机制依赖终端行为，每年至少做一轮跨品牌、跨价位的真机实测，把“默认它好着”变成“证明它好着”。

## 结语

Regents Park那台被锁死的网关，13个小时里拦下的不只是455通电话，还有一家公司十几年积累的信誉，以及2.5亿澳元的诉讼敞口。复盘到最后一层你会发现：防火墙只是扳机，真正扣动扳机的，是失效的变更管控、沉默的告警体系、流不动的内部信息，和一段失去控制的离岸外包链条。**网络故障从不可怕，可怕的是故障发生时，整个组织对此一无所知。** 这20个字，值得每一位运维管理者抄在值班室的墙上。

## 参考来源

1. [ACMA takes Optus Mobile to court over September 2025 Triple Zero outage](https://www.acma.gov.au/articles/2026-07/acma-takes-optus-mobile-court-over-september-2025-triple-zero-outage) — ACMA官方公告：1005项违规指控、法律依据与最高罚则
2. [Independent Report: The Triple Zero Outage at Optus, 18 September 2025 (PDF)](https://www.optus.com.au/content/dam/optus/cloud/documents/about-us/media-centre/speeches-and-reports/2025/Independent_Report_Triple_Zero_Outage_at_Optus_18_September_2025.pdf) — Schott独立审查报告全文：605次呼叫、150人接通等核心数据
3. [Optus Triple Zero outage report reveals internal company failures](https://www.techguide.com.au/news/mobiles-news/optus-triple-zero-outage-report-reveals-internal-company-failures-and-emergency-calling-system-faults/) — 21条整改建议全文及诺基亚指令错误、Regents Park网关等细节
4. [Optus faces $250m Triple Zero lawsuit — Information Age (ACS)](https://ia.acs.org.au/article/2026/optus-faces--250m-triple-zero-lawsuit.html) — 诉讼背景、通信部长表态及Telstra时间同步服务器故障对比

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