WiFi网络认证系统上线之后，进入长期运营阶段，很多问题是在这个阶段才暴露出来的：日志磁盘悄悄满了、短信网关余额用完了没人知道、某个AP固件升级导致认证方式不兼容、备份服务器上次切换后没有恢复……这些问题如果没有系统性的监控和巡检机制，往往要等到用户大量投诉了才能发现。把监控和运维规范做好，是认证系统平稳运行的保障。

监控体系应当覆盖哪些层面

认证系统的监控不是单一维度的，需要从基础设施、服务层、业务层三个层面同时覆盖。

基础设施层监控：服务器CPU、内存、磁盘使用率，网络接口流量，数据库服务状态，备份任务执行情况。这些是基础IT运维的标准监控项，大部分监控工具都能覆盖。需要特别注意的是磁盘使用率——认证日志会持续写入，如果磁盘满了，要么系统写入失败（合规日志丢失），要么认证服务崩溃。设置磁盘使用率70%/85%/95%三级告警，在达到满载前有足够的时间处理。

服务层监控：认证服务进程状态，RADIUS服务端口响应，Portal服务HTTP响应，数据库连接池使用率，外部依赖（短信网关、身份核验接口）的可用性。这层监控要做到进程级别，不只是机器存活就算正常——机器活着但认证进程挂了，同样是故障。

业务层监控：认证成功率、认证响应时间（P50/P95/P99）、在线用户数趋势、短信发送成功率。业务层指标直接反映用户的实际体验，也是最早发现异常的窗口。认证成功率突然从99%下降到90%，可能是外部依赖出了问题；认证响应时间P99突然上升，可能是数据库慢查询或并发压力增大。

告警规则的设计原则

告警规则设计有两个常见误区：告警太多（每件小事都告警，运维人员开始忽视告警）和告警太少（真正的问题没有覆盖）。合理的告警体系需要有优先级分层。

P0（立即响应）：认证服务不可用、RADIUS端口无响应、数据库服务宕机。这类告警发生后，应当在5分钟内触达到值班人员。

P1（小时内处理）：认证成功率下降超过5%、磁盘使用率超过85%、短信网关余额低于阈值、认证P99延迟超过5秒。这类告警发生后在一个小时内处理，不需要半夜打电话叫醒人，但要确保工作时间内有人看到。

P2（日常关注）：日志写入速率异常（可能表示日志压缩/归档出了问题）、备份任务失败、在线用户数与历史同期偏差超过20%。这类异常不影响当前运营，但需要在下一个工作日跟进排查。

短信网关的余额管理

短信余额耗尽导致认证失败，是让人哭笑不得但真实发生过的故障。用短信认证的WiFi网络认证系统，需要有短信余额的自动监控：低于X条时告警，低于Y条时再告警，彻底用完前确保有人知道并已处理续费。

合理的短信余额告警阈值取决于日均短信消耗量。如果日均发出1000条短信，告警阈值设在3000条（约三天消耗量）是合适的。设在500条就太晚了，处理续费的时间都不够。

配合短信余额监控的，是多服务商备份机制。主服务商短信发送失败时，自动切换到备用服务商，能有效降低短信服务中断的风险。两家服务商的短信费率通常不同，主服务商用便宜的，备用服务商接受稍高的价格，用量通常很小。

日常巡检清单

自动化监控覆盖的是已知的异常指标，但有些问题很难用监控指标表达，需要人工定期巡检。一个实用的巡检频率是"每日快巡+每周深检"。

每日快巡（5-10分钟）：查看昨日认证成功率和认证量趋势，是否有异常波动；查看磁盘使用率；查看短信余额；确认备份任务是否成功执行。这几项可以做成一个仪表板，每天上班后看一眼。

每周深检（30-60分钟）：用测试账号完整走一遍认证流程，验证各认证方式是否正常；查看本周的告警记录和处理情况；检查日志的写入是否连续（有没有时间段缺口）；确认主备切换机制没有异常；查看系统软件版本，是否有需要应用的安全补丁。

变更管理和配置基线

认证系统的很多故障来自变更——AP固件升级后认证方式不兼容、数据库参数调整后性能下降、Portal页改版引入了兼容性问题。没有变更管理的运维团队，出了问题排查起来特别痛苦，因为不知道最近改了什么。

变更管理的核心是：所有对系统配置的修改都要记录（改了什么、什么时候改的、谁改的）；变更前做配置备份；变更后验证核心功能正常；出问题时能快速回滚。这不需要复杂的工具，一个共享的变更记录表格就够，但必须有执行纪律，每次变更都要填，不能光靠记忆。

配置基线是指把系统正常运行时的关键配置状态固化成文档，定期对比实际配置和基线，发现漂移及时纠正。对于有多个门店的连锁场所，配置基线能帮助确保各门店的配置一致性，避免某个门店的IT人员"自己改了一个参数"但没有告诉总部的情况。

监控和运维规范不是做出来给别人看的，是用来让系统长期稳定运行的。投入时间把这套东西建立起来，后期能节省的故障排查时间和处理客诉的精力，远超建设成本。