[发明专利]一种故障单处理方法

说明书

技术领域

本发明涉及通讯领域中故障描述电子工单(以下简称故障单)管理领域，尤其涉及一种故障单处理方法。

背景技术

故障单管理系统(Trouble Ticket System，简称TT)是故障管理的一大核心，它负责完成告警到故障的转化、故障相关业务及客户信息的呈现、故障处理流程的控制以及监控等工作，是运维人员跟踪、处理故障的信息管理系统。TT在电信领域的应用要求其必须具有实时性、可靠性、安全性的特点：实时性要求TT能够快速、及时地反映告警的上报，在故障处理的各个环节能快速地对其它人员的动作做出反应，以表现故障单的实际状态；可靠性要求TT能保留下几乎所有的故障处理信息，包括各处理环节的每一人员、处理时间、处理说明等信息；安全性要求故障的处理符合组织架构的要求，故障处理流程不能打破运营商的人员分工，对于权限的分配要细化到部门和人员，不允许出现越级处理和故障信息泄漏的情况。

故障单管理系统的核心需求就是要提供一种手段来跟踪故障的处理情况。一个故障的处理周期应该是闭环的，即由告警或其它系统转化而来的故障单，需经历从产生、到处理、最后到消除并通知报障系统故障已清除这一过程。因此，一张故障单具有一个完整的生命周期，多部门、多人员的处理是故障单从一个状态迁移到另一个状态的驱动力，也是现有故障单系统大多采用工作流方式进行处理的缘故。围绕着故障单的具体信息来定位问题并设计处理流程，把不同的部门和人员分配到不同的处理环节中，这是目前大多数类似系统的处理方法。

但这样的处理方式也带来了一些问题，包括：

(1)信息安全问题：每一人员均可以看到不相关部门人员对故障进行处理的信息。而标准的做法应该是让该员工只能看到故障信息、故障来源的派发信息、以及其处理信息(包括他的派发信息)；

(2)权限设计和显示问题：由于一张故障单在系统中只由一个流程来控制，在流程中的某个环节内部，不受流程的制约，这将造成环节内部动作权限设计的困难。进一步地，环节内部的处理流程并没有被管理起来，对于组织机构比较庞大的运营商而言，某个环节的处理常常也需要多个部门的协作(包括多部门并发处理和分层迭代处理)，而这部分的控制没有纳入流程管理。另一方面，在界面显示上也只能反映故障单在整个系统中的状态，不能表现环节内部的具体状态，也就无法形成工作流程来管理环节内作业

综上所述，按照单一工作流程方式、以故障单的生命状态周期作为全系统唯一的时序关系来设计的故障单管理系统，在安全性、易用性和设计复杂度上都不够完善。

发明内容

本发明要解决的技术问题是提供一种故障单处理方法，以实现为用户提供一套直观、准确的体验呈现，并对故障处理的各个环节提供流程支持和管理，扫除故障处理环节的管理盲区。

为解决上述问题，本发明提供了一种故障单处理方法，包括以下步骤：

先将所有参与故障处理的部门构建成一部门树，该部门树中包括一个根节点和至少一个子节点，其中，所述根节点用于接收外部系统向其发送根故障单，所述子节点用于接收其上级节点向其发送的子故障单；然后设置所述各节点的故障处理环节，并将各节点的处理流程关联起来；

当所述根节点收到所述根故障单或一子节点收到子故障单后，根据其上设置的故障处理环节在本节点上进行处理，如在某一环节需要其下级子节点协助处理，则其下发携带派发信息的子故障单到相应的下级子节点；所述子节点完成所有处理环节后，向为其派发子故障单的上级节点回单，其中包括该节点的处理信息，如该子节点还收到了其下级节点的回单信息，则将该回单信息一同发送给其上级节点；当上级节点收到所有与其下发的子故障单相对应的回单后，其继续后续处理环节；所述根节点完成所有处理环节后，结束故障处理。

进一步地，上述方法还可具有以下特征：

当所述下级节点收到上级节点向其发送的子故障单后，其向上级节点返回一受理确认信息。

进一步地，上述方法还可具有以下特征：

当上级节点收到下级节点的回单信息后，其判断处理结果是否满足其期望，如果不满足，则重新下发子故障单给所述下级节点。

进一步地，上述方法还可具有以下特征：

所述将各节点的处理流程关联起来具体包括：确定所述故障单到达每一节点的触发条件及每一节点向下级节点派发子故障单的跳转条件。

进一步地，上述方法还可具有以下特征：