网络准入系统上线之后，很多运维团队的日常就是"看看在线用户数"、"看看有没有报错"。这种盯法没问题，但不够。

准入系统真正值得关注的指标有三个，这三个要是出问题，用户那边会直接感知到。

指标一：认证成功率

用户发起认证，最终有多少比例能成功通过？正常应该在99%以上。如果某天突然掉到95%，不用等用户报修，自己先查。

认证失败的原因有很多：密码错误、终端被限制、账号欠费、设备不支持某种认证协议。问题不同，处理方式也不一样。密码问题让用户重置，终端被限要看策略配置，账号欠费要走计费流程，设备不支持则可能需要换认证方式。这里有个细节：有些哑终端的认证失败不是"故意"的，而是设备启动时发了一次认证报文但那时候还没连上，后台就记了一条失败记录。这种情况要结合上下文看，别当成真实的用户认证失败来处理。

指标二：认证响应时间

用户输入密码点登录，到页面跳转出来，这中间花了多少秒？超过5秒用户就会觉得"卡"，超过10秒就可能反复刷新，反而增加服务器负担。

响应时间变长的原因通常有几个：RADIUS服务器负载高、网络延迟、数据库查询慢、Portal页面加载慢。这里有个常见的坑：有些系统白天跑得挺顺，晚上突然变慢。查了一圈发现，是凌晨有定时任务在跑报表或者做日志归档，占用了大量数据库资源。这种情况可以通过错峰执行或者加缓存来优化，但不能靠"重启试试"来解决——重启完了定时任务还在，迟早再堵一次。

指标三：并发认证峰值

每天的总认证次数不重要，重要的是"峰值时系统能不能扛住"。早高峰、午高峰是典型的高并发时段，几百人同时认证，这时候系统的表现才是真实水平。

如果峰值时响应时间明显拉长，说明系统瓶颈已经出现了。常见原因是RADIUS处理能力不够，或者数据库连接池配置偏小。这时候要看系统的"每秒并发认证数"指标，有没有达到当初选型时承诺的值。选型时吹的牛，上线后要用数据来验证，不是光靠感觉。

三个指标盯好，日常运维的核心就抓住了。剩下的都是细节问题，哪里有报修修哪里，不用过度焦虑。