License 优化里最贵的不是软件本身，是用错了口径的那份“优化报告”

License 优化最怕搞成年底大扫除

年底盘一次，买一批，消停两个月，然后人一流动、项目一换版本、合同一续签，之前那套表全废。这事儿我见过太多次了。很多工业企业的IT不是不干活，是活干错了方向——把License优化当成一次“整改运动”，而不是一个每天都得有人盯着的东西。一次性盘点的天然缺陷在于，它假设人员、项目、版本和合同是静止的，可这四样东西在工业企业里恰恰变得最快。一个仿真组三个人离职，留下的named-user许可没人动；一个车型项目结束，Catia的浮动池还按峰值锁在那里；合同到期前三个月采购才开始问“到底要续多少”，IT翻出来的数据是去年六月的。 License优化真正难的不是“发现闲置”，是让发现、判断、执行、复盘这四个动作连续转起来，而不是转一圈就停。

先讲一个最容易被跳过的技术事实：签出（checkout）不等于使用。FlexNet、DSLS、RLM这些许可管理器记录的是“谁在什么时候拿走了什么feature”，它不记录这个人拿走之后是打开软件干活了，还是开着NX去开了两个小时的会。行业里的经验数字是，典型工程环境中已签出的许可有 20% 到 40% 处于闲置状态。更麻烦的是拒绝信息。FlexNet Publisher的lmstat命令只告诉你池子里还剩几个、谁占着，它不告诉你谁被拒绝过、被拒绝了几次、拒绝发生在哪个模块上。要拿到denial数据，必须去翻debug日志。很多团队做利用率分析只拉lmstat的输出，算出来一个“平均利用率70%”就交差了，然后采购按这个数字去砍续费，结果续费后第一个月设计部门就开始排队。问题出在把“平均”当成了“安全线”。峰值被平均掉了，denial被日志埋掉了，这个利用率数字对续费决策基本没有指导价值。

一个值得翻出来看的案例是Aibel。这家做海上油气和风电工程的公司，在挪威、泰国、新加坡都有团队。他们的IT发现一个反常现象：项目进入低谷期，License消耗量却没有降下来。按正常逻辑，活少了，软件用得少，浮动池应该松下来。但没有。他们做了细粒度分析之后才发现，闲置的许可被长时间占着不放，高峰时段真正的需求反而被挤掉了。后来他们上了自动回收机制，对核心应用把闲置许可实时收回来，利用率干到了99%，然后拿着这个“优化后的真实用户数”去跟厂商谈企业协议，最后拿到的是一份双方都觉得合理的EA。这个案例的关键不是99%这个数字，而是他们的动作顺序：先证明浪费在哪里，再证明真实需求是多少，最后用真实需求去谈合同。反过来，先砍数量再指望使用习惯自己变好，在工业研发场景里几乎行不通，因为工程师不会因为采购少买了五个许可就自动缩短仿真时间。

所以日常运营要盯的东西得换一换。数据新鲜度比数据精度更值得花精力——你的许可日志是不是每天在进，还是月底从某台服务器上手动拷一个CSV出来？口径变化有没有记录，比如上个月把某个feature并进了token池，这个变化如果不标在时间线上，后面所有的趋势对比都是废的。问题复发率是个很诚实的指标：同一个部门、同一个软件、同一个“许可被占满”的报障，三个月内出现了几次。如果回收任务做了但复发率没降，说明要么回收阈值设错了，要么被回收的那个人根本不该被回收，他的工作模式就需要保留那个session。任务闭环率别只看“处理了多少条”，要看“处理完之后回读了日志没有”。一条回收任务点了“完成”，但第二天同一个用户又在同一时间拿走了同一个feature，这条任务实际上没闭环，它只是被关闭了。续费调整贡献就更直接了：这次续费砍掉的五个Catia许可，对应的是过去一个业务周期里哪几个具体的闲置回收记录和denial分析。拿不出这个对应关系，砍下去的就是赌博。

误区我挑三个最要命的说。

第一个，把安装量当授权量，把授权量当并发量，把登录人数当并发峰值。 这是四件事。安装量是装了多少台机器，授权量是你有权用多少个，并发量是同一时刻池子里被拿走的上限，登录人数是过去一段时间里碰过这个软件的人头数。拿登录人数去估浮动许可需求，在项目型团队里会严重高估，因为很多人一个月只开两次软件，却在一个季度里都被算进了“用户数”。

第二个，没有denial数据就做回收策略。 你设了30分钟闲置自动回收，听起来很合理，但如果某个CAE的前处理阶段本身就有一段时间不产生键鼠事件而CPU在跑求解器，30分钟一刀切就会把正在算的session挂起。回收必须区分“人走了”和“人在等机器算”，多维度检测——CPU占用、IO、进程状态——不是锦上添花，是必要条件。

第三个，续费谈判前才想起要数据。 厂商的续费窗口通常提前两三个月就开了，而你至少需要覆盖一个完整业务周期的数据才能把峰值和低谷分开，项目型团队还得覆盖关键节点，否则淡季平均值会把峰值需求盖得干干净净。

最后说一个我近距离见过的翻车。一家做非标设备的厂， Creo 和 Ansys 混着用，IT 在 Q3 做了一次“优化”，依据是前一个月的 lmstat 汇总，把 Creo 的浮动许可从 40 个砍到 28 个，Ansys 的 HPC token 也压了一批。Q4 两个新项目同时进详细设计，Creo 池子天天爆，denial 日志里一堆人排队，项目经理直接找到 IT 总监拍桌子。IT 回头翻日志才发现，被砍掉的 12 个许可里有 9 个在 Q3 的“闲置记录”其实集中在晚上和周末——白天峰值时段这 9 个位置是被真真实实占满的。他们犯的错误不是回收，是拿一个月的汇总数去代表一个波动极大的研发节奏，而且没有看 denial。后来重新做，把回收阈值从统一的 30 分钟改成按 feature 区分，对求解类进程拉长到 120 分钟并加 CPU 活跃判断，同时把续费决策和过去两个季度的 denial 趋势绑在一起，才把局面稳住。