很多学校上WiFi计费系统的出发点很简单：学生上网要收费，不能让没交钱的人白用网。这个出发点没问题，但计费系统能做的事远不止"收钱"这一件。
实际运营中，计费系统往往同时承担着上网行为管理、学生上网策略控制、异常账号监控、运维问题排查这些职能。这些职能做得好不好，跟计费系统的功能设计和运维人员的操作水平都有关系。
有几个具体的功能维度值得在上线之前认真评估。
校园网的账号对应的是学生真实身份，这是合规的基本要求。但实名认证这件事能不能真正落地，要看计费系统有没有跟学校的统一身份认证平台打通。
很多学校的现状是：教务系统有学生信息，校园一卡通有学生信息，但计费系统是另外一套独立账号。运维人员要手动维护两套账号体系，学生离校了账号不一定同步注销，新生入学了要批量开户，手工操作量大而且容易出错。
计费系统和学校统一身份认证平台通过LDAP或者RADIUS协议打通，实现账号自动创建和注销，这个功能说起来简单，但很多方案落地的时候对接工作量超出预期，主要卡在接口标准和数据字段对应上。如果在选型阶段没有把这个事情谈清楚，上线以后这个问题会一直挂着。
校园网的上网策略不是"全开"或者"全关"这么简单。
举几个例子：宿舍区的策略和教学区的策略不一样，教学区可能只有教职工账号能访问外网，学生只能访问内网和部分外网；图书馆的公共区域可能允许临时账号，计费方式和宿舍不一样；实验室的某些设备可能需要绑定特定IP，不能随意变更。
这些场景意味着计费系统要支持细粒度的策略配置：按区域配置、按身份配置、按时间段配置。一个能打的标签打得越细，策略配置就越灵活，运维人员就越省事。但功能复杂的代价是系统学习成本提高，配置错了也难发现。
学生反映"网速慢"和"上不了网"是运维人员最常接到的两类投诉。这两类问题的排查路径完全不同：网速慢可能是出口带宽不够、可能是设备性能瓶颈、也可能是某个账号在跑大量下载；上不了网可能是账号欠费、可能是认证失败、可能是物理线路故障。
计费系统如果能提供清晰的账号在线状态、流量使用趋势、认证日志，运维人员排查起来效率会高很多。但这个前提是计费系统的监控界面要好用，数据更新要实时，查询响应要快。很多供应商的方案里写了"智能监控"但实际界面做得粗糙，数据颗粒度粗，出了问题还是得进命令行查日志。
还有一种常见场景是"账号被盗用"——学生反映没上网但账号显示在线。这种情况的排查需要计费系统有完整的上下线记录和终端信息，能支撑运维人员还原当时的实际情况。
账号欠费了、流量快用完了、账号异常下线了——这些情况如果学校能主动推送给学生，运维人员接到的投诉会少很多。
但这个功能落地的前提是计费系统要有学生联系方式，而且推送渠道要有效。很多学校的做法是通过微信公众号推送通知，学生关注了才能收到。但实际操作中会发现：学生关注的比例不高，推送消息被折叠，通知触达不到人。这个渠道建设本身也是工作量，不能把它当成"顺带就有"的功能。
计费系统的选型，不能只看"能不能收费"这一个维度。上线以后实际承担的管理职能，往往比当初规划的要多。在选型阶段把账号管理、策略配置、监控告警、通知推送这几个维度的实际能力了解清楚，比上线以后发现问题再打补丁要省心得多。
English