## 概述 2022年7月2日凌晨1时35分，日本第二大移动运营商KDDI（au/UQ mobile/povo）在兵库县尼崎市一个电话局做了一次例行设备割接。四天后，也就是7月6日（周三）上午，公司才宣布全部功能恢复——期间约4000万名用户语音、短信、数据大面积中断，丰田车联网、气象数据回传、紧急呼叫接连告急。本文以KDDI官方复盘报告《通信障害発生の原因と再発防止策について》（2022年7月26日发布于KDDI官方新闻室 news.kddi.com）与日本总务省相关公报为解读主轴，结合路透社等当时的报道，还原这起日本电信史上规模最大断网事故的时间线、根因链条、二次风暴、处置过程与整改代价，回答一个每个割接工程师都该自问的问题：一个配置错误，是怎么滚成全国灾难的。 ## 目录 - 一、凌晨1点35分：一场例行割接变成全国事故 - 二、根因解剖：一个路由环路的雪崩链 - 三、二次风暴：恢复为什么比故障更难 - 四、影响面：断网的外溢账单 - 五、官方复盘：KDDI报告与总务省行政指导 - 六、代价：200日元的补偿与更贵的教训 - 七、给割接工程师的五条军规 - 结语 ## 一、凌晨1点35分：一场例行割接变成全国事故 先看时间线。以下节点综合KDDI官方通报与当时日媒、路透社报道整理： | 时间（日本时间） | 事件 | 网络状态 | |---|---|---| | 7月2日 01:35 | 尼崎局开始更换中继交换机（中継交換機）的割接作业 | 割接进行中 | | 7月2日 凌晨 | 割接中路由配置出错，IP骨干网出现路由环路，故障爆发 | 全国性故障开始 | | 7月2日 清晨 | 用户投诉激增，社交平台“au不通”刷屏 | 语音、短信、数据大面积异常 | | 7月2日 傍晚 | KDDI首次召开记者会，承认发生大规模通信障害 | 数据部分恢复 | | 7月2日 深夜 | 数据通信基本恢复 | 语音仍间歇性不通 | | 7月3日—4日 | 终端重连集中冲击注册系统，KDDI分区限流 | 语音、短信反复中断 | | 7月5日 | 社长高桥诚出面道歉，公布补偿方针 | 大部分业务恢复 | | 7月6日 上午（据KDDI通报为9时55分） | 宣布全部功能恢复 | 全网恢复 | 几个数字先立住体感：KDDI旗下au约2400万、UQ mobile约1300万、povo约200万，受影响用户合计最大约4000万——日本总人口约1.25亿，相当于每三个人里有一个用的是KDDI的手机。路透社7月3日的报道标题还是“多数用户已恢复、历时近两天”，结果恢复过程又拉锯了三天。这不是一次“断了又好”的事故，而是断、好、再断、限流、再好的四天拉锯战。 还有一个背景必须交代：就在事故前三个月的2022年3月31日，au的3G（CDMA）网络正式停波。从那天起，au用户的所有话音都是VoLTE，全压在IP承载网和IMS注册体系上。旧网络平时是包袱，出事时是兜底——3G没了，兜底也没了。这个细节在当时报道里提得不多，但它是理解这次事故烈度的钥匙之一。 ## 二、根因解剖：一个路由环路的雪崩链 按KDDI官方复盘的口径，根因链条是这样的：割接人员在更换中继交换机时，录错了IP网的路由配置，导致IP分组在骨干网里成环（路由环路）；环路流量冲击路由设备，造成局部网段拥塞；拥塞又让分布在各地的终端注册信令大规模汇聚到VoIP注册服务器，服务器过载，语音注册失败向全国扩散。用一张图把这条雪崩链画出来： ```mermaid flowchart TD A["尼崎局割接：更换中继交换机"] -->|配置录错| B["IP骨干网出现路由环路"] B --> C["环路流量冲击路由设备"] C --> D["局部网段拥塞"] D --> E["注册信令涌向VoIP注册服务器"] E --> F["注册服务器过载"] F --> G["全国语音短信大面积失效"] G -->|终端疯狂重试| H["信令风暴二次放大"] H --> I["局部事故扩散成全国事故"] I --> J["恢复期数千万终端同时重连"] J --> K["注册服务器二次过载"] K -->|分区限流| L["恢复拉锯四天多"] ``` 逐段拆开看，每一段都是老熟人，凑在一起才是新灾难。 **第一段：配置错误。** 割接录错配置，是运维行业最古老的事故原因，没有任何新奇之处。问题在于第二层——为什么这个错误没有被拦住。割接发生在凌晨1点35分，值班的眼睛最少、审批链最松、回滚判断最慢的时段。一个在白天十分钟就能看出来的环路，在凌晨可能要等告警涌上来才被确认，而确认它影响范围的过程本身又花了几个小时。 **第二段：环路没有被隔离。** KDDI官方报告承认，设计中缺少对环路的有效检测与抑制，一个局点的配置错误能把负荷打到全网设备上。这是故障域设计的失败：冗余化做得越多，设备之间的耦合越紧，一次“局部”事故就越容易演变成“全体”事故。任何做过骨干网的人都知道，路由协议的收敛机制在环路面前常常不是止血带，而是把故障流量均匀抹到每一台设备上的搅拌机。 **第三段：注册服务器过载。** VoLTE的话音要先向注册服务器报到，这套控制面设施是天然的全网集中点。尼崎的环路让大片终端失去承载，掉线的终端按协议规范开始重试，成百万上千万的重试信令涌向同一个服务器池——局部拥塞瞬间翻译成了全国性的注册失败。注意这里的传导方向：数据面的问题，是通过控制面的集中性完成全国扩散的。3G停波后“所有话音都是VoLTE”的单一依赖，把这条路径彻底焊死。 **第四段：重试放大。** 终端收不到应答就重试，重试加剧拥塞，拥塞导致更多重试。这就是信令风暴，所有做过大规模系统的人都在别的地方见过它的孪生兄弟——被限流压垮的接口、被缓存击穿的数据库。移动网络特殊的地方在于：重试的发起方是几千万个你无法远程降速的独立终端。 ## 三、二次风暴：恢复为什么比故障更难 如果说故障爆发是第一场风暴，那么7月2日深夜到7月3日之后的“恢复期”才是这次事故真正教科书级的部分。 网络侧修好环路、疏通拥塞之后，KDDI面对的是另一道数学题：几千万台终端同时醒来，同时发起注册。这和大停电后电网的“冷负荷恢复”是同构问题——你不能让所有用户同一秒合闸，否则刚刚爬起来的系统会再次趴下。KDDI的实际处置正是分区、分批限制终端接入，让注册请求以系统能消化的速率回流。 代价是用户侧的体验彻底混乱：很多人看到信号格回来了、数据能用了，打个电话又不通；过一会儿好了，再过一会儿又不行。这种“假恢复”比一次干脆的断网更消耗信任，社交平台上的愤怒在7月3日、4日持续发酵。第三次风暴出现在媒体层面——7月2日傍晚第一次记者会之后，直到7月5日社长高桥诚才亲自出面道歉，而据当时日媒报道，故障发生期间KDDI官方社交媒体账号还在按既定计划发布促销内容，被网友截图群嘲。危机沟通的每一步都慢半拍，这在事后被一并写进了整改清单。 给所有做容灾的人一句话总结这一节：恢复期的流量模型不等于稳态模型。你的系统按稳态容量设计，故障时是雪崩态，恢复时是洪峰态——三个态三种容量需求，只按一种设计就是留了两个坑。 ## 四、影响面：断网的外溢账单 4000万手机用户只是第一层账单。移动网络早已是无数行业的水电煤，这次断网的外溢清单在当时日媒汇总里占了很大篇幅： - **车联网**：丰田的车载通信服务T-Connect使用KDDI线路，故障期间车机侧通信服务受影响，丰田方面事后致歉。停在路上的车不会断，但远程诊断、导航、紧急救援类业务全部哑火。 - **气象与观测**：据报道，依赖移动线路回传的气象观测数据采集出现延迟——物联网设备没有“等网络好了再补传”的智慧，数据丢就是丢了。 - **紧急呼叫**：总务省和KDDI均确认部分用户无法正常拨通紧急电话。这是所有断网事故中最刺眼的一条，也是监管反应烈度直接升级的原因。 - **异网连锁**：docomo和SoftBank网络出现连锁拥塞——KDDI用户手机在无服务时会尝试漫游/切换，压力瞬间转移给邻居。断网从来不是一家运营商的内部事务。 - **千行百业的物联网**：车队管理、支付终端、监控回传，凡是用着au SIM的设备集体离线，且大量物联网卡没有人工介入能力，恢复比手机慢得多。 把这次事故放进近年同类事件的坐标系里，规律刺眼地一致——大事故几乎全是“变更”引出来的： | 事故 | 时间 | 影响规模 | 持续时间 | 直接根因 | |---|---|---|---|---| | NTT docomo | 2021年10月 | 约2900万用户 | 约4个半小时 | 注册管理设备故障 | | KDDI | 2022年7月 | 约4000万用户 | 四天多（拉锯式恢复） | 割接配置错误引发路由环路 | | Rogers（加拿大） | 2022年7月 | 超1000万用户 | 约19小时 | 核心网路由配置变更引发全网设备震荡 | | Optus（澳大利亚） | 2023年11月 | 超1000万用户 | 约14小时 | 路由变更导致双归站点脱管 | | Verizon（美国） | 2024年9月 | 全国范围 | 约10小时 | 核心网软件变更失误 | 五起事故，五种技术表象，同一个剧本：变更引入错误，错误穿过没有被设计的故障域，控制面的集中性完成全国扩散，恢复期再补一刀。KDDI是其中规模最大、拉锯最长的一个。 ## 五、官方复盘：KDDI报告与总务省行政指导 这次事故的权威材料有两份，也是本文解读的主轴。 第一份是KDDI官方复盘。2022年7月26日，KDDI在官方新闻室发布《通信障害発生の原因と再発防止策について》，首次完整披露“割接配置错误→路由环路→注册服务器过载”的因果链，并随后滚动提交进展报告。其再发防止对策大体沿六条线展开：强化IP网路由环路的检测与隔离机制；重要工程引入配置的双重检证与自动校验；注册类控制面服务器增加过载保护；预置恢复期流量控制预案（分区、分批、限速回流）；重构危机管理与信息披露流程；开展大规模障害的常态化演练。 第二份是监管侧的动作。事故当月，日本总务省即对KDDI实施行政指导，要求彻查原因、彻底落实再发防止措施，并多次要求提交报告。更大的背景是：这已经是不到一年内日本三大运营商的第三次大事故——2021年10月docomo约2900万人断网约4个半小时，2022年6月SoftBank又发生区域性故障。总务省随后把整改要求推向全行业，要求各运营商重新评估大规模故障的风险管理与信息发布机制。监管的耐心是逐次事故递减的，KDDI撞上的是第三次惩罚性关注。 值得工程师注意的细节是：KDDI官方复盘对“设计缺陷”的承认比对“操作失误”的承认更有分量。操作失误可以用培训、复核去压缩概率，而“环路检测机制不足”“注册服务器缺少过载保护”是架构层的认账——意味着要动网络设计本身，那才是真金白银的整改。 ## 六、代价：200日元的补偿与更贵的教训 7月中旬，KDDI公布补偿方案：向因故障长时间无法使用服务的用户每人补偿200日元等值积分，覆盖约3000万人，按此口径估算仅积分补偿总成本就在60亿日元（约合人民币3亿元）量级（此为按人数乘单价的估算口径，据当时日媒报道，企业客户赔偿与间接损失的总额远高于此）。据日媒报道，公司管理层还接受了减薪等处分。 但200日元买不回来的东西清单更长：紧急呼叫受阻留下的信任裂痕、企业客户对单运营商依赖的重新定价、以及日本电信业此后数年在“大规模障害对策”上被监管钉住的成本。对外溢企业来说，这次事故是给所有行业的一张风险告知书——你的业务商SLA里写着运营商赔偿上限，你的真实损失却是按小时营收计价的，两者之间隔着几个数量级。 ## 七、给割接工程师的五条军规 以一个做了十八年核心网与运维的老兵视角，把这四天浓缩成五条可以贴在工位上的军规： **一、割接窗口不是风险豁免区。** 凌晨割接的理由是用户少，但用户少意味着告警验证慢、协作资源少、回滚决策链条长。风险必须按“出事时你拥有什么资源”评估，而不是按“出事概率多低”评估。KDDI证明了凌晨一点半恰恰是烈度最大的点火时刻。 **二、配置错误要靠机器拦，不靠眼睛拦。** 双人复核能拦住手滑，拦不住理解错。路由配置的预校验、变更前后的一致性比对、自动回滚脚本的预演，应该在每一次重要割接里是标配而不是加分项。五起同类大事故，没有一起是被“眼睛多看了一遍”拦住的。 **三、控制面的集中点必须有过载保护。** 注册服务器、认证中心、DNS——凡是全网集中访问的控制面设施，都要预设“一半终端同时重试”的假设。限流、排队、降级策略要在设计期写进架构，不能等事故现场临时发明。 **四、恢复预案与故障预案同等重要。** KDDI的四天里，真正的技术考验不在7月2日凌晨，而在7月3日之后怎么让几千万终端有序回家。分区回流、限速注册、分批放行，这套预案必须在事故前就设计并演练过，否则恢复期就是第二次事故现场。 **五、承认得越早，代价越小。** KDDI在信息发布上慢的每一步，都被舆论加倍讨了回来。大规模故障发生后的第一条对外信息，宁可保守也要诚实；官方渠道停发营销内容应是无须讨论的常识。危机沟通不是公关部门的事，是故障处置流程的一部分。 ## 结语 2022年7月那四天里，KDDI没有遇到什么罕见的天灾：一次例行割接、一个录错的配置、一段被环路放大的流量、一群按协议重试的终端。每个环节单看都在正常运行，连起来就是4000万人的四天。这就是大型网络事故最诚实的一面——它不需要妖怪，只需要一条没有被设计隔断的传导链。此后四年，从渥太华到达拉斯，类似的剧本仍在不同运营商身上重演，只是换了协议和厂商名字。变更管理的自动化、控制面的过载韧性、恢复期的流量编排，这三件事今天依然是行业欠账。下一次凌晨一点半按下回车之前，值得把这份日本总务省盯着写完的复盘再翻一遍。 ## 参考来源 1. [KDDI官方新闻室：通信障害発生の原因と再発防止策について](https://news.kddi.com/) — KDDI于2022年7月26日发布的官方复盘报告页（原因认定、影响规模、再发防止对策），此后滚动提交进展报告 2. [日本总务省 新闻发布（电信事业相关）](https://www.soumu.go.jp/menu_news/s-news/) — 总务省对KDDI大规模通信障害实施行政指导、要求全行业强化大规模障害对策的公报入口 3. [Reuters：Japan's KDDI says services restored after nearly two days of outage](https://www.reuters.com/technology/japans-kddi-says-services-restored-after-nearly-two-days-outage-2022-07-03/) — 路透社2022年7月3日对故障恢复进程的英文报道 4. [Wikipedia：KDDI](https://en.wikipedia.org/wiki/KDDI) — 英文维基KDDI条目中对2022年7月通信障害经过与用户影响数据的汇总梳理 --- > 本文由「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 等场景全覆盖。