<!-- title: 一次删除，全国断网19小时 -->

2022年7月8日，加拿大经历了一场教科书级的大断网：全国最大的移动运营商Rogers，从凌晨4点多开始全网瘫痪，手机、宽带、刷卡机、银行App、甚至911报警电话一起失灵，历时约19小时才基本恢复，波及人口约占全国四分之一。事后加拿大监管机构CRTC罕见地发布了一份公开调查报告，把根因、处置失误、连带伤害一页页摊在了阳光下。本文以这份官方报告为主线，结合当时的技术分析与公开报道，完整复盘这次事故：一个深夜维护窗口里的一次配置删除，如何一步步演变成全国性灾难；为什么限流救不了它；流量风暴又如何把友商的网络也拖下水；以及这19小时给所有核心网运维人留下的教训。

## 目录

- 一、19小时，一个国家被按下暂停键
- 二、事故时间线：从一次深夜维护说起
- 三、根因解剖：路由协议帮了倒忙
- 四、管理平面陪葬：工程师为什么"看不见"设备
- 五、救援为什么慢：限流失效与重启抉择
- 六、连带伤害：流量风暴打向友商
- 七、账单：赔偿、监管与260亿的收购
- 八、给运维人的六条教训

## 一、19小时，一个国家被按下暂停键

Rogers是加拿大最大的移动运营商，无线用户约1200万，约占全国三分之一，同时还是主要的家庭宽带提供商。2022年7月8日凌晨（东部时间）4点39分前后，加拿大各地Rogers用户开始大规模掉线——手机没有信号，家庭宽带断流，大量企业专线中断。

影响很快超出了通信行业本身。据当时公开报道与各方事后声明：

| 受影响系统 | 影响表现 |
| --- | --- |
| 移动网络 | 约1200万用户无服务，占加拿大人口约四分之一 |
| 911紧急呼叫 | 部分地区报警电话无法接通，事后被监管点名 |
| Interac借记卡网络 | 骨干承载中断，全国商家刷卡大面积瘫痪 |
| 银行服务 | RBC、TD、丰业银行等App及部分ATM不可用 |
| 机场与边境 | 自助值机、部分入境查验系统受波及 |
| 企业与政府 | 专线中断，远程办公、客服中心停摆 |

加拿大是Interac借记卡渗透率极高的国家，商家日常收款高度依赖它，而Interac的承载网络正是跑在Rogers骨干上。事故当天，从连锁超市到街角咖啡店， widespread的"cash only"告示成了一道奇观。而对监管者来说，最不可容忍的一条是：**911也断了**。这直接决定了这次事故后续的监管走向——在加拿大，通信网络的底线不是体验，是紧急呼叫必须永远可达。

## 二、事故时间线：从一次深夜维护说起

综合CRTC事后调查报告与当时多家媒体报道，事故的完整时间线如下（个别时点为多家报道交叉印证的约数）：

| 时间（东部时间） | 事件 |
| --- | --- |
| 7月7日晚 | Rogers按计划在核心网执行维护，涉及配置变更 |
| 7月8日凌晨约4:39 | 变更触发故障，部分核心设备与IP核心失联，全网流量开始溃散 |
| 凌晨5点前后 | 故障确认，应急响应启动，但发现大量设备无法远程登录 |
| 上午 | 对外仍称"大部分服务已恢复"，实际全国性断网持续；媒体与用户大量投诉 |
| 上午至午后 | 尝试限流、尝试恢复路由，进展有限；911、银行、刷卡系统持续瘫痪 |
| 午后 | 决定分批重启核心路由器，派人进入机房现场操作 |
| 约21:00起 | 移动网络逐步恢复，基站重新注册上量 |
| 约23:00 | Rogers宣布大部分服务恢复；残余问题延续至次日凌晨 |
| 7月9日 | CEO Tony Staffieri公开道歉，宣布赔偿方案；监管介入升级 |

值得玩味的是上午那则"大部分服务已恢复"的口径。断网初期Rogers的对外沟通明显滞后于实际状况，这后来也被舆论反复鞭挞——对运营方来说，在根因未明、恢复路径未定之前急于报平安，几乎必然被打脸。

## 三、根因解剖：路由协议帮了倒忙

CRTC报告给出的根因结论并不复杂，但链条值得每一位网络工程师细看。

**直接原因**：维护过程中，工程师对核心路由设备上的一条配置过滤器执行了删除操作，导致部分核心设备与IP核心网之间失联。一次看似常规的变更，炸出了整个架构的脆弱性。

**放大机制**在于路由协议本身的设计逻辑。在现代IP核心网里，路由器之间靠IS-IS/BGP等协议互相通告可达性，任何一台设备状态变化都会触发全网重新收敛。这次的问题在于：与核心失联的那批设备，并没有安静地"消失"，它们发出的路由信息与实际状态脱节，周边设备基于这些错误信息更新路由表，整个IP核心的可达性数据大面积错乱——流量不是"慢了"，而是根本没有路可走。用运维的话说，这是一次由配置变更诱发的全网级路由黑洞。

```mermaid
flowchart TD
    A[深夜核心网维护] --> B[删除配置过滤器]
    B --> C[部分设备与核心失联]
    C --> D[失联设备仍向外广播路由]
    D --> E[核心网路由大面积错乱]
    E --> F[流量无路可走 全国断网]
    E --> G[管理通道同网 工程师失明]
    F --> H[用户重试风暴压垮残余链路]
    G --> I[只能派人现场重启]
    H --> I
    I --> J[分批恢复 约19小时]
```

工程上真正扎心的一点是：**变更的爆炸半径完全没有被约束**。按理想模型，核心网变更应该在受限的维护域内进行，出问题时故障域也应该被隔离在局部。但这次的一条过滤器删除，影响直接穿透了整个核心。事后复盘，业界普遍认为这暴露的不是一个"手滑"，而是变更管理体系的问题——如此高杀伤力的操作，缺乏灰度、缺乏回滚预案、缺乏爆炸半径评估。

## 四、管理平面陪葬：工程师为什么"看不见"设备

这次事故里最反直觉的一幕是：断网发生后，Rogers工程师面对成千上万台核心设备，却几乎无法远程登录任何一台。

原因是架构级的。据CRTC报告，Rogers大量设备的远程管理通道，走的正是这张出事的IP核心网——也就是说，**管理平面和数据平面共生共死**。数据面崩了，管理面跟着一起断，工程师手里的键盘瞬间变成摆设。

这里要说清楚行业里的标准设计：正规的核心网运维，设备管理流量应该走独立的带外（Out-of-Band）管理网，哪怕业务网整体崩溃，工程师依然能登进每台设备执行救援。3GPP和IETF侧的架构规范从不强制规定运营商内部如何组网，但大型运营商的通行做法就是业务、信令、管理三张网物理或逻辑隔离。标准允许多种实现，具体行为以各厂家官方文档为准——而Rogers的现实是：管理流量与业务流量同网，救援通道和事故现场在同一个爆炸半径里。

这个教训在后来的行业讨论中被反复引用，因为它是那种"人人都知道该做、实际网里却总有些设备漏网"的问题：管理网建设往往按设备清单逐步覆盖，十年老设备和新增设备的管理归属可能分属不同代际的方案，审计清单上一个不起眼的例外，就是事故之夜最贵的一环。

## 五、救援为什么慢：限流失效与重启抉择

设备失明之后，Rogers面临两个 sequentially的坏消息。

第一，**限流救不了路由病**。断网消息传开后，千万量级的终端开始疯狂重试——手机不断搜网重注册，App不断重连，这是经典的retry storm。重试流量像洪峰一样反复冲击残存的链路，任何不彻底的限流手段，面对的是一个"全网终端同时重试"的流量模型。限流可以保护局部，但救不回一张路由表已经错乱的核心网。

第二，**只能重启，而且只能现场重启**。当路由状态大面积错乱、远程管理又不可达时，逐步清理每台设备的路由状态理论上可行，实际上遥遥无期；工程团队最终选择的路径是：派人进机房，对核心路由器分批执行重启，让设备以干净状态重新上线、重新学习路由。这就是为什么恢复用了19个小时——不是网络容量问题，而是**每一批重启都是人肉推进的串行操作**。

```mermaid
flowchart TD
    A[确认全国性断网] --> B[定位核心网路由异常]
    B --> C[尝试限流压制重试风暴]
    C -->|收效有限| D[尝试远程恢复路由状态]
    D -->|管理通道失效| E[派人进机房分批重启]
    E --> F[核心逐步收敛 基站重新注册]
    F --> G[约19小时后基本恢复]
```

从事故指挥的角度看，这个决策链还拖着一个额外包袱：断网初期对外口径的犹疑，说明应急指挥在"报喜"与"报灾"之间摇摆，而灾难恢复最忌讳的就是指挥层迟迟不承认最坏情况、不第一时间切换到最大力度预案。19小时里最贵的时间，往往是凌晨到清晨那几个小时。

## 六、连带伤害：流量风暴打向友商

这次事故还有一个在行业内讨论度极高的细节：**友商也被打了**。

据CRTC报告披露，断网及恢复期间，Rogers侧设备向Bell和Telus的网络发出了海量探测流量——以每秒数百万计的ping包风暴，直接导致对端网络设备过载，Bell的部分企业客户服务受到波及。这个现象在事故复盘里被称为flood ping效应：一张核心网崩溃时，它的"求生挣扎"本身就是一种对周边网络的攻击。

这对当时的另一个背景尤其敏感：断网期间，Bell和Telus理论上可以承接Rogers用户的紧急呼叫——运营商间互联本来就是容灾设计的一部分。但现实是，Rogers用户的签约数据在Rogers自己的核心网里（HSS/HLR不可达），对端网络既无法完成鉴权，自己还挨着流量风暴，"借网求救"这条路走不通。

这给全行业提了一个此前从未如此尖锐的问题：**运营商互联的容灾设计，到底防不防得住"对端全网崩溃"这种极端场景？** 断网之后，联邦创新部长商鹏飞（François-Philippe Champagne）直接召集几大运营商，要求在30天内提交网络互联与容灾方案；CRTC随后启动专项程序，推动"911必须永远可达"的强制性互联保障。

## 七、账单：赔偿、监管与260亿的收购

事故的代价可以分三层算。

**对用户**：Rogers宣布向客户返还相当于5天的服务费用，总额约1.5亿加元；此外还面临客户发起的集体诉讼。对一家运营商而言，这个数字买回的是一次全民级别的信任透支——事故之后相当长时间里，"Rogers又断了"成为加拿大社交媒体上的条件反射式调侃。

**对监管**：CRTC于2023年发布官方调查报告，将变更管理缺陷、管理平面设计缺陷、应急响应迟缓等结论公之于众；随后推进运营商互联与紧急呼叫保障的监管新规。这次事故直接改写了加拿大的电信监管议程——一个市场集中度极高的国家，第一次系统性审视"一家运营商崩溃等于全国瘫痪"的系统性风险。

**对行业格局**：事故发生时，Rogers正在推进对Shaw的收购——一笔约260亿加元的并购交易，此前已因竞争问题遭到竞争局反对。断网事故给了这笔交易的反对者最直观的论据：这样一家占全国三分之一无线市场的公司，其网络韧性尚且如此，再合并只会更糟。交易最终在2023年4月完成，但断网事故明确地延长了审查周期、推高了剥离条件。

## 八、给运维人的六条教训

以一个跑了18年核心网和运维的老兵视角，这次事故值得写进每一份内部培训教材的教训有六条：

1. **管理平面必须真正独立**。带外管理网不是成本项，是保险单。审计你的网络：找出所有"管理流量走业务网"的例外清单，每一个例外都是19小时里的一个环节。
2. **高危变更要评估爆炸半径**。一条过滤器删除能放倒全网，说明变更审批体系对"这条配置影响多大"没有真实答案。变更单上必须能回答：最坏情况影响哪些域？回滚脚本验证过吗？
3. **路由协议的自治是双刃剑**。动态路由的"自愈"建立在信息真实的前提上；信息错乱时，协议会把局部故障放大成全网灾难。核心网设计要预设"路由信息不可信"的防御手段（过滤、认证、分域）。
4. **retry storm要纳入容量模型**。全网终端同时重试的流量模型，和正常运行模型完全是两回事。容灾演练必须模拟重试洪峰，否则容量规划就是纸面数字。
5. **对外口径要跟着灾情等级走**。根因未明时承诺"大部分已恢复"，是给自己埋雷。灾难沟通的第一原则：没核实的别说，说了的要做到。
6. **互联容灾要按"对端崩溃"设计**。运营商互联不是互保，对端全网崩溃时你既要能接住它的紧急呼叫，又要扛得住它垂死时的流量风暴——这是CRTC新规的方向，也应该写进每一份互联协议的技术附件。

一张网的韧性，从来不取决于它正常运行时有多漂亮，而取决于它崩溃的瞬间还剩下多少可控的部分。Rogers用19小时和1.5亿加元，替全行业验证了一遍这个朴素的道理——而且验证得足够彻底：配置、架构、流程、沟通、监管，每一层都塌了一角。下一次深夜维护窗口，当你按下回车之前，值得把这份19小时的时间线在脑子里过一遍。

## 参考来源

1. [2022 Rogers Communications outage — Wikipedia](https://en.wikipedia.org/wiki/2022_Rogers_Communications_outage) — 事件全貌、时间线、各方回应与后续监管动作的汇总条目
2. [CRTC官网](https://crtc.gc.ca/eng/home-accueil.htm) — 加拿大广播电视及通信委员会官网，站内检索"CRTC report on the Rogers outage"可获取2023年发布的官方调查报告全文（本文根因与flood ping细节的主要依据）
3. [Cloudflare Blog](https://blog.cloudflare.com) — Cloudflare在断网期间对Rogers方向流量骤降的技术观察（站内检索Rogers outage）
4. [ThousandEyes Blog](https://www.thousandeyes.com/blog) — 思科ThousandEyes对本次断网的路由层视角分析（站内检索Rogers）

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