《某公司业务支撑应急系统设计与实现论文.docx》由会员分享，可在线阅读，更多相关《某公司业务支撑应急系统设计与实现论文.docx（139页珍藏版）》请在三一办公上搜索。
1、摘 要目前中国移动集团天津公司NG-CRM/BOSS系统的业务连续性保障体系有三种模式，一种是多节点负荷分担方式，该方式主要用于系统接入层和业务逻辑层，有效地降低了个别节点故障对业务的影响程度；一种是容灾模式，由于多年未升级，系统资源与生产中心已不匹配，在发生突发事件时，容灾系统不能在特定的时间要求内全部或部分恢复关键业务功能；一种是双机备份共享存储（以下简称本地HA）方式，该方式主要用于系统核心层。对于系统核心层采用的本地HA模式来保障业务连续性，存在如下风险：1)由于核心系统IO量较大，如发生系统单节点宕机等严重故障可能会造成由于IO未及时写入磁盘而产生的文件系统错误，导致备机启动失败。2
2、)人为因素、数据库逻辑错误或者存储故障造成的数据损坏从而引起业务中断，本地HA将无法解决。NG-CRM/BOSS系统全部业务要求724小时运行，存储阵列的使用强度大大增加，没有时间对存储系统进行定期维修和保养。因此，当使用一段时间后，存储系统的部件连续或同时出现故障的可能性增加。此外，随着存储系统的功能和性能越来越强，存储系统内部的控制软件也日趋复杂，就像一个操作系统，其本身也会出现故障或漏洞。部分省公司也曾经发生过由于存储故障造成业务系统长时间停机、数据丢失的重大故障。3)在系统割接、平台软硬件维护或应用版本升级等情况下，本地HA都将可能无法满足业务连续性要求。4)生产机房发生火灾、泡水等情
3、况下，多节点负载分担和本地HA模式都不能保障业务连续性。本文将从应急系统的系统架构、建设实现、系统测试各方面对于上述风险及问题进行研究并逐一解决。关键词： 业务支撑系统应急系统运营商ABSTRACTAt 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, eff
4、ectively 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 function
5、s 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 th
6、e 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 c
7、ausing 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 com
8、ponents 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
9、 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 req
10、uirements 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 a
11、nd problems and solve them one by one. KEY WORDS：NG-CRM/BOSS, Emergency System, Telecom Operators目 录目 录4第一章 绪论11.1研究背景11.2研究目的及意义11.3研究的主要内容及论文结构2第二章天津移动业务支撑系统现状分析及应急建设需求32.1系统现状及风险分析32.1.1功能现状32.1.2软硬件配置现状42.1.3网络组织现状62.1.4风险分析82.1.5风险应对措施92.2 应急建设需求112.2.1业务建设范围112.2.2接管时间要求一五2.2.3应急数据同步一五2.2.3应急数
12、据回切162.2.3应急系统管理功能17第三章天津移动业务支撑应急系统技术研究193.1持续数据保护技术(CDP)193.1.1定义193.1.2与现有数据保护手段对比193.1.3总结203.2基于J2EE的多层技术架构203.2.1J2EE技术介绍203.2.2J2EE四层模型203.2.3J2EE结构223.2.43J2EE优势243.2.5J2EE和.NET体系结构比较263.2.6总结29第四章 天津移动业务支撑应急系统的建设方案304.1应急系统定位304.2应急系统与外围系统边界334.3应急系统目标344.4应急系统架构354.4.1功能架构364.4.2数据流设计414.4.
13、3物理部署474.4.4外围接口切换484.4.5应急系统安全设计484.4.6数据模型设计494.5应急系统建设方案514.5.1应急受理子系统514.5.2应急管理平台系统724.6应急系统硬件及平台软件建设方案794.6.1硬件平台方案794.6.2硬件配置方案和应用部署图854.6.3网络环境874.6.4系统软件87第五章天津移动业务支撑应急系统应急场景的分析和确定895.1应急场景895.1.1应用分析895.1.2分业务分析945.1.3针对风险点的应急分析945.2建设场景955.2.1正常场景955.2.2场景1网上营业厅应用切换场景965.2.3场景2短信营业厅应用切换场景
14、985.2.4场景3联指应用切换场景1005.2.5场景4客服应用切换场景1035.2.6场景5外围接口应用切换场景1055.2.7场景6统一接入应用切换场景1075.2.8场景7CRM应用全切场景1095.2.9场景8全切场景112第六章天津移动业务支撑应急系统演练1166.1演练场景1166.2演练范围1166.3演练流程1166.3.1生产系统切换到应急系统流程1166.3.2应急系统回切生产系统流程1196.4演练总结122第七章结论与展望125参考文献126发表论文和参加科研情况说明127致 谢128第一章 绪论1.1 研究背景中国移动业务支撑系统经过近几年的集中化改造建设和不断完善
15、，经过NGBOSS（新一代业务运营支撑系统）建设，业务支撑系统已经在市场拓展、客户服务等工作中发挥了重要的支撑作用，成为中国移动贯彻落实“服务与业务领先”战略的有力手段。日益激烈的市场竞争和不断提高的客户服务质量需求对BOSS业务支撑能力和可靠稳定运行的要求越来越高，从面向客户服务的角度而言，无论何时出现何种情况，都需要移动运营商提供不间断的业务支撑服务，以保证客户满意度、客户服务质量、企业信誉等不受影响，对企业而言也可避免财务损失，增强企业竞争力。与此同时，BOSS集中化改造、NGBOSS一阶段和二阶段建设在带来业务快速响应等众多优势的同时，也存在着系统故障点集中、风险集中的危险，如：系统故
16、障、人为误操作、火灾、水灾、传输中断、电网停电等系统风险。因此，适时、合理地规划和开展中国移动业务运营支撑系统应急保障体系建设，已经成为中国移动的重要任务。1.2 研究目的及意义为保证业务持续运营，NGBOSS系统已经在系统架构上充分考虑其可靠性。NG-CRM/BOSS系统的关键应用系统的服务器都进行了高可靠性（HA）设计，杜绝了单点故障导致业务中断。在本地高可靠性的基础上，为了在出现灾难情况时（如地震、水灾、火灾、瘟疫、人为灾难故障），能够有效对系统和应用进行恢复，NGBOSS系统还建立了容灾备份系统，实现了数据及应用的容灾。但是，在某些故障（如：数据库磁盘故障、软件错误等）发生时，HA并不
17、能解决问题，同时由于这些故障预计能够在短时间内（4小时以内）能够解决，因此并没有必须进行容灾切换。在这种情况下，运营商需要有一个应急系统，能够支持短时间的关键业务的运营生产，保证客户感受不到业务的中断。通过业务支撑应急系统的建设，建立业务支撑网的应急风险预防、应急响应机制和恢复措施，保证在发生突发事件时，能够在特定的时间要求内，能够全部或部分恢复关键业务功能，提高关键业务连续运行能力，提升服务质量和服务水平，并降低运营风险，将业务损失降低到可接受的程度，以增强企业竞争力。1.3研究的主要内容及论文结构本文主要是针对天津移动业务支撑应急系统技术方案的研究，通过对现状的分析，确认系统建设范围，设计
18、系统功能及技术架构以完成整体的建设方案。并且通过对应急场景的归纳总结，保证方案的可实施性和有效性。论文主要分为以下章节：第一章绪论，介绍了天津移动业务支撑应急系统的必要性和需解决的问题，提出了本文的研究内容及意义。第二章对目前天津移动业务支撑系统的现状分析，确认建设方向、建设范围及具体内容。第三章对天津移动业务支撑应急系统技术研究及选型。第四章介绍天津移动业务支撑应急系统的建设方案，包括系统架构设计、功能架构设计、各模块设计、数据流设计、部署方案等。第五章为天津移动业务支撑应急系统的应急场景的分析和确定，包含各子系统的应急场景及相关流程，为项目建设提供了验证依据。第六章为天津移动业务支撑应急系
19、统演练方案及演练总结。第七章为结论与展望，对论文工作进行了总结，展示了本系统开发的主要成果及丞待完善的方面。133第二章天津移动业务支撑系统现状分析及应急建设需求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软硬件配置
20、现状BOSS/CRM生产中心配有8台满配置的IBM P595小型机，主机处理能力达到3420万tpmC，主机配置如下表：表2.1.2-1 BOSS/CRM系统主机配置情况表系统划分序号主机名称数量（台）单台设备配置情况型号CPU数量CPU主频（GHz）内存（GB）生产中心BOSS系统1计费数据库Cluster11P595F102.3482账务数据库Cluster11122.3723账务应用 Cluster11402.33404连指122.3165计费数据库Cluster21P595G102.3486账务数据库Cluster21122.3727账务应用Cluster21402.33608连指12
21、2.3169连指服务器1 P63021.45810采集1P650B41.4532CRM系统1olcom11B80222网厅前置1P650C41.4583DSMP WEB1P570A82.2304ESOP 测试1P570B82.2305CRM 前置1P570C42.2206PB 测试1122.2707CRM WEB21P595A201.91288一级BOSS（落地方）1161.9369电子渠道WEB服务器181.94810ESOP1181.94811客服APP1181.96412CRM WEB11P595B201.9128一三一级BOSS（落地方）2161.93614电子渠道WEB服务器181.
22、948一五ESOP2181.94816客服APP2181.96417CRM TUX21P595C162.3128一八接口TUX1142.36419统一接入平台1102.36420CRM数据库Cluster11242.312821CRM TUX11P595D162.312822接口TUX1142.36423统一接入平台1102.36424CRM数据库Cluster21242.312825一级BOSS（平台，发起方）1P595E82.34826BPM、容错探针1122.39627Crm/actdb测试1162.312828客服DB11102.38029pbossdb182.36430toptead
23、b1P595F22.31631一级BOSS（数据指令）1P595H82.34832服务开通1122.39633计费账务应用测试1162.316034客服DB21102.38035pbossapp182.36436NG编译1P690C81.74837短信、充值营业厅181.74838CRM开发181.73239营销/一致性181.73240CRM 前置机1P690D81.74841DSMP WEB181.74842NG 测试app181.72043历史数据库1181.740BOSS/CRM系统存储配置情况如下表所示。表2.1.2-2 BOSS/CRM系统存储配置情况表磁盘阵列系统划分序号设备型号
24、数量(套)磁盘配置裸容量(TB)生产中心BOSS系统1IBM ESS800147.02IBM DS8300178.0CRM系统3IBM DS8300141.0容灾中心BOSS系统4IBM DS8300193.0CRM系统磁带库系统划分序号设备型号数量(套)裸容量(TB)生产中心BOSS/CRM共用5IBM TS35841120容灾中心BOSS/CRM共用6IBM TS35841222SAN交换机系统划分序号设备型号数量(台)端口情况生产中心BOSS/CRM共用7IBM M482每台配有5*32个光纤端口 8IBM M142每台配有5*16个光纤端口 9IBM F325每台配有32个2Bb/s光
25、纤口2.1.3网络组织现状为了充分保证BOSS/CRM系统的安全、可靠性，目前BOSS/CRM系统网络共分为三层：SAN存储层、核心网络层（内网）、接入网络层（外网DMZ）。其中，计费应用、帐务应用、CRM数据库、集中采集、测试、备份、统计分析、结算等核心服务器直接通过SAN交换机实现磁盘阵列、磁带库的存储和备份；计费应用、帐务应用、CRM数据库、集中采集、联机指令、测试、备份、统计分析、结算等核心服务器属于关键生产服务器，处于核心网络层，分别连接在移通大厦20层2台Catalyst 6509核心内网交换机及移通大厦22层2台Quidway S8505核心内网交换机上；考虑到系统的安全可靠性，
26、把与外界联系紧密的服务器，如中间件、WEB、一级BOSS接口、DSMP接口、防病毒、认证、桌面管理系统、SOC服务器连接在IP1260防火墙上的DMZ区，即4台C4506交换机上；与OA 、客服、采集、营业厅等系统的连接均通过异构防火墙连接在接入的Catalyst 6509交换机上。接入交换机Catalyst 6509（外网）、千兆防火墙IP1260、核心交换机Catalyst 6509（内网）组成BOSS系统的高速数据通道，采用负荷分担的方式进行工作，确保系统稳定、可靠的运行。此外，随着世纪大道IT机房的启用，MIS、统一信息平台和经营分析系统将陆续搬迁至相应机房；目前在世纪大道机房设有4台
27、Catalyst 6509交换机，分别与移通大厦机房、南开工业园机房对应连接，实现信息化系统及经营分析系统与BOSS系统的互联。网络结构如下图所示。图 2.1.31 BOSS及CRM系统网络结构图BOSS/CRM系统网络设备配置情况如下表所示。表2.1.3-1 天津公司BOSS/CRM系统网络设备配置情况表序号设备名称或型号数量主要配置及说明备注1Catalyst6509交换机2分别配置2x48个10/100 Base-T电口，2x16个千兆光口，1个48口千兆光口。移通20楼，核心2Catalyst6509交换机2分别配置2x48个10/100 Base-T电口，2x16个千兆光口，1个48
28、口千兆光口。南开工业园，核心3Catalyst6509交换机2分别配置2x48个10/100 Base-T电口，2x16个千兆光口移通20楼，连接外网4Catalyst6509交换机2分别配置2x48个10/100 Base-T电口，1x16个千兆光口南开工业园，连接外网5Catalyst4506交换机2分别配置1个控制卡（含2个光口）、1x6口GE卡，1个2GE+32口10/100M板卡，1个一八口光口板卡移通20楼6Catalyst4506交换机2分别配置1个控制卡（含2个光口）、1x6口GE卡，1个2GE+32口10/100M板卡，1个一八口光口板卡南开工业园7NOKIA IP1260千
29、兆防火墙2分别配置2个双端口千兆卡移通20楼8NOKIA IP1260千兆防火墙2分别配置2个双端口千兆卡南开工业园9华为S8505交换机2分别配置1个48口10/1000电口板卡，1个48口光口板卡移通22楼，核心2.1.4风险分析目前天津公司NGBOSS系统的业务连续性保障体系有三种模式，一种是多节点负荷分担方式，该方式主要用于系统接入层和业务逻辑层，有效地降低了个别节点故障对业务的影响程度；一种是磁带库、CDP和存储底层复制实现的数据级容灾（以下简称数据容灾）方式，该方式其实只是实现了系统中主要业务数据的备份，没有实现应用级容灾，不能在发生突发事件时，在特定的时间（RTO）要求内，能够全
30、部或部分恢复关键业务功能；一种是双机备份共享存储（以下简称本地HA）方式，该方式主要用于系统核心层。对于系统核心层采用的本地HA模式来保障业务连续性，存在如下风险：1) 由于核心系统IO量较大，如发生系统单节点宕机等严重故障可能会造成由于IO未及时写入磁盘而产生的文件系统错误，导致备机启动失败。2) 人为因素、数据库逻辑错误或者存储故障造成的数据损坏从而引起业务中断，本地HA将无法解决。NG-CRM/BOSS系统全部业务要求724小时运行，存储阵列的使用强度大大增加，没有时间对存储系统进行定期维修和保养。因此，当使用一段时间后，存储系统的部件连续或同时出现故障的可能性增加。此外，随着存储系统的
31、功能和性能越来越强，存储系统内部的控制软件也日趋复杂，就像一个操作系统，其本身也会出现故障或漏洞。部分省公司也曾经发生过由于存储故障造成业务系统长时间停机、数据丢失的重大故障。3) 在系统割接、平台软硬件维护或应用版本升级等情况下，本地HA都将可能无法满足业务连续性要求。4) 生产机房发生火灾、泡水等情况下，多节点负载分担和本地HA模式都不能保障业务连续性。2.1.5风险应对措施针对上述系统风险，可以通过应急系统的建设加以规避，以提高关键业务连续运行能力。应急系统是本地HA、多节点负载分担等业务连续保障模式的轻量级补充，可实现关键业务的快速恢复。本地HA是系统核心层的整体恢复体系，通过启动HA
32、可以全面接管核心层生产系统。多节点负载分担可以在生产机房未发生火灾等情况下，确保业务连续性。归纳起来，主要有两种情况下须进行生产系统至应急系统的切换：一种是主动应急，生产系统进行平台版本升级、应用版本上线、软硬件更换、数据库扩容等例行维护工作情况下，为了保障关键业务连续性，需要将生产系统切换到应急系统。一种是被动应急，生产系统的关键业务发生故障而且故障修复时间大于30分钟的情况下，生产系统应切换到本地应急系统。具体如下：1) 人为或数据库逻辑等因素引起的数据损坏：数据库的逻辑错误或人为的操作失误可能会导致生产中心关键系统数据库均不可用，在此情况下须启用应急系统。2) 应用版本升级场景：目前NG
33、-CRM/BOSS系统有稳定的新业务上线流程，在上线前有着严格的测试流程。但是由于NG-CRM/BOSS业务关联性强，前期的测试有可能没有覆盖所有的业务流程。上线后，可能造成系统运行不稳定或者部分业务受理结果不正确。在此情况下，必须采取措施，避免错误继续扩大，同时需要回退更新。3) 前台业务受理中断场景：由于系统硬件、软件、网络故障导致实体、电子渠道业务受理中断，引起客户投诉与抱怨，为了降低客户投诉率，可以切换至应急系统满足关键业务的连续性受理。4) 系统割接场景：在进行系统割接时，为了不影响用户满意度以及集团的考核，可以切换到应急系统来满足关键业务的连续性。（如：自动台的余额查询、空中充值等
34、）。5) 硬件维护场景：在系统维护过程中，可能会出现IBM/SUN/HP主机、网络设备、存储设备硬件维护或硬件微码升级的情况，可以切换到应急系统来保证关键业务的连续性。（如：IBM/SUN/HP 硬件更换）。6) 平台软件维护场景：在系统维护过程中，可能会出现数据库需要补丁升级需要重启等情况，可以切换到应急系统来保证关键业务的连续性。（如：ORACLE/TEXUDO/WEBLOGIC软件补丁升级）。7) 前台业务受理中断场景：由于系统硬件、软件、网络故障导致实体、电子渠道业务受理中断，引起客户投诉与抱怨，为了降低客户投诉率，可以切换至应急系统满足关键业务的连续性受理。8) 生产机房发生火灾或泡
35、水情况2.2 应急建设需求2.2.1业务建设范围应急系统基础建设阶段包括渠道及主要功能如下：2.2.1.1营业前台应急功能在生产系统切换至应急系统后，营业前台渠道应支持如下表格2.2.1.1-1所示的业务受理、信息查询及其他辅助功能。表2.2.1.1-1 营业前台应急功能表业务功能功能域功能说明备注开户业务受理可为客户建立档案、开通客户订购的移动服务及客户付费信息充值 业务受理可为用户进行充值的服务充值应至少包括：前台现金充值、充值卡充值、空中充值三种。缴费业务受理可为用户进行缴费服务停复机业务受理可为用户提供停机、复机的服务补换卡业务受理可实现对SIM卡的写卡处理，实现IMSI码与ICCID
36、码绑定，同时开通鉴权服务用户资料查询信息查询可查询用户的准实时资料，如姓名、证件号码等信息余额查询信息查询查询用户余额准实时数据信息积分查询信息查询可查询用户的准实时积分值信息账单查询信息查询可查询用户的准实时消费账单信息PUK码查询信息查询可为用户提供查询PUK码的服务家庭充值/缴费业务受理可为家庭用户提供充值或缴费服务集团充值/缴费业务受理可为集团用户提供充值或缴费服务套餐变更业务受理可为用户提供各类产品套餐的变更服务营销方案业务受理可为用户提供营销方案的办理及撤销服务号源查询信息查询可提供号源的查询服务亲情组合及查询信息查询可为用户提供亲情号码组合受理及查询服务用户订购信息查询信息查询可
37、提供用户的营销方案、已开通业务、附加功能、增值业务、梦网业务、自有业务、国际功能的查询服务查询GPRS流量信息查询可查询用户准实时的GPRS流量信息清单查询信息查询可查询用户准实时的清单信息2.2.1.2客服系统应急功能在生产系统切换至应急系统后，客服系统应提供如下表格2.2.1.2-1所示的基本业务及用户信息资料查询功能。表2.2.1.2-1 客服系统应急功能表业务功能渠道功能域功能说明备注密码校验人工台/自动台信息查询可对用户输入的密码进行正确性校验用户资料查询人工台/自动台信息查询可查询用户的准实时资料信息余额查询人工台/自动台信息查询查询用户余额准实时数据信息积分查询人工台/自动台信息
38、查询可查询用户的准实时积分值信息申请停复机人工台业务受理可为用户提供停机、复机的服务用户订购信息查询人工台信息查询可提供用户的营销方案、已开通业务、附加功能、增值业务、梦网业务、自有业务、国际功能的查询服务账单查询人工台信息查询可查询用户的消费准实时账单信息PUK码查询人工台信息查询可为用户提供查询PUK码的服务亲情组合及查询人工台业务受理可为用户提供亲情号码组合受理及查询服务查询GPRS流量人工台信息查询可查询用户准实时的GPRS流量信息清单查询人工台信息查询可查询用户准实时的清单信息套餐变更人工台业务受理可提供为用户办理套餐产品变更的服务查询有效期自动台信息查询可查询账户余额的有效期时间信
39、息话费查询自动台信息查询可查询用户话费准实时信息欠费信息查询自动台信息查询可查询用户欠费准实时信息2.2.1.3电子渠道应急功能2.2.1.3.1网上营业厅网上营业厅在生产系统切换至应急系统后，可支持如下表格2.2.1.3.1-1所示的业务受理、信息查询及其他辅助功能。表2.2.1.3.1-1 网上营业厅应急功能表业务功能功能域功能说明密码验证业务受理可对用户输入的密码进行正确性校验用户资料查询信息查询可查询用户的准实时资料，如姓名、证件号码等信息余额查询信息查询查询用户余额准实时数据信息查询GPRS流量信息查询可查询用户准实时的GPRS流量信息账单查询信息查询可查询用户的消费准实时账单信息清
40、单查询信息查询可查询用户准实时的清单信息网上充值卡充值业务受理可支持网上营业厅通过充值卡进行充值的服务停复机业务受理可为用户提供停机、复机的服务套餐变更业务受理可为用户提供各类产品套餐的变更服务亲情组合及查询业务受理可为用户提供亲情号码组合受理及查询服务用户订购信息查询信息查询可提供用户的营销方案、已开通业务、附加功能、增值业务、梦网业务、自有业务、国际功能的查询服务PUK码查询信息查询可为用户提供查询PUK码的服务2.2.1.3.2掌上营业厅掌上营业厅在生产系统切换至应急系统后，可支持如下表格2.2.1.3.2-1所示的业务受理、信息查询及其他辅助功能。表2.2.1.3.2-1 掌上营业厅应
41、急功能表业务功能功能域功能说明密码验证业务受理可对用户输入的密码进行正确性校验用户资料查询信息查询可查询用户的准实时资料，如姓名、证件号码等信息余额查询信息查询查询用户余额准实时数据信息查询GPRS流量信息查询可查询用户准实时的GPRS流量信息账单查询信息查询可查询用户的消费准实时账单信息清单查询信息查询可查询用户准实时的清单信息网上充值卡充值业务受理可支持网上营业厅通过充值卡进行充值的服务停复机业务受理可为用户提供停机、复机的服务套餐变更业务受理可为用户提供各类产品套餐的变更服务亲情组合及查询业务受理可为用户提供亲情号码组合受理及查询服务用户订购信息查询信息查询可提供用户的营销方案、已开通业
42、务、附加功能、增值业务、梦网业务、自有业务、国际功能的查询服务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) 网络正常而
