计费系统升级换代，是所有学校信息中心最不想面对但又迟早会面对的事。换了领导、厂商跑路、技术栈老化、新需求老系统撑不住——总有各种原因逼着你换。但跟换个核心交换机不一样，计费系统割接，中间任何一个环节出错，就意味着全校几万人上不了网。不能把全校师生的上网服务当成夜间割接窗口里赌一把的事。我见过成功的案例，也见过割接失败导致全校断网两天的惨剧。

割接前必须确认的三件事，少一件都不要动

第一件事：用户数据的完整性和可迁移性。老系统里的用户数据能不能完整导出来，格式能不能被新系统正确解析，这是割接的基础。很多老系统的账户数据是散落在好几张表里的：用户基本信息在user表，套餐关系在package_binding表，余额在account_balance表，实名认证信息在realname_auth表，上网日志在radius_log表——这些表的关联关系不一定都是标准的外键约束，有时候靠应用层逻辑维护，数据库层面的关联是断的。如果导出工具只是简单select，很可能丢数据。所以割接前必须花时间做一次全量数据导出校验，把老系统和新系统的字段一一对照，缺了哪个字段、哪个字段类型对不上，都要提前记下来、想好怎么转换。

第二件事：认证协议的兼容性。校园网计费系统对用户来说只有一个入口，就是认证页面。不管你后台换成了什么，用户打开浏览器连WiFi跳到Portal页面这个过程不能变。但老系统可能用的是私有Portal协议，新系统用的标准RADIUS或者HTTP重定向方式，两者之间的认证流程不一定完全对齐。如果老系统的Portal服务器和RADIUS服务器是分开部署的，割接的时候可以考虑先把Portal留着不动，只切后端的RADIUS计费引擎，用户侧的认证体验完全不变。等新系统跑稳了，再分批次切Portal。

第三件事：出口设备侧的配置同步。很多割接失败的原因不在计费系统本身，而在它跟核心网络设备的对接上。新系统上线后，BRAS或者AC上的RADIUS服务器地址、shared secret、计费更新间隔、COA端口这些参数全部要改。改错了或者漏改了，就会出现认证页面能打开，但点登录永远转圈的情况。所以割接方案里必须有一份详细的网络设备配置变更清单，每台设备改什么参数、回滚的时候怎么改回来，全部列清楚，不要指望割接当天现场翻设备配置。

三种割接策略，风险和代价不一样

第一种是"一次性全切"，选一个夜深人静的窗口把所有用户、所有设备、所有配置一口气切到新系统。优点是干净利落，没有新旧系统并存的维护成本。缺点是风险集中，任何一个环节出问题就直接炸。适合用户规模不大、割接经验丰富的学校。

第二种是"分批迁移"，先把一批测试用户或者志愿者切过去跑一到两周，确认没大问题后再全量切换。优点是风险分散，新系统先接受小规模真实场景的检验。缺点是需要同时维护两套系统，而且两套系统之间可能有数据同步的问题——老系统还继续在计费，新系统也在计费，两边对不上怎么办。

第三种是"新老并行运行"，保留老系统的所有配置不动，新系统独立部署一套完整的认证计费链路，通过出口路由策略把一部分用户流量引到新系统。等新系统跑满一个计费周期（通常是一个月）确认账务数据全部对齐后，再把老系统下线。这是最稳妥的做法，代价是硬件资源翻倍、需要两套RADIUS和两套Portal同时运行。

割接当天必须有的回滚预案

不管你选哪种策略，割接当天的回滚预案是底线。回滚的关键不是"把新系统关了就行"，而是老系统的状态必须能立刻恢复到割接前。这意味着在割接开始前，老系统要先做一个全量配置备份和数据库快照，包括RADIUS配置、Portal配置、用户数据、套餐规则、计费策略全部导出。同时所有网络设备的当前运行配置（running-config）也要做备份。如果新系统上线后十分钟内发现大面积认证失败，立刻执行回滚：网络设备恢复老配置、DNS把Portal域名指回老服务器IP、老系统从快照恢复启动。

回滚最大的难点是数据回退：新系统上线后已经有用户在认证、在计费了，这些新产生的数据要不要保留？如果不保留，回滚后这些用户需要重新认证，会产生一波集中的客服电话。如果保留，就得在回滚前把新产生的数据快速导回到老系统，这个操作本身也有风险。比较务实的做法是：割接窗口内产生的少量计费数据直接放弃，大不了给这批用户手工补偿几天免费上网。不要让回滚路径因为数据迁移而复杂化。

割接后的观察期

很多学校觉得割接成功、全校能上网了就完事了。实际上割接后的第一个计费周期才是真正的验收期。这个周期里至少要盯三件事：第一，日终对账报告有没有异常，余额结转对不对；第二，套餐切换有没有bug，尤其是月中切换套餐的折算逻辑是否正常；第三，月底批量操作（销户、批量充值）在新系统上能不能正常跑通。等到走完一个完整计费月、所有账务数据跟预期一致，才算真正完成割接。