工单管理模块建设思路

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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