## 概述 2022年7月2日凌晨1点35分，日本运营商KDDI在给全国传送网一台路由器做例行维护时，写错了一行路由配置。位置更新信令被丢弃，几千万台终端的重发定时器同时被点燃，信令风暴经全国传送网层层放大，au网络瘫痪61小时25分钟，涉及用户超3091万。本文以KDDI官方事后报告与总务省报送材料为主线，完整拆解这次割接作业从失控到恢复的全过程，并给出从T-7天到T+1天的割接剧本与回滚红线设计——回答一个问题：一行配置为什么能挂掉一张全国网，以及怎样让下一次割接不再赌运气。 ## 目录 - 一、割接为什么总在凌晨 - 二、多摩的一行配置：61小时时间线 - 三、三层剥因：作业、拥塞、恢复 - 四、割接剧本：从T-7到T+1 - 五、信令风暴：割接夜的头号杀手 - 六、云原生核心网改变了什么 - 七、写给一线的五条教训 ## 一、割接为什么总在凌晨 先对齐一个词。本文说的“割接”，泛指一切在运行网络上实施的变更作业：核心网软件升级、承载网路由调整、HLR/HSS搬迁、板卡更换、参数批量下发。共同特征只有一个——手术对象是一张正在承载用户的活网。 割接选在凌晨，是全行业用几十年事故换来的共识。理由有三层：第一，凌晨是话务低谷，低谷时段的话务量常常不足忙时的一半（具体比例因网而异），同样一次误操作，忙时炸出来的影响面可能是凌晨的十倍；第二，凌晨开工天然自带一整夜的处置余量，万一翻车，还有几个小时可以抢救，早高峰是挂在墙上的死线；第三，凌晨变更对用户感知的扰动最小，投诉热线不容易被打爆。 但低谷窗口不是护身符。凌晨的另一面是：观测手段薄，值守人力少，设备商后台支持响应慢，出了事往往就是几个人对着一张大屏硬扛。KDDI那次作业选的就是教科书级窗口——周六凌晨1点半，一周话务最低的时段之一。窗口选择没有任何问题，出问题的是窗口里的每一步预案。 ## 二、多摩的一行配置：61小时时间线 先把官方口径的时间线摆出来，数据来自KDDI官网事故专页及其向日本总务省报送的材料： | 时间（日本标准时） | 事件 | | --- | --- | | 7月2日 01:35 | 多摩站点全国传送网路由器维护作业中路由配置写错，位置更新信令被丢弃，故障开始 | | 7月2日 凌晨起 | 终端重发风暴形成，多摩VoLTE节点过载，并经全国传送网向其他站点扩散 | | 7月2日 03:00至下午 | 据事后披露的处置时间线，先后在无线侧与核心网侧实施限流 | | 7月2日（确切时点官方未披露） | 限流未见效，将全国18台VoLTE节点中的6台从网隔离 | | 7月3日 | 社长高桥诚出面召开记者会致歉（据读卖新闻报道） | | 7月4日 15:00 | 话务恢复至前一周同期水平，故障结束 | | 合计 | 61小时25分钟，全国范围 | 再看根因链条，KDDI官方专页交代得很诚实，可以逐环拆开： 第一步，维护作业对象是全国传送网在多摩的路由器，作业中路由配置写错。直接后果是：经过该路由器的位置更新类注册信令被丢弃——注意，不是被拒绝，是被黑洞掉。 这个区别是整个事故的引信。被拒绝的信令，终端拿到明确答复就安静了；被丢弃的信令，终端什么都收不到，NAS层的重发定时器到点就重发，重发还是黑洞，再重发。几百万台手机在同一时刻进入“我必须注册上网”的执念状态。 第二步，多摩的VoLTE节点先被信令洪峰压垮。而KDDI核心网节点之间通过全国传送网做分布式处理、互为备份——这套高可用设计在平时是优点，此刻成了放大器：多摩消化不了的洪峰顺着承载网灌向其他站点，把全国18台VoLTE节点一个接一个拖下水。 第三步，VoLTE节点和PGW每处理一次请求都要到签约数据库做认证查询，重发让查库次数成倍上涨，签约DB成为第二个饱和点。数据库一慢，响应更慢，终端重发更凶，正反馈闭环。 第四步，KDDI先上limiter限流，压不住——因为重发源头是几千万台终端，网内限流挡不住终端里的定时器。最后的手法相当粗暴：把全国18台VoLTE节点中的6台直接从网断开，让这部分区域的终端彻底收不到任何响应、重发源消失，签约DB的压力才真正回落。 影响面，官方口径：语音（VoLTE）约2278万人、数据（4G/5G）765万人以上，KDDI单体统计；合并报送总务省的口径为3091万以上用户。au、UQ mobile、povo全线波及。企业侧的连带伤害清单很有时代感：物流的配送状态回传、车联网服务、水表数据采集、银行ATM、机场无线对讲、公交IC卡——这就是一张移动网瘫痪的散射半径。 ```mermaid flowchart TD A["多摩传送网路由器维护"] --> B["路由配置写错"] B --> C["位置更新信令被丢弃"] C -->|终端收不到响应| D["定时器到点重发"] D --> E["多摩VoLTE节点过载"] E --> F["经全国传送网扩散"] F --> G["各站点VoLTE节点过载"] G --> H["认证查库请求暴涨"] H --> I["签约数据库过载"] I --> J["网内限流无效"] J --> K["隔离6台VoLTE节点"] K --> L["重发源消失，压力回落"] ``` ## 三、三层剥因：作业、拥塞、恢复 KDDI在给总务省的材料里，把原因剥成了三层。这个分法本身就值得抄进每本运维手册，因为它对应的不是三个技术缺陷，而是三种组织能力的缺失。 **第一层：作业层。**路由配置写错是表象，KDDI的自评是“作业准备不足——管理规则、确认项、审批方式都有缺口”。翻译成一线语言：这一行配置没有第二双眼睛复核，没有逐条核对清单，没有作业前的推演。割接作业里最危险的从来不是复杂操作，而是“随手一改”的简单操作——简单意味着没人觉得需要设防。 **第二层：放大层。**KDDI承认，对不规则网络状态下拥塞控制的考虑不充分。这句话信息量极大。常规拥塞预案是为“可预测的高峰”设计的：跨年、演唱会、灾难避险通话——请求多，但路径是通的，扩容、限流、排队都能起作用。而路由黑洞是另一种物种：信令不是在排队，是在消失。对付排队可以削峰，对付消失只能靠终端退避。预案库里没有这一页，等于在凌晨两点面对一个预案手册之外的故障。 **第三层：恢复层。**KDDI原话大意是：从未建立从复杂拥塞状态恢复的作业程序。于是恢复动作只能边做边发明，而现场发明的动作常常互相打架——重新接入的节点带来流量的再集中，二次拥塞又把前面压下去的信令重新顶起来。恢复一路拖到周一15:00。61小时里，真正花在“闯祸”上的只有凌晨那几个小时，剩下的大部分时间，都花在“怎么收场”上。 这是整起事故里最贵的一课：**恢复是被设计出来的，不是被现场发明出来的。** ## 四、割接剧本：从T-7到T+1 把KDDI的学费代进去，一套完整的割接剧本长什么样？下表是从方案评审到复盘归档的最小完整流程： | 阶段 | 关键动作 | 放行判据（Go/No-Go） | | --- | --- | --- | | T-7天 | 方案评审：影响面分析、爆炸半径推演、回滚方案、干系人通报 | 评审签字，回滚步骤能在纸面完整走通 | | T-1天 | 配置与信令路由全量备份；预检时钟、license、容量、告警基线；冻结期内禁止叠加其他变更 | 预检全绿，回滚点验证可用 | | T0 作业中 | 分段实施，单点灰度先行，每一步做完立即拨测验证再放大 | 每步退出判据逐条核对，不跳步 | | T+观察窗 | 盯注册成功率、接通率、位置更新成功率、DB负荷与信令重发率 | 任何一项跌破事先写死的红线，立即回滚 | | T+1天 | 复盘归档，预案库更新，解除变更冻结 | 复盘记录入库，整改项有责任人与期限 | 这张表里最值钱的是最后一列。所谓回滚红线，就是数值化的Go/No-Go判据：注册成功率低于多少、持续多久、信令重发率超过多少，必须回滚——阈值具体取值各网不同，但共同要求是：**在评审会上定死，写进方案，作业现场只执行、不讨论。** 为什么必须事先写死？因为回滚永远要与“再修一下”的诱惑对抗。故障现场的心理曲线是可以预测的：刚翻车时没人愿意承认失败，总觉得自己离修复只差一步。KDDI用61小时证明，临场发明恢复方案的代价，远大于提前回滚的“丢脸”。回滚是预案，不是失败——这句话要刻在每个割接总负责人的脑子里。 ```mermaid flowchart TD A["T-7天：方案评审"] --> B["T-1天：备份与预检"] B --> C{"预检全绿"} C -->|否| D["冻结变更另择窗口"] C -->|是| E["T0：分段实施"] E --> F["单点灰度先行"] F --> G["逐段放量观察"] G --> H{"KPI达标"} H -->|否| I["触发回滚红线"] H -->|是| G I --> J["回退至备份点"] J --> K["T+1天复盘归档"] ``` ## 五、信令风暴：割接夜的头号杀手 割接夜最脆的地方不是转发面，是控制面。原因在信令的天性：终端发出的注册、鉴权类请求，天然自带重发机制——终端无法确认网络是否收到，只能靠定时器兜底。这个机制在正常网络里是可靠性保障，一旦网络侧“沉默”（丢包、黑洞、无响应），它瞬间变成正反馈引擎：定时器驱动全体终端齐步走，重发成倍放大，直到把响应能力剩余不多的网元彻底淹没。 3GPP其实早给过工具箱。NAS层有退避定时器：网络在拒绝或释放消息中可以下发退避值（如EPC与5GC通用的T3346，见TS 24.301与TS 24.501），终端收到后在定时器超时前不得再发起同类请求——把“齐步走”打散成“错峰走”。空口侧，NR引入了统一接入控制UAC（TS 38.331），按接入类别配置概率性禁止，从源头削峰。核心网侧，网元之间可对过载方向的查询请求做节流，优先保住数据库这个最深的瓶颈。这些都写进了标准，各设备商的具体实现方式以官方文档为准。 但工具箱有一个前提，恰好被KDDI案例精准击穿：**信令必须先“能到”网络侧，才能被网络管理。**退避指令也好、准入禁止也好，都得由某个网元告诉终端。路由黑洞场景下，被丢弃的信令永远到不了那个能对它说“退避”的网元——终端只知道自己被沉默，于是按协议最大努力重发。这就是KDDI限流失效的理论解释，也是为什么最后只能物理断开6台节点：对失控的重发源，唯一有效的管理是让它消失。 对一线的实际推论有两条。第一，割接后的观察窗口里，首要指标不是话务量，而是位置更新成功率、信令重发率这类“网络有没有在沉默”的指标——它们比话务曲线早几个小时报警。第二，拥塞控制参数要按最坏状态设计：常规扩容预案对齐“可预测的高峰”，割接预案必须对齐“不可预测的畸形状态”——黑洞、环路、单点放大。两套阈值不该共用一套参数。 ## 六、云原生核心网改变了什么 传统核心网的割接是“整网换版本”：深夜窗口、全停或半停、小时级的回滚。5GC云原生化之后，这门手艺正在换代。SBA架构把控制面拆成微服务，无状态的计算层与数据层分离（如UDM与UDR分离部署），升级粒度从“整网”缩到“逐pod、逐站点”：滚动升级让新旧版本短时共存，金丝雀实例先吃流量，蓝绿切换保留瞬时回退能力。ETSI NFV的MANO框架对VNF软件升级流程也有标准化描述；标准允许多种实现，具体行为以各厂家官方文档为准。效果是实打实的：回滚动作从“整网回退”变成“摘除新版本实例”，时间从小时级压到分钟级。 但别把换代误解为免死。KDDI案例里有一个细节值得所有云原生架构师记住：最先饱和的是签约数据库。控制面可以无状态、可以滚动、可以金丝雀，可签约数据是全局单点逻辑，是有状态的地基——18台VoLTE节点砍掉6台，保的正是它。无论架构怎么演进，数据层的迁移与扩容依然要按最传统的割接纪律来：备份、灰度、红线，一个都不能省。无状态化解决的是“升级时业务不中断”，从来不承诺“配错了也没事”。 变更前在孪生环境里把配置预推一遍，正在成为大网标配，这能把一部分“写错”拦在真网之前——但孪生网覆盖的是已知场景，预案深度的上限，永远取决于人对未知场景的想象力。KDDI缺的那一页预案，孪生网里同样不会有，除非有人先把它想出来。 ## 七、写给一线的五条教训 把61小时压成五条，每条都对应这次事故里的一处伤口： 1. **割接前先回答爆炸半径问题。**这一行配置写错，最远炸到哪里？多摩一台路由器的一行路由，经过分布式处理的放大，炸穿了全国。影响面分析不是走过场，是把最坏情况在纸上画出来的过程——画不出来，说明还没有资格进窗口。 2. **信令黑洞比信令洪峰更危险。**洪峰可以限流，黑洞会让所有自治的终端同时失控。割接方案里必须有路由可达性专项验证步骤，而不是默认“配完就通”。 3. **红线写死，回滚优先。**Go/No-Go判据在评审会上定死，现场只执行不讨论。临场“再修一下”的侥幸，KDDI用两天时间计了价。 4. **恢复要阶梯放流。**故障恢复不是开关，是旋钮。放开限流、重新接入节点，要一档一档来，盯着DB负荷与重发率爬坡，防止流量再集中造成二次翻车。恢复的最后一个动作，永远是慢的。 5. **变更-故障联动是处置第一小时的标准动作。**任何大面积劣化，第一件事是调过去24小时的变更清单。这条纪律能把“从哪查起”的搜索空间砍掉九成——大多数大故障，凶手昨晚就进了机房。 割接这门手艺的本质，是在一张正在运行的网上做手术。凌晨的窗口、写死的红线、逐条的核对清单，这些看起来笨的流程，是61小时替全行业交的学费。技术会从深夜割接演进到滚动升级，但“控制爆炸半径、敬畏信令风暴、把恢复设计成流程”这三件事，不会过时。 ## 参考来源 1. [The July 2 Communication Failure and Our Response — KDDI官网事故专页](https://www.kddi.com/english/important-news/20220729_01/) — 官方口径：61小时25分钟、受影响人数、根因链条（多摩路由器配置错误/签约DB过载/隔离6台节点）、整改措施与退费方案 2. [KDDI outlines outage remedies — Mobile World Live](https://www.mobileworldlive.com/asia-pacific/kddi-outlines-outage-remedies/) — KDDI应总务省要求提交十页报告，建立拥塞早期恢复新规程 3. [KDDI network disruption in early July affected over 30 M. users — The Japan News（读卖新闻）](https://japannews.yomiuri.co.jp/business/companies/20220729-47975/) — 报送总务省的3091万用户口径与7月3日社长记者会 4. [Japanese telco KDDI back online, after weekend outage — RCR Wireless](https://www.rcrwireless.com/20220705/featured/japanese-telco-kddi-back-online-after-weekend-outage) — 恢复通报与VoLTE拥塞归因 5. [The July 2 Communication Failure and Our Response（说明资料PDF）— KDDI](https://www.kddi.com/extlib/files/english/corporate/ir/library/presentation/2023/pdf/kddi_220729_e_shougai_qe3B6V.pdf) — 2278万语音用户、765万以上数据用户的统计口径说明 --- > 本文由「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 等场景全覆盖。