工单管理模块建设思路

工单是运维工作里面的硬通货,在多年之前我们口口相传,no 工单,no work,但是似乎在很多公司里面对于工单的管理都不够给力或者给予的重视程度有一些落差。

运维工作其实也是一种服务,所以对于运维提供的服务来说,甭管你是使用了高大上的方式或者规范的流程还是手工处理,如果高效完成,那对于应用来说就是大大的赞。

实际上,很多公司里面的工单基本会和两类属性挂钩,一类属性是部门预算,或者说是工时,比如处理一个问题,需要花费2个小时,那么这个服务就可以通过工时的方式来评估服务的结算费用,第二类属性是服务质量,比如工单的处理结果是否满意,是否有一些规范的操作流程等,这些是需要做工单反馈的。

对于工单处理的一个痛点来说,就是纸质工单,如果工单使用纸质方式,质量还能基本保证,效率那就不可控了。

第二类痛点是伪电子工单,即工单是通过前端页面输入的,但是工单的信息都需要大量的附件,附件里面才是真正的需求,比如excel,比如word甚至SQL语句。

第三类痛点是模糊需求工单,即工单是电子的方式提交的,但是工单的需求是一个模糊需求,为什么是模糊,因为工单里面全是大量的文字,需求和目标都不是很明确,你需要像做阅读理解一样去解析工单。

第四类痛点是繁琐的审批程序,如果一个工单的处理流程需要经手多个人,那么工单就会成为强审批的单据,即工单有了过度的安全属性,而对于运维属性重视度不够。 这种情况下你去统计工单的处理效率,那结果肯定会有很大的落差。

第五类是工单的边界比较模糊,比如申请账号权限,如果业务同学申请数据库的账号权限,那么肯定需要开通系统层面的防火墙权限,这是一个连带的工作,我们如果要求业务同学开通一个数据库权限的工单,然后再开一个开通系统权限的工单,双方就会比较疑惑。从解决问题的角度来说,这种体验是很差的。

对于工单系统来说,不同公司的定位不同,有的公司放在OA里面,有的是独立的OMS模块,有的叫做MIS,有的和工作流是独立的模块,本质上还是和各个公司所处的行业属性有一定的关系。

至于工单模块和运维模块的建设,哪个在先?其实这是一个互相促进的过程。早期的工单肯定没有自动化运维的辅助,所以肯定是有工单模块,但是早期的工单模块建设肯定不够完善,基本操作和审批是脱节的,那就需要完成工单的自动化处理。互相促进之后,这就是一个完善的链条了。

所以简单来说,工单系统和运维系统需要对接起来,对接之后就能够互相关注自己特定的业务范围,把每一个环节都做到了可控和可考核。

工单系统的对接就好比是水渠引水一样,第一步不能迈得太大,比如双方的平台技术体系不同,接口规范不同,认证机制不同等,刚开始做深度对接,其实在前期会有很多额外的工作和调试成本。如果步子太大,可能达不到预期,为后期的接入还会带来一些隐患。

从我建设的思路来说,第一步是申请工单系统的接口权限,即工单的审批还是在已有的工单系统中完成,而工单的信息一定有一个流水编号,是一个唯一的ID值,我需要的就是根据这个唯一的编号能够从工单系统中得到一个JSON数据串,得到这个数据串之后我来解析它把它拆分为符合业务属性的工单。所以所做的工作会分为以下几个步骤:

  1. 解析工单信息,根据流水号信息解析工单的格式
  2. 工单拆分,把原来的一个工单拆分为多个业务工单,这个过程对应用同学来说是透明的。比如数据库权限开通的工单,会自动拆分为两个工单,数据库权限工单和系统权限工单。

这个阶段的意义在于,两个系统开始对接起来了,虽然不是一种很自然的对接方式,但是彼此打开了一扇窗。

第二个阶段就可以更近一步,这个时候我们可以对工单系统开放接口,让他们把数据推送过来,就不用我们去拉取了。这将是一个自动的推送过程,可以省去很多的检查和反复确认环节。

这个阶段的工作的一大亮点就在于我们可以在工单拆分为业务工单,处理完成之后,确认工单完成,让工单系统开放一个写入接口,我们把工单的状态回传过去。这样业务操作就形成了一个闭环。形成闭环是这个阶段最重要的一件事情,这样审批的关注审批环节,业务操作的关注业务操作环节,各司其职。

第三阶段是更大的一个阶段,比如我们的工单可以和外部的系统通过接口交互,那么我们就可以和其他系统开始打通这个链路。 这是一个更大更全面的过程,会有更多的事情和接口需要对接。

这个阶段的意义就在于,这是一个全链条的过程,我们可以在这个阶段更多的挖掘运维数据的价值,比如工单的处理效率,工单的数据统计分析,工单的指派,业务工单拆分 逻辑等。 这些都可以逐步的细化和改进。

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2018-08-14

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏hadoop学习

什么是大数据技术架构

大数据的应用开发过于偏向底层,具有学习难度大,涉及技术面广的问题,这制约了大数据的普及。现在需要一种技术,把大数据开发中一些通用的,重复使用的基础代码、算法封装...

5463
来自专栏互联网数据官iCDO

Facebook广告定向优化的8种方法

译者:吕东昊 审校:董梁 本文长度为3495字,预估阅读时间6分钟。 我们今天要向大家介绍的是Facebook广告定向优化的8种方法 您的Facebook广告...

6677
来自专栏鹅厂网事

海量服务器运营平台的进化之路

"鹅厂网事"由深圳市腾讯计算机系统有限公司技术工程事业群网络平台部运营,我们希望与业界各位志同道合的伙伴交流切磋最新的网络、服务器行业动态信息,同时分享腾讯在网...

3076
来自专栏云计算D1net

采用云性能监控工具消除IT的盲点

使用公共云并不意味着企业必须牺牲应用程序和工作负载性能的可见性。使用正确的工具集可以给IT一个更全面的场景。 公共云已经成为许多企业IT计划的关键要素。越来越多...

3283
来自专栏DevOps时代的专栏

影响 DevOps 成功实践的15个指标

持续对特定指标的关注是衡量 DevOps 实践是否成功的关键。通过本文,我们看一下你确实需要关注的十五个指标。 你所在的组织里 DevOps 是如何践行的?...

29210
来自专栏互联网杂技

语音交互中的“等待体验”研究

回顾人机交互发展史,人类先后经历了基于命令行的CLI 时代,基于鼠标键盘的GUI时代,基于触摸的初级NUI时代。后面每一个阶段比前一个阶段更自然,学习成本更低,...

3488
来自专栏DevOps时代的专栏

高效持续交付的 7 大原则

如果你身处IT领域,并且你不是昨天才出生的,那么你一定理解速度的必要性。自从企业实施了持续集成(CI)和持续交付(CD),开发与交付周期要比过去快了很多。举个例...

1352
来自专栏企鹅号快讯

掌握这几个工具,做微信营销活动才能高大上!

是不是你的朋友圈经常被某个H5刷屏?是不是你所在的社群也经常被某个小程序刷屏?是不是你的朋友圈经常被某篇微信公众号文章刷屏?看着他们的流量蹭蹭地往上涨,是不是很...

3035
来自专栏云计算D1net

为什么云计算更适合灾难恢复

在对灾难恢复(DR)架构进行任何实际更改之前,第一步是评估需要在紧急情况下进行保护的整个IT环境。最好的方法是确定哪些服务和功能会因延长停机时间而受到最大损害,...

1031
来自专栏喔家ArchiSelf

DevOps 全栈必备双刃剑

作为一名全栈工程师,不仅是一个研发多面手,而且必须要关注产品的最终交付,以及线上服务的稳定运行。工具化使开发、交付、运维紧密地联系在一起,于是DevOps 逐渐...

1173

扫码关注云+社区

领取腾讯云代金券