CIO们注意了：软件许可证这事不再是法务的活儿了

翻朋友圈看到2022年今天发的吐槽，有个员工离职没退许可，3个浮动许可直接被锁死了半个月。

那天真是把我气坏了。我们公司一个搞仿真的工程师离职了，走之前一切正常，AD账号当天就禁用了，我这边完全没收到通知。结果他临走之前用自己笔记本连过公司的浮动许可池，走的时候直接把本子合上了，休眠之后session一直没断，FlexNet不检测客户端的空闲状态，只要网络通着就可以一直占着那个会话。那三个许可就这么被锁在了他的笔记本上，而他那台本子被带回家扔在柜子里没再开过机。整整半个月时间我们全部门的仿真排队越来越长，我一直以为是任务多了，直到有一天无意中翻日志才发现那三个Feature被同一个用户名占着，而且已经连续在线了三百多个小时。查了考勤系统才知道这人早走了。那半个月里设计部因为排队耽误的工时折算下来得有好几万，就因为没有及时释放三个空转的许可。

那件事之后我开始琢磨一件事，软件许可的管理真的不能再只当法务或者采购的活儿来干了。以前公司里面谁买许可、谁来管合规是法务那边牵头，IT只管装机和连授权，根本没人去盯"人走了许可还在不在"。我后来从CIO的角度重新捋了一遍整个流程，把责任边界彻底理清了。

第一个认知转变是"许可的归属要跟着工位走，不能跟着人头走"。以前采购那边的台账是按员工名字登记的，谁申请买的、谁在用、谁负责管理全是人名。但人走了台账上那行名字就失效了，许可到底锁在哪台设备上根本没人知道。我后来把台账改成了按设备编号登记，哪个工位哪台电脑绑了什么许可一目了然，员工离职的时候只需要查那台设备对应的授权状态，其他关联的许可全部清理掉。当年踩过一个无效的试错是我去跟人事说"你们离职流程里加一步通知IT"，人事同意了也加了，但实际操作的时候交接人和离职员工都不把那个步骤当回事，十个人里面有八个漏填，IT照样最后一个知道人走了。

第二个认知转变是"离职触发回收得靠系统自动做，不能靠流程等人通知"。我后来在AD域和License Server之间搭了一个联动脚本，每天早上六点自动跑一次，把AD里已禁用账号跟许可池里的会话列表做比对，发现有匹配的就自动执行lmremove把那个会话踢掉。这样即使HR那边忘了通知，系统每天也会扫一遍，最多延迟二十四小时，不会出现半个月还没人发现的情况。当年踩过一个完全无效的试错是我试着让离职员工在离职当天自己手动退一下许可，还发了邮件提醒请他们离职前把所有软件退出。结果十个人里面有九个根本不看邮件就走了，剩下一个看了也忘了，完全靠不住。

第三个认知转变是"离职当天的许可回收要抢在账号禁用之前先做"。因为AD账号禁用之后，FlexNet虽然会话还在，但某些版本的服务在回收时会去反向查证用户名有效性，如果查不到就开始报错拒绝执行lmremove。我后来的做法是在离职流程里加一个前置步骤：HR在系统里发起离职申请的那一瞬间，自动触发一个脚本去把该员工名下的所有许可session强行终止掉，然后再走账号禁用和回收设备的流程。这样动作顺序是对的，许可先放出来，账号再禁用，两不耽误。当年踩过一个坑是我先禁用了账号再去回收，结果那批老版本的FlexNet查不到用户就拒绝踢会话，导致3个Feature被死锁了我只能手工重启整个服务才解决。

最后说两个我现在做的离职当天自动回收的懒人设置。第一个是在AD离职触发器上加一条钩子，员工状态一变成"离职中"就自动把该员工的所有邮箱、账号信息传到一个我写的api接口上，接口再去查许可服务器的当前会话列表，匹配到就全部清掉，完全不用人参与。第二个是我在公司IT服务台的门户页面上加了一个离职交接清单的动态勾选项，IT运维那栏默认打勾，里面写了要确认该员工的许可已经被回收，HR那边的离职流程只有看到这个确认状态才会进入最后一步发离职证明，这个强制锁死比发邮件提醒有用一百倍。

2022年那条朋友圈我后来删了，但截图还留着，时不时翻出来提醒自己那笔学费不能白交。亲测好使，这周已经帮3个同事解决了同款问题。