高校软件许可，别拿企业那套硬套

开学第三周，机房 120 台机器同时跑 SolidWorks，学生集体报错。老师打电话过来吼，IT 跑过去查，发现许可服务器被挤爆了，但平时利用率报表上明明只有 40%。

这就是高校机房最典型的坑：平时没人用，一上课全炸。

高校机房和企业完全不一样

企业仿真是项目驱动，高峰跟着项目节点走，用户相对固定。高校是课程驱动，高峰跟着课表走，用户每学期换一拨。

几个核心差异：

• 终端数量大但同质化。机房 100 多台机器装同样的软件，不像企业里每人需求不同。
• 使用高度集中。一周就那几节课，其他时间空着。按日均算利用率，永远"浪费"。
• 账号流动极快。每年毕业一批、入学一批，账号不清理，许可绑定全乱。
• 教学连续性不能断。企业里一个人等不了可以换任务，课堂上 50 个学生同时等，这节课就废了。
• 拿企业那套"削峰填谷、回收闲置"的逻辑直接搬过来，必翻车。

常见三个问题

安装量和授权量对不上。 机房 120 台机器装了软件，但许可只买了 60 套浮动许可。平时够用，一上课就超。IT 说不清楚到底装了多少台、授权能覆盖多少并发。

账号只增不减。 大四学生毕业了，账号还在许可服务器上绑着。新生入学又开一批新的，三年下来授权池里一半是死人。浮动许可的 borrow 功能被学生借走不还，其他人用不了。

课表和许可容量脱节。 教务处排课的时候不知道机房许可有多少套，两个班同时排了同一门 CAD 课，许可直接翻倍不够用。

先摸底，三件事

第一件：按课表识别高峰。 找教务处要课表，知道每周哪几个时段是高峰、哪些课程用什么软件、同时多少学生。技术日志只能告诉你"发生了什么"，课表才能告诉你"为什么发生"。两样交叉看。

第二件：区分安装和授权。 机房装了多少台是安装量，许可服务器能同时签出多少套是授权量。这是两个数字，别混。浮动许可要查清楚是节点锁定（node-locked）还是并发（concurrent），前者绑定机器，后者绑定服务器池，管理方式完全不同。

第三件：清理过期账号。 按毕业时间、结课时间标记账号状态。已毕业、已结课、临时账号分开标记。抽样回源系统验证，别光看导出的 Excel。

跨部门评审只用同一份底稿，IT、采购、教务处对着同一张表说话。

执行顺序

先建课程-软件需求清单。 哪门课用什么软件、需要多少套、什么时段，列清楚。把普通流程和例外流程分开，临时加课走审批，减少口头授权。

按学期调整授权池。 开学前根据课表预估需求，不够的提前补。学期中监控实际使用，期末回收闲置。执行前通知老师，执行后收集反馈。

自动清理过期账号。 毕业季统一跑脚本，清理已毕业学生的账号绑定。保留规则版本和变更理由，审计的时候用得上。

保留教学例外记录。 竞赛、毕业设计、临时实训，这些不在课表里的场景单独记。审批人、时间、用量都留着，后面采购决策有依据。

看什么指标

• 课程高峰满足率：上课时段许可够用多少次 / 总上课次数。
• 闲置账号数：超过一个学期没登录的账号数量。
• 终端覆盖率：机房里装了软件且能正常签出许可的机器比例。
• 账号回收及时率：毕业后 30 天内完成回收的比例。
• 别只看一个总数。指标异常时先查采集覆盖和口径有没有变，再判断是不是真出了问题。

几个坑

• 凭单日报错当长期趋势。
• 没做供需分析就先采购或强制回收。
• 安装量、授权量、登录人数、并发量混为一谈。
• 改进没责任人、没时间、没验证，人一换就失效。

一个小案例

某工科院校机房，120 台机器装了 SolidWorks 和 ANSYS，买了 60 套 SolidWorks 浮动许可。平时利用率报表显示 35%，采购觉得浪费，想砍到 40 套。

IT 拉了课表对了一下：每周二、周四上午各有两个班同时上 CAD 课，每班 55 人，高峰需要 110 套并发。但许可只有 60 套，所以每次上课都有一半学生报错。平时利用率低是因为除了上课时间基本没人用，平均值被拉低了。

另外查账号发现，过去三年毕业了 800 多个学生，账号一个没清，许可服务器里绑着一堆死人。还有 20 多个账号用 borrow 功能把许可借走两周不还。

整改没砍许可，做了四件事：把 60 套许可扩到 120 套，但跟供应商谈了教育优惠；配了课表时段优先策略，上课时段自动抢占；毕业季统一清账号，borrow 时限从 14 天缩到 3 天；临时加课走教务处审批。第二年上课再没报错，采购拿着实际使用数据跟供应商谈续费，反而比之前省了。

问题从来不是"买多买少"，是"什么时候用、谁在用"。