一种恢复用户业务数据的方法及装置与流程

本发明涉及通信技术领域，特别涉及一种恢复用户业务数据的方法及装置。

背景技术：

业务运营支撑(BOSS，Business&Operation Support System)系统是每个电信运行商的核心业务支撑系统，而统一开通系统又是BOSS域与网管域交互的“必经”通道。近年来，随着移动互联网的蓬勃发展以及流量业务的不断推广，用户停机充值后能否快速恢复业务功能(例如上网功能)，对支撑系统在程序处理及时性和运行稳定性方面的提出了更高的要求。

如图1所示，目前用户恢复流量上网功能的流程，大致如下：

用户充值后，账务系统根据用户余额和信用等级的情况，判断是否生成恢复工单；客户关系管理(CRM)系统取走该恢复工单，并根据用户的订购关系，判断是否生成流量上网恢复工单；开通系统取走该流量上网恢复工单，并根据配置的指令规则，经过一系列的规则判断，最终生成网管侧可识别指令；开通系统向交换机发送开机指令。

从上面的流程中可以看到，流量上网功能恢复的完整处理流程分布在多个系统域实现，数据分散，流程复杂，无论某一环节程序出现异常，或是某一应用部署所在的主机，数据库，或网络异常都会影响流量上网功能恢复的准确性和及时性，从而严重影响用户感知。

虽然目前运营商针对用户通话功能快速恢复，有紧急复机的机制，在及时性方面具备了一定的防御能力，但在准确性方面，由于流量功能恢复较为复杂，因而在流量上网功能快速恢复方面无防御措施，在目前运营商流量经营的大背景下，保障能力严重欠缺。

现在运营商充值紧急复机技术主要存在两方面缺陷：

第一、功能单一，无法针对流量功能应急恢复：通话功能作为每个用户必 备的基础功能可以统一处理，但对于流量功能每个用户具有一定的个性，现在流程无法进行判断。对于用户的流量上网功能来说，情况较为复杂，针对用户不同的业务订购情况需要制定不同的用户流量上网功能恢复规则。例如：当用户订购第二代移动通讯技术通用分组无线服务技术(2G GPRS，second generation General Packet Radio Service)服务，并且没有GPRS暂停或封顶服务时，则需要给用户恢复2G流量上网功能；当用户订购第四代移动通讯技术通用分组无线服务技术(4G GPRS，fourth generation General Packet Radio Service)服务，并且没有GPRS暂停或封顶服务时，则需要给用户恢复4G流量上网功能；当用户订购2G或4G GPRS服务，但同时订购GPRS暂停或封顶服务时，则不能给用户恢复2G和4G流量上网功能。

第二、仅限流程内部紧急处理，端到端的恢复能力欠缺：目前紧急复机流程仍依赖于开通系统的数据处理，无法直接在网管侧恢复用户业务功能，当开通系统出现主机、数据库或者网络异常，应急复机通道也将中断。

综上，现有的紧急复机技术存在严重缺陷，不仅无法对GPRS功能进行应急恢复，并且缺乏端到端覆盖，在流量为王的4G竞争时代，给用户体验带来较差感知。

技术实现要素：

本发明实施例的目的在于提供一种恢复用户业务数据的方法及装置，能在用于恢复用户业务数据的系统发生异常的情况下，及时恢复用户业务数据，提高用户体验。

为了达到上述目的，本发明的实施例提供了一种恢复用户业务数据的方法，该方法包括：

监测用户业务数据流程的中断状态；

当监测到用户业务数据流程由中断进入恢复状态时，扫描用于恢复用户业务数据的系统的各节点，判断各节点是否存在异常；

当系统中存在发生异常的第一节点时，采集第一节点中的用户业务数据；

向用户对应的网管设备发送恢复业务指令，使网管设备在接收到恢复业务指令后恢复用户业务数据。

其中，采集第一节点中的用户业务数据，具体包括：

判断系统中第一节点的数量；

当系统中存在多个第一节点时，获取需要被采集用户业务数据的各个第一节点的业务编码和业务流程编码；

根据需要被采集用户业务数据的各个第一节点的业务编码、业务流程编码、异常发生时刻和预设采集时间长度，分段采集需要被采集用户业务数据的第一节点中的用户业务数据；

当系统中只存在一个第一节点时，根据异常发生时刻、预设采集时间长度、预先给第一节点配置的业务编码和业务流程编码，分段采集第一节点中的用户业务数据。

其中，获取需要被采集用户业务数据的各个第一节点的业务编码和业务流程编码，具体包括：

获取给系统中各节点配置的业务编码、业务流程编码以及业务流程编码串并行标志；

根据系统中各节点的业务编码、业务流程编码以及业务流程编码串并行标志，获取需要被采集用户业务数据的各个第一节点的业务编码和业务流程编码。

其中，向用户对应的网管设备发送恢复业务指令，具体包括：

根据预先给系统的各节点配置的精确判断规则，判断第一节点是否需要进行精确判断；

当第一节点需要进行精确判断时，进一步判断对第一节点进行精确判断的环境是否可用；

当对第一节点进行精确判断的环境可用时，进一步根据预先给用户配置的特殊场景过滤规则，判断用户是否满足特殊场景过滤规则；

当用户不满足特殊场景过滤规则时，按照预先设定的第一恢复指令生成规则，生成恢复业务指令，并将恢复业务指令送给用户对应的网管设备；

当用户满足特殊场景过滤规则时，结束流程。

其中，在判断第一节点是否需要进行精确判断之前，方法还包括：

获取给系统中各节点配置的精确判断规则。

其中，在判断用户是否满足特殊场景过滤规则之前，方法还包括：

获取给用户配置的特殊场景过滤规则。

其中，判断对第一节点进行精确判断的环境是否可用，具体包括：

判断系统中在第一节点之后的节点是否能正常运行，以及是否能正常获取进行精确判断所需的信息；

当第一节点之后的节点能正常运行，且能正常获取进行精确判断所需的信息时，确定对第一节点进行精确判断的环境可用；

当第一节点之后的节点不能正常运行和/或不能正常获取进行精确判断所需的信息时，确定对第一节点进行精确判断的环境不可用。

其中，方法还包括：

当第一节点不需要进行精确判断时，按照预先设定的第二恢复指令生成规则，生成恢复业务指令，并将恢复业务指令发送给用户对应的网管设备。

其中，方法还包括：

当对第一节点进行精确判断的环境不可用时，按照预先设定的第三恢复指令生成规则，生成恢复业务指令，并将恢复业务指令发送给用户对应的网管设备。

其中，向用户对应的网管设备发送恢复业务指令，具体包括：

判断第一节点是否是系统中的最后一个节点；

当第一节点不是系统中的最后一个节点时，将第一节点中的用户业务数据转移至在第一节点之后的任意一个第二节点中，使第二节点和在第二节点之后的所有节点对从第一节点中转移出的用户业务数据进行处理，并向用户对应的网管设备发送恢复业务指令。

其中，在向用户对应的网管设备发送恢复业务指令之前，方法还包括：

确定接收到用户对应的网管设备返回的指令响应消息。

本发明的实施例还提供了一种恢复用户业务数据的装置，该装置包括：

监测模块，用于监测用户业务数据流程的中断状态；

扫描模块，用于当监测到用户业务数据流程由中断进入恢复状态时，扫描用于恢复用户业务数据的系统的各节点，判断各节点是否存在异常，并当系统中存在发生异常的第一节点时，触发采集模块；

采集模块，用于根据扫描模块的触发，采集第一节点中的用户业务数据；

发送模块，用于向用户对应的网管设备发送恢复业务指令，使网管设备在接收到恢复业务指令后恢复用户业务数据。

其中，采集模块包括：

第一判断单元，用于判断系统中第一节点的数量；

获取单元，用于当系统中存在多个第一节点时，获取需要被采集用户业务数据的各个第一节点的业务编码和业务流程编码；

第一采集单元，用于根据需要被采集用户业务数据的各个第一节点的业务编码、业务流程编码、异常发生时刻和预设采集时间长度，分段采集需要被采集用户业务数据的第一节点中的用户业务数据；

第二采集单元，用于当系统中只存在一个第一节点时，根据异常发生时刻、预设采集时间长度、预先给第一节点配置的业务编码和业务流程编码，分段采集第一节点中的用户业务数据。

其中，获取单元包括：

第一子单元，用于获取给系统中各节点配置的业务编码、业务流程编码以及业务流程编码串并行标志；

第二子单元，用于根据系统中各节点的业务编码、业务流程编码以及业务流程编码串并行标志，获取需要被采集用户业务数据的各个第一节点的业务编码和业务流程编码。

其中，发送模块包括：

第二判断单元，用于根据预先给系统的各节点配置的精确判断规则，判断第一节点是否需要进行精确判断，并当第一节点需要进行精确判断时，触发第三判断单元；

第三判断单元，用于根据第二判断单元的触发，进一步判断对第一节点进行精确判断的环境是否可用，并当对第一节点进行精确判断的环境可用时，触发第四判断单元；

第四判断单元，用于根据第三判断单元的触发，进一步根据预先给用户配置的特殊场景过滤规则，判断用户是否满足特殊场景过滤规则，并当当用户不满足特殊场景过滤规则时，触发生成单元，以及当用户满足特殊场景过滤规则时，结束流程；

生成单元，用于根据第四判断单元的触发，按照预先设定的第一恢复指令生成规则，生成恢复业务指令，并将恢复业务指令送给用户对应的网管设备。

其中，装置还包括：

第一获取模块，用于获取给系统中各节点配置的精确判断规则。

其中，装置还包括：

第二获取模块，用于获取给用户配置的特殊场景过滤规则。

其中，第三判断单元包括：

第三子单元，用于判断系统中在第一节点之后的节点是否能正常运行，以及是否能正常获取进行精确判断所需的信息，并当第一节点之后的节点能正常运行，且能正常获取进行精确判断所需的信息时，触发第四子单元，以及当第一节点之后的节点不能正常运行和/或不能正常获取进行精确判断所需的信息时，触发第五子单元；

第四子单元，用于根据第三子单元的触发，确定对第一节点进行精确判断的环境可用；

第五子单元，用于根据第三子单元的触发，确定对第一节点进行精确判断的环境不可用。

其中，装置还包括：

第一生成模块，用于当第一节点不需要进行精确判断时，按照预先设定的第二恢复指令生成规则，生成恢复业务指令，并将恢复业务指令发送给用户对应的网管设备。

其中，装置还包括：

第二生成模块，用于当对第一节点进行精确判断的环境不可用时，按照预先设定的第三恢复指令生成规则，生成恢复业务指令，并将恢复业务指令发送给用户对应的网管设备。

其中，发送模块包括：

第五判断单元，用于判断第一节点是否是系统中的最后一个节点，并当第一节点不是系统中的最后一个节点时，触发转移单元；

转移单元，用于根据第五判断单元的触发，将第一节点中的用户业务数据转移至在第一节点之后的任意一个第二节点中，使第二节点和在第二节点之后 的所有节点对从第一节点中转移出的用户业务数据进行处理，并向用户对应的网管设备发送恢复业务指令。

其中，装置还包括：

确定模块，用于确定接收到用户对应的网管设备返回的指令响应消息。

本发明的上述方案至少包括以下有益效果：

在本发明的实施例中，当用户业务数据流程由中断进入恢复状态时，通过扫描用于恢复用户业务数据的系统的各节点，判断该系统中是否存在发生异常的第一节点，且当该系统中存在发生异常的第一节点时，采集第一节点中的用户业务数据，并向用户对应的网管设备发送恢复业务指令，使网管设备恢复所采集到的用户业务数据，解决了当用于恢复用户业务数据的系统中存在发生异常的节点时，不能及时恢复用户业务数据的问题，达到了在用于恢复用户业务数据的系统发生异常的情况下，及时恢复用户业务数据，提高用户体验的效果。

附图说明

图1为现有技术中恢复上网功能的流程图；

图2为本发明第一实施例中恢复用户业务数据的方法的流程图；

图3为本发明第一实施例中进行充值业务时BOSS系统、CRM系统和开通系统中的各个节点的结构示意图；

图4为本发明第一实施例中进行程控变更时BOSS系统、CRM系统和开通系统中的各个节点的结构示意图；

图5为本发明第一实施例中图2中步骤S24的第一种实现方式的流程图；

图6为本发明第二实施例中恢复用户业务数据的装置的结构示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

第一实施例

如图2所示，本发明的第一实施例提供了一种恢复用户业务数据的方法，该方法包括：

步骤S21，监测用户业务数据流程的中断状态；

步骤S22，当监测到用户业务数据流程由中断进入恢复状态时，扫描用于恢复用户业务数据的系统的各节点，判断各节点是否存在异常；

在本发明的第一实施例中，上述用于恢复用户业务数据的系统主要包括BOSS系统、CRM系统和开通系统。需要说明的是，本发明第一实施例中所提到的用于恢复用户业务数据的系统都包括BOSS系统、CRM系统和开通系统。

在本发明的第一实施例中，会根据系统中各个节点的性能(例如处理业务的类别)，预先给各个节点配置不同的扫描间隔。即，在扫描的过程中，不同节点的扫描间隔可能会不一样。当然可以理解的是，在执行扫描步骤之前，需要建立用于扫描各节点的模块与各节点之间的连接。此外，判断各节点是否存在异常的判断条件可以根据具体的业务进行设定，例如当业务为上网时，可以将判断条件设为错误信息的数量是否达到预设值。

步骤S23，当系统中存在发生异常的第一节点时，采集第一节点中的用户业务数据；

在本发明的第一实施例中，与扫描步骤类似，在执行采集用户业务数据之前，需要建立用于采集用户业务数据的模块与各节点之间的连接。

步骤S24，向用户对应的网管设备发送恢复业务指令，使网管设备在接收到恢复业务指令后恢复用户业务数据。

在本发明的第一实施例中，会监测用户业务数据流程的中断状态，且当监测到用户业务数据流程由中断进入恢复状态时，扫描用于恢复用户业务数据的系统的各节点，判断该系统中是否存在发生异常的第一节点，且当该系统中存在发生异常的第一节点时，采集第一节点中的用户业务数据，并向用户对应的网管设备发送恢复业务指令，使网管设备恢复所采集到的用户业务数据，达到了在用于恢复用户业务数据的系统发生异常的情况下，及时恢复用户业务数据(例如2分钟内恢复用户的上网功能)，提高用户体验的效果。

在本发明的第一实施例中，上述方法可以理解成当用于恢复用户业务数据 的系统中存在发生异常的第一节点时，建立了一条用于恢复用户业务数据的专线，从而避开任何一个节点的故障，及时恢复用户业务数据(例如2分钟内恢复用户的上网功能)，提高用户体验的效果。

其中，在本发明的第一实施例中，上述步骤S23具体包括：首先判断系统中第一节点的数量；当系统中存在多个第一节点时，获取需要被采集用户业务数据的各个第一节点的业务编码和业务流程编码，并根据需要被采集用户业务数据的各个第一节点的业务编码、业务流程编码、异常发生时刻和预设采集时间长度，分段采集需要被采集用户业务数据的第一节点中的用户业务数据；而当系统中只存在一个第一节点时，直接根据异常发生时刻、预设采集时间长度、预先给第一节点配置的业务编码和业务流程编码，分段采集第一节点中的用户业务数据即可。

在本发明的第一实施例中，当第一节点中的用户业务数据较多时，为了避免遗漏用户业务数据，可以从异常发生时刻，按照预设采集时间长度分段采集用户业务数据。其中，预设采集时间长度可以预先设定，也可以在采集的过程中进行更改。

具体地，在采集的过程中，会先根据上次采集用户业务数据的时刻(有可能是异常发生时刻)和预先配置的“异常发生时确认无感知恢复的时间范围”，确定出本次采集用户业务数据的时间范围。例如，上次采集用户业务数据的时刻为T1，“异常发生时确认无感知恢复的时间范围”为T2(例如设为0)，那么本次采集用户业务数据的时间范围为T1～当前时刻-T2，而为了保持采集的连续性，会将当前时刻-T2作为一次采集用户业务数据的开始时刻。其中，当本次采集用户业务数据的时间范围(例如T1～当前时刻-T2)确定之后，会从本次采集的开始时刻(例如T1)按照预设时间长度分段采集本次采集用户业务数据的时间范围(例如T1～当前时刻-T2)内的用户业务数据，且在分段采集的过程中，为了避免遗漏用户业务数据，会时刻记录采集的进度。

其中，在本发明的第一实施例中，当系统中存在多个第一节点时，获取需要被采集用户业务数据的各个第一节点的业务编码和业务流程编码，具体包括：获取给系统中各节点配置的业务编码、业务流程编码以及业务流程编码串并行标志，并根据系统中各节点的业务编码、业务流程编码以及业务流程编码串并 行标志，获取需要被采集用户业务数据的各个第一节点的业务编码和业务流程编码。

在本发明的第一实施例中，存在串行关系的两个或者两个以上的第一节点中积压的用户业务数据是重复的，因此只需要处理一次即可，即对于存在串行关系的两个或者两个以上的第一节点，只需要采集位于系统中最前面的一个第一节点中的用户业务数据就可以了。这样既能确保用户业务数据的完整性，也能确保数据量的最小化。

在本发明的第一实施例中，用充值业务和程控变更为例阐述当存在多个第一节点时，确定需要被采集用户业务数据的各个第一节点的业务编码和业务流程编码。如图3所示，在此充值业务用S表示，至于与充值业务对应的BOSS系统、CRM系统和开通系统中的各个节点的表示方式为：资金上发用G1表示，实时信控用G2表示，账处进程用G3表示，停复机进程用G4表示，工单调度用G5表示，工单拆分用G6表示，网元处理用G7表示，其中G1为S业务的初始点，G2与G1是串行关系，G3与G2是串行关系，G4与G3是串行关系，G5与G1是并行关系，G6与G1是并行关系，G7与G1是并行关系。因此，如果G1、G4、G6和G7这4个节点出现异常的话，只需要采集G1、G6和G7这3个节点中用户业务数据即可。具体地，可以用“S.G1.初始”表示S业务G1为流程初始点，“S.G6.并G1”表示S业务G6与G1为并行关系，“S.G2.串G1”表示S业务G2与G1为串行关系，其他串并行关系也可以用相同的方式表示。需要说明的是，其中S相当于是上述资金上发、实时信控、账处进程、停复机进程、工单调度、工单拆分和网元处理这7个节点的业务编码，G1、G2、G3、G4、G5、G6和G7相当于是资金上发、实时信控、账处进程、停复机进程、工单调度、工单拆分和网元处理这7个节点的业务流程编码，“S.G1.初始”相当于是资金上发的业务流程编码串并行标志，“S.G2.串G1”相当于实时信控的业务流程编码串并行标志，其他节点的业务流程编码串并行标志也可以用相同的方式表示。

类似地，如图4所示，在此程控变更用F表示，至于与充值业务对应的BOSS系统、CRM系统和开通系统中的各个节点的表示方式为：上发进程用G1表示，营业送开通进程用G2表示，工单调度用G3表示，工单拆分用G4 表示，网元处理用G5表示，其中G2为F业务的初始点，G1与G2是并行关系，G3与G2是串行关系，G4与G3是串行关系，G5与G2是串行关系。因此，如果G2、G4和G5这3个节点出现异常的话，只需要采集G2这1个节点中用户业务数据即可。具体地，可以用“F.G2.初始”表示F业务G2为流程初始点，“F.G1.并G2”表示F业务G1与G2为并行关系，“F.G3.串G2”表示F业务G3与G2为串行关系，其他串并行关系也可以用相同的方式表示。需要说明的是，其中F相当于是上述上发进程、营业送开通进程、工单调度、工单拆分和网元处理这5个节点的业务编码，G1、G2、G3、G4和G5相当于是上发进程、营业送开通进程、工单调度、工单拆分和网元处理这5个节点的业务流程编码，“F.G2.初始”相当于是营业送开通进程的业务流程编码串并行标志，“F.G3.串G2”相当于工单调度的业务流程编码串并行标志，其他节点的业务流程编码串并行标志也可以用相同的方式表示。

其中，在本发明的第一实施例中，上述步骤S24包括两种实现方式，如图5所示，上述步骤S24的第一种实现方式具体包括：

步骤S51，根据预先给系统的各节点配置的精确判断规则，判断第一节点是否需要进行精确判断；

在本发明的第一实施例中，在执行步骤S51之前，需要获取给系统中各节点配置的精确判断规则，该精确判断规则主要包括节点需要进行精确判断或节点不需要进行精确。

步骤S52，当第一节点需要进行精确判断时，进一步判断对第一节点进行精确判断的环境是否可用；

步骤S53，当对第一节点进行精确判断的环境可用时，进一步根据预先给用户配置的特殊场景过滤规则，判断用户是否满足特殊场景过滤规则，若是，则执行步骤S54，否则，执行步骤S55；

在本发明的第一实施例中，在执行步骤S53之前，需要获取给用户配置的特殊场景过滤规则，例如给该用户配置为GPRS暂停的用户，这样就相当于该用户满足特殊场景过滤规则，会直接结束流程，不会给该用户恢复上网功能。

步骤S54，当用户满足特殊场景过滤规则时，结束流程；

步骤S55，当用户不满足特殊场景过滤规则时，按照预先设定的第一恢复 指令生成规则，生成恢复业务指令，并将恢复业务指令送给用户对应的网管设备。

其中，在本发明的第一实施例中，上述步骤S52具体包括：判断系统中在第一节点之后的节点是否能正常运行，以及是否能正常获取进行精确判断所需的信息；当第一节点之后的节点能正常运行，且能正常获取进行精确判断所需的信息时，确定对第一节点进行精确判断的环境可用；而当第一节点之后的节点不能正常运行和/或不能正常获取进行精确判断所需的信息时，确定对第一节点进行精确判断的环境不可用。

在本发明的第一实施例中，当步骤S51判断出第一节点不需要进行精确判断时，直接按照预先设定的第二恢复指令生成规则，生成恢复业务指令，并将恢复业务指令发送给用户对应的网管设备，进而使用户对应的网关设备恢复用户业务数据。

类似地，当步骤S52判断出对第一节点进行精确判断的环境不可用时，按照预先设定的第三恢复指令生成规则，生成恢复业务指令，并将恢复业务指令发送给用户对应的网管设备，进而使用户对应的网关设备恢复用户业务数据。

在本发明的第一实施例中，上述第一恢复指令生成规则、第二恢复指令生成规则和第三恢复指令生成规则均可以是预先设定的。具体可以根据业务场景、网管设备的属性等特征进行设定。

其中，在本发明的第一实施例中，上述步骤S24的第二种实现方式为：首先判断第一节点是否是系统中的最后一个节点，当第一节点不是系统中的最后一个节点时，将第一节点中的用户业务数据转移至在第一节点之后的任意一个第二节点中，使第二节点和在第二节点之后的所有节点对从第一节点中转移出的用户业务数据进行处理，并向用户对应的网管设备发送恢复业务指令，进而使用户对应的网关设备恢复用户业务数据。

其中，在本发明的第一实施例中，为了确保网关设备的正常工作，在执行上述步骤S24之前，需要确定接收到用户对应的网管设备返回的指令响应消息。即确保网管设备存在空闲的通道。具体地，可以通过给网管设备配置最大的连接数或连接数最大占比或单次连接的指令通信量等来监控网管设备是否存在空闲的通道。只有当网管设备存在空闲的通道时，才可以执行上述步骤S24。

第二实施例

如图6所示，本发明的第二实施例提供了一种恢复用户业务数据的装置，该装置包括：

监测模块61，用于监测用户业务数据流程的中断状态；

扫描模块62，用于当监测到用户业务数据流程由中断进入恢复状态时，扫描用于恢复用户业务数据的系统的各节点，判断各节点是否存在异常，并当系统中存在发生异常的第一节点时，触发采集模块63；

采集模块63，用于根据扫描模块62的触发，采集第一节点中的用户业务数据；

发送模块64，用于向用户对应的网管设备发送恢复业务指令，使网管设备在接收到恢复业务指令后恢复用户业务数据。

其中，采集模块63包括：

第一判断单元，用于判断系统中第一节点的数量；

获取单元，用于当系统中存在多个第一节点时，获取需要被采集用户业务数据的各个第一节点的业务编码和业务流程编码；

第一采集单元，用于根据需要被采集用户业务数据的各个第一节点的业务编码、业务流程编码、异常发生时刻和预设采集时间长度，分段采集需要被采集用户业务数据的第一节点中的用户业务数据；

第二采集单元，用于当系统中只存在一个第一节点时，根据异常发生时刻、预设采集时间长度、预先给第一节点配置的业务编码和业务流程编码，分段采集第一节点中的用户业务数据。

其中，获取单元包括：

第一子单元，用于获取给系统中各节点配置的业务编码、业务流程编码以及业务流程编码串并行标志；

第二子单元，用于根据系统中各节点的业务编码、业务流程编码以及业务流程编码串并行标志，获取需要被采集用户业务数据的各个第一节点的业务编码和业务流程编码。

其中，发送模块64包括：

第二判断单元，用于根据预先给系统的各节点配置的精确判断规则，判断 第一节点是否需要进行精确判断，并当第一节点需要进行精确判断时，触发第三判断单元；

第三判断单元，用于根据第二判断单元的触发，进一步判断对第一节点进行精确判断的环境是否可用，并当对第一节点进行精确判断的环境可用时，触发第四判断单元；

第四判断单元，用于根据第三判断单元的触发，进一步根据预先给用户配置的特殊场景过滤规则，判断用户是否满足特殊场景过滤规则，并当当用户不满足特殊场景过滤规则时，触发生成单元，以及当用户满足特殊场景过滤规则时，结束流程；

生成单元，用于根据第四判断单元的触发，按照预先设定的第一恢复指令生成规则，生成恢复业务指令，并将恢复业务指令送给用户对应的网管设备。

其中，装置还包括：

第一获取模块，用于获取给系统中各节点配置的精确判断规则。

其中，装置还包括：

第二获取模块，用于获取给用户配置的特殊场景过滤规则。

其中，第三判断单元包括：

第三子单元，用于判断系统中在第一节点之后的节点是否能正常运行，以及是否能正常获取进行精确判断所需的信息，并当第一节点之后的节点能正常运行，且能正常获取进行精确判断所需的信息时，触发第四子单元，以及当第一节点之后的节点不能正常运行和/或不能正常获取进行精确判断所需的信息时，触发第五子单元；

第四子单元，用于根据第三子单元的触发，确定对第一节点进行精确判断的环境可用；

第五子单元，用于根据第三子单元的触发，确定对第一节点进行精确判断的环境不可用。

其中，装置还包括：

第一生成模块，用于当第一节点不需要进行精确判断时，按照预先设定的第二恢复指令生成规则，生成恢复业务指令，并将恢复业务指令发送给用户对应的网管设备。

其中，装置还包括：

第二生成模块，用于当对第一节点进行精确判断的环境不可用时，按照预先设定的第三恢复指令生成规则，生成恢复业务指令，并将恢复业务指令发送给用户对应的网管设备。

其中，发送模块64包括：

第五判断单元，用于判断第一节点是否是系统中的最后一个节点，并当第一节点不是系统中的最后一个节点时，触发转移单元；

转移单元，用于根据第五判断单元的触发，将第一节点中的用户业务数据转移至在第一节点之后的任意一个第二节点中，使第二节点和在第二节点之后的所有节点对从第一节点中转移出的用户业务数据进行处理，并向用户对应的网管设备发送恢复业务指令。

其中，装置还包括：

确定模块，用于确定接收到用户对应的网管设备返回的指令响应消息。

在本发明的第二实施例中，上述装置会监测用户业务数据流程的中断状态，且当监测到用户业务数据流程由中断进入恢复状态时，扫描用于恢复用户业务数据的系统的各节点，判断该系统中是否存在发生异常的第一节点，且当该系统中存在发生异常的第一节点时，采集第一节点中的用户业务数据，并向用户对应的网管设备发送恢复业务指令，使网管设备恢复所采集到的用户业务数据，达到了在用于恢复用户业务数据的系统发生异常的情况下，及时恢复用户业务数据(例如2分钟内恢复用户的上网功能)，提高用户体验的效果。

在本发明的第二实施例中，上述装置可以将网管设备的连接信息(例如IP地址等)转化成自身能识别的格式储存在本地，方便其向网关设备发送恢复业务指令。

需要说明的是，上述装置既适用于传统运营商支撑域和网管域的各个网元(例如归属位置寄存器等)的数据交互，在用户业务数据中断情况下快速无感知恢复，也适用于其他任何(例如虚拟运营商等)外围平台与传统运营商系统域交互异常情况下用户业务数据快速无感知恢复。此外，本发明第二实施例提供的恢复用户业务数据的装置是应用上述方法的装置，即上述方法的所有实施例均适用于该装置，且均能达到相同或相似的有益效果。

以上所述是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明所述原理的前提下，还可以作出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。