仿真排队排到下班？我们改了个设置就快了3倍

翻出2016年刚入行时写的许可运维手写笔记，纸都泛黄了，当年的认知现在看一半都是错的。

那时候我觉得许可管理就是装软件、输密钥、激活完事。笔记本第一页写着"多买几套许可准没错，不够用就加"，现在看简直像笑话。当年我坚信许可是越多越好，领导问预算我就往上报，结果公司账上躺着四十套仿真许可，日常同时在线的从来不超过十二个人，钱全压在抽屉里吃灰。我还觉得手动管最靠谱，每天拿个Excel表格记谁借了谁还了，觉得自己特负责。现在回头看，那不叫运维，叫记账。对许可池的周转逻辑、对并发峰值和总装机量的区别，当年的我完全没有概念，把"拥有数量"等同于"可用能力"，这是最致命的认知偏差。

第一段讲仿真排队这事。去年有个客户，三十个工程师共用八套仿真许可，每天下午两点开始排队，有人等到下班才轮到跑任务。业务部门天天催我加购，我差点又按老思路报预算了。后来我翻了许可服务器的日志，发现真正的问题不是数量不够，而是默认释放超时设成了八小时。也就是说，一个人跑完两小时的任务，许可要空占六小时才归还给池子。我把超时改成四十分钟，加了一条空闲自动回收规则，第二天排队直接消失，八套许可撑住了三十人的日常。当年踩的大坑是：我第一份工作里，前主管坚持"排队就是不够用"，硬让公司多买了十五套许可，花了将近二十万。实际上只要把超时从默认值调短，一套都不用加。那十五套许可到今天还在闲置，每次盘点我都觉得心疼。

第二段讲许可分配别搞平均主义。同一个客户，我把八套许可拆成两组：五套给结构仿真这种高频刚需，三套给流体分析这种低频但单次占用久的任务。之前混在一个池里，做流体的人一跑就是六小时，把做结构的人全堵在外面。分组之后两边互不干扰，吞吐量又涨了一截。当年那个坑我记在笔记本第三页：有次我把所有许可放进一个池子，一个实习生跑了个错误参数的仿真任务，挂了整整两天没关，全部门等他一个人释放许可。我当时只会打电话催他关机，压根没想到要在服务器端设单用户最大占用时长。如果当年懂这个，一个参数就能拦住，不用打那通电话，也不用看全部门干等。

第三段讲客户端的缓存刷新周期。那个客户改完服务器设置后，有五六台机器还是连不上。我第一反应又是"网络问题"，差点又去甩锅给网管。后来查下来是客户端本地缓存了旧的池子分配信息，刷新间隔默认是二十四小时。改成十五分钟强制同步，问题立刻消失。当年最离谱的一次是2017年，我花了整整一周排查"许可服务器不稳定"，最后发现是客户端DNS缓存过期没更新，跟服务器一点关系没有。那一周我拉着网络组开了三次会，写了长篇报告，最后改了一行hosts就解决了。丢人归丢人，但那个教训刻得最深：排障先查客户端本地状态，别一上来就怀疑服务端。

最后说两个入行十年才真正想明白的底层逻辑。第一，许可管理的本质不是"管资产"，是"管时间"。一套许可值不值，不看你花了多少钱买的，看它一天被有效使用了几小时。周转率上不去，买一百套也是浪费。第二，所有许可故障里，百分之八十的根因在客户端本地，不在服务端。遇到报错先查本机缓存、注册表、时间同步，别急着重启服务器。这两条我花了十年才从"知道"变成"本能反应"，如果2016年那个蹲在机房翻手册的自己能看到今天这篇东西，大概能少走五年弯路。

笔记本合上了，纸确实黄了，但上面那些弯路，一步都没白走。