校园网更换网络Portal认证系统的割接实操：并存、分流、回滚

校园网换认证系统，最难的从来不是新系统本身，而是割接——旧AAA还在跑，几万学生的账号在里面，新Portal认证系统要接管认证入口，怎么换才不出事故？这类项目没有一键迁移的捷径，靠的是并存、分流、割接、回滚这套节奏。这篇把节奏里的每个环节掰开讲。

先明确一个前提：割接之前，新旧系统必须先并存。直接停旧上新，等于拿全校的上网服务做赌注。并存期的形态是：旧AAA继续服务存量用户，新认证计费平台同步部署并完成对接，Portal、802.1X、历史账号体系多种认证入口在这个阶段同时在线。并存不是浪费，它是新系统在真实流量下验证自己的唯一机会——对接参数、认证链路、计费口径，都要在这个阶段跑通，跑不通就还没到谈割接的时候。

并存期最关键的配置是Radius Proxy。它承担请求转发、协议透传、策略衔接：新平台的认证请求经过代理与旧系统或运营商AAA交互。这个环节的功课要做扎实：认证属性映射必须联调验证，新旧系统对属性的要求对不上，认证直接失败；计费字段的一致性同样要验，两边记的时长流量口径不一致，割接完对不上账；失败回退路径要提前定义——某一侧不可用时用户走哪里，是拒绝还是降级，不能等出了事再临时决定。

分流是并存期的执行策略。哪些用户切到新系统、哪些还留在旧系统，按什么维度切，要提前设计：按年级切、按宿舍区切、按账号批次切，都是常见做法。分流粒度越细，单次切换的影响面越小，出问题时的定位也越快。每个批次切过去之后，盯一段时间的认证成功率和工单量，稳定了再放下一批。校园网的特殊性在于有天然的低峰窗口——寒暑假、周末，大批次切换尽量排在这些窗口里；实在赶不上假期的，也至少避开开学注册周和考试周这两个网络使用的尖峰时段，割接窗口和业务尖峰撞在一起，任何微小的异常都会被放大成群体性事件。

回滚机制是割接方案里最不能省的部分。割接窗口选在业务低峰，回滚方案要在割接前演练过，而不是出问题后现想。回滚的触发条件也要量化：认证成功率跌到多少、工单量涨到多少，就执行回滚，不靠现场拍脑袋。回滚本身要快——旧系统在并存期一直在线，就是为了这一刻能切回去。没有演练过的回滚方案，等于没有回滚方案。

校园网的割接还有一层复杂度：出口往往接着多家运营商。每家运营商的BRAS、AAA接口、账号体系、策略规则都不一样，割接时每条链路要单独验证——协议是否匹配、BRAS和AAA的配合条件是否具备、账号体系能不能对上。单条链路验证通过的结果，不能外推到其他链路，这是多运营商场景的铁律。涉及和运营商结算的，认证日志、拨号日志、计费日志三本账要能对上，割接期间数据断档，月底就是对不清的糊涂账。

账号数据的迁移核验是割接的另一条主线。存量账号从旧AAA迁到新平台，不是导出导入完事——字段映射先定清楚，旧系统的账号属性、套餐信息、余额和到期时间，迁到新平台对应哪些字段，两边口径逐项核对；迁移完成后做抽样核验，随机抽一批账号在新系统里查信息，和旧系统的记录比对，余额、到期时间、状态三项必须一致。计费历史要不要迁、迁多少，按审计和争议处理的需要定，网络安全法要求的日志留存不少于六个月，这条线上的数据迁移前后都不能断档。割接期间新旧系统各自产生的记录，归档时要能拼出完整时间线，否则月中割接的项目，月底结算时两边的账拼不起来。

监控指标也要在割接前定义好：认证成功率、认证时延、工单量三个数，割接窗口内按小时盯。哪个数越过阈值就触发预案——先分流回旧系统稳定业务，再排查新系统的问题，顺序不能反。业务稳定永远排在问题排查前面，这是割接夜的基本纪律。按小时记录的指标曲线还有事后价值：割接复盘时它是唯一的客观依据，哪个时段出的波动、持续了多久、恢复动作是什么，全都对得上号。

这类项目有几个坚决不能做的承诺：零改造直接迁移、无需联调即可上线、任意旧系统都能无条件对接。真实施工就是分阶段推进——先并存、再分流、再割接，每一步靠映射规则、联调计划和回退方案的完整性撑着。节奏对了，一个学期到一年能把这件事平稳做完；节奏不对，每年开学季都是事故高发期。

割接完成的标志不是新系统上线，而是旧系统能够安全下线：账号数据完整迁移核验、历史记录可查、旧设备退网。到这一步，才算真正换了认证系统。把割接当作一个项目管理过程而不是一次技术操作——想通了这一点，这类项目就算真正落地了。