一个WiFi认证系统上线后的运维质量，决定了这个系统是用三年还是用一年就需要重建。运维不是等到灯亮了才去看是什么问题，而是在灯亮之前就知道哪些地方可能会出问题、提前做好预案。建立一套系统性的监控告警和故障处理规范，比掌握任何一种运维工具都更重要。

监控指标的分类和优先级。

WiFi认证系统的监控指标可以分为几个层级。基础设施层：服务器的CPU使用率、内存使用率、磁盘空间使用率、网络带宽使用率。这些是最基础的，任何一个指标异常都会影响上层服务。应用服务层：认证接口的响应时间、认证成功率、Portal页面的加载时间、在线用户数量。这些指标直接反映用户体验和系统健康度。外部依赖层：短信网关的送达率、微信公众平台接口的响应时间、RADIUS服务的可用性、数据库的连接数。外部依赖出问题，认证系统本身再健康也没用。

这些指标不是所有都要设告警，需要按优先级分类。P0级别（需要立即响应）：认证成功率低于95%持续5分钟、认证接口响应时间超过5秒、数据库连接池耗尽、短信网关全部不可用。P1级别（需要当天处理）：磁盘使用率超过85%、单通道短信送达率低于80%、在线用户数异常下降超过50%。P2级别（需要关注但不必立即处理）：CPU使用率持续超过70%、认证日志存储空间增长速度超过预期、某个区域的Portal页加载时间波动变大。

告警的分级不光是为了区分紧急程度，更重要的是防止告警疲劳。如果所有告警都打P0级别的电话通知，运维人员很快会变得麻木，真正重要的告警反而被忽略了。正确的做法是：P0告警通过电话和短信通知，P1告警通过企业微信或钉钉通知，P2告警只记录在监控平台里，每天早上运维人员巡检时查看。

监控工具的选择和部署。

监控工具的选择没有绝对的"最佳方案"，取决于团队的运维能力和预算。对于运维团队能力较强、有专职运维人员的项目，可以用Prometheus采集指标数据、Grafana做可视化面板、AlertManager做告警路由——这套组合功能强大且开源免费，但需要一定的学习成本和维护成本。对于运维人员有限、希望降低运维负担的项目，可以用云服务商提供的监控产品或者商业化的APM工具，虽然要付费但配置和运维更简单。

不管用什么工具，有几类监控是必须要做的。一是服务存活性检测（Health Check）——每隔30秒或1分钟对认证服务的关键接口做一次HTTP请求，确认接口是否返回正常的响应码和响应内容。二是认证流程的全链路探测——用一个测试账号模拟完整的认证流程（连接WiFi、弹出Portal、输入验证码、认证成功、访问外网），每隔5分钟跑一次，记录每一步的耗时和成功率。这种业务级的监控比底层的CPU/内存监控更有意义，因为只有它能告诉你"用户感受到的服务是否正常"。

三是日志的异常模式检测。不只看"有没有错误日志"，而是看"错误日志的数量和类型是否出现了异常变化"。认证超时日志突然增加了10倍、某个IP地址的认证失败次数异常高、短信网关的调用全部返回超时错误——这些模式变化通过人工看日志很难及时发现，需要通过日志分析工具设置聚合规则和告警阈值。

故障处理的标准化流程。

出了故障之后怎么处理，应该有标准化的流程，而不是每次靠运维人员的个人经验和直觉。一个标准的故障处理流程通常包括这些步骤：

第一步，确认故障范围和影响程度。是所有用户都不能认证还是只有某些区域的用户？是所有的认证方式都失败还是只有某一种？是Portal页打不开还是认证提交后没有响应？把故障范围搞清楚，才能知道问题的严重程度和排查方向。

第二步，快速做一轮关键的检查项。按照一个固定的检查清单走一遍：认证服务器的进程是否在运行、数据库是否可连接、Redis缓存是否可用、短信网关的API是否可达、网络设备上的认证配置是否被误改。这个检查清单应该提前准备好，不要等到故障发生了才现场想应该检查什么。

第三步，如果检查清单走完没有找到原因，启动更深入的排查——查看认证服务的详细日志、抓取网络包分析网络层的交互、查看数据库的慢查询日志。这个阶段的排查需要更专业的技术能力，但也不需要诊断所有可能性——80%的故障原因都集中在认证服务配置错误、外部依赖不可用、网络连接中断这三类里。

第四步，找到原因后立即执行修复操作，同时记录下故障的发生时间、原因、修复方法、修复耗时。修复后需要持续观察一段时间确认问题没有复发。

第五步，故障恢复后的复盘。不是走过场——要有明确的改进措施和责任人，改进措施要落到系统配置、监控告警、运维文档的具体变更上。比如这次故障是因为短信网关的单通道不可用，那就把双通道自动切换的机制做了，避免下一次再因为同样原因出问题。

日常巡检：把问题消灭在爆发之前。

监控告警是被动的——问题发生了才会触发。日常巡检是主动的——在问题发生前发现隐患并提前处理。WiFi认证系统的日常巡检不需要每天做，但至少每周做一次。巡检的内容包括：磁盘空间使用趋势（按当前的增长率，还有多少天会写满）、认证成功率的变化趋势（是否在缓慢下降）、短信账户余额（是否快要耗尽）、HTTPS证书的到期时间（是否在未来30天内到期）、数据备份是否最近一次执行成功。

巡检的结果应该形成记录——不一定要写正式报告，但至少在一个共享文档或者工单系统里留下记录。如果某次巡检发现了一个需要处理的问题，把这个问题登记为一个任务并追踪到解决。巡检的目的是发现问题和解决问题，不是为了完成一个形式上的流程。

运维这件事，说到底不是技术问题，是持续性和规范性的问题。再好的WiFi认证系统，如果没有配套的监控告警和故障处理规范，上线之后的稳定性只能靠运气。把监控体系建起来、把故障处理流程固化下来、把日常巡检常态化做下去，系统的运维质量就不会依赖于某一个人的能力和责任心。