您现在的位置是：首页 > 文章详情

IT工单治理野史：由每周最高150+治理到20+ | 京东物流技术团队

日期：2024-02-05点击：48收藏

背景

相信不少人都值过班当过小秘吧，每天都要在线排查与解答各种各样来自IT或"单聊"的问题，同时还要针对每个问题进行"复盘"分析，在完善系统、提高体验的同时挖掘出其中的雷点，防止某一天突然"爆炸"造成不可控的局面。

我们这边在值班小秘每日进行线上问题排查、解答与跟踪，工单量越大耗费的精力和成本就越高。周而复始了一段时间之后，发现IT工单量不但没有得到明显的降低，而且还很不稳定，一周最高可达150个，效果不是很理想。于是此项被单独成立为一个目标，而我被指派为此项负责人，会在每周对上一周的IT工单逐个进行分析复盘，其中治理的具体思路和过程如下。

在此之前，我们先来看一下比较振奋人心的实战效果吧，来吧，上图

新方案实践

1.问题分类治理

在进行了一段时间跟踪治理之后，发现很多问题在本质上都是同一类问题，如果是按场景、功能模块、操作节点等维度进行归类，同一种类别算成是一个工单的话，那么这个量级至少是一半以下，基于上述发现，我们基于这样一个原则来进行问题归类以及各类别的治理方案：优先分析、跟踪治理优先级高的类别问题，优先级规则如下（由高到低）

• 影响财务结算类问题（涉及到计费模块类的功能异常）

• 影响系统稳定类问题（系统缺陷、BUG等）

• 产品场景异常类问题（场景丢失、场景越界等）

• 系统体验类问题（并发、核心实操类功能性能低下、提示术语存在歧义等）

• 其余非咨询类问题量级由高到低

• 其他问题

基于以上优先级规则，我们的归类维度以及对应治理方案主要如下（出现频率高的类别）

• 系统类问题

◦ 系统缺陷类（并发、业务交叉等）-->挖出根因并修复，而不是简单的更改数据

◦ 系统BUG类（代码逻辑错误）-->多方核实出正确逻辑并修复上线

• 产品类问题-->多方排查核实并由产品和业务牵头进行业务场景梳理落实需求

◦ 场景丢失

◦ 场景越界

• 体验类问题

◦ 功能慢需要等待-->进行性能优化

◦ 提示语歧义不明确-->展示信息纠正抽象概括类名词未具体语义名词、多业务同名名词进行区分改名、实操提示语中明确具体因由和解决方案等

◦ 操作繁杂-->根据具体场景进行简化：能自动带出的信息自动带出、能简化步骤的简化步骤、能进行合并的进行合并等

◦ 操作口隐藏太深-->根据对应场景进行功能模块的聚合

◦ 业务逻辑反人类-->重新核实业务逻辑并进行优化

◦ 重要信息没地儿查-->现场调研收集吐槽点、核实分析后产出需求或一些简单信息直接在对应模块页面上展示出来

• 业务实操类-->多次培训

◦ 业务规则卡控

◦ 基础信息配置卡控

◦ 异步逻辑无感

• 咨询类-->多次培训

◦ 业务规则咨询

◦ 协助查询数据信息

◦ 系统使用教程

◦ 系统中一些业务词汇或数据的含义解释

◦ 对应职责对接人员名单

• 其他类

◦ 历史问题（N年没有的业务突然来量了，系统逻辑早已面目全非）-->重新核实业务逻辑并进行优化

◦ 数据类问题（N年前的数据已经结转走了）-->提供拉回功能和权限控制

经过上述的方案进行治理了一段时间之后，需要产品、研发、业务介入跟进开发落实类的问题是越来越少，系统的稳定性提高不少。不过呢IT单量虽然整体有所下降，但是并没有达到预期，因由就是优先级高的类别问题占比总体其实并不大，而除此之外的其他类问题占比最大的就是咨询和实操类别的问题，而这两类占比更高的是咨询类问题（几乎是一多半），所以我们又想出了接入智能问答机器人的方案。

2.接入智能问答机器人

基于上述经历呢，我们决定基于最小成本和简易问答场景进行接入一款智能问答机器人进行尝试，经过与多方沟通最终采用慧言机器人：对比过程这里不再详述，各个机器人平台都有对应的教程文档和对接人，随时可看与咨询，大体原则是：接入成本、使用场景两个主要要素。

接入前我们整理了下述类别的数据，并会定时更新

• 咨询类问题与答案-->原材料来源于日常值班记录和IT工单数据

◦ 业务规则咨询

◦ 系统使用咨询

◦ 名词解释咨询

◦ 上下游关联场景咨询

◦ 其他零散类咨询

• 系统教程类文档

• 上下游交互类文档（接口、MQ等）

• 各系统对接人/值班人文档

风风火火一顿整理后同步后，就开始尝试进行推进，在日常工作中、对应的群里以及一些联手小伙伴们都会时不时地进行宣导，一段时间下来后发现实际效果确实是差强人意，IT单总量几乎是没有什么大的变化，后来经过私下调研一些使用者的反馈后，大体总结出以下几个原因

• 不够便捷，需要弹出京me进行咨询

• 命中率不高（是个难题）

• 推广受限（使用人员：系统操作期间非必要不会打开京me，基本上体验一次后就望而却步了）

基于上述原因和结果，我们放弃了此种方案，开始着想其他方案，下图是最近日期的一些使用数据统计

3.知识库前置功能

基于上述两种方案的经历后，日常值班和IT单的类型占比就大头的就是一些偏向咨询和实操类的工单了，挑选治理期间其中一周明细进行二次分析，其分布图如下

出去产研侧类问题，我们能看看到图中蓝色和绿色部分就是所谓的咨询和用户类问题，而这两类问题中可以粗略拆为基础信息配置和业务操作类，基于此种特色我们又想出了一种方案：进行知识库前置

这里我来解释一下知识库前置是个啥东东哈，所谓的知识库前置是一种思想：在咨询前通过配置好的知识库进行拦截指引，即在对应实操上给出具体解决方案、业务页面上给出具体指导手册，达到具体问题/业务具体指引的效果，方便系统使用者自行快速地解决遇到的问题。

思想听起来挺高大上的哈，其实实现起来就比较简单了，我们这边的系统是传统的web网站系统

• 首先在知识库平台上进行上述方案2中整理好的方案导入进去，然后拿到每个知识库的id编号

• 在埋点系统上新创建一批空的埋点站位，拿到对应埋点的ID

• 在系统中新增一张表用来保存知识库ID、埋点ID、访问URL/业务异常码关系（当然还有一些兼容前台体验的属性配置：这里不再赘述）

• 通过新增spirngMVC的拦截器进行解析其中的页面uri或业务异常码，在库中进行关系检索并拿到具体配置的知识库内容挂在/返回页面进行展示提醒

具体使用的展示效果图如下

实操同步交互的业务异常拦截方式：在提示业务异常的同时，会在对应的提示信息后边跟着一个上下跳动的“解决方案”字样（为了吸引注意让使用者去点击）

点击后效果如下图所示(弹窗中的内容都是自行编辑，此处抓取其中一个示例展示效果，并非对应上述的业务异常)

页面挂载的拦截方式：在对应页面上挂载此页面涉及到的业务功能和使用教程知识库（默认展示在页面的右下角，点击可进行拖拽：不影响页面使用或遮挡信息），点击后弹出上图所示效果的具体知识库内容，如下图

其实呢，说白了就是一个AOP切面的事情，一样的道理，但是这个效果确实有着显著的效果，通过下图中的知识库埋点点击数据可看到确实有人在使用，而本文最开始的IT单量统计折线图确实能够看到目前每周单量维持在20左右，相比最初的150、中间阶段的90上下，确实整体下降量非常明显

4.智能问答功能（目前处于试用阶段）

基于此种治理效果，基本上算是比较满意了（心里美滋滋），然而周而复始的值班进行在线解答与事后分析盘点，其实还是能看到咨询类的问题占比较多，纵横对比发现此时的咨询类问题提出人的所属部门很零散（销售、客服、运营、解决部、仓等等），问的问题也是“千奇百怪”，算是上述方案中的一些盲点区域了。基于此种特色，我们在想是否能够在系统中提供一个简易的问答检索功能来支持这些"边角"咨询类的问题的咨询，那么咱们说干就干。

• 将此类问题人工分析抽象为问答模式数据

• 将数据存储在ES进行保存于检索（问题字段采用IK分词器）

• 采用NLP结合停用词过滤（一些自定义匹配过滤：比如特定的业务单号是需要过滤的等）进行特征词的提取

• 采用TF-IDF+余弦相似度进行数据转为向量的训练与相似度匹配

• 个性化加工包装（比如识别到规则识别出的一些特定业务模块，可根据用户录入的单号或其他业务数据，进行入库查询返回给客户带有业务数据的解决方案）

上述为此功能的粗略设计步骤，简易功能实现模式如下：责任链：es-->算法-->模块；工厂策略：算法