研发群里又炸了。有人截图发出来,"License checkout failed",下面一串人跟着喊。IT一看,许可证服务器确实满了。采购随即收到邮件:再买20个吧,业务等不了。
这种场景我见过太多次。最后买回来了,该抢不到还是抢不到。钱花了,问题还在。
说句难听的,大多数"不够用"是假性短缺。真缺口当然存在,但比例真没你想的那么高。
先定性,这到底是什么性质的问题
许可证不足不是一个问题,它是四类问题披的同一件外衣:
- 容量问题:确实买少了,峰值并发打满。
- 配置问题:许可池没拆开,一个模块把整包吃掉。
- 流程问题:人走了许可没回收,界面开着不动,离线许可(borrow / offline license)借出去忘了还。
- 合规问题:用了合同范围外的功能模块,或者装在了不该装的机器上。
- 这四种根因,处理方向可能完全相反。容量问题要加买,配置问题改配置就行,流程问题靠回收,合规问题得赶紧整改而不是扩容。不先分类就动手,方向错了越使劲越糟。
- 还有个绕不开的东西——口径。采购说的"买了60套"、IT看到的"装了80台"、日志里的"峰值并发31",压根不是一回事。安装量、授权量、登录人数、并发量这四个数混着用,算出来的利用率自己都不信,更别提拿去汇报。

各家都踩过的坑
- 只看平均使用量。平均值最能骗人,淡季一拉,峰值全被抹平。
- 单次报错当趋势。就某一天打不开,就下结论说不够。
- 日志只有汇总没有下钻。知道上周五下午满了,可哪台机器、哪个账号、哪个模块占着,查不出来。
- 历史数据被覆盖。今天的状态盖住昨天,三个月前那次事故没法复盘。
- 口头授权一堆。"先给他开一下",过后没人收。
- 回收脚本返回success就以为解决了。那人明天还得用,你把他惹毛了,业务没真好转。
五步。一步一步来,别跳
第一步:摸底,采集至少一个完整业务周期的数据。
做装备的可能是季度交付节奏,做项目的要覆盖关键节点。至少一个月,最好一个季度,短了没意义。
看的时候注意三点:
- 看峰值并发,别看平均。把每天最大值拉出来排序,看前几名都是哪几天、哪个项目。
- 区分排队、拒绝和启动失败。排队是拿到了但要等,拒绝是压根没拿到,启动失败可能是环境或配置问题,跟容量没关系。这三个混着统计,你的拒绝次数是假的。
- 识别长时间占用但无操作的会话。挂一整天不动的,就是你的回收对象。必须能回到具体设备、账号、模块,光有个总数不够用。
- 例外场景和批准人一起记下来,后面做策略才不会误伤关键任务。采完记得抽样回读源系统,确认导出和汇总没丢东西。
- 第二步:按功能模块拆许可池。
- 工业软件多半是模块化的,建模一块、仿真求解一块、后处理又一块。合在一起卖,占的时候却可能整包吃。去系统里看feature级别的占用,能拆就拆,能分开授权就分开。这步不花钱,收益往往比买许可大。
- 第三步:配空闲提醒和安全回收。
- 闲置超时回收最立竿见影,也最容易被骂。我的经验是从宽松起手,比如4小时无操作提醒、再过半小时回收,别上来就设30分钟。回收前十分钟发消息,回收后给个自助重新申请入口。
- 第四步:关键人留白名单,例外流程写进制度。
- 总有人真得长期挂着——跑长仿真的、做模具的、项目冲刺期的。这些人走审批留白名单,普通和例外走两条线。别用口头授权,口头的东西过两个月谁都不认。
- 第五步:以上都做完了峰值还打满,再谈采购。
- 这时候你拿出来的数据能说服人:峰值多少、拒绝多少次、平均等待多久、回收回来几个、白名单占了几个。采购拿这个去谈续费,底气完全不一样。
工具放最后说
在数据层,许可优化这类能力可以帮你把安装、授权、使用线索归到一处,也能持续记录平均等待时长这类运营证据。但管理层的事它替不了——动作还得按合同和内部制度定,审批还得人拍板。
每次调完策略记三样:改了什么、为什么改、改完峰值并发和拒绝次数变成多少。指标异常时先怀疑采集覆盖和口径变了,别急着说业务变了。
举个实在的例子
有家做重工装备的,仿真软件买了50个浮动许可。项目集中那阵子天天有人排队,业务部门直接写邮件要求加到70个。
IT把日志拉出来看了一个季度。峰值并发确实到过47,看着像真不够。可往下钻发现,其中9个会话连续挂着超过一天半,CPU和IO几乎为零——几个人跑完仿真忘了关,界面就那么开着。还有3个是出差的人借了离线许可,两个多月没还。
于是先干了两件事:闲置超时设成6小时提醒、8小时回收;离线借用上限压到14天,到期强制归还。真被回收的人会有意见,所以给几个跑长仿真的加了白名单。
两个月后峰值降到34。第二年续费从50个减到42个,省了十几万。业务那边也没再喊,排队基本消失了。
顺带一句,复查时还发现有两台机器装了合同里没涵盖的模块。这不属于扩容范畴,得走合规整改。幸亏是在摸底阶段翻出来的,要是直接买了70个,这事还得继续烂在那儿。