KDDI断网61小时复盘：一条路由配置如何放倒全国核心网

概述

2022年7月2日凌晨1点35分，日本第二大运营商KDDI因一次全国传送网路由器维护中的配置错误，引发VoLTE位置登记信令风暴，最终演变为波及全国、持续61小时25分钟的重大通信事故——约2278万语音用户、765万以上数据用户受影响，银行ATM、快递跟踪、气象数据采集、车载联网等大量依赖移动网的社会基础设施连锁瘫痪，110/119紧急呼叫也一度受阻。本文基于KDDI官方事故报告和日本总务省电信事故检证委员会的检证结论，完整复盘这条“配置错误→信令风暴→数据库拥塞→脏备份→恢复失灵”的故障链，并从核心网运维视角提炼五条真正值钱的教训。它至今仍是全球核心网 reliability 教科书级的反面案例。

一、事故时间线：三块表，三个口径

复盘这个案例，首先要搞清楚一个很多媒体都搞混了的问题：这次故障到底持续了多久？ 答案取决于你用哪块表计时。

7月4日15:00是“受影响状态”的结束，但之后KDDI还在做流量限制解除、稳定性观察、状态一致性修复，直到7月5日15:36才官宣全网正常。61小时和86小时不是矛盾，而是两个不同的恢复里程碑——这一点在写故障报告时极其重要，混用口径会让复盘失去公信力。

timeline
    title KDDI 2022年7月断网事故时间线
    7月2日 01:35 : 多摩网络中心路由器维护中配置错误 : VoLTE位置登记请求被丢弃 : 终端与网元开始海量重传
    7月2日 凌晨 : 多摩VoLTE节点负载达平时7倍 : 分布式架构把重试扩散到全国 : 其他站点达6.5倍负载
    7月2日 白天 : 签约用户数据库（HSS/HLR类）被认证请求打满 : 6/18个VoLTE节点状态异常 : 语音大面积中断 波及数据业务
    7月3日 : 实施流量控制 效果有限 : 发现部分节点重启后仍异常 : 定位到"脏备份"问题
    7月4日 15:00 : 隔离6个持续异常VoLTE节点后拥塞消退 : 官方受影响窗口结束（61h25m）
    7月5日 15:36 : 全部网络确认恢复正常 : 事故实质结束（约86小时）
    7月29日 : 公布补偿方案 : 每'user 200日元道歉补偿

二、根因：一次“半故障态”比全断更致命

按KDDI官方报告和总务省检证报告的口径，事故起点是多摩（Tama）网络中心一次全国传送网路由器的例行维护。作业中路由器配置错误，VoLTE流量所需的路由变更没有正确下发，导致该路径上的信令响应间歇性失败——检证报告 reconstruct 出的状态大约是一半请求能得到响应。

很多工程师的第一直觉是：一半失败总比全失败好吧？恰恰相反。这是本次事故第一个值得写进运维手册的要点：

• 全失败时，终端和网元会快速判定路径不可用，切换到备用路径或进入退避；
• 半失败时，系统“偶尔能通”，恰好健康到足以让它继续在原路径上反复尝试——每一次丢失的响应都催生一次重传，重传又消耗更多控制面容量，更多容量被吃掉又导致更多失败。

这是一个正反馈的重试风暴。据总务省检证报告估算，多摩节点的VoLTE呼叫控制负载达到平时的约7倍；由于KDDI的分布式架构会通过全国传送网分发处理，重试被复制到全国其他站点，达到约6.5倍。一个局部维护失误，就此进入了全国耦合的信令控制系统。

三、故障扩散链：从语音控制面烧到签约数据库

VoLTE节点并不是孤岛。位置登记和呼叫建立每一步都要到签约用户数据库（KDDI官方报告里明确点名PGW等网元每次都去认证）做认证和状态查询。于是拥塞从语音控制面传导到了数据面共用的数据库：

flowchart TD
    A[多摩路由器维护配置错误<br>VoLTE路由变更未正确下发] --> B[信令响应间歇性失败<br>约50%成功率]
    B --> C[终端/网元海量重传<br>位置登记请求暴涨]
    C --> D[多摩VoLTE节点拥塞<br>负载约7倍]
    D --> E[分布式处理经全国传送网扩散<br>各站点负载约6.5倍]
    E --> F[签约用户数据库被认证请求打满<br>全国性拥塞]
    F --> G[数据库返回错误<br>触发更多重传 正反馈循环]
    G --> H[语音中断 语音失败又影响登记状态<br>数据业务间歇性不可用]
    F --> I[高负载下认证会话状态未同步<br>6个节点带着不一致状态写备份]
    I --> J[用最新备份重启<br>异常状态被重新加载]
    J --> K[6/18个VoLTE节点持续产生异常信令<br>常规重启无效]
    K --> L[最终将6个节点从网中隔离<br>重试源头切断 拥塞才消退]

这里面藏着本次事故最核心、也最反直觉的技术细节：KDDI按照常规手段对VoLTE节点做重启恢复时发现，全国18个VoLTE节点中有6个重启之后依然异常。总务省的结论是——这些节点在拥塞期间，内部认证会话状态已经不一致，而周期性备份恰恰是在这种“脏状态”下写出来的。运维用“最新备份”恢复，加载进来的却是脏数据，设备启动后继续产生认证失败和重复登记请求。重启不再等于恢复，因为恢复所用的工件本身已经被故障污染了。

雪上加霜的是第二层状态不一致：数据库拥塞期间，PGW上本应删除的会话信息没有被正常清理，后续新会话与残留旧会话冲突。修复这些不一致，还得在已经高负载的设备上小心翼翼地做——这就是为什么恢复拖了三天多。

四、影响面：一部手机断网，半个社会跟着抖

KDDI官方报告列举的受影响行业清单，值得每个做核心网的人贴在工位上：

这份清单说明一件事：移动核心网早已不是“打电话的服务”，而是其他关键业务的控制通道。快递的“控制面”是扫码回传，气象的“控制面”是数据回传，ATM的“控制面”是通信链路探测。用户感知到的故障是“手机打不出电话”，但对物流公司来说是丢失状态更新，对气象厅来说是观测数据缺失。核心网可靠性设计的边界，必须按这些间接依赖来划，而不是按手机用户数来划。

五、监管定性与技术问责：总务省检证报告说了什么

总务省将本次事件定性为重大事故，并由电信事故检证委员会做了专项技术检证。检证报告没有把原因简单归结为“一个人配错了路由”，而是列出了一整串控制失效：

1. 作业程序选择与审批失控——所用作业程序是错误/过时版本，其中根本没有包含VoLTE路由变更这一步；作业前的管理规则、确认项、审批流程全部失守；
2. 拥塞控制设计缺陷——对非正常网络状态下的拥塞控制缺乏充分考虑，没有评估故障向全国传播的可能性；
3. 高负载恢复未经验证——从未在“复杂拥塞状态”下测试过恢复程序，高负载下的重置/备份恢复演练缺失；
4. 信息发布失当——“恢复作业完成”与“服务恢复”两个概念被混用，用户和媒体误以为故障已结束，实际拥塞和流量限制仍在持续。

需要特别指出：总务省的处置是行政指导与事故检证，并未开出监管罚单。真正真金白银的代价是KDDI自己的补偿方案——按合同条款，连续24小时以上无法使用全部服务的271万KDDI用户（另含冲绳Cellular 7万）获得相当于2天基本费的退款；同时向全部3589万KDDI用户（另含冲绳66万）发放每用户200日元（不含税）的道歉补偿。据共同社报道，补偿总额约73亿日元，社长高桥诚自愿减薪。povo2.0用户因本身月租为零，改为发放1GB/3天的流量加油包。

六、整改措施：KDDI的修复清单

KDDI在事故后一个月内密集落地了一批整改，官方公布的节奏如下：

公司层面，KDDI还建立了跨组织的网络稳定优先体制，并在9月结合防灾演习开展了全公司范围的通信故障训练——把“核心网故障”当成和地震同级别的假想敌来演练。

七、运维视角的五条硬教训

做了十几年核心网运维，我认为这个案例真正值得写进自己手册的是以下五条：

第一，变更管理防的是“程序正确地执行了错误的程序”。 多摩那次作业走完了审批、按程序执行、作业者并没有“乱来”——错的是程序本身就是过时版本，缺了VoLTE路由变更这一步。所以变更管控的检查点不能只问“是否按程序做了”，还要问“程序本身是否与当前网络状态一致”。传送网路由表和核心网信令路由的联动变更，必须在作业票里显式列出关联影响，并由核心网侧会签。

第二，重试风暴的根源在“半故障态”，容量设计必须按重传倍数而不是均值做。 7倍、6.5倍的负载放倒全国，说明控制面网元（尤其CSCF/数据库这类有状态环节）的过载保护不能假设故障是干净的二值状态。重传退避、信令准入控制、按网元级别的信令隔离区（blast radius），要在架构设计阶段就画进图纸——事后补救的流控，在这起事故里被证明“必要但不充分”。

第三，备份恢复必须验证“状态一致性”，否则重启就是重新加载故障。 6个节点重启后依然异常，是整个事故最有教学价值的细节。高负载期间写出的备份是脏的。整改方向应该是：关键网元在拥塞期间触发“状态快照冻结”或标记备份可疑；恢复剧本里必须包含恢复后的一致性校验步骤（认证成功率、信令基线比对），校验不过就换更早的干净备份而不是反复重启。

第四，恢复剧本要在“复杂拥塞态”下真刀真枪演练。 KDDI承认“没有建立从复杂拥塞状态恢复的程序”。很多运营商的应急预案停在单点故障场景，从来没演练过“多个环节互相污染”的复合故障。每年至少一次全网级混沌演练，专门设计“备份可疑+会话残留+数据库高载”三重叠加的场景，才能暴露真实恢复路径上的断点。

第五，对外发布要区分技术里程碑和用户体感。 “恢复作业完成”≠“能打电话”。事故通报体系应该公布分层的证据链：故障输入已消除→重传增长已被遏制→拥塞消退→会话状态一致→流控解除→端到端接通率恢复基线→依赖行业确认正常。每个里程碑可观测、可验证，才能避免第二次舆情灾害。

顺带一提，这不是日本运营商第一次栽在这类坑里：据媒体报道，NTT Docomo 2021年10月因通信设施施工故障断网29小时、影响1290万用户；SoftBank 2018年12月因爱立信软件故障导致3000万用户断网5小时；T-Mobile美国2020年因租用光纤电路故障引发IMS容量连锁问题、断网13小时。共同模式都是：触发点很小，控制面重试和状态不一致把事故放大到了全国。

结语

KDDI这次事故的最吊诡之处在于：起点只是一个过时的作业程序、一个没下发成功的路由变更，终点却是86小时的全国瘫痪和73亿日元的账单。中间隔着的，是重试风暴、数据库拥塞、脏备份、恢复剧本空白——每一环都是可以在设计期、演练期拦截的。核心网的可靠性从来不是买更贵的设备堆出来的，而是把“人一定会犯错、程序一定会过时、备份可能已经脏了”当作设计前提，一层层设防。这，才是61小时黑暗留给全球同行的真正遗产。

参考来源

1. The July 2 Communication Failure and Our Response — KDDI官方事故报告 — 事故经过、根因、三阶段失效分析、整改措施与补偿方案的第一手官方口径
2. KDDI 2022年度统合报告（PDF） — 61小时25分钟受影响窗口、2278万语音/765万数据用户影响的官方数字
3. KDDI's 2022 VoLTE outage: when recovery control became the accountability test — btw.media — 总务省电信事故检证委员会报告细节：7倍/6.5倍负载、脏备份、6节点隔离、双时钟口径辨析
4. Outline about Communication Failure on July 2, 2022 — KDDI IR新闻稿 — 2022年8月5日官方说明
5. Network fallout in KDDI, what happened? — Medium (Guruprasad S) — 技术社区对CSCF/PCRF层面的分析及Docomo/SoftBank/T-Mobile同类案例
6. KDDI network goes down for two days after maintenance failure — Light Reading — 行业媒体对事故影响的报道

本文由「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 等场景全覆盖。