# 告别凌晨割接：核心网升级不打烊 **概述**：割接窗口，是通信运维人又爱又恨的四个字。本文回答一个具体问题：核心网升级，能不能不再靠凌晨停机窗口赌一把？本文以爱立信官方博客与三家运营商的商用实践为主轴，拆解 ISSU（In-Service Software Upgrade，在役软件升级）如何让 5G 核心网「边跑边换」：芬兰 Elisa 成为欧洲首个在商用 5G SA 网络部署 ISSU 的运营商；澳大利亚 TPG Telecom 实测升级执行时间缩短 70%、彻底告别外部供应商到场；西班牙 Telefónica 则在用户面上完成了实践。同时，本文也保留并整理传统割接的「八步军规」——因为 3GPP 标准允许多种实现，并不是每一次升级都能在役完成，割接纪律仍然是运维人的看家本领。 ## 目录 1. 凌晨两点的集体记忆：割接为什么让人又怕又烦 2. 权威锚定：爱立信说的 ISSU 到底是什么 3. 三张商用答卷：Elisa、TPG 与 Telefónica 4. 原理拆解：核心网凭什么能边跑边换 5. 边界：哪些升级仍然要老老实实割接 6. 割接夜八步军规与标准时间线 7. 从人扛到流水线：CI/CD 进核心网 8. 写在最后：给运维人的三条建议 ## 一、凌晨两点的集体记忆：割接为什么让人又怕又烦 在核心网机房干过的人，都有一段相似的记忆：变更窗口定在凌晨零点到四点，晚上十点集结开会，二十多项前置检查一条条过，割接脚本打印出来钉在白板上，十几个人盯着大屏上的 KPI 曲线，谁也不敢先去眯一会儿。割接顺利，凌晨四点解除变更、各自回家；割接不顺利，天亮之前总有人开始盘算「要不要回滚」——这是整个行业最煎熬的十分钟。 割接的本质矛盾在于：**风险越集中的操作，越只能放在业务低峰，而业务低峰意味着人最疲惫的时刻**。传统电信设备的软件升级是「整机替换」思路——网元要重启，重启就要中断，中断就必须找窗口。窗口资源极其稀缺：大型省网的维护窗口一周就那么几个晚上，还要给例行维护、硬件扩容、传输调整排队。于是升级被压成大包大揽：半年攒一堆功能，一次换完，风险高度集中。 回看这几年本栏目复盘过的多起重大断网事故——无论是路由器维护引发的全国性瘫痪，还是一次软件包放倒全网九小时——相当一部分都发生在「变更」这个环节。变更管理水平，直接决定一个网络的可用性上限。这也是为什么「在役升级」这几年从概念变成商用：它不是锦上添花的自动化点缀，而是把风险敞口从「一次全量、凌晨执行、人工兜底」改造成「小步快跑、随时执行、流水线兜底」。 ## 二、权威锚定：爱立信说的 ISSU 到底是什么 本文的解读主轴，是爱立信官方渠道的一系列一手材料，先把来源说清楚： 2019 年 12 月，爱立信官方博客发表《In-Service Software Upgrade: A relief planning for 5G》，明确提出：**ISSU 配合金丝雀测试（Canary Testing），是核心网降低运维成本的关键特性，也是 5G 服务敏捷性的使能器**。这篇文章的观点很直白——5G 核心网既然是云原生的，升级就该像互联网服务一样滚动推进，而不是靠停机窗口。 ISSU 的字面意思是「在役软件升级」：在网元承载真实业务的同时，完成软件版本从旧到新的更换，用户无感知。它的玩法对互联网工程师来说毫不陌生，就是滚动升级（Rolling Update）加灰度发布（Canary Release）的组合拳： - **不整体停机**：一个网元功能（NF）由多副本承载，升级时逐个副本换版本，任一时刻都有旧版本在跑业务； - **金丝雀先行**：先升级小比例节点，观察真实流量的 KPI 表现，达标后再放量； - **门限自动卡控**：注册成功率、会话建立成功率等指标一旦越限，立即停止放量甚至回滚。 需要强调的是：博客讲的是理念与架构方法，属于厂商观点；而下面第三节的三张商用答卷，是可验证的事实。两者分开看。 ## 三、三张商用答卷：Elisa、TPG 与 Telefónica ### 案例一：Elisa——欧洲第一个吃螃蟹 2023 年 3 月，爱立信与芬兰运营商 Elisa 联合宣布：在 Elisa 的**商用生产 5G SA 网络**上成功部署 ISSU 能力，Elisa 由此成为**欧洲首个**在现网 5G SA 网络上落地该能力的运营商。据爱立信官方通稿，该能力通过「持续交付与部署（Continuous Delivery and Deployment）」模式交付，Elisa 可以在不中断客户业务与体验的情况下高效升级核心网软件。这一消息被 CXOtoday、Voice&Data 等多家行业媒体转载交叉证实。 ### 案例二：TPG Telecom——70% 提速与供应商解放 2024 年 2 月 25 日（MWC24 期间），爱立信发布通稿：澳大利亚 TPG Telecom（旗下拥有 Vodafone、iiNet 等品牌）在其双模 5G Core 的网元功能上成功实现自动化 ISSU，官方称之为「5G Core 与云原生技术内软件自动化的一种新架构方法」。两个关键数字值得划线： - 相比此前的升级机制，**升级执行时间缩短 70%**； - **消除了升级时对外部供应商到场支持的依赖**。 第二点容易被忽视，但对运维团队意义巨大。传统割接的隐形成本之一，就是每次大版本升级都要协调设备商专家到场、跨时区支持、按人天计费的服务单。TPG 核心网应用总经理 Clinton Fick 在通稿中说得很清楚：自动化提升了网络效率，更重要的是「把员工的时间重新投向网络其他关键领域的创新与投资」。爱立信澳新区负责人 Emilio Romeo 则将其定位为「网络管理敏捷性与效率新时代的开端」。 ### 案例三：Telefónica——用户面上的实践 西班牙 Telefónica 在其官网技术博客发表《ISSU or how to upgrade network software without disrupting operations》，介绍了与爱立信合作、由 O2 承载的实践：在 5G 核心网**用户面**（负责业务流量传输的部分）上使用 ISSU，实现不中断运营的软件更新。这篇文章未标注具体商用日期，但把用户面单独拿出来讲，恰恰说明了一个行业共识：用户面承载全部流量、吞吐压力大，是「边跑边换」最难啃的骨头之一。 ### 三案例横向对比 | 维度 | Elisa（芬兰） | TPG Telecom（澳大利亚） | Telefónica（西班牙） | |---|---|---|---| | 公开时间 | 2023 年 3 月 | 2024 年 2 月 25 日 | 日期未注明 | | 落地范围 | 商用 5G SA 现网 | 双模 5G Core 网元功能 | 5G 核心网用户面 | | 关键成果 | 欧洲首个商用 5G SA 网 ISSU；业务零中断 | 升级执行时间快 70%；无需外部供应商到场 | 用户面不中断更新实践 | | 交付模式 | 持续交付与部署（CD/CD） | 自动化 ISSU | 与爱立信合作实践 | | 管理层定位 | 云原生数字化转型关键一步 | 员工时间转向创新投入 | 不中断运营的软件升级 | 三张答卷的时间线很说明问题：2023 年欧洲首个现网落地，2024 年 MWC 期间就作为成熟案例登台——ISSU 从概念验证到规模商用的间隔，比行业以往任何一次核心网架构变革都要短。 ## 四、原理拆解：核心网凭什么能边跑边换 传统 EPC 时代不是没人想做在役升级，是做不到。5G 核心网能做，靠的是四层地基： **第一层：云原生化。** 5G 核心网 NF 被拆成微服务，跑在容器平台之上。升级一个 NF，本质上是替换容器镜像并滚动重建 Pod——这是互联网行业已经跑了十年的成熟动作。旧版本副本摘流、销毁，新版本副本起苗、挂流，业务在版本间无缝过渡。 **第二层：计算与状态分离。** 滚动升级的前提是「副本随时可死可生」，那就要求网元尽量无状态：会话上下文、签约数据外置到统一数据层与冗余备份节点。状态不在计算节点本地，重建副本才不丢业务。 **第三层：3GPP 定义的池化与冗余。** 3GPP TS 23.501（5G 系统架构）定义了 AMF 集合（AMF Set）、备份 AMF 选择等机制，终端在接入侧就带有冗余锚点。同一集合内部分节点升级换代时，信令可以由集合内其他成员继续承载。需要说明的是，标准允许多种实现，各网元在升级期间的精细化行为以各厂家官方文档为准——这也是为什么灰度验证永远不能省。 **第四层：金丝雀与门限。** 前三层解决「能不能换」，第四层解决「敢不敢换」。真实生产流量按小比例打到新版本上，KPI 门限自动盯守——爱立信 2019 年那篇博客强调的 Canary Testing，就是这层安全网。 把四层串起来，一次典型的在役升级是这样推进的： ```mermaid flowchart TD S["割接启动：在役升级流水线"] --> C1["前置检查全项通过"] C1 -->|通过| B1["批次1：灰度百分之五节点"] C1 -->|失败| AB["中止本次升级"] B1 --> K1["KPI观察10分钟"] K1 -->|达标| B2["批次2：放量至百分之三十"] K1 -->|越限| RB["仅回滚已升级批次"] B2 --> K2["KPI观察10分钟"] K2 -->|达标| B3["批次3：全量推进"] K2 -->|越限| RB B3 --> V["全量后观察四小时"] V --> R["升级结束：无需停机窗口"] ``` 注意回滚那一路：**只回滚已升级的批次**，未动过的百分之九十五业务毫无感觉。这就是灰度架构给运维人的底气——风险敞口被物理性地切小了。 ## 五、边界：哪些升级仍然要老老实实割接 把 ISSU 讲成万能药是不负责任的。以下几类变更，行业目前仍然依赖传统割接窗口，缺一不可： 1. **大版本不兼容升级**：涉及数据模型变更、网元服务架构大版本跨越、UDR 数据迁移的升级，新旧版本无法稳定混跑，灰度无从谈起，只能整体切换。 2. **底座平台变更**：容器平台版本、操作系统内核、网络插件这类底座升级，动的是所有 NF 共同站立的地板，必须统一窗口处理。 3. **硬件与机房级操作**：板卡更换、机框下电、机房搬迁、传输电路调整——物理世界的活儿，永远叫割接。 4. **license 与容量联动变更**：软件版本与授权容量强耦合的变更，错一步就是业务挂死，宁可窗口里做。 业界一条血泪共识值得写进每本运维手册：**升级失败的最大损失，往往不在新版本本身，而在回滚路径没有预先打通**。这也是为什么即使 ISSU 时代，传统割接方法论仍然要传承——下面的八步军规，就是为此准备的。 ## 六、割接夜八步军规与标准时间线 以 18 年一线经验打底，我把核心网割接归纳为八步，每一步都对应一个具体的交付物，缺件不开工： 1. **方案三级评审**：方案文档、操作脚本、回滚预案三件套，分别经科室、部门、网络口评审签字，交付物是签字版方案。 2. **基线采集**：割接前至少一周，连续采集注册成功率、会话建立成功率、切换成功率、话务量等核心 KPI 的同时段基线——没有基线，割接后的「正常」就是一句空话。 3. **备份与回滚演练**：配置、数据、镜像、license 四类备份落库，回滚操作在测试环境完整演练过一遍，交付物是回滚演练记录。 4. **批次与门限设计**：把网元分成三个批次，明确每批的比例、每批的观察时长、每项 KPI 的越限门限，以及「谁有权限喊回滚」——这个人是事先指定的，不是现场推举的。 5. **前置检查**：版本号核对、license 有效期、磁盘容量、存量告警清零等二十余项，全过才开第一枪。 6. **割接执行三不原则**：不讨论新方案、不临时扩大范围、不跳步执行。窗口里只允许做窗口前写好的事。 7. **验证与解除**：拨测、话务对比、KPI 与基线比对全部达标后，正式解除变更、解冻工单。 8. **观察班与复盘**：解除不等于结束，72 小时观察班值守，复盘报告一周内归档。 对应的夜间时间线如下： | 时点 | 动作 | 关键交付物 | |---|---|---| | T-7 天 | 方案终审、基线采集启动 | 签字版割接方案 | | T-1 天 | 备份完成、回滚演练、工单冻结公告 | 回滚演练记录 | | T-30 分钟 | 二十余项前置检查 | 检查单全过截图 | | T0 | 批次 1 灰度执行 | 批次 1 操作日志 | | T+15 分钟 | KPI 门限评估，决定放量或回滚 | 门限评估记录 | | T+1 小时 | 批次 2 放量 | 批次 2 操作日志 | | T+2 小时 | 全量推进 | 全量操作日志 | | T+4 小时 | 拨测验证、解除变更 | 解除变更通告 | | T+72 小时 | 观察班值守结束、复盘归档 | 复盘报告 | ```mermaid timeline title 割接夜标准时间线 22点 集结 : 变更会交底 : 基线拨测确认 23点 前置检查 : 版本与license核对 : 备份与回滚包就绪 0点 割接执行 : 批次推进 : KPI门限盯守 2点 业务验证 : 注册与呼叫拨测 : 话务与基线比对 4点 解除变更 : 观察班交接 : 复盘排期 ``` ## 七、从人扛到流水线：CI/CD 进核心网 Elisa 案例里那个容易被忽略的词——「持续交付与部署模式」——其实指向了比 ISSU 更大的图景。传统割接是「项目制」：攒需求、排窗口、一次性切换；CI/CD 是「流水线制」：软件包从研发产出就进入制品库，经自动测试、灰度、门禁，小步流入现网。变化的不只是工具，是**变更的组织方式**：从十几个人守一夜，变成几个人盯流水线。 TPG 的「无需外部供应商到场」正是这条路线的终点站之一：升级能力内化进运营体系，运维团队重新掌握变更主导权。爱立信官网也已将 CI/CD 作为独立的主题栏目运营，面向运营商推广核心网的持续交付实践。沿着这条路线往下走，就是本栏目此前写过的自智网络高阶自治——但不必把愿景拉太远，眼前的台阶很清晰：先把灰度、门限、自动拨测这三件事做进流水线，割接的「夜」就会一天天变亮。 ## 八、写在最后：给运维人的三条建议 **第一，能在役升级的先在役，不能在役的把割接做轻。** 推动设备商明确每类变更的支持边界，能走滚动升级的绝不走停机窗口；必须停机的，把批次切得更细、单批影响面压到最小。 **第二，回滚路径先于升级路径设计。** 每一次变更申请，先答「怎么退回来」，再答「怎么切过去」。答不出回滚方案的变更，方案写得再漂亮也不该上会。 **第三，把 KPI 门限写进流水线，而不是写在值班群里。** 门限一旦是口头约定，执行时就一定会被「再观察一下试试」逐渐击穿。让机器卡门限，人只做机器解释不了的判断。 凌晨四点的机房不会消失，但它应该越来越少地出现在核心网升级的日历上。当「割接」从一场战役变成一条流水线上的一次例行过站，运维人才算真正把时间买了回来——用 TPG 那句话说，投向创新，而不是投向黑夜。 ## 参考来源 1. [TPG Telecom automates software and security updates with new Ericsson upgrade](https://www.ericsson.com/en/press-releases/7/2024/tpg-telecom-automates-software-and-security-updates-with-new-ericsson-upgrade) — 爱立信官方通稿（2024-02-25），TPG 双模 5G Core 自动化 ISSU、升级执行时间缩短 70%、无需外部供应商到场 2. [In-Service Software Upgrade: A relief planning for 5G](https://www.ericsson.com/en/blog/2019/12/in-service-software-upgrade-a-relief-planning-for-5g) — 爱立信官方博客，ISSU 与金丝雀测试（Canary Testing）的核心理念 3. [Elisa and Ericsson launch In-Service Software Upgrade in live production 5G Standalone network](https://www.ericsson.com/en/press-releases/3/2023/elisa-and-ericsson-launch-in-service-software-upgrade-in-live-production-5g-standalone-network) — 欧洲首个商用 5G SA 现网 ISSU，持续交付与部署模式 4. [ISSU or how to upgrade network software without disrupting operations](https://www.telefonica.com/en/communication-room/blog/issu-upgrade-network-software-disrupting-operations/) — Telefónica 官网博客，5G 核心网用户面 ISSU 实践 5. [3GPP TS 23.501: System architecture for the 5G System (5GS)](https://www.3gpp.org/dynareport/23501.htm) — 5G 系统架构标准，AMF 集合与备份 AMF 等冗余机制的定义 --- > 本文由「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 等场景全覆盖。