## 概述 2025年9月18日凌晨，澳大利亚运营商Optus在南澳Regency Park局所做一次例行的防火墙升级，因操作方案漏掉了「先卸载话务再锁定网关」这一步，导致南澳、西澳、北领地和新南威尔士州部分地区的000（Triple Zero）紧急呼叫中断约14小时：605个号码拨号受阻，455通完全没接通，事件最终关联两条人命。本文以澳大利亚参议院调查报告和Schott独立审查报告为轴，逐帧复盘这14小时：变更是怎么走样的、三条告警为何无人处置、恢复之后为什么又拖延了一天半才对外通报，以及这份账单最终开给了谁。 ## 目录 - 事件：一通打不通的求救电话 - 精确到分的时间线 - 根因链：十处失误如何叠加 - 为什么十四小时没人发现 - 影响评估：605个号码与两条人命 - 追责与整改：从Schott报告到联邦法院 - 给运维人的五条教训 - 结语 ## 事件：一通打不通的求救电话 在澳大利亚，紧急电话不拨911也不拨112，拨000，官方叫法是Triple Zero。整个国家的规矩是：任何一张网上的任何一部手机，任何时候都必须能打通紧急电话——这写在运营商的法定义务里，由Telstra担任全国的紧急呼叫接续方（Emergency Call Person），其他运营商的紧急呼叫最终都要汇到它那里。 2025年9月18日凌晨0点，Optus委托诺基亚，在南澳阿德莱德的Regency Park局所实施一次防火墙升级。这本是例行工程：从2025年4月开始，Optus在多个州分批升级IX局所的网络管理防火墙，Regency Park之前已有六台防火墙顺利割接完毕。没人想到，第七台会出事。 0点17分，升级中的Soft Lock（软锁定）流程启动。锁定网关本该先把话务引流到别的路径，但这次没有——00:17起，经该局所汇接的000呼叫开始失败，第一通打不通的求救电话出现在不到一分钟之后。此后14个小时，南澳、西澳、北领地以及新南威尔士州边境小镇Broken Hill（话务经南澳局所汇接，同样中招）的Optus用户，拨000要么听不到任何回应，要么被无声掐断。 普通语音呼叫反倒没事。它们被网络自动迂回到其他局所，全程无感。受影响的只有紧急呼叫——因为在Optus网内，000走的是一套独立的紧急呼叫处理系统，恰恰从这台被锁住的网关过。最要命的通信，走的是最脆弱的那条路。 这一天，有人摔伤、有人突发疾病、有位八周大的男婴家人抱着手机一遍遍重拨。电话那头，一片死寂。 ## 精确到分的时间线 参议院调查报告附录里有一份以分钟计的大事记，串起来看比任何分析都震撼： | 时间（2025-09-18，AEST） | 事件 | |---|---| | 9月3日–17日 | Optus与诺基亚共同规划Regency Park防火墙升级 | | 9月16日 | Optus下达指令：对SBG加锁；未明示EPG流量卸载 | | 9月17日 | 诺基亚定稿MOP；标记为「紧急变更、风险等级零」 | | 00:00 | 诺基亚开始实施升级 | | 00:17 | Soft Lock启动，话务未引流，000呼叫开始失败 | | 00:18前后 | 第一通000呼叫失败 | | 00:20–01:00 | 三条内部告警先后触发，均未被处置 | | 02:10 | 执行Hard Lock，强拆全部活动会话 | | 02:40前后 | 实施后检查，未发现000异常 | | 10:13–12:27 | 海外客服中心接到4通用户反映000打不通 | | 11:40 | 电信业申诉专员（TIO）收到首起投诉并转Optus | | 13:14 | 南澳救护服务（SAAS）致电Telstra的000中心核实 | | 13:17 | Optus经SAAS第二通电话首次意识到故障 | | 13:51 | Optus宣布重大事件（Major Incident） | | 14:20 | 指示诺基亚解锁SBG | | 14:31 | 最后一通失败的000呼叫 | | 14:34 | 确认恢复正常 | | 19:50 | 才成功提取出第一批100条失败呼叫记录 | | 20:34–21:01 | 首轮关爱回访，发现两起死亡（20:43、21:01） | | 9月19日 08:13 | CEO Stephen Rue才得知出现死亡 | | 9月19日 14:36 | Rue致电ACMA主席：600余通失败、3人死亡 | | 9月19日 17:45 | 首次公开新闻发布会 | | 2025-12-18 | Schott独立审查报告发布 | | 2026-07-30 | ACMA在联邦法院对Optus提起诉讼 | 两个细节值得每个运维人盯着看久一点。第一，从故障发生到Optus自己知道，隔了13个小时；可这13个小时里，告警响了、用户打了电话、申诉专员转了投诉——所有信号都到了，只是没人把它们连起来。第二，恢复之后的事情并没有变快：诺基亚下午3点48分交来的话单（CDR）里居然查不到任何失败记录，Optus的工程师只能另起炉灶开发新的提取方法，晚上7点50分才拿到第一批100条失败呼叫清单——而关爱回访（welfare check，逐户确认打电话的人是否安好）要等这份清单才能开始。 ## 根因链：十处失误如何叠加 Schott独立审查在报告里数出了至少10处失误。它们单独看都不致命，串成一条链，就是一场人命关天的故障。 ```mermaid flowchart TD A["4月起: IX防火墙批量升级"] --> B["9月8日评审会
核心网工程师缺席"] B --> C["9月16日指令:
只写锁SBG 未写EPG卸载"] C --> D["9月17日: 诺基亚选定
不含EPG卸载的MOP"] D --> E["三人互审
没人发现缺了关键步骤"] D --> F["标记为紧急变更
风险等级: 零"] F --> G["跳过Optus风险评估
与变更委员会审批"] G --> H["9月18日00:17
Soft Lock启动"] H --> I["话务未引流即隔离
000呼叫全部失败"] I --> J["紧急呼叫失败率
超10%的自动告警"] J --> K["邮件只在内部转发
无人处置"] H --> L["02:10执行Hard Lock
强拆全部会话"] L --> M["实施后检查
未覆盖000拨测"] M --> N["故障持续约14小时
至14:34才恢复"] ``` **第一处断点：指令含糊。** 9月16日，Optus给诺基亚下达变更指令，要求对一台会话边界网关（SBG）加锁，目的是把防火墙从网络里隔离开再动刀。锁SBG意味着掐断经它接续的呼叫，所以锁之前必须先把话务从演进分组网关（EPG）上卸载引流。Optus的工程师默认诺基亚「自然会做」，指令里没写。诺基亚的工程师严格按指令办事——他们后来说得很直白：「我们被明确要求做SBG锁定，我们就选了做这件事的MOP，这个方法过去也成功过。」 **第二处断点：评审会缺人。** 9月8日的变更范围评审会，Optus核心网工程团队有几名该到场的工程师没到场。Schott审查认为，这正是指令不够准确的重要原因——最懂这台设备话务流向的人，没参与最该他说话的会。 **第三处断点：MOP选错。** 诺基亚9月17日定稿的作业方案（MOP，Method of Procedure）不含EPG卸载步骤。方案在诺基亚内部三人互审，没人发现关键引流步骤缺失，也没人对照此前六次成功割接用的MOP。Optus事后主张这是一份「过时」的方案；诺基亚则坚称这是过去成功执行过的老方法。不管哪方说法成立，事实是：三人互审，零发现。 **第四处断点：风险评级为零。** 这项变更被人工标记为「紧急变更、风险等级零」。零风险意味着什么？意味着Optus侧的风险评估和工程复核被跳过，高级工程师评审和变更顾问委员会（CAB）审批全部免了。一台位于紧急呼叫汇接路径上的网关，一次风险等级为零的变更——事后看荒诞，当时却合规地走完了流程。 于是0点17分，Soft Lock在话务未引流的情况下执行，000呼叫应声而断。凌晨2点10分，诺基亚又执行了Hard Lock——强制拆除所有活动会话、阻断一切新连接——把故障又加深了一层。半小时后的实施后检查照做了，但检查项里没有000拨测。 这场故障里没有设备坏、没有容量崩、没有网络韧性不足。CEO Rue在参议院听证上的原话是：「这不是复杂的系统问题，不是系统失效，不是设备，不是网络缺乏冗余，也不是投资不足。这就是管控措施都在那儿，但确保管控被执行的流程没被执行。」 ## 为什么十四小时没人发现 变更走样只是前半场。真正的悬念是：告警明明响了，为什么13个小时无人问津？ **告警一：诺基亚工程师的KPI曲线。** 故障后一小时内，诺基亚工程师在VoLTE关键性能指标（KPI）图上看到明显尖峰。 **告警二：Optus工程师的性能图。** 几乎同时，Optus侧工程师也观察到呼叫建立失败率、掉话率、呼叫注册失败率升高。他找诺基亚核实，得到的答复是：这是防火墙升级的正常作业活动。一句话，把怀疑挡了回去。 **告警三：那封10%的邮件。** Optus系统自动发出一封邮件，明确写着「VoLTE紧急呼叫失败率超过10%」，收件人包括诺基亚和Optus的多个地址。一名诺基亚员工把它转发给了诺基亚内部的其他团队核实——此后再无下文。参议院报告的表述是：Optus没有该升级被处置的任何记录。 三条告警，三条都是关于「呼叫失败」的，但没有一条被翻译成「紧急呼叫正在失败」。事后查明，Optus的国家级话务量监控体系里，000呼叫压根不在监控范围——官方通报原话：「没有任何告警提醒我们，有些紧急呼叫没能打通。」 上午10点13分起，海外客服中心陆续接到4通用户来电，说000打不通。客服按流程排查「本地故障或终端问题」，没有升级。Schott的评语是「明显不可接受」——既没有预案告诉客服这类投诉意味着什么，也没有通道把「打不通000」这个关键词送到网络部门眼前。11点40分，电信业申诉专员TIO收到投诉，按常规流程邮件转给Optus，处理时限：10个工作日。 直到下午1点14分，南澳救护服务发现联系不上一个从Optus网络拨出的求助者，打电话到Telstra的000中心核实，又连打三通电话给Optus——1点17分，Optus才第一次意识到有事。1点51分宣布重大事件，2点20分指示解锁，2点31分最后一通失败呼叫，2点34分确认恢复。 还有一个常被忽略的技术疑点：按照行业惯例，本网紧急呼叫失败时，手机应当自动「倒灌」（camp-on）到其他运营商的网络发起紧急呼叫—— Telstra、TPG的网在当时都是可用的。但455通完全失败的呼叫里，绝大多数没有倒灌成功。反对党通讯发言人质问：camp-on机制为什么没兜住底？Schott审查坦承，原因尚不完全清楚，可能与终端行为和用户行为有关，「这是行业和政府必须进一步调查的技术问题」。防线二道闸，同样形同虚设。 ## 影响评估：605个号码与两条人命 按参议院报告核定的口径：故障从0点17分持续到14点34分，超过14小时；605个唯一服务号码曾尝试拨打000，其中455通从未接通，其余150通经延迟重拨、camp-on倒灌或其他局所迂回最终接通。 事件最初的通报口径是4起关联死亡：南澳的八周大男婴和68岁女性、西澳的74岁男性和49岁男性（后者由西澳警方回访时发现）。后续出现了重要的修正——Optus向参议院提交的材料中，将关联死亡数确认为2起：警方认定其中2起与呼叫失败无关。南澳警方披露，八周大男婴的初步死因调查表明，即便首次拨号成功，也不太可能改变结局；68岁女性的调查仍在进行，报告将提交州死因裁判官。生命的账，最终以司法口径定案为两条——但任何一条，都足够压垮一家运营商的信誉。 除了人命，还有一场信任的塌方。故障恢复后Optus的处置同样糟糕透顶：2点42分电话通报ACMA时说「只影响固话呼叫」（错）；2点45分给联邦部门的故障通报邮件发到了旧邮箱地址（该部门9月11日已通知换地址，Optus第二天还确认过已完成改造）；3点17分的重大网络故障通报里，日期写成了9月19日。WA州政府直到次日下午——事发超过24小时、Optus已准备好新闻稿之后——才被告知存在可能的关联死亡，而当时Optus只披露了西澳149通失败呼叫中的26通。南澳警察总监不得不亲自致电CEO索要用户名单，第一次拿到的只是「哪些郊区有失败呼叫」。州长Malinauskas的原话：「我们对Optus所说的一切都非常谨慎。」 ## 追责与整改：从Schott报告到联邦法院 事件之后，三组追责平行推进。 **内部：Schott独立审查。** Optus董事会委托Kerry Schott博士牵头独立审查，2025年12月12日定稿、12月18日公开，Optus董事会于12月16日全盘接受全部建议。报告认定故障根因是「隔离Regency Park防火墙前未能引流呼叫话务」，列数至少10处失误；对风险管理体系，Schott的原话毫不留情：「网络业务部门的风险管理之匮乏让我非常震惊——而那几乎是Optus的心脏。」报告还确认了2023年11月Bean审查的建议虽已落实，但半年一次的端到端000拨测频率明显不够。 **监管：ACMA司法追诉。** ACMA于2025年9月22日立案调查，2026年7月30日在联邦法院正式起诉Optus，指控其违反《紧急呼叫服务裁定2019》第15条和第19条——未能为拨打000的用户提供紧急呼叫服务接入、未能确保呼叫被传送至规定的终接点——合计1005次，每次违规最高罚金25万澳元。案件截至参议院报告成文时仍在审理，法院尚未作出认定。算一下上限：1005 × 25万，这是一张2.5亿澳元量级的罚单，虽然实际量刑通常远低于上限，但创纪录没有悬念。 **议会：参议院专案调查。** 参议院环境与通信委员会专案调查，2026年发布报告，用「不可接受」定性整个事件：「如此简单、本可避免的错误，夺走了试图联系紧急服务的人的生命。这不应发生。」 背景板上还站着2023年。2023年11月8日，Optus因一次互联网交换机升级引发路由信息异常、触发路由器过载保护集体脱网，全国约1000万用户、近50万企业断网14小时，其中2697通移动000呼叫未能接通；ACMA 2024年认定其多项违法，Optus累计支付了超过1200万澳元罚款。现任CEO Stephen Rue于2024年11月上任，使命正是「主导组织的根本转型」。两年之后，悲剧换了一种死法重演——2023年输给技术缺陷，2025年输给流程失守。Rue自己在听证上承认：两次事故的共同主题，「也许是我们需要解决的文化」。 同业也未能幸免：据ABC报道，2025年11月18日，TPG Telecom因手机软件老旧问题导致000呼叫受阻，确认至少1人死亡；12月9日又确认蓝山地区另一起故障中可能有第二人死亡。000体系的问题，不是一家运营商的问题。 ## 给运维人的五条教训 十八年核心网和运维一线，我看这份报告的感受不是震惊，是熟悉。每一条断点在哪家没出现过？区别只是别人出了人命，写成了国会报告。 **一、关键变更的MOP，缺一步就是全部。** 三人互审没发现「缺一行」，是因为没人拿上一份成功MOP逐行比对。教训很具体：涉及紧急呼叫、计费、鉴权这类关键路径的割接，MOP必须与最近一次成功执行的版本做差异比对，引流/回退步骤逐项打钩，缺项即中止。标准允许多种实现方式，具体行为以各厂家官方文档为准——但无论哪家实现，「先卸话务、再锁网关」的顺序纪律不容变通。 **二、「紧急变更、风险为零」是最危险的组合。** 紧急通道本该留给抢修，却被用来绕开CAB省事。任何变更若落在紧急呼叫路径上，无论标什么级别，都应强制触发最严档审批——不是不信任谁，而是凌晨0点的会议室里没有第二个大脑兜底时，流程就是那个大脑。 **三、告警要按业务后果分级，不能按技术指标归档。** 「VoLTE紧急呼叫失败率超10%」这封邮件最终停在别人公司的转发链里。紧急呼叫失败率应当是一级告警：自动电话+短信直达值班经理，要求签收闭环。同时把「000打不通」设为客服工单的顶级关键词——用户投诉是最灵敏的拨测，且已经付过费了。 **四、恢复不是终点，可观测性才是。** 诺基亚交来的CDR里查不到失败记录，导致故障恢复后花5个多小时才拼出受害者名单，直接拖垮了回访和通报的全部时间线。平时就要演练：如果现在要拉出「过去N小时所有失败的紧急呼叫明细」，你的系统多久能给出答案？给不出来，就是在拿最坏一天的应对速度赌博。 **五、应急通报走的是法定时钟，不是新闻节奏。** 这次通报链条上的每一个污点——错误的邮箱、写错的日期、只说10通、24小时后才告诉州政府——都不是技术问题，是应急通讯录和通报模板的问题。地址变更要有确认回执机制，模板里的时间字段要用变量，谁在哪个时点必须通知谁，写进预案并演练。故障会考验你的网络，人命会考验你的流程。 ## 结语 复盘这场事故，最刺眼的不是哪一个人犯错，而是十处失误里没有一处需要多花一分钱：让该到会的人到会，让指令多写一行，让互审对照旧版本，让风险评级如实填写，让那封10%的邮件有人签收——任何一环被认真执行，这场故障都不会发生。 Rue说，这不是系统问题，是「确保管控被执行的流程没被执行」。这话只对了一半。管控为什么会被系统性跳过？Schott给出了下半句答案：风险团队人手不足、内审计建议无人落实、部门各自为战。流程写在纸上，文化决定它是否被执行。对每一个挂着「网络可用率99.99%」看板的团队来说，这份国会报告值得打印出来贴在值班室：真正压垮网络的，从来不是那个凌晨被锁住的网关，而是此前每一张为了省事而跳过的检查表。 ## 参考来源 1. [Chapter 3 – The Optus network outage, Senate Environment and Communications References Committee Report](https://www.aph.gov.au/Parliamentary_Business/Committees/Senate/Environment_and_Communications/TripleZero48P/Report/Chapter_3_-_The_Optus_network_outage) — 澳大利亚参议院专案调查报告第三章，本文时间线、根因链与追责进展的主要事实来源 2. [The Triple Zero Outage at Optus: 18 September 2025 — Independent Report by Dr Kerry Schott AO](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) — Optus董事会委托的独立审查报告全文（2025年12月18日公开） 3. [2025 Optus emergency calling outage - Wikipedia](https://en.wikipedia.org/wiki/2025_Optus_emergency_calling_outage) — 事件概览与死亡关联认定的演变过程，含TPG后续同类事件 4. [Optus firewall upgrade behind 13-hour Triple Zero outage - iTnews](https://www.itnews.com.au/news/optus-firewall-upgrade-behind-13-hour-triple-zero-outage-620427) — CEO Stephen Rue对「例行防火墙升级」导致故障的最初公开说明 5. [ACMA statement on Optus Triple Zero investigation](https://www.acma.gov.au/acma-statement-optus-triple-zero-investigation) — 澳大利亚通信与媒体管理局对本次事件调查的官方声明 --- > 本文由「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 等场景全覆盖。