# 防火墙升级，放倒澳洲急救线：Optus「三重零」故障深度复盘 ## 概述 2025年9月18日，澳大利亚第二大运营商Optus发生全国性紧急呼叫故障：一次凌晨执行的数据中心防火墙例行升级，导致其移动网用户的「三重零」（000）求救电话大面积无法接通，异常持续约十几个小时，数百通呼叫失败，澳媒与议会听证披露至少3起死亡事件与拨不通000直接相关。事故的直接诱因，恰恰是Optus为整改2023年11月那场持续13小时全国断网而启动的网络加固工程。本文以ACMA（澳洲通信与媒体管理局）调查通报与Optus官方声明（[acma.gov.au](https://www.acma.gov.au)、[optus.com.au/about/media-centre](https://www.optus.com.au/about/media-centre)）为主轴，结合澳媒与议会听证的公开信息，复盘这起「修上次的病，得这次的病」的典型事故：时间线、根因、影响、处置与整改，以及留给所有网络工程师的教训。 ## 目录 - 一、事故全景：000打不通的一天 - 二、根因解剖：一次防火墙升级如何演变成全国事故 - 三、影响评估：几百通没打通的求救电话 - 四、处置过程：从回退变更到CEO离任 - 五、连锁反应：监管、议会与全行业的紧急呼叫整顿 - 六、四年事故对照：同样的剧本为何反复上演 - 七、工程师视角：八条带血的教训 - 结论 ## 引言：为什么这次事故值得复盘 通信行业的故障复盘文章很多，但大多数断网事故的代价是「不方便」：上不了网、刷不了视频、扫不了码。而Optus这次不一样——**打不通的电话，是求救电话**。 000是澳大利亚的全国紧急呼叫号码（相当于国内的110/119/120合一，官方称Triple Zero，三重零）。它由Telstra运营的紧急呼叫服务中心（Emergency Call Service，ECS）统一接听，再按位置分转警察、消防或救护。这个体系的铁律是：**任何运营商的网络，都必须无条件保障紧急呼叫优先、可靠接通**。这是写入监管规则的红线，也是全球电信业的共识——3GPP规范里，紧急呼叫（Emergency Call）在接入层拥有最高接入等级（AC 10），网络拥塞时也要优先放行。 正因如此，当Optus的用户在2025年9月18日那天拿起手机拨000、听到的却是忙音或无法接通时，这已经不是一次普通的网络故障，而是一起动摇行业根基的事故。更讽刺的是：压垮它的不是什么从未见过的黑天鹅，而是一次**计划内、走流程、为了整改上一次事故而做的防火墙升级**。 ## 一、事故全景：000打不通的一天 先看事件时间线。以下整理自Optus事后通报、ACMA立案信息与澳媒持续报道（具体到分钟的时刻各家报道略有出入，以官方最终通报为准）： | 时间（2025-09-18，澳洲东部时间） | 事件 | |---|---| | 凌晨（约4时前后） | Optus在计划维护窗口内对某数据中心防火墙执行例行升级 | | 凌晨升级完成后 | 防火墙行为异常，移动网发往紧急呼叫服务中心的000呼叫接续开始大面积失败 | | 清晨至上午 | 用户开始大量拨打000失败；故障在数小时后才被确认为全国性事故并对外通报 | | 白天 | Optus应急团队排查，逐步将问题锁定在当夜防火墙变更；紧急处置方案讨论与回退准备 | | 晚间（约21时～22时间） | 回退生效，000呼叫恢复正常，Optus对外确认故障排除 | | 随后数日 | Optus启动逐单回拨核实；ACMA立案调查；联邦政府宣布对紧急呼叫体系启动独立审查 | | 随后数周至数月 | 参议院听证会传唤高管；Optus高层人事变动；全行业紧急呼叫保障整改启动 | 这次故障的特殊性在于影响面：它没有让用户「断网」——刷微信（如果他们用的话）、看视频可能一切正常，移动网的其他业务大体运行。坏的只是那一类呼叫：**打给000的电话**。也就是说，这是一个「窄而致命」的故障，业务影响面（流量的比例）极小，但后果等级极高。很多运维团队的价值排序里，故障按「影响的流量/用户数」排优先级，这次事故把另一把尺子拍在了所有人面前：**按业务的关键性排**。 ## 二、根因解剖：一次防火墙升级如何演变成全国事故 ### 官方披露的事实 据Optus事后声明，事故根因是：**当夜对某数据中心防火墙进行的例行升级，升级后设备行为与预期不符，阻断了移动网用户呼叫000的接续路径**。换句话说，变更本身是获准执行的常规操作，问题出在变更后的效果与验证环节——升级后的防火墙没有放行（或正确处理）通往紧急呼叫接续方向的话务，导致呼叫失败。 Optus没有（至少在公开层面没有）披露防火墙内部的具体故障机理，这在重大事故里并不罕见——完整技术细节通常只会出现在监管最终报告或内部复盘里。但从移动网络的结构出发，工程师可以还原出大致的故障链，以下是**基于公开信息的工程推断**，非官方结论： ### 故障链的工程还原 手机拨打000，在移动网里不是一次普通被叫。终端会在呼叫建立请求中带上紧急呼叫指示，网络识别后将话务路由至紧急呼叫专用的接续通道，最终送到Telstra运营的紧急呼叫服务中心。这条路径要穿越核心网的信令面和媒体面，而现代运营商的这些流量普遍要经过安全设备——防火墙、SBC（会话边界控制器）之类的边界网元。 这带来一个关键认知：**防火墙在紧急呼叫路径上，是一个「一票否决」的串接点**。它放行了，呼叫通；它状态异常、策略不匹配、会话表满，或者升级后对新信令流程处理不当，呼叫就死。而且这类故障非常隐蔽——普通上网、普通通话可能完全不受影响，唯独紧急呼叫这种低频、特殊信令流程的业务路径被卡住。凌晨升级、清晨用户才开始拨000，意味着**故障从发生到被「人肉感知」，中间隔着好几个小时的天然空窗**——这段时间里，恰好是深夜到清晨，紧急呼叫的需求密度最低，但每一通都是人命。 ```mermaid flowchart TD A["凌晨维护窗口：防火墙例行升级"] --> B["升级后防火墙行为异常"] B --> C["紧急呼叫接续路径被阻断"] C --> D["000呼叫失败或异常中断"] E["低频业务缺乏分钟级拨测"] --> F["故障确认时间被大幅拉长"] D --> F F --> G["上午确认全国性故障并对外通报"] G --> H["锁定变更并执行回退"] H --> I["晚间呼叫恢复正常"] ``` ### 三个叠加的管理失守 单看技术，这是一次「升级翻车」。但把它放进运维管理的框架里，至少有三层防线同时失守： **第一层：变更验证没有覆盖紧急呼叫。** 任何接入紧急呼叫路径的设备升级，验证清单的第一条就应该是「拨一通测试000确认接通」。这通电话成本几秒钟，但它验证的是最高优先级业务。事后参议院听证会上被反复追问的正是这一点——变更完成后，没有人立刻验证过一通真实的000呼叫。 **第二层：监控没有把紧急呼叫单独设防。** 运营商的KPI体系里，掉话率、接通率、时延都有大盘监控，但大盘是被海量普通呼叫稀释的。000呼叫全天占比极低，混在大盘里根本激不起告警浪花。紧急呼叫接通率必须是一条独立红线：**失败一通，就应该是最高级别的告警**，而不是等统计周期出报表。 **第三层：故障确认被「窄故障」特性拖延。** 上文说过，这个故障不影响普通业务，用户感知集中于「打000打不通」这一件事，投诉形态分散、不易汇聚成 clearly 的故障画像。运维值班面对的是零散的用户反馈，而不是铺天盖地的断网告警——识别「这是全国性事故」的时间被拉长了。据澳媒报道，从凌晨异常到上午对外确认，中间隔了好几个小时。 ### 最讽刺的部分：这次变更，是上一次事故的整改产物 复盘这起事故，绕不开它的前情：2023年11月8日，Optus发生全国大断网，约1000万用户断网约13小时，据ACMA调查通报，期间有超过21万通000呼叫失败。那场事故的根因是例行软件升级后，边界网关设备与核心网重连时遭遇消息风暴，触发设备自我保护进入隔离状态。 那次事故之后，Optus启动了大规模网络加固与整改工程——而2025年9月18日这场防火墙升级，正是这条整改工作流上的一环。**为了不再断网而做的加固，制造了一场更严重的事故。** 这不是Optus独有的悖论，而是整个运维行业的经典困境：事故驱动的整改自带「急、密、叠」三重属性——急于出成效、变更密集排期、多层安全措施叠加部署——每一层新防线在成防线之前，都先是新的风险面。 ## 三、影响评估：几百通没打通的求救电话 评估这次事故的影响，流量数字毫无意义，真正要数的是「没打通的求救电话」。 据Optus事后逐单回拨核实并向监管与议会披露的数据，本次故障期间000呼叫失败达数百通量级（澳媒广泛报道的数字是超过600通）。Optus逐一回拨核实呼叫人处境，这一过程本身持续了数周。而最沉重的部分是：**至少3起死亡事件，在议会听证与官方程序中被认定与000无法接通直接相关**——据澳媒报道，死者家属在紧急情况下反复拨打000未能接通，救援延误。另有个案仍在尸检官认定程序中，最终数字以官方结论为准。 一个谨慎的工程师应该从这组数字里读出概率的残酷：600通失败呼叫，不是600个「错误」，而是600次「求救被系统静默丢弃」的独立事件，每一通背后都是一个小概率但后果无限的场景。这就是紧急呼叫业务和一切其他业务的本质区别——**它的失败率没有「可接受阈值」可言**。 业务之外，还有三层影响： - **监管与法律**：ACMA随即立案，审查Optus是否违反《紧急呼叫服务裁定》（Emergency Call Service Determination）。值得注意的是，Optus在2023年事故中因未履行紧急呼叫警告等义务已被联邦法院判罚（据ACMA通报，罚金1200万澳元）——一年多后再次因紧急呼叫问题被立案，属于「累犯」，按2022年修法后的罚则框架，罚金上限与营业额挂钩，可达千万澳元级甚至更高。 - **政治层面**：联邦政府宣布对全国三重零体系启动独立审查；参议院相关委员会召开听证会，Optus高管两次到会接受质询。紧急呼叫保障从企业技术问题上升为公共治理议题。 - **品牌层面**：Optus在2022年刚经历过近千万用户数据泄露，2023年大断网，2025年又出人命事故——三年三连击。CEO Stephen Rue在事故后的议会质询风暴中宣布离任（据Singtel与澳媒报道）。 ## 四、处置过程：从回退变更到CEO离任 把Optus和监管在事故后的动作按顺序排开，是一次完整的「事故响应+问责+整改」教科书样本，值得每家运营商对照。 **应急阶段（当日）**：定位变更→执行回退→确认业务恢复。这一段Optus做得中规中矩——故障的「可回退性」是万幸，如果升级造成了不可逆的配置损坏，恢复时间会以天计。 **补救阶段（数日到数周）**：这是本次事故处置里最特别、也最应该被写进行业教材的一步——**逐单回拨**。Optus调出故障时段所有失败的000呼叫记录，逐一回拨核实呼叫人身份与处境、是否已通过其他途径获得救援。对仍处于危险中的个案，立即补送救援。数百通电话逐一打过去，这个动作在工程上不复杂，在组织上却需要巨大决心——它等于官方逐条确认事故的伤害清单，每一通电话都可能面对一个愤怒或悲痛的家庭。但反过来说，没有这个动作，伤害评估就永远是一堆匿名CDR记录。**故障的止损不止于网络恢复，还包括把业务侧已经造成的伤害逐一接住。** **问责与整改阶段（数周到数月）**：据公开信息，Optus的动作包括——暂停同类防火墙变更并全面复核、引入外部机构对变更管理与紧急呼叫保障流程做独立审计、公开承诺整改清单、对受影响用户推出补偿方案。人事层面，CEO离任（据报道），高管层调整。监管层面，ACMA的调查按程序推进，最终处罚与整改决定以官方公布为准（截至本文完稿，笔者未见该案最终处罚金额的官方通报）。 **行业层面**：值得特别记一笔的是，2026年初，另一家澳洲运营商TPG也披露了因网络变更导致部分000呼叫短时受阻的故障（据当地媒体报道）。这不是Optus的孤例，而是暴露了全行业在「变更管理×紧急呼叫」这个交叉点上的系统性薄弱。随后，围绕紧急呼叫的强制拨测、旁路机制、更快的外部通报义务，成为监管与行业讨论的共同议题。 ## 五、连锁反应：监管、议会与全行业的紧急呼叫整顿 把镜头拉远，这次事故的后续影响已经超出Optus本身，塑造着澳大利亚电信监管的走向： 其一，**独立审查直指体系而非单点**。政府委托的审查不仅问「Optus哪里错了」，更问「三重零体系作为一个整体，为什么能让一家运营商的故障静默数小时」。这触及一个结构性问题：000的接听由Telstra统一承担，但故障发生在各家接入运营商的网络里——**跨运营商的紧急呼叫链路，谁来端到端监控？谁来在故障发生的第一时间发现？** 目前的答案是「没有谁」，各运营商自扫门前雪，而紧急呼叫的低频特性让「门前」也扫不干净。 其二，**强制性的工程保障措施进入讨论**。方向大致包括：所有涉紧急呼叫路径的变更必须先验证测试呼叫；紧急呼叫接通率作为实时红线指标；部署独立的7×24紧急呼叫自动拨测（synthetic call testing），从各区域发起真实测试呼叫；故障时向监管与ECS的通报时限义务。这些措施单看都不新颖——拨测机器人、红线告警是成熟工具——难的是强制所有运营商落地并接受审计。 其三，**变更管理的监管化趋势**。传统上，变更管理是运营商的内部流程，监管管结果不管过程。但当「过程失守」反复直接导致人命事故，监管介入过程只是时间问题。可以预期的方向是：对最高风险等级变更（涉及紧急呼叫、核心信令）引入报备或评估要求。对运营商运维团队来说，这意味着变更管理从「内部纪律」变成「合规义务」，流程的每一个环节都要经得起外部检查。 ```mermaid timeline title Optus 三重零事故与行业连锁反应 section 2025年9月18日 凌晨 : 防火墙例行升级在维护窗口执行 升级后 : 000呼叫接续大面积失败 上午 : 确认全国性故障并对外通报 晚间 : 回退生效 呼叫全面恢复 section 事故后数周 监管 : ACMA立案调查 政府启动独立审查 补救 : 逐单回拨核实失败呼叫 质询 : 参议院听证会传唤高管 section 事故后数月 人事 : CEO宣布离任 管理层调整 整改 : 同类变更冻结 外部审计 整改清单 行业 : TPG披露同类故障 全行业紧急呼叫保障整顿 ``` ## 六、四年事故对照：同样的剧本为何反复上演 把近年几起标志性重大故障放在一张表里对照，会看到一个令人不安的重复模式——**几乎所有让运营商伤筋动骨的事故，都发生在「计划内变更」上，而不是发生在意料之外的外部攻击或硬件老化上**： | 事故 | 时间 | 影响面 | 直接根因 | 持续时长 | 关键教训 | |---|---|---|---|---|---| | Rogers 全国断网（加拿大） | 2022-07 | 约1200万用户，影响金融支付 | 核心网维护中配置变更失误，路由器与核心网失联 | 约19小时 | 核心网变更需分域隔离与独立逃生通道 | | Optus 全国断网（澳大利亚） | 2023-11 | 约1000万用户，逾21万通000失败 | 例行升级后边界网关重连消息风暴，设备自我隔离 | 约13小时 | 重连风暴防护与紧急呼叫警告机制缺失 | | AT&T 全国断网（美国） | 2024-02 | 数千万用户语音受影响 | 核心网设备软件升级操作失误 | 约12小时 | 变更执行过程管控与快速回退能力 | | Optus 三重零故障（澳大利亚） | 2025-09 | 000呼叫大面积失败，多人死亡与延误相关 | 防火墙升级后阻断紧急呼叫接续 | 约十余小时 | 低频关键业务必须独立监控与强制拨测 | 四起事故，四个国家/场景，根因惊人一致：**计划内变更，执行后与预期不符，且故障都未在第一时间被发现**。Rogers断网后行业喊了三年「变更要隔离」，2024年AT&T照栽，2025年Optus接着栽。剧本不变的原因也很清楚：变更之于网络，就像手术之于病人——所有人都知道风险，但没有人能不做。真正的分水岭不在「做不做变更」，而在**变更失败后，系统要多长时间才能告诉运维团队「你刚才做错了」**。Rogers用了以小时计的痛苦才确认，Optus这次的000故障同样是以小时计——每一次「以小时计」，背后都是设计上的缺口。 ## 七、工程师视角：八条带血的教训 最后收敛成可执行的经验清单。以下每一条，都能在这次事故里找到对应「学费」： 1. **紧急呼叫是变更验证的第一科目，不是附加项。** 凡变更涉及紧急呼叫路径上的网元（边界安全设备、信令面、路由策略），验证清单第一条必须是真实测试呼叫。测试要覆盖各接入方式（移动、固网、受限终端）。 2. **给低频关键业务装「分钟级拨测」。** 000这类业务的特征是：低频、关键、用户反馈形态分散。唯一能在故障发生后几分钟内拉响警报的，是从全网各区域持续发起测试呼叫的拨测系统。没有它，你的平均故障确认时间（MTTD）就只能依赖用户投诉的「人肉汇聚」。 3. **紧急呼叫指标独立设红线。** 接通率大盘会稀释一切小样本业务。紧急呼叫接通率要单独建指标、单独设告警等级：异常一通即触发人工介入。 4. **安全设备视同核心网元管理。** 防火墙在紧急呼叫路径上就是串接的「一票否决」点，其变更风险等级应等同核心网割接，享受同等级的评审、灰度、回退预案待遇——而不是被归在「IT安全设备例行维护」里降低警觉。 5. **回退预案要与变更同步演练。** 这次万幸回退有效。回退预案必须在变更前明确：回退动作、执行人、决策时限、验证手段。超过回退时限仍不奏效，就升级到灾备方案，而不是在原路上继续耗。 6. **窄故障要有专项识别手段。** 不影响大盘、只打掉单一业务的「窄而深」故障，最难确认。建立跨域工单关联：当多个不相关渠道（客服、微博、110转办）出现同主题反馈时，自动触发故障研判，而不是等值班人员人肉拼图。 7. **变更排期要给整改项目「减密度」。** 事故驱动的大规模整改期，是网络最脆弱的时期——变更密集、并行、叠加。整改项目自身的变更密度要纳入容量管理，宁可拉长工期，也要保住「任何时刻在网变更总量可控」的底线。 8. **事故止损的终点是业务伤害清零，不是网络恢复。** 逐单回拨核实是本次处置的亮点：网络恢复只是止损的第一步，把故障已在业务侧造成的伤害逐一接住、逐一补救，才算处置闭环。这条对运营商、对云厂商、对任何关键服务提供者都成立。 ## 结论 Optus这次事故没有华丽的外因：没有攻击者，没有硬件批量老化，没有极端天气。它就是一次凌晨的、走了流程的、为了整改上一次事故而做的防火墙升级。这恰恰是它最值得复盘的地方——**当一家运营商连「认真整改」都能整出人命事故时，说明问题不在某个具体环节，而在整个「变更-验证-监控-响应」链条对关键业务的基本假设**。 所有运维团队都该问自己一个问题：如果今晚凌晨三点，我在这台防火墙上按下了升级按钮，一通从悉尼郊区打出的求救电话会经过什么？谁能保证它通？如果它不通，几分钟内会有人知道？ 答不上来，就说明下一场Optus式的事故，只是还没有轮到你的网络而已。 ## 参考来源 1. [ACMA 澳大利亚通信与媒体管理局官网](https://www.acma.gov.au) — 本文主轴来源：ACMA对Optus三重零事故的调查立案通报、2023年断网调查结论与处罚通报（站内检索 Optus triple-zero 可获取原文） 2. [Optus 官方新闻室](https://www.optus.com.au/about/media-centre) — Optus对事故根因、处置过程与整改承诺的官方声明入口 3. [The Guardian Australia](https://www.theguardian.com/australia-news) — 对事故时间线、失败呼叫数据、死亡个案与议会听证的持续追踪报道（站内检索 Optus triple zero） 4. [ABC News（澳大利亚广播公司）](https://www.abc.net.au/news) — 事故后续、独立审查启动与TPG同类故障的公开报道 5. [Wikipedia: Optus](https://en.wikipedia.org/wiki/Optus_(Australia)) — Optus历年重大事故（2022数据泄露、2023断网等）的时间线梳理 > 注：文中具体时刻、失败呼叫数量等数据以ACMA最终调查报告与Optus官方通报为准；个别数字在澳媒报道间存在出入，本文已按「据xx报道」方式标注。 --- > 本文由「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 等场景全覆盖。