收到 License 合规函先别卸载：异常使用怎么核，软件许可事实和许可回收的正确顺序

法务周五下午转过来一封函，代理发的，附件一张截图，列了十一台机器号，写"疑似超出授权范围"。群里三分钟就炸了，第一句是"先把那几台卸了"，第二句更狠，"日志也清一下，别留把柄"。我当场把群禁了。最怕的从来不是那封函，是自己人先动手把证据毁了，后面想说清楚都没得说。

这事儿压根不是技术排查。它是内部事实调查加合同边界，两样搅一块，谁单独拍板都要出事。别一上来就问"要不要再买几套"，加资源是最省事也最不负责任的那个动作，先把真实需求、现有供给、授权边界对上再说。要的是可解释、可复核、业务能接受，不是给谁交一个漂亮百分数。厂商到底怎么发现异常的，我不猜，也不替他们猜，合同里审计条款和通知期限翻出来就够了，猜机制除了让自己先慌，没别的用。

〔 报错不等于超授权 〕

日志里一句 license denied，看着吓人，其实可能是池子容量不够，可能是 options 文件里 RESERVE 锁了某个 feature，可能是权限没开，也可能纯粹是借用许可没人还。日志时间线得跟业务场景摞一块看，单拎一条出来定性，我见一次拦一次。

管理者要的也不是更多原始日志，是能拿去开会的决策证据。设备—账号—许可—项目，这四样串起来，谁受影响、什么时候、是不是重复发生、现在风险落在哪，写清楚就行。口径不齐，扩容、调度、回收、整改全没有共同起点。

三类矛盾我一般随手记白板上，不整齐也没关系：

——安装量对不上授权量，多半是报废机没销号，或者测试机装完没人管；

——授权量对得上、使用量看着超了，先翻合同里第三方、外包、关联方那几条，技术日志自己下不了这个结论；

——来函说的数跟资产台账对不上，别急着认，也别急着否认，中间差的那段历史变更才是重点。

核查范围，就三件事，别扩也别省：

• 不假设厂商具体检测机制。当前状态跟历史变化分开记，别拿今天的数据去解释去年那批机器，报废单、变更单都在，翻出来比我嘴说管用。
  
• 核对来函内容与内部资产记录。得跟合同、业务排期交叉验证，技术日志单独不能形成最终结论，这条我从不让步。
  
• 联网设备、账号、外包使用边界过一遍。原始记录、统计周期、数据负责人三样留全，谁转述一句"大概就那几台"不算证据，我一律不收。（顺手把 VPN 进来的外部终端也列上，最常漏的就是这个。）
  
• 四栏压一页就够，事实 / 缺口 / 影响 / 责任人，别做成花里胡哨的表，上会没人看。比如"11 台在册、6 台已报废 / 资产台账未同步 / 来函数字虚高 / IT 张某 3 月 9 日"，一行一个，能追到人就行。
• 〔 顺序反了就收不回来 〕
• 先立独立的内部事实调查，单一负责人，沟通边界写死，每份材料标来源和时间，别七八个人各收各的截图。然后验授权凭证（entitlement）跟实际使用主体，原始证据先冻住，哪些动作能做，法务点头再动。来源不明的安装做隔离整改，隔离不是卸载，结果要能对应到设备、账号、合同、真正用的那个人。事实和待确认事项分两摞摆着，再决定内部整改和对外回函先后，必要时把法务或专业顾问叫进来，别省那点咨询费。gofar 那头把安装、授权、使用线索归到一处，IT 找异常快些；真到停用、隔离、对外回复，还是按合同和内部制度拍板，工具替不了。任何一步动之前，业务影响和授权依据先确认，我见过没确认就禁账号，周一早上出图全停。
• 复盘口径，四个，别多：
• 来源不明安装数 —— 连续看趋势，口径一变就记一笔，不然今年跟去年没法比。
• 授权核验覆盖率 —— 抽样回读源记录，二十条里错两条就得重来。
• 外包账号清理率 —— 按部门、按项目能下钻，光一个 100% 我不认。
• 证据可追溯率 —— 跟整改任务或者业务事件挂上钩，孤零零一份截图不算。
• 趋势比单点有意义，至少连续两个复盘周期再谈要不要扩策略。效率、体验、风险都还在能接受的范围，才算过。
• 别这么干，说多少遍都有人犯：只凭一封来函、一张截图、一条日志就认责任性质，证据根本不够；急着卸载、清设备、删日志，时间线一断，本来能说清的也说不清了；几个部门各回各的邮件，事实口径、承诺范围、材料版本能差出三个样；把技术排查结果直接当法律结论交上去，合同条款、授权类型、具体使用场景全被跳过去。特别是最后一条，IT 别自己扛。
• 问：能不能先卸了再说。答：不建议，卸载当唯一动作最糟，必要记录先留，业务影响先确认，隔离、停用、整改的次序法务和 IT 一起定，别一个人半夜点鼠标。
• 问：谁参与。答：IT 还原技术事实，采购翻授权材料，业务确认到底谁在用、干哪张图，法务或专业人员审对外口径，就这么几方，多一个都乱。
• 问：收到通知要不要马上回。答：先把来函主体、要求、截止时间核清楚，统一窗口回，事实没核清之前谁也别以个人名义承诺责任或者金额，那句话一发出去就收不回。gofar 集中记记外包账号清理率这类运营证据挺好，审批和专业判断它不替代。

• 〔 3 月那回，华中做轨交装备的一家厂 〕
• 3 月 4 日 来函，SOLIDWORKS 代理，附截图列 11 台机器号，合同附件里 entitlement 写的是 40 个 SolidNetWork License（SNL）并发许可，对方说疑似超了。群里有人要连夜卸，被按住，日志和资产台账先做只读快照。
• 3 月 6 日 SNL 许可服务器日志拉了 14 个月，跟资产台账一对，11 台里 6 台两年前就走了报废流程，销号没做，台账还挂着；另有 3 台借了 borrow 离线许可一直没还，占着坑，出图周那几回 denied 是这么来的，跟超授权不是一回事。
• 3 月 11 日 真缺口翻出来了：6 个外包设计院的人拿内部域账号走 VPN 连进 SNL 池，合同里第三方使用那条没覆盖，外包排期正好压在 3 月那批图上。没卸载，先把这 6 个账号冻结、原始日志和两台样机镜像封存，法务统一窗口回函，只确认收到、列事实与待确认事项，没认责任，没报金额，也没解释厂商那张截图怎么来的。
• 4 月 补了 6 个并发，true-up 按合同附件年度口径结，外包改走独立临时授权、单列批准人，borrow 周期从 30 天压到 7 天，报废机销号挂进资产流程，指定了人。
• 连续两个复盘周期，来源不明安装数 11→2，授权核验覆盖率 68%→97%（回读 20 条，错 1 条重核过），外包账号清理率 6/6 按三个项目下钻，证据可追溯率跟四张整改单全对得上。那 6 张报废单的编号贴在证据目录第 3 页，日志谁也没删。