大模型辅助的 ITSM 变更风险评审落地

日期:2026-07-25

一、项目背景

某企业的 IT 变更评审长期靠人。一份变更单可能包含 SQL 脚本、配置改动、服务启停,评审人要在几分钟内看出"这条 Drop 表会不会影响在跑的业务""这个配置改了会不会触发限流"。但资深评审者稀缺,标准也不统一——A 评审人觉得"没事"的改动,B 评审人可能看出高危。更危险的是,变更单里夹带的"高危操作"(如全表更新、跨机房写、权限提升)常被淹没在几十行脚本里,靠人眼扫容易漏,漏一次就是线上事故。

我们当时判断,核心矛盾是"变更风险看不全、标准不统一、高危会漏审"。这个项目里,我们采用私有化 AI 底座承载大模型评审,把"读变更单、抽风险、标高危、推清单"做成评审平台的前置环节。底座确定后,真正的难点是怎么让模型真正读懂技术语义、和历史事故对齐、又不滥用模型导致误报淹没评审人。

二、落地场景

第一类场景是变更语义理解与风险抽取。大模型读变更单(SQL/配置/YAML/说明),抽取出"影响对象、操作类型、影响范围、回滚方案",并标记其中的高危模式(DROP/TRUNCATE、无 WHERE 的 UPDATE、生产写、权限提升)。

第二类场景是历史事故对齐。我们把过往变更事故库作为参照,模型在评审时召回相似历史事故,标注"此类操作曾导致 X 事故",让评审人看到先例而非凭空判断。

第三类场景是高危项分级与误报控制。不是所有"DROP"都高危(可能是临时表),模型结合上下文做分级(高/中/低),并给出"为什么判高危"的依据;对低置信度项标"建议人工复核"而非硬判,控制误报。

第四类场景是与评审平台对接闭环。评审结果以结构化清单嵌入 ITSM 变更单,评审人只需确认模型标的项、补充判断,而非从零读脚本;高危未通过则卡住变更。

落地过程中我们还补了一块常被忽略的能力:评审一致性看板。过去不同评审人标准不一,现在模型给出统一基线标注,人工只在"边界项"上做判断,评审口径被拉齐。

三、关键技术挑战与解决思路

第一个挑战是变更语义理解与风险抽取。关键不是"正则匹配关键词",而是"理解上下文"——一个 DROP 在事务里且有回滚是低风险,裸 DROP 是高风险。我们用结构化 prompt 让模型输出风险清单。下面是评审 prompt 与分级的脱敏片段。

# 变更风险评审 prompt 与分级(已脱敏)
review_prompt: |
  你是资深变更评审。读下面变更单,抽取:影响对象、操作类型、
  影响范围、回滚方案,并标记高危模式(DROP/TRUNCATE/无WHERE更新/
  生产写/权限提升),按高/中/低分级并给依据。
risk_tiers:
  high:   "生产库 DROP/TRUNCATE、无WHERE全表更新、跨机房写、权限提升"
  mid:    "大表加列锁表、配置影响限流、批量删除"
  low:    "临时表操作、只读查询、回滚完备的小改"

第二个挑战是历史事故对齐。我们把事故库做成可检索知识,模型评审时召回相似变更,标注"类似操作曾致事故",让评审有先例支撑,也把"个人经验"沉淀成"组织记忆"。

第三个挑战是高危项分级与误报控制。模型对低置信度项只标"建议复核"而非硬判高危,避免误报淹没评审人。我们设了"高危必须人工确认"的硬卡点,模型辅助、人守最后一关。

四、效果数据

改造前后,我们拉通了四组口径一致的脱敏示意指标:

指标改造前改造后说明
评审采纳率约 65%约 92%评审人采纳模型标注比例
高危漏审率约 8%降至约 1%高危项未被标出比例
变更事故率约 3.5%降至约 1.2%变更引发事故占比
评审工时约 25min降至约 8min单变更评审耗时

上表为脱敏示意值,用于说明趋势而非审计口径;事故率为季度统计口径。

五、可复用经验总结

第一,评审辅助而非替代。我们没想用模型替评审人拍板,而是把"读脚本、抽风险、标高危"这种重复劳动交给模型,人只在边界项上判断。模型擅长扫全、人擅长定夺,分工清晰。

第二,高危先拦截、低置信只提示。误报比漏报更伤信任——如果模型天天标一堆假高危,评审人会直接忽略。对高危硬卡、对不确定只建议复核,既保安全又控误报。

第三,历史事故要变成组织记忆。把事故库接进评审,让"类似操作曾出事"直接显示在变更单上,评审口径被拉齐,也把个人经验沉淀为可复用的知识。

第四,结构化输出才能接平台。模型如果只写一段"建议谨慎",平台没法用。我们要求输出结构化风险清单,才能嵌进 ITSM、才能卡住高危变更、才能做一致性看板。

案例片段(已脱敏):一份变更单里夹了一行无 WHERE 的 UPDATE,意图是修复某状态字段,但会全表更新。模型在评审中将其标为高危并附"无 WHERE 全表更新,影响全部在跑订单"依据,召回历史库中一起类似误操作事故。评审人据此要求补 WHERE 与事务回滚后才放行,避免了一次可能波及全量订单的事故。

案例片段(已脱敏):一次配置变更模型初判为"中危(影响限流)",但结合上下文发现该限流配置仅作用于测试命名空间,模型将置信度标低并改"建议人工复核"。评审人确认测试域后快速通过,未被误判拖慢。该机制上线后,评审人采纳率从约 65% 升至约 92%,说明误报控制到位、标注可信。