去年秋天参与了一个近万人的高校项目，从进场勘测到最终割接上线，整整跑了四个半月。这个过程里最有价值的不是最终的配置文档，而是那些在会议室里吵过的架、在机房里熬过的夜、还有在对接会议里发现的"原来你们是这么理解的"瞬间。把这些记录下来，也许比任何部署手册都更接近真实。

进场第一周，别急着装软件

很多人以为部署校园WiFi网络计费系统的第一件事是装服务器、配数据库。实际上第一件事是开会——跟网络中心的人聊，跟后勤财务的人聊，跟学生工作处的人聊。你会发现，同一套系统，不同部门对它的期待是完全不一样的。

网络中心关心的是：系统稳不稳定？会不会拖慢认证速度？出问题了能不能快速定位？财务处关心的是：钱能不能准确到账？对账报表是不是符合财务规范？学生工作处关心的是：学生投诉了好不好处理？自助服务能不能减少人工窗口的压力？

这三方的需求如果有冲突，你部署得再标准也没用，因为验收的时候总有人不满意。我们那个项目，进场第一天就开了个三方协调会，把各自的需求和底线都摊在桌面上说清楚，后面少走了很多弯路。

认证对接：每家都有私货

校园的认证系统，理论上都是Radius或者Portal标准协议，但实际上每个厂商都有自己的扩展字段和私有逻辑。我们对接的那套认证系统，标准Radius流程走完了还会发一个私有协议的"上线通知"给计费系统，里面包含了用户MAC地址、AP的MAC地址、接入交换机端口号——这些信息对计费来说不是必需的，但学校希望能在后台看到"某个学生具体在哪个宿舍哪个AP上的网"，所以必须接。

这个对接花了不止两周。不是因为协议复杂，而是因为双方的开发人员对字段定义的理解有偏差。比如"上线时间"这个字段，认证系统用的是"认证服务器收到请求的时间"，计费系统期望的是"用户实际开始产生流量的时间"，两者差了三到五秒。单独看不影响计费准确性，但在做"在线时长统计"的时候，一个月累积下来能差出几个小时，财务对账的时候就会被问到。

认证对接这个阶段，不要只测"能不能通"，要测字段语义是不是一致，时间戳基准是不是一样，异常断线的处理逻辑是不是跟预期相符。

套餐配置比技术对接更耗时

很多人以为校园WiFi网络计费系统的核心难点在技术层面，实际上真正的耗时大户是套餐和计费策略的配置。一个近万人的学校，套餐类型至少有七八种：新生入学套餐、老生续费套餐、教职工套餐、访客临时套餐、毕业生清退套餐、寒暑假暂停套餐、还有各种促销活动期间的特价套餐。

这些套餐之间要有优先级：比如一个用户同时符合"老生续费套餐"和"促销活动特价套餐"，系统应该扣哪一个？这个逻辑必须在配置阶段就定义清楚，不能靠"先到先得"的默认顺序去碰运气。

我们那个项目，套餐配置花了三周。不是因为系统不好用，而是因为学校的套餐规则经常改——改着改着就会发现之前配的规则有漏洞，然后又推倒重来。后来学聪明了，先在一个测试环境里把所有可能的用户场景都模拟一遍，确认套餐扣费逻辑跟预期完全一致，再导入生产环境。

老系统的数据怎么办

如果学校之前有旧的校园WiFi网络计费系统，那部署新系统的时候一定会遇到数据迁移的问题。这个问题比想象中复杂：旧系统的数据库表结构跟新系统不一样，用户密码的加密方式可能也不一样，历史账单数据要不要迁移？迁移了之后怎么跟新系统的账单对账？

我们采取的做法是：旧系统的数据不完全迁移，只迁移用户账户信息和当前有效套餐信息。历史账单数据以旧系统导出报表的形式保留，不做入库。这样做的好处是迁移工作量可控，坏处是财务要做两套报表——旧系统的历史数据和新系统的当前数据要分开统计。

如果学校要求历史数据也必须入库，那迁移工作量至少要翻倍，而且要做大量的数据清洗和格式转换。这个工作量在初期评估的时候很容易被低估，一定要提前跟学校确认清楚。

试运行：先跑一批真实用户

系统部署完了，套餐配好了，数据库也迁移了，接下来最忌讳的就是"全校一刀切割接"。我们采取的做法是：先开放一个宿舍楼做试点，让学生自愿迁移到新系统，跑两个星期，收集问题、修复bug、优化流程，确认没问题了再逐步扩大范围。

试运行阶段发现的问题，80%都不是什么高大上的技术难题，而是一些很细节的用户体验问题：比如自助服务页面的"修改密码"功能，学生用手机访问的时候按钮被虚拟键盘挡住了；比如套餐到期的提醒短信，有些学生的手机号是运营商的虚拟号段，短信发不进去；比如财务对账报表的格式，跟学校财务系统的导入模板对不上，每个月都要手工重新整理。

这些问题不大，但堆积起来就是用户投诉。试运行的价值，就是把这些问题在影响面还很小的时候先暴露出来，修好了再放大。

割接上线：选对时间

正式割接的时间窗口，我们选在了国庆假期。学生离校了，宿舍区流量几乎为零，这个时候做割接，即使出问题影响也最小。如果选在开学季或者期中考试前后，一旦有闪失，投诉电话能打爆。

割接当天的操作其实不复杂：把旧系统的流量切到新系统，确认认证和计费都正常，然后安排人值守24小时。真正复杂的是割接前的准备工作：操作手册要写清楚，回滚方案要验证过，值守人员要知道出问题了先查哪里、该打给谁。

我们那个项目，割接当天其实很平淡，没什么惊险的瞬间——这恰恰说明前面的准备工作做得够充分。最好的部署，就是用户感知不到"换了一套系统"这件事。

整个部署流程走完，回头看，技术难题其实都能解决，真正难的是协调各方期望、把细节问题在试运行阶段充分暴露、还有选一个对的时机做割接。校园WiFi网络计费系统的部署，本质上不是一个单纯的技术项目，而是一个涉及多个部门、多种用户角色、多套历史系统的综合性工程。