电信系统下的应急派单方法、装置、设备及介质与流程

本发明涉及电信技术领域，尤其涉及一种电信系统下的应急派单方法，装置、设备及介质。

背景技术：

电信系统中的长流程派单系统每天承载一个省或市的业务工单支撑工作，包括家庭宽带、家庭互联网电视、家庭ims固话、家庭无线终端、家庭组网业务、宽带延伸服务等其他业务工单。由于业务支撑时，需要了解用户的基本资料，设备基本资料、组网资料、网络覆盖情况、gis地图信息、终端设备信息、vlan组网信息等信息；现有系统采用串行同步传输方式来处理工单。即，目前系统中按照顺序依次由网上营业厅、掌上营业厅通过crm受理后，依次传入一级boss系统、订单中心系统、服务开通流程系统、radius平台账号管理系统、管线综合管理系统、数字家庭平台系统、代维施工管理系统、最终回向crm。

然而，该种方式业务处理流程较长、受系统中各个分系统的影响较大且容易存在综合受理成功率低的情形。而在综合受理成功率低的情况下更需要完善的应急处理机制和应急处理系统。

技术实现要素：

本发明实施例提供了一种电信系统下的应急派单方法、装置、设备以及计算机可读存储介质，能够提高应急效率以及应急工单的综合受理成功率。

第一方面，本发明实施例提供了一种电信系统下的应急派单方法，方法包括：接收系统受理的工单；判断接收到的工单中是否存在连续撤销且业务相同的工单，若存在，则确定该工单为应急工单，以及将该应急工单直接派发到代维施工管理系统进行处理。

第二方面，本发明实施例提供了一种电信系统下的应急派单装置，装置包括：接收单元、应急工单判断单元以及派发单元，所述接收单元用于接收系统受理的工单；所述应急工单判断单元用于判断接收到的工单中是否存在连续撤销且业务相同的工单，所述派发单元用于将该应急工单直接派发到代维施工管理系统进行处理。

第三方面，本发明实施例提供了一种应急派单设备，包括：至少一个处理器、至少一个存储器以及存储在存储器中的计算机程序指令，当计算机程序指令被处理器执行时实现如上述实施方式中第一方面的方法。

第四方面，本发明实施例提供了一种计算机可读存储介质，其上存储有计算机程序指令，当计算机程序指令被处理器执行时实现如上述实施方式中第一方面的方法。

本发明实施例提供的应急派单方法、装置、设备及介质，通过在正常派单系统故障的情况下查找预定时间内连续撤销且业务相同的工单，将该工单确定为应急工单，并重点处理该应急工单。具体地，以直接派发到代维施工管理系统的方式进行工单处理，该应急派单方法中间流程短，应急派单装置结构简单、部署启动速度快，移动性高，从而大大地提高了应急效率以及应急工单的综合受理成功率。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例中所需要使用的附图作简单地介绍，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示出了本发明实施例提供的应急派单方法的流程示意图；

图2示出了本发明实施例提供的应急派单方法中的镜像过程示意图；

图3示出了本发明实施例提供的应急派单方法中应急工单判断方法的流程示意图；

图4示出了本发明实施例提供的应急派单方法中应急预判工单判断方法的流程示意图；

图5示出了本发明实施例提供的应急派单方法中正常受理工单轮询队列的示意图；

图6示出了本发明实施例提供的应急派单方法中撤销工单轮询队列的示意图；

图7示出了本发明实施例提供的应急派单方法中针对相同业务连续撤销工单判断方法的流程示意图；

图8示出了本发明实施例提供的应急派单方法中的系统恢复修复过程的流程示意图；

图9示出了本发明实施例提供的应急派单装置的功能结构框图；

图10示出了本发明实施例提供的应急派单装置中应急工单判断单元的功能结构框图；

图11示出了本发明实施例提供的应急派单装置中应急预判单元的功能结构框图；

图12示出了本发明实施例提供的应急派单装置中连续撤销工单判断单元的功能结构框图；

图13示出了本发明实施例提供的应急派单设备的硬件结构示意图。

具体实施方式

下面将详细描述本发明的各个方面的特征和示例性实施例，为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细描述。应理解，此处所描述的具体实施例仅被配置为解释本发明，并不被配置为限定本发明。对于本领域技术人员来说，本发明可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本发明的示例来提供对本发明更好的理解。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

首先，如前所述，现有的长流程派单系统采用串行同步传输方式，该长流程派单系统包括：网上营业厅、掌上营业厅、crm(customerrelationshipmanagement)系统、一级boss(businessoperationsupportsystem)系统、订单中心系统、服务开通流程系统、radius平台账号管理系统、管线综合管理系统、数字家庭平台系统以及代维施工管理系统。该长流程派单系统在工作过程中按照顺序依次由网上营业厅、掌上营业厅通过crm系统受理后，依次传入一级boss系统、订单中心系统、服务开通流程系统、radius平台账号管理系统、管线综合管理系统、数字家庭平台系统以及代维施工管理系统，最终回向crm系统。

其中，网上营业厅可以为移动门户网站，具有7×24小时不间断全业务办理的能力。

掌上营业厅可以为移动设备客户端(如手机客户端)；具有7×24小时随时随地提供全业务办理能力。

crm系统通过用户特定的需求，为用户受理特别的业务工单，包括但不限于：单宽带新装、单固话新装、单ims系统、业务移机、提速、互联网电视新装、互联网电视加装以及其他业务中的一种或多种。

一级boss系统接受crm系统受理信息通过报文的形式(如拼装xml报文)发送给订单中心系统，该一级boss系统的功能包括但不限于：节点拼装、流量控制、因下游系统停止服务，保留工单以及错误预处理中的一种或多种。

订单中心系统接收一级boss系统的报文(xml)信息，并进行分解存储，为地市提供工单流程展示、工单缓装处理、工单异常修复、工单审核通知等功能。

服务开通流程系统为通过流程驱动，根据不同的业务规则驱动不同的业务流程导向、匹配具体的流程总线。达到业务流向不同、数据流向与业务一致的目的。

radius平台账号管理系统可为用户提供鉴权、用户话单记录、用户帐号锁定以及解锁的能力。

管线综合管理系统可以为某地区移动网络部系统，该管线综合管理系统可以提供关于管线的管理、资源的配置、端口的管理、接入方式的管理、负载端口的管理、以及代维信息团队配置分配管理的方式等功能。

数字家庭平台系统可为用户以及设备提供vlan预配置、账号预激活、设备激活能力。

代维施工管理系统也可以称为合作伙伴管理系统，该代维施工管理系统为用户具体安装施工能力的平台，可以为最终安装呈现以及收单系统分配代维具体人员、分配具体安装时间以及安装方案。

示例性的，该长流程派单系统的综合受理成功概率可由如下方式获得：

首先定义概率p(正常运行率)

p(正常运行率)＝p(正常运行小时数/年)/p(全年小时数)

标记以下系统正常运行率:

p(网上营业厅)＝p1；

p(掌上营业厅)＝p2；

p(crm系统)＝p3；

p(一级boss系统)＝p4；

p(订单中心系统)＝p5；

p(服务开通流程系统)＝p6；

p(radius平台账号管理系统)＝p7；

p(管线综合管理系统)＝p8；

p(数字家庭平台系统)＝p9；

p(cms系统)＝p10；

p(代维施工管理系统)＝p11；

其中，工单受理方式有如下几种：

1.由网厅受理成功率；记为p(wsu)，

p(wsu)＝p(n)∏n,n∈[1,3,4,5,6,7,8,9,10，11]；

2.由掌厅受理；记为p(zsu)，

p(zsu)＝p(n)∏n,n∈[2,3,4,5,6,7,8,9,10，11]；

3.由crm系统受理；记为p(csu)，

p(csu)＝p(n)∏n,n∈[3,4,5,6,7,8,9,10，11]；

该长流程派单系统的综合受理成功率:记为p(su)，

p(su)＝1-[1-p(wsu)]*[1-p(zsu)]*[1-p(csu)]。

由此可知，该长流程派单系统由于业务受理流程长，很容易受各个系统的影响，从而降低工单的综合受理成功率。而在综合受理成功率低的情况下，更需要比较完善的应急处理机制和应急处理系统。因此，本发明基于上述原因，提供了一种电信系统下的应急派单方法以及系统，尤其适用于如上p4-p10系统发生故障所采用的应急派单方法以及系统。如下将具体介绍本发明实施例提供的应急派单方法以及系统。

请参阅图1，本发明实施例首先提供了一种电信系统下的应急派单的方法，方法包括：

s12，接收系统受理的工单。

s14，判断接收到的工单中是否存在连续撤销且业务相同的工单，若存在，则确定该工单为应急工单，以及

s16，将该应急工单直接派发到代维施工管理系统进行处理。

在步骤s12中，接收来自crm系统派发或经一级boss系统派发的工单。

请参阅图2，应急派单方法进一步包括一将步骤s12接收的工单进行镜像的步骤s13。

镜像的步骤s13具体包括：

s132，复制接收到的工单，以及

s134，将复制的工单一份转发给存储单元进行存储，另外一份进行处理以判断是否存在应急工单。

在上述步骤s134中，接收到所有工单都会按照先到先来的顺序进行存储，以便后续派单系统恢复后可以正常派单流程进行派单。

上述步骤s14用于确定接收到的工单中是否有应急工单，以决定是否要应急处理。具体的，在上述步骤s14中，判断接收到的工单中是否存在连续撤销且业务相同的工单，即例如可以判断是否存在连续撤销且业务相同的用户的号码。请参阅图3，该步骤s14进一步包括：

s142，判断是否存在应急预判工单，以及

s144，如果存在应急预判工单，进一步判断该应急预判工单是否属于连续撤销的工单。

对于一个工单而言，存在两种业务状态：撤销和正常，且撤销触发时间点大于正常受理业务时间点。因此，由同一业务产生的正常受理工单和撤销工单之间存在对应关系。

在上述步骤s142中，可通过比较接收到的正常受理工单以及接收到的撤销工单之间的对应关系来确定是否存在应急预判工单。换言之，针对每一个正常受理工单，在接收到的撤销工单中查找是否存在针对该正常受理工单的撤销工单。如果存在，则判定该工单为应急预判工单。示例性的，对于同一用户的相同业务的正常受理工单以及撤销工单，可通过工单单号之间的关系来判断是否存在应急预判撤销工单。如正常受理工单为：业务a，对应的撤销工单为：撤销业务a。

请参阅图4，步骤s142可进一步包括：

s1422，建立正常受理工单轮询队列，并将接收到的正常受理工单加入该正常受理工单轮询队列中。

s1424，建立撤销工单轮询队列，并将接收到的撤销工单加入该撤销工单轮询队列中，以及

s1426，当正常受理工单队列以及撤销工单队列同时满足第一预定条件时，查找是否存在应急预判工单。

在上述步骤s1422中，正常受理工单轮询队列包括多个节点，每个节点包括一接收的正常受理工单的信息。请参阅图5，正常受理工单轮询队列优选地可以为一环形队列。前端每接收到一个正常受理工单(如图所示的节点)，便将该正常受理工单以请求报文的形式塞入正常受理工单轮询队列中。

步骤s1422进一步包括一记录环形的正常受理工单轮询队列的队列时间周长。该队列时间周长tz＝t(尾结点(tail)业务办理时间)-t(头结点(head)业务办理时间)。具体地，每次当在正常受理工单轮询队列中插入新接收的正常受理工单时，同时记录该环形的正常受理工单轮询队列的队列时间周长。该正常受理工单轮询队列的队列时间周长大于第一阈值。该第一阈值可根据系统的特性来设定，此外，也可以根据不同的应用场景和不同的设计要求设置相应的值。当正常受理工单轮询队列的队列时间周长大于第一阈值时，按照先进先出的方式，可丢弃该正常受理工单轮询队列最先收到的正常受理工单，从而可有效地降低负载以及降低该应急方法所设计的系统的复杂性。

此外，上述步骤s1422中进一步包括一设计正常受理工单轮询队列中的每个正常受理工单(节点)信息的步骤。正常受理工单轮询队列中的每个正常受理工单可包括但不限于工单单号、工单受理时间点以及订单拼装信息中的一种或多种信息。订单拼装信息可以但不限于xml报文结构的体现。请参阅表1，本发明某一实施例中，每个正常受理工单信息可以表的形式表示如下：

表1

在上述步骤s1424中，撤销工单轮询队列包括多个节点，每个节点包括一受理的撤销工单的信息。撤销的行为可以为用户、业务员撤销或其它原因撤销。请参阅图6，撤销工单轮询队列优选地可以为一环形队列。前端每接收到一个撤销工单(如图所示的节点)，便将该撤销工单以请求报文的形式塞入撤销工单轮询队列中。

步骤s1424进一步包括一记录环形的撤销工单轮询队列的队列时间周长。该队列时间周长tc＝t(尾结点(tail)业务办理时间)-t(头结点(head)业务办理时间)。具体地，每次当在撤销工单轮询队列中插入新接收的撤销工单时，同时记录该环形的撤销工单轮询队列的时间周长。该撤销工单轮询队列的队列时间周长大于第二阈值。该第二阈值可根据系统的特性来设定，此外，也可以根据不同的应用场景和不同的设计要求设置相应的值。第二阈值优选地远大于第一阈值。在某一实施例中，第二阈值是第一阈值的1.5至3倍，从而后续可更有效地确定是否有应急工单存在。当撤销工单轮询队列的队列时间周长大于第二阈值时，按照先进先出的方式，可丢弃该撤销工单轮询队列最先收到的撤销工单，从而可有效地降低负载以及降低该应急方法所设计的系统的复杂性。

此外，上述步骤s1424中进一步包括一设计撤销工单轮询队列中的每个撤销工单(节点)信息的步骤。撤销工单轮询队列中的每个撤销工单可包括但不限于工单单号、工单受理时间点以及订单拼装信息中的一种或多种信息。订单拼装信息可以但不限于xml报文结构的体现。请参阅表2，本发明某一实施例中，每个正常受理工单信息可以表的形式表示如下：

表2

在上述步骤s1426中，第一预定条件为正常受理工单队列的队列时间周长大于第一阈值且撤销工单队列的队列时间周长大于第二阈值。

步骤s1426可以进一步包括：

s14262，判断正常受理工单队列的队列时间周长是否大于第一阈值；

s14264，当正常受理工单队列的队列时间周长大于第一阈值时，进一步判断撤销工单队列的队列时间周长是否大于第二阈值；以及

s14266，当撤销工单队列的队列时间周长大于第二阈值时，启动应急预判工单查找，即在撤销工单队列中查找是否与正常受理工单队列中的正常受理工单相对应的撤销工单。

步骤s14262和s14264中的两个条件必须同时满足时才会进行步骤s14266中的应急预判工单的查找步骤。当只要有一个条件不满足时，则继续等待、条件判断，知道满足上述条件。

在上述步骤s14266中，应急预判工单是指针对某一的正常受理工单同时有对应该正常受理工单的撤销工单。因此，应急预判工单可利用同一用户、同一业务的正常受理工单单号与撤销工单单号之间的对应关系进行查找。本发明某一实施例中，可先定位到正常受理工单队列的头部节点，分离出该头部节点的单号，然后进入撤销工单队列进行查找，如可从环形的撤销队列的头部节点开始查找，一直循环到尾部。

在上述步骤s14266中，如果查找到，则认为该正常受理工单已经被撤销，将该正常受理工单确定为应急预判工单，进入步骤s144。且暂时不对该应急预判工单进行持久化存储。另外，如果没有查找到，则认为该正常受理工单没有被撤销，将该工单存储到存储单元执行持久化存储。

在上述步骤s144中，当找到应急预判工单时，此时还不能确定该工单是否为真正的应急工单，即该正常受理工单被撤销后，在短期内是否又重新针对该同一业务的工单重新申请受理，因此，还需要进一步判断该应急预判工单是否属于连续撤销的工单。

步骤s144进一步包括确定该应急预判工单的撤销次数是否大于预定次数的步骤，如果是，则确定该应急预判工单为应急工单。

具体地，应急派单的方法可进一步包括一设定一短时间撤销队列的步骤s15，该短时间撤销队列包括多个经确认已撤销的节点，每个节点至少包括经撤销的正常受理工单的单号以及撤销次数。本发明某一实施例中，短时间撤销队列中的每个节点可包括一下信息：

表3

请参阅图7，步骤s144进一步包括：

s1442，在短时间撤销队列中查找与应急预判工单对应的节点以及该节点对应的撤销次数。

s1444，比较该撤销次数与预定次数，以及

s1446，当撤销次数大于预定次数，则确定该应急预判工单为应急工单。

上述步骤s1442进一步包括当找到与应急预判工单对应的节点时，更新节点信息，至少包括更新节点的单号以及撤销次数。具体地，可将撤销次数加1，以及将更新后的撤销次数与预定次数进行比较。另外，上述步骤s1442未找到与应急预判工单对应的节点时，可将应急预判工单作为新的节点加入到短时间撤销队列中。

在上述步骤s1444中，预定次数可根据实际场景来设置，本发明实施例中，预定次数可以为大于等于2次。设定预定次数大于等于2的目的在于，工单在被撤销后，并不表示该撤销的业务急于办理，而当该工单被撤销后，在短时间内又重新受理了同一业务的工单，此时则表明该工单属于应急工单。

当确定了应急工单后，进一步从正常受理工单轮询队列和撤销工单轮询队列中删除对应的工单以减小队列的数据存储大小。

在上述步骤s16中，当确定了应急工单后，将应急工单直接派发到代维施工管理系统进行处理。具体地，解析应急工单报文以及拼装代维施工管理系统接口报文，然后直接进行派发。该步骤s16进一步包括对该应急工单进行备注标记，如“该工单为应急派发工单，请先安装后补激活单”。步骤s16还可进一步包括将应急工单通过代维施工管理系统直接派发后，通过短信等方式派发到代维施工人员。

应急派单方法还可进一步系统恢复修复步骤s17，具体包括：

s17，在正常派单系统恢复后，从存储单元获取所有存储的工单，以及按照正常派单流程对该存储的工单进行派单。

请参阅图8，步骤s17进一步包括：

s170，获取存储的每个工单。

s172，判断每个存储的工单是否为已派发的对应的应急工单。

s174，如果是非应急工单，则按照正常派单流程进行派单处理，以及

s176，如果是对应的应急工单，则调整该工单的流程节点使其与与应急工单的当前的流程节点保持一致，并继续剩余的正常派单流程。

由于镜像存储的为所有的工单，即包括非应急工单以及正在处理或已处理的应急工单，因此，在系统恢复正常派单时，要避免重复派单或流程冲突，从而要在正常派单时检测该工单是否已经被系统派过单。

具体地，在上述步骤s172中，正常派单流程中的订单中心系统可将当前要派发的工单与代维施工管理系统记录派发的应急工单进行对比，以判断是否已经派过单。

步骤s174中的正常派单流程可以为的长流程派单过程。

在步骤s174中，非应急工单可以包括无对应撤销工单的正常受理工单、撤销次数标记为1次的撤销工单。

其中，对于非应急工单中的撤销工单的派发包括以下步骤：

s1742，检测系统恢复后派发到常规派单系统接口上的工单受理时间点，以及

s1744，对存储单元上的非应急工单中的撤销工单进行派发，同时检测该撤销工单的受理时间点，以避免撤销工单的请求早于与该撤销工单对应的正常受理工单请求。

优选地，正常受理工单受理时间与撤销工单的受理时间查大于10分钟。

所属步骤s176可进一步包括当检测到当前的存储的工单与应急工单一致时，进一步锁定应急工单当前流程一定时间，然后再调整该工单的流程节点使其与应急工单的当前的流程节点保持一致，以保持工单处理的一致性。在锁定的时间内，不进行该工单的业务变更。一定时间可以为比较短的一段时间，例如3-7秒。

请参阅图9，本发明进一步提供了一种电信系统下的应急派单装置20，该应急派单装置20包括：

接收单元22，用于接收系统受理的工单。

应急工单判断单元24，用于判断接收到的工单中是否存在连续撤销且业务相同的工单，以及

派发单元26，用于将该应急工单直接派发到代维施工管理系统进行处理。

应急派单装置20进一步包括一镜像单元27以及存储单元28。镜像单元27用于复制接收到的工单，并将复制的工单一份转发给存储单元28进行存储，另外一份送入应急工单判断单元24以判断是否存在应急工单。

请参阅图10，应急工单判断单元24进一步包括一应急预判单元242以及连续撤销工单判断单元244。

应急预判单元242用于判断接收到的工单中时候存在应急预判工单。连续撤销工单判断单元244用于当存在应急预判工单时，进一步判断该应急判断工单是否属于连续撤销的工单，以进一步确认应急预判工单是否属于应急工单，即进一步确定该应急预判工单的撤销次数是否大于预定次数。

请参阅图11，应急预判单元242进一步包括正常受理工单轮询队列单元2422，撤销工单轮询队列单元2424以及应急预判工单查询单元2426。

该正常受理工单轮询队列单元2422、撤销工单轮询队列单元2424以及应急预判工单查询单元2426的功能分别与上述步骤s1422、s1424、s1426以及该些步骤对应的子步骤所起的作用相同，在此不再赘述。

请参阅图12，该连续撤销工单判断单元244包括查找单元2442、比较单元2444以及决策单元2446。其中，查找单元2442用于在短时间撤销队列中查找与应急预判工单对应的节点以及该节点对应的撤销次数。比较单元2444用于比较该撤销次数与预定次数。决策单元2446用于当撤销次数大于预定次数时，确定该应急预判工单为应急工单。

请参阅图9，应急系统进一步还包括系统恢复修复单元29，用于在正常派单系统恢复后，从存储单元28获取所有存储的工单，以及按照正常派单流程对该存储的工单进行派单。该系统恢复修复单元29具有的功能与系统恢复修复步骤s17相同。

需要说明的是，本发明仅仅对应急派单装置20中的各个单元模块进行了简单的描述，其原因是各个模块单元与应急派单方法中的各个步骤一一对应，因此，为保证描述简洁性，在次不再赘述，但应急派单方法的各个步骤所描述的特征均在应急派单装置20的保护范围之内。

此外，应急派单方法以及应急派单装置20可基于在一种轻量级的文件系统进行开发来实现，具体地，本发明实施例提出一种基于快速分布式文件系统(fastdfs，fastdistributedfilesystem)上进行java语言开发的应急派单方法以及应急派单装置20。该应急派单装置20具有轻量级、易维护、开发工作量小以及使用简单等特点。

fastdfs是一款类googlefs的开源分布式文件系统，其充分考虑了冗余备份、负载均衡、线性扩容等机制，并注重高可用、高性能等指标。和现有的类googlefs分布式文件系统相比，fastdfs的架构和设计理念有其独到之处，主要体现在轻量级、分组方式和对等结构三个方面。

就轻量级而言，fastdfs只有两个角色：trackerserver和storageserver。trackerserver作为中心结点，其主要作用是负载均衡和调度。trackerserver在内存中记录分组和storageserver的状态等信息，不记录文件索引信息，占用的内存量很少。另外，客户端(应用)和storageserver访问trackerserver时，trackerserver扫描内存中的分组和storageserver信息，然后给出应答。由此可以看出trackerserver非常轻量化，不会成为系统瓶颈。

就分组方式而言，fastdfs采用了分组存储方式。集群由一个或多个组构成，集群存储总容量为集群中所有组的存储容量之和。一个组由一台或多台存储服务器组成，同组内的多台storageserver之间是互备关系，同组存储服务器上的文件是完全一致的。文件上传、下载、删除等操作可以在组内任意一台storageserver上进行。类似木桶短板效应，一个组的存储容量为该组内存储服务器容量最小的那个，由此可见组内存储服务器的软硬件配置最好是一致的。

就对等结构而言，fastdfs集群中的trackerserver也可以有多台，trackerserver和storageserver均不存在单点问题。trackerserver之间是对等关系，组内的storageserver之间也是对等关系。传统的master-slave结构中的master是单点，写操作仅针对master。如果master失效，需要将slave提升为master，实现逻辑会比较复杂。和master-slave结构相比，对等结构中所有结点的地位是相同的，每个结点都是master，不存在单点问题。

正因为fastdfs具有轻量级，分组存储，对等结构的的分布式文件系统的特点，故本发明采用此分布式文件系统作为存储框架，具有部署容易，扩展性高，成本低，可维护性强的特点。

另外，如上所述，本发明采用java语言来开发应急派单装置20。java是一门面向对象编程语言，具有功能强大和简单易用两个特征。java语言作为静态面向对象编程语言的代表，极好地实现了面向对象理论，允许程序员以优雅的思维方式进行复杂的编程。java具有简单性、面向对象、分布式、健壮性、安全性、平台独立与可移植性、多线程、动态性等特点。java可以编写桌面应用程序、web应用程序、分布式系统和嵌入式系统应用程序等。此外，java具有多平台可移植性，开发简洁，高安全性的特点。

因此，优选地，本发明中提出了一种基于fastfds上进行java语言开发的应急派单方法以及系统。

该应急派单装置20的正常运行率为p(emc)，该应急派单装置20的受理成功率可由如下公式来确定，首先定义如下参数：

1.在应急派单装置下网厅受理成功率；记为p(ewsu)，p(ewsu)＝p(n)∏n,n∈[1,3,emc，11]；

2.在应急派单装置下掌厅受理；记为p(ezsu)，p(ezsu)＝p(n)∏n,n∈[2,3,emc，11]；

3.在应急派单装置下crm受理；记为p(ecsu)，p(ecsu)＝p(n)∏n,n∈[3,emc，11]；

在应急派单装置综合受理成功率:记为p(esu)，

p(esu)＝1-[1-p(ewsu)]*[1-p(ezsu)]*[1-p(ecsu)]；

故如应用本发明的应急派单方法以及系统，则具有应急派单装置综合的受理成功率p(e+su)为：

p(e+su)＝p(su)[1-p(esu)]+p(esu)×[1-p(su)]。

本发明实施例提供的电信系统的应急派单方法以及应急派单装置通过查找在正常派单系统故障的情况下查找预定时间内连续撤销且业务相同的工单工单确定为应急工单，并重点处理该应急工单，具体地，以直接派发到代维施工管理系统的方式进行工单处理，从而大大地提高了应急效率，此外，该应急派单方法中间流程短，应急派单装置结构简单、部署启动速度快，移动性高，只要对程序进行简单的复制保存后既可以运行。扩展速度快。在灾难环境中具有快速响应启动的特点。另外，应急派单方法以及应急派单装置对系统要求低，应急环境下，不需要特殊配置的正常服务器即可运行。不需要为此专门预留服务器。节省硬件开销，可解放人力、规范流程，提高效率，降低人为错误概率。

另外，结合图2描述的本发明实施例的应急派单方法以及应急派单装置20可以由电信系统下的应急派单设备来实现。图13示出了本发明实施例提供的应急派单设备的硬件结构示意图。

该应急派单设备可以包括处理器401以及存储有计算机程序指令的存储器402。

具体地，上述处理器401可以包括中央处理器(cpu)，或者特定集成电路(applicationspecificintegratedcircuit，asic)，或者可以被配置成实施本发明实施例的一个或多个集成电路。

存储器402可以包括用于数据或指令的大容量存储器。举例来说而非限制，存储器402可包括硬盘驱动器(harddiskdrive，hdd)、软盘驱动器、闪存、光盘、磁光盘、磁带或通用串行总线(universalserialbus，usb)驱动器或者两个或更多个以上这些的组合。在合适的情况下，存储器402可包括可移除或不可移除(或固定)的介质。在合适的情况下，存储器402可在数据处理装置的内部或外部。在特定实施例中，存储器402是非易失性固态存储器。在特定实施例中，存储器402包括只读存储器(rom)。在合适的情况下，该rom可以是掩模编程的rom、可编程rom(prom)、可擦除prom(eprom)、电可擦除prom(eeprom)、电可改写rom(earom)或闪存或者两个或更多个以上这些的组合。

处理器401通过读取并执行存储器402中存储的计算机程序指令，以实现上述实施例中的任意一种应急派单方法。

在一个示例中，应急派单设备还可包括通信接口403和总线410。其中，如图12所示，处理器401、存储器402、通信接口403通过总线410连接并完成相互间的通信。

通信接口403，主要用于实现本发明实施例中各模块、装置、单元和/或设备之间的通信。

总线410包括硬件、软件或两者，将应急派单设备的部件彼此耦接在一起。举例来说而非限制，总线可包括加速图形端口(agp)或其他图形总线、增强工业标准架构(eisa)总线、前端总线(fsb)、超传输(ht)互连、工业标准架构(isa)总线、无限带宽互连、低引脚数(lpc)总线、存储器总线、微信道架构(mca)总线、外围组件互连(pci)总线、pci-express(pci-x)总线、串行高级技术附件(sata)总线、视频电子标准协会局部(vlb)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线410可包括一个或多个总线。尽管本发明实施例描述和示出了特定的总线，但本发明考虑任何合适的总线或互连。

另外，结合上述实施例中的应急派单方法，本发明实施例可提供一种计算机可读存储介质来实现。该计算机可读存储介质上存储有计算机程序指令；该计算机程序指令被处理器执行时实现上述实施例中的任意一种应急派单方法。

需要明确的是，本发明并不局限于上文所描述并在图中示出的特定配置和处理。为了简明起见，这里省略了对已知方法的详细描述。在上述实施例中，描述和示出了若干具体的步骤作为示例。但是，本发明的方法过程并不限于所描述和示出的具体步骤，本领域的技术人员可以在领会本发明的精神后，作出各种改变、修改和添加，或者改变步骤之间的顺序。

以上所述的结构框图中所示的功能块可以实现为硬件、软件、固件或者它们的组合。当以硬件方式实现时，其可以例如是电子电路、专用集成电路(asic)、适当的固件、插件、功能卡等等。当以软件方式实现时，本发明的元素是被用于执行所需任务的程序或者代码段。程序或者代码段可以存储在机器可读介质中，或者通过载波中携带的数据信号在传输介质或者通信链路上传送。“机器可读介质”可以包括能够存储或传输信息的任何介质。机器可读介质的例子包括电子电路、半导体存储器设备、rom、闪存、可擦除rom(erom)、软盘、cd-rom、光盘、硬盘、光纤介质、射频(rf)链路，等等。代码段可以经由诸如因特网、内联网等的计算机网络被下载。

还需要说明的是，本发明中提及的示例性实施例，基于一系列的步骤或者装置描述一些方法或系统。但是，本发明不局限于上述步骤的顺序，也就是说，可以按照实施例中提及的顺序执行步骤，也可以不同于实施例中的顺序，或者若干步骤同时执行。

以上所述，仅为本发明的具体实施方式，所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、模块和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。应理解，本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本发明的保护范围之内。