工业企业在软件中踩的坑，高校一样踩，而且更隐蔽

买了80个点的MATLAB并发，期中交作业那两周学生还是抢不到。IT说授权用满了，采购说预算就这么多，院长问是不是买少了。我把License Server的日志拉出来看了一周，大量会话在没跑任何计算的情况下占着席位超过两个小时，与此同时，毕业生离校半年多的账号还挂在命名用户名单里，继续占着不该占的位置。这不是买少了的问题，是从来没人真正看过“谁在用、怎么用、什么时候用”。

高校机房的许可管理，坑不在技术，在口径和边界。

先把几个词掰清楚，不然后面全歪

并发授权（concurrent / floating） 和命名用户（named user） 是两套完全不同的逻辑，不能混着说。

命名用户是“这把椅子写了一个人的名字”，这个人不用的时候，别人也不能坐。并发授权是“池子里有N把椅子，谁来了谁坐，坐完站起来把椅子还回去”。高校机房绝大多数专业软件，CAD、CAE、MATLAB、统计包，走的是并发。但麻烦在于，并发授权的容量是按“同一时刻最多多少人用”来配的，不是按学生总数配的。一个机房30个终端配30个并发席位，一天服务60个学生完全正常：上午一批，下午一批，椅子没增加，人流转了。

所以第一个要打死的问题：别把“安装量”“账号数”“登录人数”“并发峰值”这四个数字当同一件事来回倒。教务处给你的是选课名单，机房给你的是终端数，License Server给你的是拒绝次数，这三个数说的是三个世界的事。分不清这个，后面所有讨论都是吵架。

工业研发那边有个数据：很多制造企业在跑FLEXlm/RLM浮动许可时，25%到40%的席位属于“占而不用”，实际有效并发利用率长期在30%到50%之间。工程师开了CAE界面不关，挂着去吃午饭、开会、回家，席位就那么被锁着。高校机房更狠，学生下课不注销，或者干脆把软件开着去上下一节课，License Server那边看到的是一个“活跃会话”，人早就不在屏幕前面了。

第二个坑比闲置更恶心：并发口径被瞎算。英国一所研究型大学被IBM审计追着要180万英镑，理由是SPSS的“并发用户超标”。仔细一看，审计方的算法把后台并行计算线程也算成了“并发用户”，一个作业spawn了12个分析进程就记12个人。独立审计重新跑日志，真实的人类同时连接峰值只有34个，远低于合同里的50个并发上限，180万的索赔直接蒸发掉一大半。高校机房里跑仿真、跑批量脚本的时候，同一个逻辑完全可能重演：你以为你超了，其实你没超；你以为你够用，其实全被僵尸会话吃了。

第三个坑最low但最普遍：账号生命周期没人管。学生毕业、转专业、退课，账号还留在授权组里。微软教育版那边，一届毕业后管理员要做账号删除来释放许可证给下一届，回收站留30天，之后云端再留最多93天。很多学校自己的专业软件许可根本没这个动作——毕业生离校了，命名用户还占着，并发池里他的旧会话可能还卡着。“人走授权要回”这句话，在高校比在企业难执行十倍，因为学生账号和教务系统、统一身份认证缠在一起，IT不敢随便动。

别急着买工具，先干三件脏活

第一件：拿课程表当分母，不是拿学生名单当分母。

一个机房到底需要多少并发，唯一靠谱的输入是排课表。哪几门课在哪个时段用哪个软件，班级人数多少，重叠多少，只有排课数据能回答。去问教务处要下学期完整的机房排课，按软件类型拉一个时间轴，标出“同一时刻最多有多少个教学班在调用同一款软件”。这个数字出来之后，再去跟License Server日志里的峰值对照。你会发现很多“不够用”的时段，其实排课就集中在那两周，平时并发池是空的。

第二件：给License Server加一个空闲超时，然后忍住别关。

浮动许可如果没人管，就是个漏水的池子。设置一个合理的空闲超时——比如30分钟没有交互就把席位收回池子。别设太短，5分钟会把查资料的学生踢出去，怨气比省下的席位大。设完之后盯一周日志，看“拒绝”发生在什么时间、被谁触发。如果拒绝集中在交作业前夜，那可能是真容量问题；如果拒绝零星发生在白天，但池子里大量会话挂着不动，那就是回收策略在打架，不是买少了。

第三件：拉一张“活人名单”，把死人踢出去。

从统一身份认证或者教务系统导一份当前在校生和选课名单，跟License Server里过去一个学期有过会话的账号做交集。交集之外的、毕业超过一个学期的、离职或转岗的，列成回收清单。先别直接删，发一轮通知，给两周异议期，然后批量移出授权组、解除设备绑定、把命名席位放回池子。这一步做完，很多学校会发现自己“多出来”的可用席位比想象中多。

真正值得上的工具，长什么样

工具不是用来“看报表”的，是用来把上面三件脏活自动化的。一个靠谱的许可优化工具在高校场景里至少干这几件事：

把软件发现和许可服务器日志放在同一个视图里。终端上装了什么版本、License Server上谁在借、借了多久、有没有被拒绝，这三条线对不上，后面全是人工猜。

把账号状态接到许可分配上。账号一旦被标记为毕业或停用，自动触发一次回收检查，而不是等IT每学期末手动翻名单。工业企业里成熟的SAM实践，核心动作之一就是软件收割（harvesting） ：识别不活跃分配、回收、重新放进共享池，而不是直接走采购流程。

把课程高峰期做成可复核的指标，而不是“感觉最近挺卡的”。比如“高峰时段拒绝率”和“高峰时段有效会话占比”，分子分母都写清楚。只有拒绝率在涨、同时有效会话占比在跌，才说明是真容量缺口；如果拒绝率涨了但池子里全是超时未释放的会话，那是管理问题，增购只会把浪费做大。

一个真实的、可以照着踩的案例

某工科院校的机房，买了某仿真软件的50个并发授权，服务两个学院的本科上机课和研究生课题。学期中段开始，学生频繁反映“下午两点到四点根本连不上”。IT第一反应是打报告申请增购20个点，采购让先给数据。

拉出来一周的License Server日志，发现几件事叠在一起：

排课表显示，周二和周四下午确实有三个班的实验课重叠，理论峰值需求大约45到48个并发，离50不远，但不应该每天都炸。日志里，每天下午平均有11到14个会话在启动后30分钟内没有任何计算动作，纯粹是学生打开界面填了参数、跑了两步、然后切出去做别的事，席位一直挂着。更隐蔽的是，授权组里有6个命名用户账号属于已经毕业超过半年的学生，当初是因为他们做毕业设计时单独配的，没人想起来回收。这6个命名席位和50个并发池是分开的，但管理上长期被忽略，导致“账面可用”和“实际可调度”之间一直有个缺口。

他们没有增购。做了三件事：把空闲超时从默认的“无”改成25分钟；按排课表把周二周四下午的并发池临时预留了5个缓冲席位，只对那两个时段生效；把6个毕业生命名账号移出授权组，释放出来的席位并入共享池。下一周同样的课程高峰，拒绝次数从日均23次降到4次，没有花一分钱新增许可。

后来采购问IT：那到底还买不买？IT说：先把这套回收和超时机制跑满一个学期，看下学期的拒绝率曲线再决定。这才是正常人该说的话。

最后一句，不是总结

高校机房的许可管理，说到底是在“教学不能断”和“席位不能白占”之间走钢丝。课表是硬的，学生流动是快的，厂商合同是死的。你不可能靠一次盘点解决所有问题，但你可以做到一件事：下次有人问“要不要加许可”的时候，你手里有一份能说清楚“现在到底谁在用、卡在哪、为什么卡”的东西。没有这份东西，买和卖都是赌。