商业WiFi项目里有一种很典型的场景：运营方建好了一套WiFi认证系统，然后把这个网络资源开放给园区里的租户企业或者商铺使用。比如一个科技园区，园方统一做了WiFi覆盖和认证，然后各入驻企业可以在这个基础设施上开通面向自己员工的WiFi服务。这种模式下，WiFi认证系统需要解决一个核心问题——怎么把网络资源切分开，让不同租户的管理不互相干扰，同时计费和统计也能分得清楚。

认证域的隔离逻辑

WiFi认证系统在多租户场景下的第一步，是建立清晰的认证域隔离逻辑。每家企业就是一个独立的认证域，拥有自己的一套SSID、认证策略和用户管理界面。对于A企业的IT管理员来说，他登录管理后台之后只能看到和管理自己企业的WiFi认证相关配置，看不到也操作不了B企业的数据。

认证域的隔离在系统设计上有两个层次需要关注。一个是数据层的隔离——用户账号、认证日志、上网记录这些数据必须按租户严格隔离，不能存在跨租户的数据泄露风险。另一个是策略层的隔离——A企业配置的带宽限制策略、上网时段限制策略、应用层过滤策略，不能影响到B企业的用户。这两个层次中任何一个出了问题，都会引发严重的租户投诉。

网络资源的计费和配额管理

在多租户模式下，运营方通常需要对每个租户的网络使用量进行计量。计量方式一般有三种：按在线用户数峰值收费、按总流量收费、按带宽占用收费。WiFi认证系统需要在后台提供对应的统计能力，并且这些数据必须按租户维度呈现。

实际操作中有几个容易出现争议的地方。第一是"在线用户数"的计算口径——是按并发在线数算还是按日活算？如果按并发在线数，那峰值是按小时粒度还是分钟粒度？这些口径在合同中必须提前约定，否则到了月底对账的时候很容易扯皮。

第二是流量统计的去重逻辑。一个用户同时用手机和笔记本上网，两个设备产生的流量应该算在一个账号下还是分开算？如果按账号汇总，统计逻辑上没什么难度。但如果同一个租户下的多个员工之间也需要分别统计（比如为了内部成本分摊），WiFi认证系统就需要支持按账号粒度导出流量报表。

租户自助管理后台的功能边界

WiFi认证系统在多租户模式下应该给每个租户开放一个自助管理后台。这个后台的功能边界需要仔细设计：给太多，运维复杂度会爆表，而且可能出现租户自己改错配置导致全网影响的情况；给太少，租户事事都要找运营方，运维工作量也很大。

实践下来功能边界大致这样划：租户可以管理自己的SSID名称和密码、查看在线用户列表、拉取认证日志和上网行为日志、配置自己租户范围内的带宽策略和访问控制策略、自己创建和管理用户账号。但不能动的东西包括：AP的信道和功率设置、路由配置、核心交换机的VLAN配置、其他租户的任何资源。

这个功能边界需要有明确的设计文档，并且在系统部署前和运营方逐项确认。不要把哪些功能该给租户哪些不该给的问题，留到上线之后再讨论。

多租户下的告警和运维责任划分

在单租户环境下，WiFi认证系统出任何问题都是运维团队的事。但在多租户环境下，出问题之后第一件事是先判断责任归属——是运营方的基础设施问题、还是租户自己改配置改出的问题？

这要求WiFi认证系统的告警输出必须带租户维度信息。比如"租户A的SSID1从10分钟前开始出现大量认证失败"——这个告警到了运维手里，一看就知道是A租户自己改密码还是SSID策略写错了。如果没有租户维度的信息，运维拿到一个"SSID1认证失败率升高"的告警，还得花时间去查这个SSID1是谁的。

另外在运维流程上也需要明确SLA的分层。运营方对租户承诺的SLA只能覆盖基础设施层——AP在线率、认证系统可用性、上联带宽可用性这些。租户自己管理的配置层面导致的故障不在SLA覆盖范围内——比如租户自己改了Radius密钥导致全公司的人认证失败，这个锅运营方不背。

多租户WiFi管理是一个看起来只比单租户多了一点"隔离"需求但实际复杂度高出一个数量级的场景。提前把认证域隔离、计费口径、管理后台权限和运维责任划分想清楚，上线之后才不会陷入无穷无尽的跨租户协调工作中。 还有一个实际情况值得单独提一下：多租户环境下的带宽共享和争抢问题。园区上联带宽是一个共享资源池，所有租户共用。如果没有在WiFi认证系统里按租户设置带宽上限，某个租户搞一次大文件传输或者视频直播，可能把整条上联带宽打满，其他租户的WiFi体验直接崩掉。做法是在认证策略里按租户维度设置带宽保障和带宽上限——每个租户保证最低带宽、同时不超过上限——并且这个策略应该在AC或网关层面生效，不能只靠Portal认证之后再下发策略，因为那样会有几秒钟的窗口期。