如果你做过 ITIL 事件管理，一定对下面这个场景很熟：

月底了，要做月报。

工单系统里有一堆事件单，你需要统计数量、看 SLA、找高频故障、整理用户反馈，最后再写点分析结论和改进建议。

问题是，这种事越到后面越容易变成体力活。

因为工单不是没有信息，而是信息太碎。

单条事件看得明白，不代表整个月的规律看得清楚。

我最近看了一组 200 条事件单的分析案例，最大的感受是：

AI 在这里最适合扮演的角色，不是“替你写月报”，而是“帮你把所有本来要靠人工反复比对的模式先找出来”。

如果你也想把 AI 用到 ITIL 事件分析里，下面这套思路比较值得参考。

先明确：事件单分析的目标，不只是做统计

很多团队做月报，其实默认目标只有两个：

• 汇总本月处理了多少事件；

• 看 SLA 是否达标。

这两个指标当然要有，但如果只停留在这里，月报通常很难产生治理价值。

因为它只能告诉你“发生了什么”，很难告诉你“为什么总在发生”。

真正有价值的事件分析，至少要多回答三类问题：

• 哪些问题在重复出现，只是换了表象？

• 哪些配置项或系统存在持续性风险？

• 哪些反馈说明流程或体验有明显短板？

这时 AI 才有用武之地。

因为它比人工更适合做跨字段、跨时间、跨描述的归并。

事件单字段越完整，AI 的输出才越靠谱

这是个很现实的问题。

很多人一上来就想把工单丢给 AI，然后希望它自动总结出高质量结论。

但实际效果，基本取决于事件单本身写得怎么样。

如果事件单有这些字段：

• 服务目录

• 优先级

• SLA 时限

• 实际 TTO/TTR

• 事件标题

• 问题描述

• 解决方案

• 关联配置项

• 用户满意度与评论

那 AI 基本就能做比较像样的分析。

因为它至少能同时看“影响范围、处理动作、资源对象、用户感受”这几件事。

但如果工单写成这样：

• 现象：系统异常

• 处理：重启后恢复

那分析上限就很低。

AI 最多只能告诉你：这是一条重启型处理事件。

至于根因、重复性、系统性风险，基本无从谈起。

所以第一条经验很明确： 想让 AI 产出有用结论，先把事件单写规范。

一定要做“解决方案归类”，它能快速看出团队是不是在重复救火

这组样本里，最典型的发现之一就是：

有相当一部分事件，是通过重启服务、清缓存、释放资源、手动恢复之类的方式结案的。

这件事为什么重要？

因为从事件处理角度看，这很正常；

但从月度治理角度看，它暴露的是另一个问题：

团队是否有大量事件停留在“恢复服务”层面，没有进入根因治理。

所以我建议，如果你要让 AI 参与月报，优先做一件事： 把解决方案字段做统一归类。

比如可以粗分成：

• 重启/重载类

• 清理/释放类

• 手工修复类

• 配置调整类

• 代码修复类

• 硬件/环境处理类

归完类之后，很多问题会一眼看出来。

如果“重启/清理/手工处理”占比长期偏高，那基本就说明团队还在偏被动运维阶段。

不要只按系统统计，最好再加一层“配置项聚合”

这是我觉得最容易出价值的一步。

大多数月报喜欢按系统统计：

MES 出了多少单，EAP 出了多少单，网络多少单，桌面多少单。

这没问题，但这种维度很容易把真正的风险打散。

因为风险不一定按系统边界出现，它可能集中在某台服务器、某个节点、某个数据库实例上。

你把同一个配置项一个月内关联的所有事件聚到一起，很容易发现几类典型场景：

• 表象不同，但都在指向容量不足；

• 故障位置不同，但都和同一台服务器状态有关；

• 业务现象不一样，但底层都和某个数据库维护不到位有关。

这类发现特别适合拿来做下月治理重点。

因为它已经不是“某次偶发问题”，而是“同一对象反复触发事件”。

用户评论不要只算满意度，最好再做语义聚类

很多团队的满意度分析太粗了，通常只有：

• 满意多少

• 不满意多少

• 非常满意多少

这样看其实用处有限。 真正应该分析的是：用户为什么不满意。

AI 在这里很擅长。

它可以把各种表达不同、意思相近的评论归到一起，比如：

• 响应太慢

• 解决太久

• 影响业务

• 备件不足

• 同类问题反复发生

一旦做完这个聚类，你就能把满意度从“结果指标”变成“改进输入”。

尤其是和优先级、SLA、业务影响交叉看时，往往能很快定位到真正需要先优化的流程环节。

平均值只能看趋势，真正危险的要看异常样本

整体达标率、平均响应时间这些指标，适合看趋势，但不适合单独拿来判断风险。

因为平均值最大的问题就是会把关键异常冲淡。

比如某些高优先级事件，本身要求极短响应时限。

只要这类事件超时，哪怕数量不多，也应该比很多普通事件更值得关注。

所以我的建议是： AI 做完全量统计后，一定要再拉一层异常事件列表。

重点盯：

• 高优先级且超时的；

• 影响生产/质量/外部访问的；

• 涉及关键控制点失效的；

• 低频但高后果的。

这类单子通常才是真正影响团队治理质量的关键样本。

一个更实用的落地流程

如果要把这套方法放进月度复盘，我觉得比较实用的流程是：

第一步：准备原始事件单

保证字段齐全，尤其是描述、解决方案、配置项、用户反馈。

第二步：让 AI 做四类基础分析

• 事件数量与 SLA 统计

• 解决方案归类

• 配置项聚合

• 用户评论语义聚类

第三步：让 AI 输出异常和模式

比如：

• 哪些处理方式重复率高

• 哪些配置项反复卷入故障

• 哪些场景用户最不满意

• 哪些事件虽然数量少但风险高

第四步：人工审核并转成行动项

比如扩容、整改、补监控、加巡检、建审核机制、优化值班等。

这一步不能省。

AI 适合做“找线索”和“生成初稿”，但正式结论必须人工把关。

AI 在 ITIL 里真正改变的，不是流程，而是复盘深度

我觉得这才是重点。

AI 并没有改变 ITIL 事件管理本身。

事件还是要受理、分类、响应、恢复、关闭。

但它改变了月度复盘的深度。

以前很多团队只能做到：

• 看数量

• 看达标率

• 看 Top 故障

现在可以进一步做到：

• 看重复恢复模式

• 看配置项系统性风险

• 看用户痛点聚合

• 看低频高风险事件

• 看哪些线索值得升级为问题管理项

这一步，才是从“事件记录”走向“治理输入”的关键。

如果让我用一句话总结这次案例，我会说：

AI 最适合做的，不是替运维写报告，而是帮运维把那些原本要靠经验、记忆和反复翻工单才能发现的规律，先系统地找出来。

这样团队才能少做一点重复救火，多做一点前置治理。

而这，也许才是 AI 放进 ITIL 场景里最现实、也最值得落地的价值。