大多数关于WiFi网络实名认证系统的讨论集中在选型和部署阶段——选哪个平台、怎么接入网络、认证方式用哪种。但一套系统上线之后，才是真正的麻烦开始。这篇文章从运维两年以上的视角出发，说说那些在第一年没有暴露、但在第二年开始慢慢显现的问题。

账号库越来越大，清理越来越难

任何实名认证系统都面临账号生命周期管理的问题。企业里员工离职了、学校里学生毕业了、园区里租户退租了，这些账号应该被禁用或删除。理论上，账号和数据源（HR系统、学工系统、PMS）同步的话，这些账号会自动失效。但实际情况是：同步往往是单向的、周期性的，而不是实时的；有些账号是手动创建的，根本没有对应的数据源；同步脚本跑了很久也没有人去验证它到底有没有正常工作。

两年下来，账号库里可能堆积了大量的"僵尸账号"——账号存在、状态是启用，但对应的人已经不在了。这些账号本身不一定会造成安全问题（因为密码还是那个密码，不会被轻易猜到），但会在审计时造成麻烦：系统里显示的"活跃账号"比实际在用的多很多，当有人要求提供"当前在册用户列表"时，无法给出准确的数字。

清理账号的另一个难点是没有可信的参照数据。如果账号是从LDAP同步过来的，LDAP里有没有保留所有离职员工的记录？如果账号是手动创建的，当初创建时有没有记录归属部门和有效期？这些信息缺失时，清理工作就变成了一个半凭感觉的过程，很难系统化地推进。

日志量增长超出预期，存储压力越来越大

上线时对日志量的估算往往偏低。实际运行一段时间后，存储容量的消耗速度比预期快，尤其是在用户数增长或者流量策略放开之后。更换存储硬件或者扩容云存储都需要额外预算，而这笔钱在年初的预算里通常没有。

另一个问题是日志老化策略没有认真设计。要求保存6个月的日志，有的系统会在6个月后自动删除，有的不会——6个月前的日志一直留着，占用存储空间，但实际上已经超过了法规要求的保存期限，没有必要继续保留。日志老化策略如果没有配置好，在存储资源有限的情况下会反复出现"存储快满了"的告警，运维人员要花时间手动清理。

日志的完整性也是一个容易被忽视的运维问题。系统运行了一段时间后，有没有人定期检查日志是否真的在写入？有没有某段时间因为磁盘满了或者服务崩溃导致日志中断？如果真的出了事故需要溯源，发现那段时间的日志恰好是缺失的，是很麻烦的。建议设置日志完整性监控，每天自动验证日志写入量是否在合理范围内，如果某一天的日志量异常低，及时告警。

系统升级带来的兼容性风险

WiFi网络实名认证系统的厂商会持续发布版本更新，修复安全漏洞、添加新功能、调整接口。但每次升级对现有部署来说都是一个风险点：升级后Portal页的样式变了，用户认证行为改变；接口字段调整了，和第三方系统（LDAP、PMS、短信网关）的对接出了问题；某个曾经关闭的功能在新版本里默认开启了，改变了现有的认证策略。

真实案例：某学校升级了认证平台的小版本，升级后发现iOS设备上的Portal页弹出逻辑变了，从原来的自动弹窗变成了需要手动点击通知才能打开。这个变化在更新日志里根本没有提及，IT部门完全不知情，结果第一天有几百个学生反映"WiFi弹不出来认证"，运维团队花了半天时间才定位到是升级导致的。

建议建立版本升级评审机制：每次升级前，在测试环境先验证认证流程的关键路径（Portal弹出、认证完成、漫游保持）；升级操作安排在低峰时段；升级后的第一个工作日保持值班，关注用户反馈。不要把认证系统当作"升级了就升级了"的无关紧要组件，它的任何行为变化都会直接影响到用户的上网体验。

运维人员流失导致的知识断层

系统上线时，通常有1到2个IT人员深度参与了实施过程，熟悉系统架构、配置细节、各种踩过的坑。这些知识大量存在他们脑子里，没有文档化。一旦这2个人离职，接替的人员就要从零开始摸索，遇到问题只能联系供应商，而供应商的响应速度和质量参差不齐。

这个问题在IT基础设施里普遍存在，但认证系统这类"关键路径"组件上尤为突出，因为它一旦出问题，影响范围大，定位和修复的时间压力高。建议在系统稳定运行3个月后，由当时的实施负责人输出一份运维手册，至少覆盖：系统架构图、关键配置参数清单、常见故障排查步骤、供应商联系方式。这份文档不需要很精致，但要真实、准确、可操作。

认证方式跟不上用户习惯变化

两年前上线时选择的认证方式，在今天可能已经过时了。比如，两年前短信验证码是主流认证方式，用户接受度高；但现在越来越多的用户厌倦了等待短信，更希望扫微信二维码或者刷脸就能完成认证。如果系统在上线时没有预留扩展认证方式的能力，现在升级就需要较大改造，或者干脆换平台。

另一个变化是对"免认证"范围的预期。两年前的标准是内网设备（如打印机、投影仪）不需要认证；但随着安全意识提升，现在越来越多的场所要求所有设备都走认证，包括IoT设备和会议室大屏。这些设备不支持Portal认证，需要走MAC地址白名单或者802.1X证书认证，而这两种方式的配置复杂度都比Portal认证高很多。认证系统如果当初没有支持这些方式，现在要补，改造工作量不小。

合规要求在悄悄变化

WiFi实名认证的合规要求不是静止的。近两年，对日志字段的要求、对日志存储时长的要求、对认证页面信息展示的要求都有不同程度的调整。当初按照旧标准建设的系统，有些地方需要更新才能满足新要求。问题是，运维团队通常不会主动去跟进合规标准的变化，除非主管部门来检查。

建议每年做一次合规自查，对照当前有效的规定，检查认证系统的几个核心点：Portal页运营主体信息是否完整、日志字段是否覆盖最新要求、存储时限是否满足、实名认证深度是否达标。不要等到被动检查才发现问题，那个时候整改的时间压力会很大。

运维阶段的问题不如部署阶段的问题显眼，但积累到一定程度，处理起来一点都不比重新部署一套系统省力。把这些长期问题提前纳入系统生命周期管理，才能让这套基础设施真正长期跑稳。