License 优化实战指南：让每份许可服务真实业务

又有人把一张利用率报表推过来，问能不能再调好看点。我瞄一眼就搁回去了。数好看有什么用，评审前那两天该抢不到还是抢不到。

这活儿到底是个啥

License 优化听着像省钱，其实头一件事是保业务不中断，然后才轮到错配，最后才是合规边界。同一个"不够用"，背后可能是容量真不够、feature 配错、人走了许可没还这种流程烂账，也可能是用了合同外的模块。四种根因，动作方向是反的——配置问题你去采购，白扔钱。

还有口径。采购说买多少套，终端说装多少台，登录过的人数，同一时刻峰值并发，四个数都对，压根不是一回事。混着算出来的利用率，拿去开会等于自己递刀。我认的目标就仨，能解释、能复核、业务肯认，不追那个漂亮数字。

几年攒下来的，翻来覆去就这些

1. 最贵那几套没人盯，拒绝日志攒一堆，反倒天天讨论最便宜的工具。2) 开着界面下班不关，feature 占一整夜，CPU、IO 基本是零。3) borrow 借出去，人回来不还，服务器上平白少几个。4) 例外全靠口头，"先给他开一下"，过俩月连批准人都查不出。5) 日志只有汇总，下不去，回不到具体设备、账号、模块。6) 今天的快照盖住历史；还有那种没责任人、没完成时间、没回读验证的改进，人一换项目一变，立刻回原样。
   
2. 头两周，只要三样，别的一个字不改
3. 至少拉一个完整业务周期，项目型的还得盖住关键节点，淡季平均值最会骗人。
4. 一，把高成本、高拒绝、高闲置挑出来，不全量铺，就那几套贵的、跟出图绑死的，顺手记下例外场景和批准人，后面做策略才不误伤关键任务。二，确认业务关键时段和真实用户群，谁天天用，谁一年碰两回。三，翻合同，看允许你怎么优化——能不能按 feature 拆池、能不能跨站点调、闲置回收写没写进条款。这条最容易漏，也最容易出事。
5. 导完表抽样回读源系统。人工合并粘错行这种事我见太多了，拿份错表去评审，一天白开。所以只认同一份底稿，带版本号和时间，IT 出数据、采购对合同、业务定优先级，合规争议法务把关。查不明白的标"待补证据"搁着，别拿推测填。
6. 动刀，顺序别反
7. 建基线：每件事挂责任人、完成时间、验证材料。清单不是交完就完的一次性文档，得进月度运营和变更管理，不然下个月又从头来。
8. 选场景：一个部门或者一类软件先试，稳了再扩。别一上来全铺，我吃过这个亏。
9. 上策略：闲置提醒、超时回收、队列调度，普通走系统、例外走书面审批。执行前通知到人，执行后收重新申请和异常反馈。白名单、延迟、人工恢复入口，三样都得有，关键项目不拿来试错。
10. 复盘再扩：命令返回 success 不算完，得回头看业务那边是不是真不堵了。每次改规则记下改了啥、为什么、前后指标变多少，版本和理由留着，审计时候救命。

1. 工具最后，一句带过
2. 许可优化那类东西，能把软件发现、许可日志、账号分配、整改记录归到一个视图，也一直记着拒绝下降趋势这种数。但它不替你定谁插队，不替你批钱。合同怎么解释、对外怎么承诺，得有资质的人过一遍，IT 别顺手签。
3. 我盯的数就四个
4. 许可满足率，指定谁负责、多久复核一次。闲置回收量，公式写死，纳哪些不纳哪些说清楚。拒绝下降趋势，连着看，口径变了记一笔。用户体验反馈，抽样回读源记录——别信"零投诉"这种话，有时候只是大家懒得骂了。指标突然变好或变差，先怀疑采集覆盖和口径，别急着说业务变了。效率、体验、风险三项同时过得去，才算验收。
5. 别这么干：单日单次报错当趋势；没做供需分析就先采购或者强制回收；四个口径混着算利用率。
6. 去年冬天那单
7. 做风电齿轮箱的一家，有限元求解器 20 个浮动许可，外加一个显式动力学模块。评审前一天十几次 denial，IT 方案都写好了：按 feature 拆池加闲置回收。翻合同才发现，那批是打包的 bundle，条款写明不允许拆开单独转授，也不让跨厂区调度。拆池这条直接作废。
8. 只能走能走的：闲置 6 小时提醒、8 小时回收，跑满 8 小时的任务进白名单，白名单走书面审批、批准人挂号；能延后的算例错峰到夜里；borrow 压到 14 天到期提醒。
9. 拉了一个季度看，14 个会话挂着过夜不动，3 个 borrow 两月没还，真实峰值并发 13。两个月后拒绝基本没了，续费一个没加。中间误伤过一次，一个 overnight 的显式任务被回收，重跑一整晚，从那以后回收脚本对带预约标记的一律跳过，那条规则版本我到现在还留着。