业务部门报了100个，我导了半年日志，实际峰值只有55个

研发报上来 100 个。我把过去半年的许可服务器日志导出来，按 5 分钟粒度跑了一遍，日峰值的 P90 是 55。

差了 45 个。按单价折一下，是六位数的钱。

这不是谁在撒谎，是两个部门在说两个不同的数。

两个数，根本不是一回事

研发报的是"可能会用的人数"。

这数一般怎么来的？部门负责人把人头过一遍：这个项目组 8 个人，那个组 12 个，偶尔要打开看一眼的再加几个。加出来 100，逻辑上没毛病。他要的是"谁想用的时候都有得用"。

我算的是"同一时刻真正在用的人数"，就是许可服务器里那个并发占用数。

这两个数天然就不相等。

麻烦出在哪呢——浮动许可是按并发计数的，采购单按后一个数买，需求却按前一个数提。中间那一截，就是你多掏的钱。

为什么不能用月均

我以前干过一件蠢事。

早年报采购量，我的办法是：导日志，看月均占用，乘以 1.2，提交申请。当时觉得挺科学，还带系数。

后来有个项目进了验证阶段，台架测试和自动化回归一起上。白天十六个人同时开着，晚上只有四个脚本在跑。月均一算，十个。我按十个买的。

结果白天天天排队，研发在群里骂，我去查才发现——月均把深夜的低占用和白天的峰值互相抵消掉了。这是个平均值最经典的坑，跟"平均工资"一个道理。

从那以后我改了口径。

现在我的取值口径

• 日志按 5 分钟粒度聚合，取每天的最大值，得到"日峰值"
  
• 把过去 30 天的日峰值排个序，取 P90，不是最大值
  
• 拿 P90 当采购基数，不是拿峰值，更不是拿月均
  
• 为什么要 5 分钟？太细了噪声大，太粗了会把短尖峰抹平。5 分钟是个折中，大部分工程软件的许可日志默认粒度也差不多在这个量级。
• 那 P90 和最大值之间那十几个怎么办？
• 别为它常备。一年出现三次的尖峰，不值得你养一年。我一般这么处理：排个队等着，或者临时租几天，或者跟厂商谈短期的弹性扩容。排队二十分钟的成本，比十几个许可躺一年的成本低太多了。

四个最容易踩的坑

① 把人头当采购基数

"我们部门 80 个人" → 买 80 个。这是最普遍的一个。

为什么会踩？因为人头是最容易拿到的数，HR 系统里一拉就有。而并发数要导日志，没人愿意干。

后果不只是多花钱——更麻烦的是，这么买完之后你永远解释不清"为什么还是有人抢不到"，因为瓶颈根本不在这儿（往下看第三个坑）。

② 月均 × 系数

就是我上面说的那个。系数 1.2、1.5 都见过，全凭手感。

后果是项目一进密集期就崩，然后紧急加买，加买的时候一点议价余地都没有，厂商报多少你付多少。

③ 只看软件，不看 feature

这个坑最隐蔽，也最贵。

浮动许可是按 feature（功能模块）​ 计数的，不是按软件名。你买了 100 个"某仿真软件"的基座，但 popular 的那个求解器模块只买了 20 个。

现象就是：总授权明明还有余量，还是有人在排队。​ 你去查总数，一片绿；去查那个 feature，常年飘红。

采购如果不看 feature 级的数据，永远查不出这个问题。

④ 把闲置占用当成数量不足

有人开会，软件开着，许可占着。有人下班不关，挂着过夜。有人开了个高价模块，其实只用里面的画图功能。

这些占着的许可，在别人眼里就是"不够用"。

怎么解：按顺序来，别跳步

第一层：摸底，查使用率

• 导出许可服务器 6–12 个月的日志（大部分许可管理器都自带日志，lmutil 类的命令行工具能读，或者直接找厂商要导出方法）
  
• 看三样：日峰值序列、拒绝/排队记录、feature 级的占用
• 拒绝记录特别重要，它直接告诉你"谁在什么时候没抢到、抢的是哪个 feature"
  
• 产出一张表：软件 / feature / 授权类型 / 现有数量 / P90 / 峰值 / 拒绝次数
  
• 这一步用一个 Excel 就能干完，不用买任何东西。
• 第二层：零成本的配置优化
• 看你的许可管理器支不支持 idle timeout（闲置超时自动回收）。支持的就配上，一般设 30–60 分钟，配之前先跟用户打个招呼，免得误伤
  
• 有些管理器支持 license borrow（离线借用），出差和居家办公的可以签出去用，不占在线池子 —— 但这个要看你的许可类型和合同允不允许，不是所有都能借
  
• 客户端启动配置里，把默认预加载的高价 feature 去掉，改成按需加载
  
• 设排队优先级，关键项目的组先拿
  
• 这几项基本不花钱，动的是配置。
• 第三层：优化采购策略
• 采购基数按 P90，不按人头，不按峰值
  
• 常年独占的岗位（比如固定工位的主设计）用节点锁，流动和协作的用浮动 —— 别一刀切全买浮动，也别全买节点锁
  
• 缓冲留一点，但单独列出来，别混进固定基数里，不然下次续约你又忘了它是缓冲
  
• 续约前把使用数据摆到桌上。厂商定价看的是你的迁移成本，你手里有数据，谈判的位置就不一样了
  
• 第四层：才轮到工具
• 如果你的软件种类少、就两三套，导日志 + Excel 完全够用。
• 等到了十几套、跨地域、要天天看的时候，再考虑上一套集中的许可监控和调度平台。别反过来——先买工具再想数据怎么来，我见过太多工具上线半年，里面跑的还是脏数据的案例。

一个真事

有家做汽车零部件的（不点名了），结构仿真那个套件，采购基数是按历史峰值锁的 85 个。

我把全年日峰值排了个序：最大值 85，P90 是 72。差 13 个。每个授权算上维护和服务，一年差不多 1.9 万，13 个就是 24 万多。

另外还有一组 12 个节点锁，利用率 21%——就那么几个人在用，剩下时间全空着。转成浮动之后利用率到 67% 上下，同样的活，6 个浮动就覆盖了，这块一年省 14 万多。

两头加起来接近 40 万，占那个套件年支出的三成多。

改完之后一年里大概有三天出现排队，那三天是临时租的，成本两万不到。

净省三十多万。这三十多万不是砍出来的，是算出来的。

下次业务部门报数，别急着反驳，也别急着照批。先问一句：这是同时用的人数吗？