WiFi认证系统上线首月运维节奏：从割接盯防到日常化

一套 WiFi认证系统 从割接上线到进入日常运行，中间通常要经过一段不算短的磨合期。很多单位把上线当成终点，割接当天盯紧一点，第二天就恢复原班人马做别的事，结果第三周开始投诉集中冒出来：有人连不上、有人认证完弹不出页面、有人换了手机就上不了网。这些问题不是系统本身坏了，而是上线首月的运维节奏没有踩对。

上线首月和日常运维最大的区别，在于这个阶段暴露的问题密度远高于稳态期。日常运行时，认证系统每天处理的是相对规律的请求，用户结构、终端类型、使用时段都已经被摸过一遍；而上线初期，所有用户都是第一次接触这套认证流程，手里的终端五花八门，操作系统版本、浏览器、无线网卡驱动都在变化，同样一套配置在不同手机上表现可能完全不同。把这段时间当成普通运维期，按常规节奏巡检，问题就会在用户端攒着，最后变成集中投诉。

第一周的核心任务是把异常流量看住。割接完成后的头几天，不要急着做策略调优，先把认证系统的实时在线数、认证成功率、认证失败原因分布这几个基础指标盯起来。一台 Portal 系统在设计上每秒可以处理数千次认证请求，Radius 侧同样有对应的处理能力，但真实环境里能不能跑满这个数字，要看出口链路、AC/AP 设备和后端联动是否通畅。第一周要做的事，是在真实用户流量下确认这些指标和预期是否一致，有没有某个时段成功率明显掉下去，有没有某一类终端集中失败。

失败原因分布比成功率本身更值得看。成功率 99% 听起来不错，但如果剩下那 1% 里有一半都是同一种原因，比如某品牌手机的无线网卡驱动在特定信道下关联不稳定，或者某个浏览器版本在 Portal 跳转时丢了参数，那这就是一个可以定位的具体问题，而不是笼统的"网络不好"。把失败原因按终端类型、操作系统、时段、认证方式拆开看，第一周就能收敛掉一批和终端兼容性相关的工单。

第二周开始处理流程类问题。认证系统跑稳之后，用户问得最多的往往不是技术故障，而是流程：账号怎么开通、密码忘了怎么办、换了手机号怎么改、访客账号在哪里申请、为什么自己的手机连上 WiFi 却上不了网。这些问题如果没有一个清晰的自助流程和标准答复，就会全部涌到网管和前台。上线首月应该把这些高频问题整理成简短的说明，放在认证页面上，或者做成自助入口，让用户能自己解决掉大部分常见疑问，而不是每一个都打服务台电话。

第三周是策略校准期。前两周收集到的真实使用数据，这时候可以用来反推最初的策略配置是不是合理。比如一开始为了安全把 MAC 无感知的有效期设得很短，结果大量用户每次回到办公区都要重新认证，投诉量上升；或者一开始把访客带宽限得太低，访客开个网页都转圈。这些不是系统能力问题，而是策略参数没有结合真实使用习惯校准。校准策略时要一条一条改，改完观察一两天，不要一次动一堆参数，否则出了问题分不清是哪条改动引起的。

第四周做一次完整复盘。把这一个月里的工单分类统计：有多少是终端兼容、多少是流程不清、多少是策略不当、多少是真故障、多少是外部链路（短信通道、运营商 AAA、PMS 对接）波动。这个分布决定了接下来的运维重点在哪里。如果工单里终端兼容占大头，说明需要针对常见机型出一份连接指引；如果外部链路波动占大头，就要和对应服务商约定故障响应方式；如果策略类问题占大头，就要把策略调整成更符合实际使用习惯的默认值。

首月还要特别留意认证日志的留存是否完整。一套 WiFi认证系统 不只是让用户连上就行，它同时承担着把账号、终端、IP、MAC、在线记录关联起来的责任。首月是验证日志链路是否畅通的好时机：用户认证成功之后，对应的日志有没有写进去，退出网络之后记录有没有闭合，时间戳是不是准确，这些在合规检查和故障追溯时都会被翻出来。如果首月发现日志有缺口，趁数据量还不大赶紧补配置，等到半年后公安检查再发现缺日志，补都补不回来。

运维责任也要在首月明确下来。认证系统涉及网管、前台、IT 支持、甚至安保几个部门，出了问题谁接电话、谁看后台、谁联系厂商，不能等故障发生了再临时指派。首月把一个简单的值班和升级机制跑通：一线先看常见自助问题，二线看后台日志和在线状态，三线联系厂商技术支持，每一级明确什么情况下往上转。这个机制跑过几次真实工单之后，后面就顺了。

上线首月不是验收期，而是把系统从"能跑"调到"好用"的关键窗口。这段时间投入的运维精力，会在之后一两年的稳态运行里持续回收——早期把终端兼容问题、流程问题、策略问题、日志问题处理干净，后面日常运维就只剩下例行巡检。反过来，首月图省事把问题拖过去，这些问题不会自己消失，只会在某个业务高峰或者合规检查时集中爆发。