校园网认证系统部署完成后，验收环节容易被理解成"功能跑通了就行"。但在实际运维场景中，很多问题恰恰是在功能验收的简单流程里暴露不出来的。本文梳理几个上线前验收应该重点关注的维度。

一、多终端并发场景下的认证成功率

单台设备、单一浏览器的认证测试几乎不会出问题，但在真实环境里，开学季或者晚上高峰时段，几千台设备同时发起认证请求，情况就不一样了。

验收时需要有意识地模拟并发场景。不一定需要专业压测工具，哪怕组织几十个学生同时连 Wi-Fi、同时打开认证页面、同时提交登录，观察一下认证页面的加载速度和登录响应时间，也能发现一些单机测试看不见的问题。常见的问题包括 Portal 页面弹出延迟、认证服务器 CPU 飙高、Radius 报文丢包等。

无线环境下的漫游切换也是验收中容易被跳过的场景。学生拿着手机从教学楼走到宿舍楼，Wi-Fi 信号从一个 AP 切换到另一个 AP 的过程中，认证状态能不能无缝保持，还是需要重新登录一次，这直接影响实际使用体验。

二、异常场景的容错表现

认证系统正常流程跑通只是及格线，异常场景的处理能力才是区分方案成熟度的标志。

一个典型的异常场景是认证服务器宕机或者重启。在服务器恢复的过程中，已经在线的用户会不会被强制踢下线？新接入的用户是直接放行还是阻断？这个策略在设计文档里通常会写，但验收时要实地验证。

另一个常见场景是上游数据源故障。如果认证系统对接了教务或者一卡通系统，上游接口暂时不可用时，认证系统应该怎么处理？是拒绝所有认证请求，还是使用本地缓存的数据继续提供服务，缓存的时效窗口设多长？这些策略验收时需要有明确的预期和测试手段。

还有日志和时间同步的问题。认证系统的日志是后续排查问题和审计的重要依据。验收时需要检查认证服务器的时间是否和标准时间源同步，日志的格式是否完整记录了用户 IP、MAC 地址、认证时间、认证结果等关键字段。时间偏差过大会导致日志在跨系统关联分析时失去参考价值。

三、策略下发的准确性

认证系统除了判断"能不能上网"，往往还承担着"能上什么网"的职责。不同用户分组对应不同的网络策略，比如学生默认不能访问校内部分管理网段，教职工在非工作时间有额外的带宽限制，访客只能访问互联网出口等。

验收时不能只看一个分组、一个策略生效就算通过。需要把每种用户角色、每种策略组合都走一遍。实际操作中可以准备一份策略矩阵表，逐行验证。重点验证的是策略变更后的生效速度：在管理后台修改了某个分组的策略后，该分组下已登录的用户是否需要重新认证才能应用新策略，还是可以实时生效。

另外要关注策略冲突的情况。如果一个用户同时属于两个分组，而两个分组对同一项策略的定义不一致，最终的生效结果是什么？这个优先级逻辑在方案中应该有说明，验收时需要验证实际行为是否与方案一致。

四、管理后台的权限粒度

信息中心负责认证系统日常运维的通常不止一个人。有人负责账号管理，有人负责策略配置，有人负责查看报表。管理后台如果只有一个超级管理员账号，所有人都用同一个密码登录，这在安全审计上是不合规的。

验收时需要确认管理后台是否支持多管理员账号、是否支持基于角色的权限控制。账号管理员只能创建和注销账号，不能修改网络策略；策略管理员只能配置策略，不能查看敏感日志。这种权限隔离在验收阶段配置好，后续运维才有基本的安全保障。

五、文档是否跟得上实际部署

最后一点经常被忽略，但对后续运维影响很大：部署文档和实际环境是否一致。供应商交付的文档里，网络拓扑图、IP 地址规划、端口配置信息应该和实际部署的完全一致。验收时如果发现有偏差，要求供应商更新文档远比上线后出了问题再去翻实际配置要省事。

验收不是走过场。把这几项盯住了，上线后的运维压力会小很多。