概述：割接窗口，是通信运维人又爱又恨的四个字。本文回答一个具体问题：核心网升级，能不能不再靠凌晨停机窗口赌一把？本文以爱立信官方博客与三家运营商的商用实践为主轴，拆解 ISSU（In-Service Software Upgrade，在役软件升级）如何让 5G 核心网「边跑边换」：芬兰 Elisa 成为欧洲首个在商用 5G SA 网络部署 ISSU 的运营商；澳大利亚 TPG Telecom 实测升级执行时间缩短 70%、彻底告别外部供应商到场；西班牙 Telefónica 则在用户面上完成了实践。同时，本文也保留并整理传统割接的「八步军规」——因为 3GPP 标准允许多种实现，并不是每一次升级都能在役完成，割接纪律仍然是运维人的看家本领。
在核心网机房干过的人，都有一段相似的记忆：变更窗口定在凌晨零点到四点，晚上十点集结开会，二十多项前置检查一条条过，割接脚本打印出来钉在白板上，十几个人盯着大屏上的 KPI 曲线，谁也不敢先去眯一会儿。割接顺利，凌晨四点解除变更、各自回家；割接不顺利，天亮之前总有人开始盘算「要不要回滚」——这是整个行业最煎熬的十分钟。
割接的本质矛盾在于：风险越集中的操作，越只能放在业务低峰，而业务低峰意味着人最疲惫的时刻。传统电信设备的软件升级是「整机替换」思路——网元要重启，重启就要中断，中断就必须找窗口。窗口资源极其稀缺：大型省网的维护窗口一周就那么几个晚上，还要给例行维护、硬件扩容、传输调整排队。于是升级被压成大包大揽：半年攒一堆功能，一次换完，风险高度集中。
回看这几年本栏目复盘过的多起重大断网事故——无论是路由器维护引发的全国性瘫痪，还是一次软件包放倒全网九小时——相当一部分都发生在「变更」这个环节。变更管理水平，直接决定一个网络的可用性上限。这也是为什么「在役升级」这几年从概念变成商用：它不是锦上添花的自动化点缀，而是把风险敞口从「一次全量、凌晨执行、人工兜底」改造成「小步快跑、随时执行、流水线兜底」。
本文的解读主轴，是爱立信官方渠道的一系列一手材料，先把来源说清楚：
2019 年 12 月，爱立信官方博客发表《In-Service Software Upgrade: A relief planning for 5G》，明确提出：ISSU 配合金丝雀测试（Canary Testing），是核心网降低运维成本的关键特性，也是 5G 服务敏捷性的使能器。这篇文章的观点很直白——5G 核心网既然是云原生的，升级就该像互联网服务一样滚动推进，而不是靠停机窗口。
ISSU 的字面意思是「在役软件升级」：在网元承载真实业务的同时，完成软件版本从旧到新的更换，用户无感知。它的玩法对互联网工程师来说毫不陌生，就是滚动升级（Rolling Update）加灰度发布（Canary Release）的组合拳：
需要强调的是：博客讲的是理念与架构方法，属于厂商观点；而下面第三节的三张商用答卷，是可验证的事实。两者分开看。
2023 年 3 月，爱立信与芬兰运营商 Elisa 联合宣布：在 Elisa 的商用生产 5G SA 网络上成功部署 ISSU 能力，Elisa 由此成为欧洲首个在现网 5G SA 网络上落地该能力的运营商。据爱立信官方通稿，该能力通过「持续交付与部署（Continuous Delivery and Deployment）」模式交付，Elisa 可以在不中断客户业务与体验的情况下高效升级核心网软件。这一消息被 CXOtoday、Voice&Data 等多家行业媒体转载交叉证实。
2024 年 2 月 25 日（MWC24 期间），爱立信发布通稿：澳大利亚 TPG Telecom（旗下拥有 Vodafone、iiNet 等品牌）在其双模 5G Core 的网元功能上成功实现自动化 ISSU，官方称之为「5G Core 与云原生技术内软件自动化的一种新架构方法」。两个关键数字值得划线：
第二点容易被忽视，但对运维团队意义巨大。传统割接的隐形成本之一，就是每次大版本升级都要协调设备商专家到场、跨时区支持、按人天计费的服务单。TPG 核心网应用总经理 Clinton Fick 在通稿中说得很清楚：自动化提升了网络效率，更重要的是「把员工的时间重新投向网络其他关键领域的创新与投资」。爱立信澳新区负责人 Emilio Romeo 则将其定位为「网络管理敏捷性与效率新时代的开端」。
西班牙 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，就是这层安全网。
把四层串起来，一次典型的在役升级是这样推进的：
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 讲成万能药是不负责任的。以下几类变更，行业目前仍然依赖传统割接窗口，缺一不可：
业界一条血泪共识值得写进每本运维手册：升级失败的最大损失，往往不在新版本本身，而在回滚路径没有预先打通。这也是为什么即使 ISSU 时代，传统割接方法论仍然要传承——下面的八步军规，就是为此准备的。
以 18 年一线经验打底，我把核心网割接归纳为八步，每一步都对应一个具体的交付物，缺件不开工：
对应的夜间时间线如下：
| 时点 | 动作 | 关键交付物 |
|---|---|---|
| T-7 天 | 方案终审、基线采集启动 | 签字版割接方案 |
| T-1 天 | 备份完成、回滚演练、工单冻结公告 | 回滚演练记录 |
| T-30 分钟 | 二十余项前置检查 | 检查单全过截图 |
| T0 | 批次 1 灰度执行 | 批次 1 操作日志 |
| T+15 分钟 | KPI 门限评估，决定放量或回滚 | 门限评估记录 |
| T+1 小时 | 批次 2 放量 | 批次 2 操作日志 |
| T+2 小时 | 全量推进 | 全量操作日志 |
| T+4 小时 | 拨测验证、解除变更 | 解除变更通告 |
| T+72 小时 | 观察班值守结束、复盘归档 | 复盘报告 |
timeline
title 割接夜标准时间线
22点 集结 : 变更会交底 : 基线拨测确认
23点 前置检查 : 版本与license核对 : 备份与回滚包就绪
0点 割接执行 : 批次推进 : KPI门限盯守
2点 业务验证 : 注册与呼叫拨测 : 话务与基线比对
4点 解除变更 : 观察班交接 : 复盘排期
Elisa 案例里那个容易被忽略的词——「持续交付与部署模式」——其实指向了比 ISSU 更大的图景。传统割接是「项目制」：攒需求、排窗口、一次性切换；CI/CD 是「流水线制」：软件包从研发产出就进入制品库，经自动测试、灰度、门禁，小步流入现网。变化的不只是工具，是变更的组织方式：从十几个人守一夜，变成几个人盯流水线。
TPG 的「无需外部供应商到场」正是这条路线的终点站之一：升级能力内化进运营体系，运维团队重新掌握变更主导权。爱立信官网也已将 CI/CD 作为独立的主题栏目运营，面向运营商推广核心网的持续交付实践。沿着这条路线往下走，就是本栏目此前写过的自智网络高阶自治——但不必把愿景拉太远，眼前的台阶很清晰：先把灰度、门限、自动拨测这三件事做进流水线，割接的「夜」就会一天天变亮。
第一，能在役升级的先在役，不能在役的把割接做轻。 推动设备商明确每类变更的支持边界，能走滚动升级的绝不走停机窗口；必须停机的，把批次切得更细、单批影响面压到最小。
第二，回滚路径先于升级路径设计。 每一次变更申请，先答「怎么退回来」，再答「怎么切过去」。答不出回滚方案的变更，方案写得再漂亮也不该上会。
第三，把 KPI 门限写进流水线，而不是写在值班群里。 门限一旦是口头约定，执行时就一定会被「再观察一下试试」逐渐击穿。让机器卡门限，人只做机器解释不了的判断。
凌晨四点的机房不会消失，但它应该越来越少地出现在核心网升级的日历上。当「割接」从一场战役变成一条流水线上的一次例行过站，运维人才算真正把时间买了回来——用 TPG 那句话说，投向创新，而不是投向黑夜。
本文由「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 等场景全覆盖。