软件许可抢不到，别急着买,格发有办法解决

设计师正画着图，SolidWorks 或者 CATIA 突然弹个框：许可不足，无法启动。然后电话就打到 IT 这儿了。第一反应往往是——是不是该加购了？

先别急。许可抢不到，真实原因通常有四种：容量真不够、网络或服务器异常、模块配置不对、空闲会话占着不放。直接买许可是最贵的解法，而且大概率买完还会不够。

先把原理搞清楚

工业软件的浮动许可，核心就是一个池子。客户端启动时向许可证服务器申请签出（check-out），用完释放（check-in）。FlexNet、DSLS、SolidNetWork License Manager 这些底层机制不同，但逻辑一致：池子里有空闲的就给，没有就排队或拒绝。

问题在于，"池子满了"这个表象背后，可能是完全不同的根因。有人开着软件去开会了，许可没释放；有人 VPN 闪断导致会话僵死；有人用的模块和池子里的授权类型不匹配；还有人纯粹就是服务器端口被防火墙拦了，跟容量半毛钱关系没有。

企业里常见的几种情况

• 峰值冲突。下午两点到四点，设计、评审、修改任务叠在一起，短时并发冲高。过了这个时段又空了。
• 闲置占用。人走了，软件没关，TCP 连接还活着，服务器以为他在用。FlexNet 原生的 TIMEOUT 默认两小时，而且只认网络通断，不认人有没有在操作。
• 模块错配。买了 30 套基础许可，但仿真模块只配了 5 个，瓶颈卡在 CAE 上。
• 网络问题。端口没开、DNS 解析失败、系统时间偏差超过几分钟，都能导致客户端拿不到许可，跟容量无关。
• 口径混乱。安装量、授权量、登录人数、并发量混在一起算"利用率"，算出来的数字没法支持决策。

排查三步走

第一步：确认报错本身。 什么时间、哪个模块、哪个用户、什么错误码。别只听"软件打不开了"，要拿到具体信息。抽样回读源系统，确认导出汇总没丢数据。

第二步：查服务器状态和日志。 登录 LMTOOLS 或 DSLS 管理台，看实时占用情况，按占用时长排序，找有没有超过几小时的会话，有没有陌生设备名或离职员工账号。 要能定位到具体设备、账号、模块，光看汇总数没用。

第三步：对比峰值并发、拒绝记录和空闲会话。 拒绝记录比用户抱怨更接近事实——是偶发还是连续发生？集中在哪个时段？被拒绝的是少数人还是多个部门同时撞车？ 当前状态和历史变化分开记，别拿今天的数据解释上个月的事。

核查结果压缩成四栏就行：事实、缺口、影响、责任人。管理层扫一眼就能判断下一步。

改进动作

1. 先恢复服务，保留日志。 别急着删东西，原始证据留着，方便后面复盘和审计。
2. 按错误类型分流。 网络问题走 IT 排障，闲置占用作回收策略，模块错配调整授权池配置，真不够用再走采购流程。结果要连到具体决策，别停在报表里。
3. 配置告警和空闲治理。 先定义影响范围和回退方案，再安排执行窗口。影响用户的策略先观察、再提醒、后执行，别大白天直接踢人下线。
4. 用周期数据判断扩容。 至少覆盖一个完整业务周期，项目型团队还要覆盖关键节点，淡季平均值会掩盖峰值。 指定负责人和截止时间，完成后回读验证。

效果怎么验证

• 许可拒绝率：抽样回读源记录，避免只有汇总数。
• 故障恢复时长：按部门或项目保留可下钻明细。
• 峰值并发：和业务事件建立关联，看是不是项目节点导致的。
• 空闲会话比例：分子、分母、异常样本都留着。
• 汇总值不能替代明细复核。效率、体验、风险三个都在可接受范围，才算过验收。

四个坑

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

一个真实的小案例

某家电企业研发中心，CATIA 和 NX 混用，总共 80 套浮动许可。每天下午都有人抱怨抢不到，项目经理催 IT 加购。IT 查了一周日志，发现峰值并发其实只有 65 左右，池子没满。

进一步看占用明细：有 6 个许可被测试部门的电脑挂了三四天没释放，人早就不在了；还有十几个会话占用超过 4 小时，中间没有任何操作记录；另外仿真模块的 8 套许可里，有 3 套被结构工程师占着但根本没跑计算。

整改就三件事：强制释放 6 个僵尸会话，配了 30 分钟无操作自动提醒、60 分钟自动回收的策略，把仿真模块的许可从结构组调回仿真组。没多花一分钱，下午的投诉基本没了。后来项目攻关期峰值确实冲到了 78，那时候才补了 5 套临时许可。

问题从来不是"少几套"，而是"怎么在用"。