Optus 给出的指令有误，员工又未及时上报问题。

据一份关于 9 月份事件的报告显示，负责防火墙升级的技术人员至少犯了十处错误，导致两人死亡。

该事件导致澳大利亚电信公司 Optus 无法将呼叫转接到紧急服务部门。

澳大利亚的紧急联系电话是 000。当地法律要求所有电信公司必须将紧急呼叫转接到该号码。

2025 年 9 月 18 日，Optus 在长达 14 个小时的时间里无法将部分客户的呼叫转接到 000，也没有意识到其网络存在的任何问题。

这家公司最终从向其呼叫中心投诉的客户处获悉了此事。

在 000 中断期间，455 个紧急服务电话未接通，两名求助者不幸身亡。

2025 年 12 月 19 日，Optus 发布了一份关于此事的独立报告，该报告由澳大利亚高管 Kerry Schott 博士撰写，他曾在 Optus 旗下多家重要业务部门担任要职。

报告指出，Optus 计划进行 18 次防火墙升级，成功完成了 15 次。但在第 16 次升级中，Optus 向外包供应商诺基亚下达了错误的指令。

报告指出：“这些错误似乎是由于防火墙网络工程师对此事不够重视造成的。”

报告还发现，“一些网络工程师未参加这些项目会议，以评估计划工作的影响。”

之后工作人员要求进行一些更改，这需要隔离设备并锁定网关，在 Optus 网络架构中，000 紧急呼叫依赖跨网关重定向作为兜底路径，锁定网关等同于在系统设计层面切断紧急呼叫的逃生通道。此决定意味着流量将无法重定向。

Optus 在前六次防火墙升级中均未采用这套操作程序。同时，诺基亚选择使用了 2022 年的操作程序方法（Method of Procedure），这种方法在以往的升级中并未采用过，也不适用于此次升级。

该 MoP 仅适用于不影响流量的升级场景，与 Optus 当时的网络拓扑并不兼容，且并未在此前 15 次升级中使用，属于供应商在高风险操作中擅自切换方法体系。

诺基亚开始工作后，误以为此次升级对网络流量没有影响。

此时，Optus 已将此次升级列为紧急任务。“紧急变更”标签直接导致工程评审、影响评估及回滚演练被跳过，使多道原本用于防止灾难性后果的制度性防线失效。这意味着 Optus 没有像通常那样进行工程审查。

随后，诺基亚使用错误的操作程序方法实施了升级。不久后，诺基亚检测到了网络问题的迹象。诺基亚注意到了这些问题，但没有进行调查。Optus 也获悉了这些警告，但未深入调查。

凌晨 2 点 40 分，团队进行了实施后检查。

报告发现，呼叫失败率不降反升。报告指出：“异常情况并未被发现。”

最后一个错误是，Optus 使用了全国汇总数据来评估其网络中呼叫量的变化。

Schott 写道：“这些数据不够精细，无法检测到新出现的问题”，因此，一次升级失误导致的局部问题无法被发现。

Schott 对此次事件总结如下：

此次事件中存在三个明显的问题。

首先是 Optus Networks 及其承包商诺基亚内部管理和绩效极差。流程未得到遵守，选择了错误的操作程序。检查不到位，控制措施形同虚设，警报也未得到足够重视。

网络部门似乎不愿寻求更中肯的建议，而是一味注重速度和完成任务，而不是强调工作正确无误。

审查还发现，Optus 的呼叫中心没有意识到自己可能是“000故障的首条警报渠道”。

报告还指出，这家澳大利亚电信公司在中断期间试图转接 000 呼叫，但这并非易事；由于不同智能手机的运行方式各不相同，难上加难。如果设备未经过拨打 000 的连接能力测试，Optus 会提醒客户，并且维护一份已知存在问题的设备清单。但报告指出，Optus 的流程“未涵盖所谓的‘灰色’设备，这种设备是从网上或海外购买的，可能不符合规定。”

目前，所有澳大利亚电信公司都在竭力排查潜在问题。

一位了解另一家澳大利亚运营商手机测试运作情况的知情人士近日透露，其团队一直在评估他们能够拿到的每一部手机的性能。

报告呼吁 Optus 停止目前各行其是的工作模式，并提升事件和危机管理响应能力。

但报告对参与此次失败升级的技术团队给出了措辞最严厉的批评。

报告指出：“一次标准的防火墙升级竟然如此糟糕，让人无法容忍。执行力差强人意，似乎更注重完成任务，而不是确保正确。对网络人员和诺基亚的监管必须更严格更规范，才能确保万无一失。”

云头条声明：如以上内容有误或侵犯到你公司、机构、单位或个人权益，请联系我们说明理由，我们会配合，无条件删除处理。