去年帮一家企业选型认证计费系统，对方IT主管拿了一份功能对比表，上面列了七八家厂商的产品，每项功能后面打勾打叉。我扫了一眼，打勾数量差不多，但也说明不了什么。因为有些功能，PPT上写着"支持"，实际用起来完全不是一回事。后来项目实施完，回头看这份对比表，发现最关键的几个功能点，当时根本没在表上。

自助服务端口的"真实能力"

几乎每家厂商都会说"支持自助改密、自助充值、自助查询"，但你点进去看，差异很大。有一种自助服务是"功能存在但很难用"：用户要改密码，先得记住原密码，还要回答安全问题，还要输入验证码，三步做完，用户已经放弃，转而打电话给IT部门。另一种自助服务是"功能完整但没接入正确渠道"：系统有自助门户，但企业微信里进不去，用户还是得打开浏览器输入网址，这就导致实际使用率很低。

我后来养成一个习惯，选型阶段一定要让厂商现场演示自助服务的完整流程：从用户忘记密码开始，到最后成功改密并能正常上网，全程走一遍。你会发现，有些产品的流程设计是给"理想用户"做的——假设用户记得原密码、假设用户在电脑面前、假设用户会看系统提示。但真实场景是：用户手机连不上网，忘了密码，急着想上网，这时候自助改密流程如果第一步就要"输入原密码"，那就完全没用。

多区域策略的"细粒度"到底有多细

很多企业网络分了好几个区域：办公区、生产区、访客区、会议室、甚至不同楼层不同部门。认证计费系统需要支持"不同区域不同策略"，这个大家知道。但"细粒度"三个字，不同厂商理解不一样。

有一种实现是"按VLAN下发策略"：你在交换机上把端口划到不同VLAN，认证系统根据VLAN ID分配不同的访问权限和计费策略。这个方案简单，但问题是VLAN是二层隔离，如果你希望"同一个VLAN内不同用户有不同的策略"，它就做不到。

另一种实现是"基于用户组/角色下发策略"：用户在认证系统里属于哪个角色（员工、访客、合作伙伴），系统就动态下发对应的ACL和计费规则。这个方案灵活，但要求认证系统能跟网络设备做深度的策略联动，不是所有厂商都做得好。

选型的时候，我会问清楚客户有没有这种需求："同一区域里，不同人要不要有不同的上网权限？"如果有，就要重点考察基于角色的细粒度策略能力，而不能只看"支持多区域策略"这个勾。

数据导出和第三方对接的"实际接口"

认证计费系统积累了很多数据：用户上网行为日志、计费消费记录、流量统计报表等。这些数据，客户有时候要导出给第三方系统用。比如，有些企业要把上网行为日志对接到态势感知平台；有些学校要把计费数据对接到财务系统；有些园区要把流量统计对接到运营分析平台。

对接这件事，厂商一般会说"支持标准API接口"或者"支持数据导出"。但"标准API"四个字，实际含义差别很大。有些厂商的API是RESTful风格，有完整的接口文档，调用方便；有些厂商的API是老式的SOAP，或者干脆就是让你直接查数据库。数据导出也是，有些支持定时自动导出到指定目录，有些只能手动在管理界面点"导出"。

我一般会请厂商提供一份接口文档，哪怕只是看看目录结构也行。如果厂商说"我们有标准接口，文档后面提供"，我会在选型评分里扣一点分。因为有些厂商的"标准接口"是等项目签完合同才开始写的。

系统自身的高可用和灾备方案

认证计费系统一旦宕机，影响的是整个网络的上网能力。所以高可用是选型时必须考虑的点。但"高可用"三个字，不同方案差别很大。

最简单的方案是"双机热备"：主服务器挂了，备服务器自动接管。这个方案技术上成熟，但问题是：如果主备之间的数据同步有延迟，切换的时候可能丢数据。比如用户刚充值，主服务器还没把充值记录同步给备服务器，这时候主服务器宕机，切换后用户账户余额就不对了。

更完善的方案是"集群+数据库主从+会话保持"：认证服务、数据库、日志服务分别做高可用，而且会话信息要实时同步，确保切换的时候用户不会掉线。但这个方案复杂，成本高，有些客户不一定需要。

选型阶段，我会问客户："你们网络中断的容忍时间是多少？"如果答案是"几分钟不行，必须秒级切换"，那就得往上找方案。如果答案是"偶尔断一下，半小时内恢复就行"，那双机热备可能就够了。

还有一个 related 的点：有些厂商会把"高可用"作为高级功能，要额外收费。这个要在选型阶段就问清楚，不能等到项目合同都签了才发现预算不够。

日志存储和检索性能的"隐形瓶颈"

认证计费系统要存很多日志：用户登录日志、上网行为日志、计费消费日志、系统操作日志等。这些日志，安全合规要求至少存六个月，有些行业要求存一年甚至更久。数据量大的时候，日志检索性能就会成为问题。

我见过一个案例，系统上线前三个月，日志查询速度还可以，但到了第六个月，数据库里积累了上亿条记录，再想查某个用户某天的上网记录，查询时间超过三十秒，管理界面直接超时。后来排查发现，厂商默认用的数据库引擎不支持高效的按时间范围检索，而且没有做表分区。

选型的时候，我会问厂商："你们日志存储用什么方案？数据量大的时候怎么保证检索性能？"有些厂商会回答"我们用ES（Elasticsearch）做日志检索"，这个方案比较成熟。有些会说"我们数据库做了分区表"，这个也可以。但如果厂商回答"我们用MySQL默认配置，数据多了会慢，但到时候可以加硬件"，我就会打个问号。

另外还有一个点：日志归档策略。有些系统支持自动将老日志归档到冷存储，减轻主数据库压力。这个功能看起来不起眼，但在实际运维中很有用。

选型这件事，不是找一份功能对比表勾勾画画就能完成的。有些关键功能点，PPT上写着"支持"，但实际用起来才知道到底"支持"到什么程度。我的做法是：先让厂商做产品演示，而且演示不能是"按剧本走"的那种，要能现场改需求、现场测试功能。然后再找一家已经用了这家产品的客户，问问真实使用感受。这两个步骤做完，比看十份功能对比表都管用。