# KDDI断网61小时复盘：一条路由配置如何放倒全国核心网 ## 概述 2022年7月2日凌晨1点35分，日本第二大运营商KDDI因一次全国传送网路由器维护中的配置错误，引发VoLTE位置登记信令风暴，最终演变为波及全国、持续61小时25分钟的重大通信事故——约2278万语音用户、765万以上数据用户受影响，银行ATM、快递跟踪、气象数据采集、车载联网等大量依赖移动网的社会基础设施连锁瘫痪，110/119紧急呼叫也一度受阻。本文基于KDDI官方事故报告和日本总务省电信事故检证委员会的检证结论，完整复盘这条“配置错误→信令风暴→数据库拥塞→脏备份→恢复失灵”的故障链，并从核心网运维视角提炼五条真正值钱的教训。它至今仍是全球核心网 reliability 教科书级的反面案例。 ## 一、事故时间线：三块表，三个口径 复盘这个案例，首先要搞清楚一个很多媒体都搞混了的问题：**这次故障到底持续了多久？** 答案取决于你用哪块表计时。 | 口径 | 时间 | 时长 | 含义 | |---|---|---|---| | KDDI/总务省官方受影响时间 | 7月2日 01:35 — 7月4日 15:00 | **61小时25分** | 语音+数据服务受影响的官方窗口 | | 全网确认完全正常 | 7月5日 15:36 | 约**86小时** | KDDI确认所有网络（含检查、观察）完全恢复正常 | | 路透社早期报道 | 7月2日起 | — | 3915万潜在受影响用户（含26万企业客户）的瞬时最大口径 | 7月4日15:00是“受影响状态”的结束，但之后KDDI还在做流量限制解除、稳定性观察、状态一致性修复，直到7月5日15:36才官宣全网正常。**61小时和86小时不是矛盾，而是两个不同的恢复里程碑**——这一点在写故障报告时极其重要，混用口径会让复盘失去公信力。 ```text 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等网元每次都去认证）做认证和状态查询。于是拥塞从语音控制面传导到了数据面共用的数据库： ```mermaid flowchart TD A[多摩路由器维护配置错误
VoLTE路由变更未正确下发] --> B[信令响应间歇性失败
约50%成功率] B --> C[终端/网元海量重传
位置登记请求暴涨] C --> D[多摩VoLTE节点拥塞
负载约7倍] D --> E[分布式处理经全国传送网扩散
各站点负载约6.5倍] E --> F[签约用户数据库被认证请求打满
全国性拥塞] F --> G[数据库返回错误
触发更多重传 正反馈循环] G --> H[语音中断 语音失败又影响登记状态
数据业务间歇性不可用] F --> I[高负载下认证会话状态未同步
6个节点带着不一致状态写备份] I --> J[用最新备份重启
异常状态被重新加载] J --> K[6/18个VoLTE节点持续产生异常信令
常规重启无效] K --> L[最终将6个节点从网中隔离
重试源头切断 拥塞才消退] ``` 这里面藏着本次事故**最核心、也最反直觉的技术细节**：KDDI按照常规手段对VoLTE节点做重启恢复时发现，全国18个VoLTE节点中有6个**重启之后依然异常**。总务省的结论是——这些节点在拥塞期间，内部认证会话状态已经不一致，而周期性备份恰恰是在这种“脏状态”下写出来的。运维用“最新备份”恢复，加载进来的却是脏数据，设备启动后继续产生认证失败和重复登记请求。**重启不再等于恢复，因为恢复所用的工件本身已经被故障污染了。** 雪上加霜的是第二层状态不一致：数据库拥塞期间，PGW上本应删除的会话信息没有被正常清理，后续新会话与残留旧会话冲突。修复这些不一致，还得在已经高负载的设备上小心翼翼地做——这就是为什么恢复拖了三天多。 ## 四、影响面：一部手机断网，半个社会跟着抖 KDDI官方报告列举的受影响行业清单，值得每个做核心网的人贴在工位上： | 领域 | 具体影响 | |---|---| | 物流 | 大和运输等包裹状态更新中断、无法联系配送司机 | | 金融 | 银行网点外ATM停机（大垣共立银行190台ATM离线，据媒体报道） | | 交通 | 机场无线对讲、公交IC卡充值/更新滞后、JR货运列车受影响 | | 汽车 | 丰田、铃木车载联网通话功能失效 | | 公共服务 | 气象厅1300个观测站数据采集受阻、水表数据上传中断 | | 应急通信 | 据路透社和共同社报道，部分用户长时间无法拨通110/119 | 这份清单说明一件事：**移动核心网早已不是“打电话的服务”，而是其他关键业务的控制通道**。快递的“控制面”是扫码回传，气象的“控制面”是数据回传，ATM的“控制面”是通信链路探测。用户感知到的故障是“手机打不出电话”，但对物流公司来说是丢失状态更新，对气象厅来说是观测数据缺失。核心网可靠性设计的边界，必须按这些间接依赖来划，而不是按手机用户数来划。 ## 五、监管定性与技术问责：总务省检证报告说了什么 总务省将本次事件定性为**重大事故**，并由电信事故检证委员会做了专项技术检证。检证报告没有把原因简单归结为“一个人配错了路由”，而是列出了一整串控制失效： 1. **作业程序选择与审批失控**——所用作业程序是错误/过时版本，其中根本没有包含VoLTE路由变更这一步；作业前的管理规则、确认项、审批流程全部失守； 2. **拥塞控制设计缺陷**——对非正常网络状态下的拥塞控制缺乏充分考虑，没有评估故障向全国传播的可能性； 3. **高负载恢复未经验证**——从未在“复杂拥塞状态”下测试过恢复程序，高负载下的重置/备份恢复演练缺失； 4. **信息发布失当**——“恢复作业完成”与“服务恢复”两个概念被混用，用户和媒体误以为故障已结束，实际拥塞和流量限制仍在持续。 需要特别指出：总务省的处置是**行政指导与事故检证**，并未开出监管罚单。真正真金白银的代价是KDDI自己的补偿方案——按合同条款，连续24小时以上无法使用全部服务的271万KDDI用户（另含冲绳Cellular 7万）获得相当于2天基本费的退款；同时向全部3589万KDDI用户（另含冲绳66万）发放**每用户200日元（不含税）的道歉补偿**。据共同社报道，补偿总额约**73亿日元**，社长高桥诚自愿减薪。povo2.0用户因本身月租为零，改为发放1GB/3天的流量加油包。 ## 六、整改措施：KDDI的修复清单 KDDI在事故后一个月内密集落地了一批整改，官方公布的节奏如下： | 问题域 | 整改措施 | 落地时间 | |---|---|---| | 维护作业 | 重新修订作业程序与项目审批流程 | 2022-07-14 | | 维护作业 | 对计划内作业做项目级风险分析 | 2022-07-22 | | 故障扩大 | 开发更精细的VoLTE节点拥塞检测工具 | 2022-07-28 | | 故障扩大 | 重新审查并验证拥塞控制设计 | 2022年8月底完成 | | 恢复拖延 | 重新制定拥塞状态下的恢复程序 | 2022-07-11 | | 恢复拖延 | 开发VoLTE节点拥塞恢复工具 | 2022年8月底 | | 对外发布 | 改进信息披露机制、及时准确的公告 | 7-9月分步实施 | 公司层面，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官方事故报告](https://www.kddi.com/english/important-news/20220729_01/) — 事故经过、根因、三阶段失效分析、整改措施与补偿方案的第一手官方口径 2. [KDDI 2022年度统合报告（PDF）](https://www.kddi.com/extlib/files/english/corporate/ir/ir-library/sustainability-integrated-report/2022-online/pdf/kddi_sir2022_e06.pdf) — 61小时25分钟受影响窗口、2278万语音/765万数据用户影响的官方数字 3. [KDDI's 2022 VoLTE outage: when recovery control became the accountability test — btw.media](https://btw.media/en/kddi-2022-volte-outage-recovery-accountability) — 总务省电信事故检证委员会报告细节：7倍/6.5倍负载、脏备份、6节点隔离、双时钟口径辨析 4. [Outline about Communication Failure on July 2, 2022 — KDDI IR新闻稿](https://news.kddi.com/kddi/corporate/english/ir-news/2022/08/05/6189.html) — 2022年8月5日官方说明 5. [Network fallout in KDDI, what happened? — Medium (Guruprasad S)](https://medium.com/@prasad.sg/network-fallout-in-kddi-what-happened-9b206dc887f6) — 技术社区对CSCF/PCRF层面的分析及Docomo/SoftBank/T-Mobile同类案例 6. [KDDI network goes down for two days after maintenance failure — Light Reading](https://www.lightreading.com/business-management/kddi-network-goes-down-for-two-days-after-maintenance-failure) — 行业媒体对事故影响的报道 --- > 本文由「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 等场景全覆盖。