IT工单治理野史：由每周最高150+治理到20+

京东技术

发布于 2024-02-26 10:12:40

920

发布于 2024-02-26 10:12:40

导读

在IT运维领域，工单处理效率直接关联到企业的运营效能。本文将分享一段真实案例，讲述如何通过精细化治理流程，从每周超过150个工单高峰，优化至20个以下的治理经验。文章深入探讨了工单管理的痛点，以及通过流程重构、自动化工具和跨部门合作等措施来实现工单数量和处理时间的显著降低。这是一篇对于IT管理人员和团队来说富有启发性的实战分享，为工单治理提供了可行的改进策略。

01 、背景

在今年的敏捷团队建设中，我通过Suite执行器实现了一键自动化单元测试。Juint除了Suite执行器还有哪些执行器呢？由此我的Runner探索之旅开始了！

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

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

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

02 、新方案实践

理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。

2.1 问题分类治理

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

影响财务结算类问题（涉及到计费模块类的功能异常）
影响系统稳定类问题（系统缺陷、BUG等）
产品场景异常类问题（场景丢失、场景越界等）
系统体验类问题（并发、核心实操类功能性能低下、提示术语存在歧义等）
其余非咨询类问题量级由高到低
其他问题

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

系统类问题
- 系统缺陷类（并发、业务交叉等）-->挖出根因并修复，而不是简单的更改数据
- 系统BUG类（代码逻辑错误）-->多方核实出正确逻辑并修复上线
产品类问题-->多方排查核实并由产品和业务牵头进行业务场景梳理落实需求
- 场景丢失
- 场景越界
体验类问题
- 功能慢需要等待-->进行性能优化
- 提示语歧义不明确-->展示信息纠正抽象概括类名词未具体语义名词、多业务同名名词进行区分改名、实操提示语中明确具体因由和解决方案等
- 操作繁杂-->根据具体场景进行简化：能自动带出的信息自动带出、能简化步骤的简化步骤、能进行合并的进行合并等
- 操作口隐藏太深-->根据对应场景进行功能模块的聚合
- 业务逻辑反人类-->重新核实业务逻辑并进行优化
- 重要信息没地儿查-->现场调研收集吐槽点、核实分析后产出需求或一些简单信息直接在对应模块页面上展示出来
业务实操类-->多次培训
- 业务规则卡控
- 基础信息配置卡控
- 异步逻辑无感
咨询类-->多次培训
- 业务规则咨询
- 协助查询数据信息
- 系统使用教程
- 系统中一些业务词汇或数据的含义解释
- 对应职责对接人员名单
其他类
- 历史问题（N年没有的业务突然来量了，系统逻辑早已面目全非）-->重新核实业务逻辑并进行优化
- 数据类问题（N年前的数据已经结转走了）-->提供拉回功能和权限控制

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

2.2 接入智能问答机器人

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

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

咨询类问题与答案-->原材料来源于日常值班记录和IT工单数据
- 业务规则咨询
- 系统使用咨询
- 名词解释咨询
- 上下游关联场景咨询
- 其他零散类咨询
系统教程类文档
上下游交互类文档（接口、MQ等）
各系统对接人/值班人文档

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

不够便捷，需要弹出京me进行咨询
命中率不高（是个难题）
推广受限（使用人员：系统操作期间非必要不会打开京me，基本上体验一次后就望而却步了）

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

2.3 知识库前置功能

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

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

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

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

首先在知识库平台上进行上述方案2中整理好的方案导入进去，然后拿到每个知识库的id编号
在埋点系统上新创建一批空的埋点站位，拿到对应埋点的ID
在系统中新增一张表用来保存知识库ID、埋点ID、访问URL/业务异常码关系（当然还有一些兼容前台体验的属性配置：这里不再赘述）
通过新增spirngMVC的拦截器进行解析其中的页面uri或业务异常码，在库中进行关系检索并拿到具体配置的知识库内容挂在/返回页面进行展示提醒

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

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

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

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

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

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

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