上海画图，北京仿真，共用一套许可怎么不打架？我们试出来了

这破许可问题卡了我2小时17分钟，差点赶不上接娃放学，回家还被老婆骂了一顿，必须把整个过程完完整整记下来。

昨晚本来计划五点四十准时走人。五点二十三分，北京那边突然在群里炸了。说仿真提交上去一直卡在队列里，报错说许可证不可用。我远程看了一眼FlexNet的lmstat，上海池子里显示还有6个空闲。这就怪了。北京那边说他们明明看到有4个任务在等。我从座位上弹起来，眼睛盯屏幕上开始排查。手机响了，老婆打来的。我没接。又响了。我还是没接。娃幼儿园六点十分关门，迟到要扣钱。我心里有数。但脑子还在转，为什么显示有空闲却抢不到？这时候我还没意识到，接下来两个多小时我把自己绕进去了。

第一条弯路真叫一个蠢。我第一个念头是网络延迟问题。北京连上海的License Server，跨专线会不会丢包？我翻出ping和telnet测了一通，延时不到10毫秒，稳得很。又查了防火墙策略，端口全开。折腾了快四十分钟，啥都没改。又去查FlexNet的日志，发现报错是"Feature not licensed"。我就盯着那几个Feature ID挨个对，明明都有啊。结果你猜怎么着？我从头到尾没注意到时间是五点二十多，那时候大批上海同事已经下班了，许可确实闲在那里，但北京同事用的是另一个Feature版本号，就差一个尾缀，一个叫XX_2023，一个叫XX_2024_LTS。上海那边没人用2024版，所以2024版的池子是满的，2023版的池子是空的。我当时心态就是"我真是个傻子"。

第二条弯路更加离谱。我查完Feature发现版本不对，就想着干脆让北京那边统一切到2023版算了。结果切完之后还是报错。我又回头去查FlexIni文件，怀疑是SERVER行配错了端口。重启了两次服务，每次重启时上海同事就嗷嗷叫说连不上了。群里开始有人问"谁在动服务器"，我硬着头皮没吭声。那时候正好六点整，老婆消息发过来："人呢？"我回了个"马上"然后继续埋头。实际上问题根本不是端口，而是北京提交任务的脚本里写死了环境变量指向旧版本的二进制，新切过去的Feature名称不认，前台界面切了，后台脚本没切。我当时心态是"能不能别这么搞我"。

第三条弯路我自己都不想提。我开始怀疑是FlexNet的option文件里那个超时回收白名单出了问题。因为之前我给上海的结构组单独放过长仿真白名单，我怕这个白名单把北京IP段给拦了。我把option文件翻出来逐行看，又加了一行INCLUDE把北京那个网段放进去，再重启服务。白忙活一顿。事后复盘发现根本就是前面两个问题叠在一起造成的假象，第三个完全是自己吓自己。真实心态是"赶紧让我走吧，天都黑透了"。

最后把三件事做完问题才消停。第一是统一了两边Feature版本号，把2023版全部淘汰，都走2024_LTS。第二是把提交脚本里的环境变量写成动态判断，不再写死版本号。第三是加了条规则，每天下午五点之后，北京提交的任务自动切换指向远程备用的一个许可池子，避免和上海下班前那波清理操作撞车。三件事做完已经七点四十七分了，我冲到幼儿园门口的时候，娃是最后一个被老师牵着站在门卫室里等，老师说"下次早点"。

这事之后我连夜定了三组小设置防止再犯。第一个就是每天下班前定时跑个脚本把两个地区的Feature列表自动比对一次，不一样的直接报警到我手机上。第二个是把FlexNet的日志输出级别调高，把每一个Feature分配的精确版本号打出来，以后一眼能看出谁拿的是哪个包。第三个更土，我把那台License Server的hosts文件里强制把两个Feature的别名写死了，不管脚本怎么传参都只能拿到当前激活的那个版本，彻底断掉混用的根。亲测好使，这周已经帮3个同事解决了同款问题。

—— 一个刚被老婆骂完的运维老哥