天津移动业务支撑应急系统设计与实现.docx

摘 要

目前中国移动集团天津公司NG-CRM/BOSS系统的业务连续性保障体系有三种模式，一种是多节点负荷分担方式，该方式主要用于系统接入层和业务逻辑层，有效地降低了个别节点故障对业务的影响程度；一种是容灾模式，由于多年未升级，系统资源与生产中心已不匹配，在发生突发事件时，容灾系统不能在特定的时间要求内全部或部分恢复关键业务功能；一种是双机备份共享存储（以下简称本地HA）方式，该方式主要用于系统核心层。对于系统核心层采用的本地HA模式来保障业务连续性，存在如下风险：
1) 由于核心系统IO量较大，如发生系统单节点宕机等严重故障可能会造成由于IO未及时写入磁盘而产生的文件系统错误，导致备机启动失败。
2) 人为因素、数据库逻辑错误或者存储故障造成的数据损坏从而引起业务中断，本地HA将无法解决。NG-CRM/BOSS系统全部业务要求7×24小时运行，存储阵列的使用强度大大增加，没有时间对存储系统进行定期维修和保养。因此，当使用一段时间后，存储系统的部件连续或同时出现故障的可能性增加。此外，随着存储系统的功能和性能越来越强，存储系统内部的控制软件也日趋复杂，就像一个操作系统，其本身也会出现故障或漏洞。部分省公司也曾经发生过由于存储故障造成业务系统长时间停机、数据丢失的重大故障。
3) 在系统割接、平台软硬件维护或应用版本升级等情况下，本地HA都将可能无法满足业务连续性要求。
4) 生产机房发生火灾、泡水等情况下，多节点负载分担和本地HA模式都不能保障业务连续性。
本文将从应急系统的系统架构、建设实现、系统测试各方面对于上述风险及问题进行研究并逐一解决。

关键词： 业务支撑系统　应急系统　运营商
ABSTRACT
At present the Tianjin NG-CRM/BOSS business continuity security system has three modes, one is a multi-node load balancing mode, this mode is mainly used for system access layer and business logic, effectively reducing the individual node failuresthe degree of influence of the business; a disaster recovery mode, due to years of not upgraded, the system resources and production center does not match, not within a specific time requirements in whole or in part, to restore critical business functions in the event of an emergency, disaster recovery system; a double backup shared storage (hereinafter referred to as the local HA) mode, which is mainly used for the core of the system layer. The local HA mode for the system core layer to protect business continuity, the following risks:
1) due to the large amount of core system IO, such as the occurrence of a serious failure of the system single-node downtime may cause IO is not written to disk file system errors, leading to the backup machine failed to start.
2) data corruption caused by human factors, database logic error or storage failure causing business interruption, local HA will not resolve. All of NG-CRM/BOSS system requirements 7 × 24 hours to run, greatly increase the intensity of use of the storage array, do not have time for regular repair and maintenance of the storage system. Therefore, when used for a period of time, the components of the storage system continuously or at the same time increase the probability of failure. In addition, with the growing functionality and performance of storage systems, storage systems within the control software are becoming increasingly complex, as an operating system, which itself will be failure or vulnerability. Some provinces have also undergone major failure of the business system for a long time downtime, data loss due to a storage failure.
3) in the system cutover, platform hardware and software maintenance or application upgrade, the local HA may not be able to meet the requirements of business continuity.
4) production engine room fire, flood damage and other circumstances, multi-node load balancing and the local HA mode can not guarantee business continuity.

From the emergency system architecture, construction, implementation, system testing all aspects of the risks and problems and solve them one by one.

KEY WORDS：NG-CRM/BOSS, Emergency System, Telecom Operators

目 录
目 录 4
第一章 绪　论 1
1.1 研究背景 1
1.2 研究目的及意义 1
1.3研究的主要内容及论文结构 2
第二章　天津移动业务支撑系统现状分析及应急建设需求 3
2.1系统现状及风险分析 3
2.1.1功能现状 3
2.1.2软硬件配置现状 4
2.1.3网络组织现状 6
2.1.4风险分析 8
2.1.5风险应对措施 9
2.2 应急建设需求 11
2.2.1业务建设范围 11
2.2.2接管时间要求 15
2.2.3应急数据同步 15
2.2.3应急数据回切 16
2.2.3应急系统管理功能 17
第三章　天津移动业务支撑应急系统技术研究 19
3.1 持续数据保护技术(CDP) 19
3.1.1定义 19
3.1.2与现有数据保护手段对比 19
3.1.3总结 20
3.2 基于J2EE的多层技术架构 20
3.2.1J2EE技术介绍 20
3.2.2J2EE四层模型 20
3.2.3J2EE结构 22
3.2.43J2EE优势 24
3.2.5J2EE和.NET体系结构比较 26
3.2.6总结 29
第四章 天津移动业务支撑应急系统的建设方案 30
4.1应急系统定位 30
4.2应急系统与外围系统边界 33
4.3应急系统目标 34
4.4应急系统架构 35
4.4.1功能架构 36
4.4.2数据流设计 41
4.4.3物理部署 47
4.4.4外围接口切换 48
4.4.5应急系统安全设计 48
4.4.6数据模型设计 49
4.5应急系统建设方案 51
4.5.1应急受理子系统 51
4.5.2应急管理平台系统 72
4.6应急系统硬件及平台软件建设方案 79
4.6.1硬件平台方案 79
4.6.2硬件配置方案和应用部署图 85
4.6.3网络环境 87
4.6.4系统软件 87
第五章　天津移动业务支撑应急系统应急场景的分析和确定 89
5.1应急场景 89
5.1.1应用分析 89
5.1.2分业务分析 94
5.1.3针对风险点的应急分析 94
5.2建设场景 95
5.2.1正常场景 95
5.2.2场景1网上营业厅应用切换场景 96
5.2.3场景2短信营业厅应用切换场景 98
5.2.4场景3联指应用切换场景 100
5.2.5场景4客服应用切换场景 103
5.2.6场景5外围接口应用切换场景 105
5.2.7场景6统一接入应用切换场景 107
5.2.8场景7CRM应用全切场景 109
5.2.9场景8全切场景 112
第六章　天津移动业务支撑应急系统演练 116
6.1演练场景 116
6.2演练范围 116
6.3演练流程 116
6.3.1生产系统切换到应急系统流程 116
6.3.2应急系统回切生产系统流程 119
6.4演练总结 122
第七章　结论与展望 125
参考文献 126
发表论文和参加科研情况说明 127
致 谢 128

第一章 绪　论
1.1 研究背景
中国移动业务支撑系统经过近几年的集中化改造建设和不断完善，经过NGBOSS（新一代业务运营支撑系统）建设，业务支撑系统已经在市场拓展、客户服务等工作中发挥了重要的支撑作用，成为中国移动贯彻落实“服务与业务领先”战略的有力手段。
日益激烈的市场竞争和不断提高的客户服务质量需求对BOSS业务支撑能力和可靠稳定运行的要求越来越高，从面向客户服务的角度而言，无论何时出现何种情况，都需要移动运营商提供不间断的业务支撑服务，以保证客户满意度、客户服务质量、企业信誉等不受影响，对企业而言也可避免财务损失，增强企业竞争力。
与此同时，BOSS集中化改造、NGBOSS一阶段和二阶段建设在带来业务快速响应等众多优势的同时，也存在着系统故障点集中、风险集中的危险，如：系统故障、人为误操作、火灾、水灾、传输中断、电网停电等系统风险。因此，适时、合理地规划和开展中国移动业务运营支撑系统应急保障体系建设，已经成为中国移动的重要任务。
1.2 研究目的及意义
为保证业务持续运营，NGBOSS系统已经在系统架构上充分考虑其可靠性。NG-CRM/BOSS系统的关键应用系统的服务器都进行了高可靠性（HA）设计，杜绝了单点故障导致业务中断。在本地高可靠性的基础上，为了在出现灾难情况时（如地震、水灾、火灾、瘟疫、人为灾难故障），能够有效对系统和应用进行恢复，NGBOSS系统还建立了容灾备份系统，实现了数据及应用的容灾。
但是，在某些故障（如：数据库磁盘故障、软件错误等）发生时，HA并不能解决问题，同时由于这些故障预计能够在短时间内（4小时以内）能够解决，因此并没有必须进行容灾切换。
在这种情况下，运营商需要有一个应急系统，能够支持短时间的关键业务的运营生产，保证客户感受不到业务的中断。
通过业务支撑应急系统的建设，建立业务支撑网的应急风险预防、应急响应机制和恢复措施，保证在发生突发事件时，能够在特定的时间要求内，能够全部或部分恢复关键业务功能，提高关键业务连续运行能力，提升服务质量和服务水平，并降低运营风险，将业务损失降低到可接受的程度，以增强企业竞争力。
1.3研究的主要内容及论文结构
本文主要是针对天津移动业务支撑应急系统技术方案的研究，通过对现状的分析，确认系统建设范围，设计系统功能及技术架构以完成整体的建设方案。并且通过对应急场景的归纳总结，保证方案的可实施性和有效性。
论文主要分为以下章节：
第一章绪论，介绍了天津移动业务支撑应急系统的必要性和需解决的问题，提出了本文的研究内容及意义。
第二章对目前天津移动业务支撑系统的现状分析，确认建设方向、建设范围及具体内容。
第三章对天津移动业务支撑应急系统技术研究及选型。
第四章介绍天津移动业务支撑应急系统的建设方案，包括系统架构设计、功能架构设计、各模块设计、数据流设计、部署方案等。
第五章为天津移动业务支撑应急系统的应急场景的分析和确定，包含各子系统的应急场景及相关流程，为项目建设提供了验证依据。
第六章为天津移动业务支撑应急系统演练方案及演练总结。
第七章为结论与展望，对论文工作进行了总结，展示了本系统开发的主要成果及丞待完善的方面。

第二章　天津移动业务支撑系统现状分析及应急建设需求
2.1系统现状及风险分析
2.1.1功能现状
BOSS系统主要包括产品管理、信息管理、融合计费、综合结算、综合帐务、采集预处理、服务开通、合作伙伴管理、基础管理等九大功能域，如下图2.1.1-1所示。

图 2.1.11 BOSS系统功能架构图
CRM系统主要包括渠道管理、市场营销、销售管理、客服服务、客服管理、产品管理、资源管理和基础管理等八大功能域。功能结构如下图2.1.1-2所示。
图2.1.1-2 CRM系统功能结构图
2.1.2软硬件配置现状
BOSS/CRM生产中心配有8台满配置的IBM P595小型机，主机处理能力达到3420万tpmC，主机配置如下表：
表2.1.2-1 BOSS/CRM系统主机配置情况表
系统划分
序号

主机名称
数量（台）

单台设备配置情况
型号
CPU数量
CPU主频（GHz）
内存（GB）
生
产
中
心

B
O
S
S
系
统

1
计费数据库Cluster1
1
P595F
10
2.3
48
2
账务数据库Cluster1
1
12
2.3
72
3
账务应用 Cluster1
1
40
2.3
340
4
连指
1
2
2.3
16
5
计费数据库Cluster2
1
P595G
10
2.3
48
6
账务数据库Cluster2
1
12
2.3
72
7
账务应用Cluster2
1
40
2.3
360
8
连指
1
2
2.3
16
9
连指服务器
1
P630
2
1.45
8
10
采集
1
P650B
4
1.45
32
C
R
M
系
统

1
olcom1
1
B80
2

2
2
网厅前置
1
P650C
4
1.45
8
3
DSMP WEB
1
P570A
8
2.2
30
4
ESOP 测试
1
P570B
8
2.2
30
5
CRM 前置
1
P570C
4
2.2
20
6
PB 测试
1
12
2.2
70
7
CRM WEB2
1
P595A
20
1.9
128
8
一级BOSS（落地方）1
1
6
1.9
36
9
电子渠道WEB服务器
1
8
1.9
48
10
ESOP1
1
8
1.9
48
11
客服APP1
1
8
1.9
64
12
CRM WEB1
1
P595B
20
1.9
128
13
一级BOSS（落地方）2
1
6
1.9
36
14
电子渠道WEB服务器
1
8
1.9
48
15
ESOP2
1
8
1.9
48
16
客服APP2
1
8
1.9
64
17
CRM TUX2
1
P595C
16
2.3
128
18
接口TUX
1
14
2.3
64
19
统一接入平台
1
10
2.3
64
20
CRM数据库Cluster1
1
24
2.3
128
21
CRM TUX1
1
P595D
16
2.3
128
22
接口TUX
1
14
2.3
64
23
统一接入平台
1
10
2.3
64
24
CRM数据库Cluster2
1
24
2.3
128
25
一级BOSS（平台，发起方）
1
P595E
8
2.3
48
26
BPM、容错探针
1
12
2.3
96
27
Crm/actdb测试
1
16
2.3
128
28
客服DB1
1
10
2.3
80
29
pbossdb
1
8
2.3
64
30
topteadb
1
P595F
2
2.3
16
31
一级BOSS（数据指令）
1
P595H
8
2.3
48
32
服务开通
1
12
2.3
96
33
计费账务应用测试
1
16
2.3
160
34
客服DB2
1
10
2.3
80
35
pbossapp
1
8
2.3
64
36
NG编译
1
P690C
8
1.7
48
37
短信、充值营业厅
1
8
1.7
48
38
CRM开发
1
8
1.7
32
39
营销/一致性
1
8
1.7
32
40
CRM 前置机
1
P690D
8
1.7
48
41
DSMP WEB
1
8
1.7
48
42
NG 测试app
1
8
1.7
20
43
历史数据库1
1
8
1.7
40

BOSS/CRM系统存储配置情况如下表所示。
表2.1.2-2 BOSS/CRM系统存储配置情况表
磁盘阵列
系统划分
序号
设备型号
数量(套)
磁盘配置裸容量(TB)
生产中心
BOSS系统
1
IBM ESS800
1
47.0
2
IBM DS8300
1
78.0
CRM系统
3
IBM DS8300
1
41.0
容灾中心
BOSS系统
4
IBM DS8300
1
93.0
CRM系统
磁带库
系统划分
序号
设备型号
数量(套)
裸容量(TB)
生产中心
BOSS/CRM共用
5
IBM TS3584
1
120
容灾中心
BOSS/CRM共用
6
IBM TS3584
1
222
SAN交换机
系统划分
序号
设备型号
数量(台)
端口情况
生产中心
BOSS/CRM共用
7
IBM M48
2
每台配有5*32个光纤端口
8
IBM M14
2
每台配有5*16个光纤端口
9
IBM F32
5
每台配有32个2Bb/s光纤口

2.1.3网络组织现状
为了充分保证BOSS/CRM系统的安全、可靠性，目前BOSS/CRM系统网络共分为三层：SAN存储层、核心网络层（内网）、接入网络层（外网DMZ）。其中，计费应用、帐务应用、CRM数据库、集中采集、测试、备份、统计分析、结算等核心服务器直接通过SAN交换机实现磁盘阵列、磁带库的存储和备份；计费应用、帐务应用、CRM数据库、集中采集、联机指令、测试、备份、统计分析、结算等核心服务器属于关键生产服务器，处于核心网络层，分别连接在移通大厦20层2台Catalyst 6509核心内网交换机及移通大厦22层2台Quidway S8505核心内网交换机上；考虑到系统的安全可靠性，把与外界联系紧密的服务器，如中间件、WEB、一级BOSS接口、DSMP接口、防病毒、认证、桌面管理系统、SOC服务器连接在IP1260防火墙上的DMZ区，即4台C4506交换机上；与OA 、客服、采集、营业厅等系统的连接均通过异构防火墙连接在接入的Catalyst 6509交换机上。接入交换机Catalyst 6509（外网）、千兆防火墙IP1260、核心交换机Catalyst 6509（内网）组成BOSS系统的高速数据通道，采用负荷分担的方式进行工作，确保系统稳定、可靠的运行。
此外，随着世纪大道IT机房的启用，MIS、统一信息平台和经营分析系统将陆续搬迁至相应机房；目前在世纪大道机房设有4台Catalyst 6509交换机，分别与移通大厦机房、南开工业园机房对应连接，实现信息化系统及经营分析系统与BOSS系统的互联。
网络结构如下图所示。

图 2.1.31 BOSS及CRM系统网络结构图
BOSS/CRM系统网络设备配置情况如下表所示。
表2.1.3-1 天津公司BOSS/CRM系统网络设备配置情况表
序号
设备名称或型号
数量
主要配置及说明
备注
1
Catalyst6509交换机
2
分别配置2x48个10/100 Base-T电口，2x16个千兆光口，1个48口千兆光口。
移通20楼，核心
2
Catalyst6509交换机
2
分别配置2x48个10/100 Base-T电口，2x16个千兆光口，1个48口千兆光口。
南开工业园，核心
3
Catalyst6509交换机
2
分别配置2x48个10/100 Base-T电口，2x16个千兆光口
移通20楼，连接外网
4
Catalyst6509交换机
2
分别配置2x48个10/100 Base-T电口，1x16个千兆光口
南开工业园，连接外网
5
Catalyst4506交换机
2
分别配置1个控制卡（含2个光口）、1x6口GE卡，1个2GE+32口10/100M板卡，1个18口光口板卡
移通20楼
6
Catalyst4506交换机
2
分别配置1个控制卡（含2个光口）、1x6口GE卡，1个2GE+32口10/100M板卡，1个18口光口板卡
南开工业园
7
NOKIA IP1260千兆防火墙
2
分别配置2个双端口千兆卡
移通20楼
8
NOKIA IP1260千兆防火墙
2
分别配置2个双端口千兆卡
南开工业园
9
华为S8505交换机
2
分别配置1个48口10/1000电口板卡，1个48口光口板卡
移通22楼，核心

2.1.4风险分析
目前天津公司NGBOSS系统的业务连续性保障体系有三种模式，一种是多节点负荷分担方式，该方式主要用于系统接入层和业务逻辑层，有效地降低了个别节点故障对业务的影响程度；一种是磁带库、CDP和存储底层复制实现的数据级容灾（以下简称数据容灾）方式，该方式其实只是实现了系统中主要业务数据的备份，没有实现应用级容灾，不能在发生突发事件时，在特定的时间（RTO）要求内，能够全部或部分恢复关键业务功能；一种是双机备份共享存储（以下简称本地HA）方式，该方式主要用于系统核心层。对于系统核心层采用的本地HA模式来保障业务连续性，存在如下风险：
1) 由于核心系统IO量较大，如发生系统单节点宕机等严重故障可能会造成由于IO未及时写入磁盘而产生的文件系统错误，导致备机启动失败。
2) 人为因素、数据库逻辑错误或者存储故障造成的数据损坏从而引起业务中断，本地HA将无法解决。NG-CRM/BOSS系统全部业务要求7×24小时运行，存储阵列的使用强度大大增加，没有时间对存储系统进行定期维修和保养。因此，当使用一段时间后，存储系统的部件连续或同时出现故障的可能性增加。此外，随着存储系统的功能和性能越来越强，存储系统内部的控制软件也日趋复杂，就像一个操作系统，其本身也会出现故障或漏洞。部分省公司也曾经发生过由于存储故障造成业务系统长时间停机、数据丢失的重大故障。
3) 在系统割接、平台软硬件维护或应用版本升级等情况下，本地HA都将可能无法满足业务连续性要求。
4) 生产机房发生火灾、泡水等情况下，多节点负载分担和本地HA模式都不能保障业务连续性。
2.1.5风险应对措施
针对上述系统风险，可以通过应急系统的建设加以规避，以提高关键业务连续运行能力。应急系统是本地HA、多节点负载分担等业务连续保障模式的轻量级补充，可实现关键业务的快速恢复。本地HA是系统核心层的整体恢复体系，通过启动HA可以全面接管核心层生产系统。多节点负载分担可以在生产机房未发生火灾等情况下，确保业务连续性。
归纳起来，主要有两种情况下须进行生产系统至应急系统的切换：一种是主动应急，生产系统进行平台版本升级、应用版本上线、软硬件更换、数据库扩容等例行维护工作情况下，为了保障关键业务连续性，需要将生产系统切换到应急系统。一种是被动应急，生产系统的关键业务发生故障而且故障修复时间大于30分钟的情况下，生产系统应切换到本地应急系统。具体如下：
1) 人为或数据库逻辑等因素引起的数据损坏：数据库的逻辑错误或人为的操作失误可能会导致生产中心关键系统数据库均不可用，在此情况下须启用应急系统。
2) 应用版本升级场景：目前NG-CRM/BOSS系统有稳定的新业务上线流程，在上线前有着严格的测试流程。但是由于NG-CRM/BOSS业务关联性强，前期的测试有可能没有覆盖所有的业务流程。上线后，可能造成系统运行不稳定或者部分业务受理结果不正确。在此情况下，必须采取措施，避免错误继续扩大，同时需要回退更新。
3) 前台业务受理中断场景：由于系统硬件、软件、网络故障导致实体、电子渠道业务受理中断，引起客户投诉与抱怨，为了降低客户投诉率，可以切换至应急系统满足关键业务的连续性受理。
4) 系统割接场景：在进行系统割接时，为了不影响用户满意度以及集团的考核，可以切换到应急系统来满足关键业务的连续性。（如：自动台的余额查询、空中充值等）。
5) 硬件维护场景：在系统维护过程中，可能会出现IBM/SUN/HP主机、网络设备、存储设备硬件维护或硬件微码升级的情况，可以切换到应急系统来保证关键业务的连续性。（如：IBM/SUN/HP 硬件更换）。
6) 平台软件维护场景：在系统维护过程中，可能会出现数据库需要补丁升级需要重启等情况，可以切换到应急系统来保证关键业务的连续性。（如：ORACLE/TEXUDO/WEBLOGIC软件补丁升级）。
7) 前台业务受理中断场景：由于系统硬件、软件、网络故障导致实体、电子渠道业务受理中断，引起客户投诉与抱怨，为了降低客户投诉率，可以切换至应急系统满足关键业务的连续性受理。
8) 生产机房发生火灾或泡水情况
2.2 应急建设需求
2.2.1业务建设范围
应急系统基础建设阶段包括渠道及主要功能如下：
2.2.1.1营业前台应急功能
在生产系统切换至应急系统后，营业前台渠道应支持如下表格2.2.1.1-1所示的业务受理、信息查询及其他辅助功能。
表2.2.1.1-1 营业前台应急功能表
业务功能
功能域
功能说明
备注
开户
业务受理
可为客户建立档案、开通客户订购的移动服务及客户付费信息

充值
业务受理
可为用户进行充值的服务
充值应至少包括：前台现金充值、充值卡充值、空中充值三种。
缴费
业务受理
可为用户进行缴费服务

停复机
业务受理
可为用户提供停机、复机的服务

补换卡
业务受理
可实现对SIM卡的写卡处理，实现IMSI码与ICCID码绑定，同时开通鉴权服务

用户资料查询
信息查询
可查询用户的准实时资料，如姓名、证件号码等信息

余额查询
信息查询
查询用户余额准实时数据信息

积分查询
信息查询
可查询用户的准实时积分值信息

账单查询
信息查询
可查询用户的准实时消费账单信息

PUK码查询
信息查询
可为用户提供查询PUK码的服务

家庭充值/缴费
业务受理
可为家庭用户提供充值或缴费服务

集团充值/缴费
业务受理
可为集团用户提供充值或缴费服务

套餐变更
业务受理
可为用户提供各类产品套餐的变更服务

营销方案
业务受理
可为用户提供营销方案的办理及撤销服务

号源查询
信息查询
可提供号源的查询服务

亲情组合及查询
信息查询
可为用户提供亲情号码组合受理及查询服务

用户订购信息查询
信息查询
可提供用户的营销方案、已开通业务、附加功能、增值业务、梦网业务、自有业务、国际功能的查询服务

查询GPRS流量
信息查询
可查询用户准实时的GPRS流量信息

清单查询
信息查询
可查询用户准实时的清单信息

2.2.1.2客服系统应急功能
在生产系统切换至应急系统后，客服系统应提供如下表格2.2.1.2-1所示的基本业务及用户信息资料查询功能。
表2.2.1.2-1 客服系统应急功能表
业务功能
渠道
功能域
功能说明
备注
密码校验
人工台/自动台
信息查询
可对用户输入的密码进行正确性校验

用户资料查询
人工台/自动台
信息查询
可查询用户的准实时资料信息

余额查询
人工台/自动台
信息查询
查询用户余额准实时数据信息

积分查询
人工台/自动台
信息查询
可查询用户的准实时积分值信息

申请停复机
人工台
业务受理
可为用户提供停机、复机的服务

用户订购信息查询
人工台
信息查询
可提供用户的营销方案、已开通业务、附加功能、增值业务、梦网业务、自有业务、国际功能的查询服务

账单查询
人工台
信息查询
可查询用户的消费准实时账单信息

PUK码查询
人工台
信息查询
可为用户提供查询PUK码的服务

亲情组合及查询
人工台
业务受理
可为用户提供亲情号码组合受理及查询服务

查询GPRS流量
人工台
信息查询
可查询用户准实时的GPRS流量信息

清单查询
人工台
信息查询
可查询用户准实时的清单信息

套餐变更
人工台
业务受理
可提供为用户办理套餐产品变更的服务

查询有效期
自动台
信息查询
可查询账户余额的有效期时间信息

话费查询
自动台
信息查询
可查询用户话费准实时信息

欠费信息查询
自动台
信息查询
可查询用户欠费准实时信息

2.2.1.3电子渠道应急功能
2.2.1.3.1网上营业厅
网上营业厅在生产系统切换至应急系统后，可支持如下表格2.2.1.3.1-1所示的业务受理、信息查询及其他辅助功能。
表2.2.1.3.1-1 网上营业厅应急功能表
业务功能
功能域
功能说明
密码验证
业务受理
可对用户输入的密码进行正确性校验
用户资料查询
信息查询
可查询用户的准实时资料，如姓名、证件号码等信息
余额查询
信息查询
查询用户余额准实时数据信息
查询GPRS流量
信息查询
可查询用户准实时的GPRS流量信息
账单查询
信息查询
可查询用户的消费准实时账单信息
清单查询
信息查询
可查询用户准实时的清单信息
网上充值卡充值
业务受理
可支持网上营业厅通过充值卡进行充值的服务
停复机
业务受理
可为用户提供停机、复机的服务
套餐变更
业务受理
可为用户提供各类产品套餐的变更服务
亲情组合及查询
业务受理
可为用户提供亲情号码组合受理及查询服务
用户订购信息查询
信息查询
可提供用户的营销方案、已开通业务、附加功能、增值业务、梦网业务、自有业务、国际功能的查询服务
PUK码查询
信息查询
可为用户提供查询PUK码的服务

2.2.1.3.2掌上营业厅
掌上营业厅在生产系统切换至应急系统后，可支持如下表格2.2.1.3.2-1所示的业务受理、信息查询及其他辅助功能。
表2.2.1.3.2-1 掌上营业厅应急功能表
业务功能
功能域
功能说明
密码验证
业务受理
可对用户输入的密码进行正确性校验
用户资料查询
信息查询
可查询用户的准实时资料，如姓名、证件号码等信息
余额查询
信息查询
查询用户余额准实时数据信息
查询GPRS流量
信息查询
可查询用户准实时的GPRS流量信息
账单查询
信息查询
可查询用户的消费准实时账单信息
清单查询
信息查询
可查询用户准实时的清单信息
网上充值卡充值
业务受理
可支持网上营业厅通过充值卡进行充值的服务
停复机
业务受理
可为用户提供停机、复机的服务
套餐变更
业务受理
可为用户提供各类产品套餐的变更服务
亲情组合及查询
业务受理
可为用户提供亲情号码组合受理及查询服务
用户订购信息查询
信息查询
可提供用户的营销方案、已开通业务、附加功能、增值业务、梦网业务、自有业务、国际功能的查询服务
PUK码查询
信息查询
可为用户提供查询PUK码的服务

2.2.1.3.3短信营业厅
短信营业厅在生产系统切换至应急系统后，可支持如下表格2.2.1.3.3-1所示的业务受理、信息查询及其他辅助功能。
表2.2.1.3.3-1 短信营业厅应急功能表
业务功能
功能域
功能说明
密码验证
业务受理
可对用户输入的密码进行正确性校验
用户资料查询
信息查询
可查询用户的准实时资料，如姓名、证件号码等信息
余额查询
信息查询
查询用户余额准实时数据信息
查询GPRS流量
信息查询
可查询用户准实时的GPRS流量信息
账单查询
信息查询
可查询用户的消费准实时账单信息
清单查询
信息查询
可查询用户准实时的清单信息
网上充值卡充值
业务受理
可支持网上营业厅通过充值卡进行充值的服务
停复机
业务受理
可为用户提供停机、复机的服务
套餐变更
业务受理
可为用户提供各类产品套餐的变更服务
亲情组合及查询
业务受理
可为用户提供亲情号码组合受理及查询服务
用户订购信息查询
信息查询
可提供用户的营销方案、已开通业务、附加功能、增值业务、梦网业务、自有业务、国际功能的查询服务
PUK码查询
信息查询
可为用户提供查询PUK码的服务

2.2.1.4网络中断
网络中断业务受理流程：
1) 在网络出现问题时，应急系统只在本机进行缴费信息的记录，生成缴费记录文件，不做任何后续操作；
2) 网络正常而生产系统未恢复时，执行应急缴