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

京东云开发者
• 阅读 186

背景

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

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

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

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

新方案实践

1.问题分类治理

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

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

•影响系统稳定类问题(系统缺陷、BUG等)

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

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

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

•其他问题

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

•系统类问题

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

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

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

◦场景丢失

◦场景越界

•体验类问题

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

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

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

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

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

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

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

◦业务规则卡控

◦基础信息配置卡控

◦异步逻辑无感

•咨询类-->多次培训

◦业务规则咨询

◦协助查询数据信息

◦系统使用教程

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

◦对应职责对接人员名单

•其他类

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

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

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

2.接入智能问答机器人

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

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

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

◦业务规则咨询

◦系统使用咨询

◦名词解释咨询

◦上下游关联场景咨询

◦其他零散类咨询

•系统教程类文档

•上下游交互类文档(接口、MQ等)

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

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

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

•命中率不高(是个难题)

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

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

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

3.知识库前置功能

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.智能问答功能(目前处于试用阶段)

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

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

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

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

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

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

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

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

语料训练过程如下

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

通过开关和双套数据模型设计支持在线语料训练与检索并行

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

目前处于试用阶段,正在尝试推行,在系统上进行挂靠,同时在值班过程中也在推行,目前经过部分使用者的反馈看是有些效果,但是在单量上还未有所体现,可以随着推行时间的延长来看具体的效果,让我们拭目以待吧,效果图和使用记录如下所示

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

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

未来展望

接入chagpt,数据保密不会泄露,并且根据聊天记录自行进行思维训练更新与解答。

作者:京东物流 张小龙

来源:京东云开发者社区 自猿其说 Tech 转载请注明来源

点赞
收藏
评论区
推荐文章
Stella981 Stella981
3年前
LiveVideoStack线上交流分享 (九) —— B站的QUIC实践简介
为了给大家提供一个学习,交流的平台,畅聊音视频技术开发新趋势,新实践。我们推出了LiveVideoStack线上交流分享活动,在每周四晚19:30,邀请1名业内资深技术专家进行线上分享技术干货,解答热点问题。你可以通过以下方式参与:关注LiveVideoStack公众号【livevideostack】回复“
Stella981 Stella981
3年前
LiveVideoStack线上交流分享 ( 一 ) —— 解密GPU:视频转码与分析加速
为了给大家提供一个学习,交流的平台,畅聊音视频技术开发新趋势,新实践。我们推出了LiveVideoStack线上交流分享活动,在每周四晚19:30,邀请1名业内资深技术专家进行线上分享技术干货,解答热点问题。你可以通过以下方式参与:关注LiveVideoStack公众号【livevideostack】回复“
Wesley13 Wesley13
3年前
Oracle一张表中实现对一个字段不同值和总值的统计(多个count)
需求:统计WAIT\_ORDER表中的工单总数、未处理工单总数、已完成工单总数、未完成工单总数。表结构:为了举例子方便,WAIT\_ORDER表只有两个字段,分别是ID、STATUS,其中STATUS为工单的状态。1表示未处理,2表示已完成,3表示未完成总数。 SQL:  1.SELECT   2
Wesley13 Wesley13
3年前
JAVA 线上故障排查
线上故障主要会包括CPU、磁盘、内存以及网络问题,而大多数故障可能会包含不止一个层面的问题,所以进行排查时候尽量四个方面依次排查一遍。同时例如jstack、jmap等工具也是不囿于一个方面的问题的,基本上出问题就是df、free、top三连,然后依次jstack、jmap伺候,具体问题具体分析即可。CPU一般来讲我们首先会排查
Easter79 Easter79
3年前
Taro 版本升级权威指南
“Taro\1\是一款由京东凹凸实验室\2\推出的开放式跨端跨框架解决方案,致力于解决小程序、H5、ReactNative的跨端同构问题,支持同时使用React和Vue来进行开发。本文由Taro团队成员隔壁老李撰写,旨在帮助Taro开发者厘清当前Taro多版本之间关系的那些事儿,同时解答有关Taro3、T
Stella981 Stella981
3年前
Executors使用不当引起的内存泄漏
线上服务内存溢出这周刚上班突然有一个项目内存溢出了,排查了半天终于找到问题所在,在此记录下,防止后面再次出现类似的情况。先简单说下当出现内存溢出之后,我是如何排查的,首先通过jstack打印出堆栈信息,然后通过分析工具对这些文件进行分析,根据分析结果我们就可以知道大概是由于什么问题引起的。关于jstack如何使用,大家可以先看看这篇文章
Stella981 Stella981
3年前
PHP如何避免高并发下insert into 重复入库
场景:用户签到/分享功能,每天只能签到一次或分享一次数据库:id  user\_id  add\_time  逻辑分析:用户每天进行分享或签到,得到积分,数据库通过以上字段进行记录,同一时间不可插入多条,一天只能有一条记录,插入前判断是否当天已插入过问题点:用户连点、并发请求等会导致同时插入多条记录,导致积分异常解决方案:使用文件锁,经过
利用CI机制管控jar依赖树 | 京东云技术团队
为了有效控制jar包更新带来的未知jar引入和变动,我们经常使用dependencytree来查看依赖关系排查问题,通常是出现问题再被动分析和排查,此时人力成本是巨大的,同时系统已出问题,没有后悔药。
京东云开发者 京东云开发者
10个月前
分布式日志追踪ID实战 | 京东物流技术团队
本文通过介绍分布式应用下各个场景的全局日志ID透传思路,以及介绍分布式日志追踪ID简单实现原理和实战效果,从而达到通过提高日志查询排查问题的效率。背景开发排查系统问题用得最多的手段就是查看系统日志,相信不少人都值过班当过小秘吧:给下接口和出入参吧,麻烦看看
质量视角下的系统稳定性保障--稳定性保障常态化自动化实践
作者:京东物流翁美婷一、前言随着系统数量增多,复杂度提高,线上应急问题时有发生;加之需投入大量人力进行服务治理和验证,为了减少日常应急问题及提前排除风险,发起对生产系统的持续综合性治理,实现常态化稳定性治理。在常态化治理过程中我们将识别问题等重复性有规律的