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

摘 要目前中国移动集团天津公司NG-CRM/BOSS系统的业务连续性保障体系有三种模式，一种是多节点负荷分担方式，该方式主要用于系统接入层和业务逻辑层，有效地降低了个别节点故障对业务的影响程度；一种是容灾模式，由于多年未升级，系统资源与生产中心已不匹配，在发生突发事件时，容灾系统不能在特定的时间要求内全部或部分恢复关键业务功能；一种是双机备份共享存储（以下简称本地HA）方式，该方式主要用于系统核心层。对于系统核心层采用的本地HA模式来保障业务连续性，存在如下风险：1)由于核心系统IO量较大，如发生系统单节点宕机等严重故障可能会造成由于IO未及时写入磁盘而产生的文件系统错误，导致备机启动失败。2)人为因素、数据库逻辑错误或者存储故障造成的数据损坏从而引起业务中断，本地HA将无法解决。NG-CRM/BOSS系统全部业务要求724小时运行，存储阵列的使用强度大大增加，没有时间对存储系统进行定期维修和保养。因此，当使用一段时间后，存储系统的部件连续或同时出现故障的可能性增加。此外，随着存储系统的功能和性能越来越强，存储系统内部的控制软件也日趋复杂，就像一个操作系统，其本身也会出现故障或漏洞。部分省公司也曾经发生过由于存储故障造成业务系统长时间停机、数据丢失的重大故障。3)在系统割接、平台软硬件维护或应用版本升级等情况下，本地HA都将可能无法满足业务连续性要求。4)生产机房发生火灾、泡水等情况下，多节点负载分担和本地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, 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第一章 绪论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接管时间要求152.2.3应急数据同步152.2.3应急数据回切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.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短信营业厅应用切换场景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 研究背景中国移动业务支撑系统经过近几年的集中化改造建设和不断完善，经过NGBOSS（新一代业务运营支撑系统）建设，业务支撑系统已经在市场拓展、客户服务等工作中发挥了重要的支撑作用，成为中国移动贯彻落实“服务与业务领先”战略的有力手段。日益激烈的市场竞争和不断提高的客户服务质量需求对BOSS业务支撑能力和可靠稳定运行的要求越来越高，从面向客户服务的角度而言，无论何时出现何种情况，都需要移动运营商提供不间断的业务支撑服务，以保证客户满意度、客户服务质量、企业信誉等不受影响，对企业而言也可避免财务损失，增强企业竞争力。与此同时，BOSS集中化改造、NGBOSS一阶段和二阶段建设在带来业务快速响应等众多优势的同时，也存在着系统故障点集中、风险集中的危险，如：系统故障、人为误操作、火灾、水灾、传输中断、电网停电等系统风险。因此，适时、合理地规划和开展中国移动业务运营支撑系统应急保障体系建设，已经成为中国移动的重要任务。1.2 研究目的及意义为保证业务持续运营，NGBOSS系统已经在系统架构上充分考虑其可靠性。NG-CRM/BOSS系统的关键应用系统的服务器都进行了高可靠性（HA）设计，杜绝了单点故障导致业务中断。在本地高可靠性的基础上，为了在出现灾难情况时（如地震、水灾、火灾、瘟疫、人为灾难故障），能够有效对系统和应用进行恢复，NGBOSS系统还建立了容灾备份系统，实现了数据及应用的容灾。但是，在某些故障（如：数据库磁盘故障、软件错误等）发生时，HA并不能解决问题，同时由于这些故障预计能够在短时间内（4小时以内）能够解决，因此并没有必须进行容灾切换。在这种情况下，运营商需要有一个应急系统，能够支持短时间的关键业务的运营生产，保证客户感受不到业务的中断。通过业务支撑应急系统的建设，建立业务支撑网的应急风险预防、应急响应机制和恢复措施，保证在发生突发事件时，能够在特定的时间要求内，能够全部或部分恢复关键业务功能，提高关键业务连续运行能力，提升服务质量和服务水平，并降低运营风险，将业务损失降低到可接受的程度，以增强企业竞争力。1.3研究的主要内容及论文结构本文主要是针对天津移动业务支撑应急系统技术方案的研究，通过对现状的分析，确认系统建设范围，设计系统功能及技术架构以完成整体的建设方案。并且通过对应急场景的归纳总结，保证方案的可实施性和有效性。论文主要分为以下章节：第一章绪论，介绍了天津移动业务支撑应急系统的必要性和需解决的问题，提出了本文的研究内容及意义。第二章对目前天津移动业务支撑系统的现状分析，确认建设方向、建设范围及具体内容。第三章对天津移动业务支撑应急系统技术研究及选型。第四章介绍天津移动业务支撑应急系统的建设方案，包括系统架构设计、功能架构设计、各模块设计、数据流设计、部署方案等。第五章为天津移动业务支撑应急系统的应急场景的分析和确定，包含各子系统的应急场景及相关流程，为项目建设提供了验证依据。第六章为天津移动业务支撑应急系统演练方案及演练总结。第七章为结论与展望，对论文工作进行了总结，展示了本系统开发的主要成果及丞待完善的方面。130第二章天津移动业务支撑系统现状分析及应急建设需求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）生产中心BOSS系统1计费数据库Cluster11P595F102.3482账务数据库Cluster11122.3723账务应用 Cluster11402.33404连指122.3165计费数据库Cluster21P595G102.3486账务数据库Cluster21122.3727账务应用Cluster21402.33608连指122.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.912813一级BOSS（落地方）2161.93614电子渠道WEB服务器181.94815ESOP2181.94816客服APP2181.96417CRM TUX21P595C162.312818接口TUX1142.36419统一接入平台1102.36420CRM数据库Cluster11242.312821CRM TUX11P595D162.312822接口TUX1142.36423统一接入平台1102.36424CRM数据库Cluster21242.312825一级BOSS（平台，发起方）1P595E82.34826BPM、容错探针1122.39627Crm/actdb测试1162.312828客服DB11102.38029pbossdb182.36430topteadb1P595F22.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系统存储配置情况表磁盘阵列系统划分序号设备型号数量(套)磁盘配置裸容量(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光纤口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系统网络设备配置情况表序号设备名称或型号数量主要配置及说明备注1Catalyst6509交换机2分别配置2x48个10/100 Base-T电口，2x16个千兆光口，1个48口千兆光口。移通20楼，核心2Catalyst6509交换机2分别配置2x48个10/100 Base-T电口，2x16个千兆光口，1个48口千兆光口。南开工业园，核心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个18口光口板卡移通20楼6Catalyst4506交换机2分别配置1个控制卡（含2个光口）、1x6口GE卡，1个2GE+32口10/100M板卡，1个18口光口板卡南开工业园7NOKIA IP1260千兆防火墙2分别配置2个双端口千兆卡移通20楼8NOKIA 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系统全部业务要求724小时运行，存储阵列的使用强度大大增加，没有时间对存储系统进行定期维修和保养。因此，当使用一段时间后，存储系统的部件连续或同时出现故障的可能性增加。此外，随着存储系统的功能和性能越来越强，存储系统内部的控制软件也日趋复杂，就像一个操作系统，其本身也会出现故障或漏洞。部分省公司也曾经发生过由于存储故障造成业务系统长时间停机、数据丢失的重大故障。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业务建设范围应急系统基础建设阶段包括渠道及主要功能如下：营业前台应急功能在生产系统切换至应急系统后，营业前台渠道应支持如下表格-1所示的业务受理、信息查询及其他辅助功能。表-1 营业前台应急功能表业务功能功能域功能说明备注开户业务受理可为客户建立档案、开通客户订购的移动服务及客户付费信息充值 业务受理可为用户进行充值的服务充值应至少包括：前台现金充值、充值卡充值、空中充值三种。缴费业务受理可为用户进行缴费服务停复机业务受理可为用户提供停机、复机的服务补换卡业务受理可实现对SIM卡的写卡处理，实现IMSI码与ICCID码绑定，同时开通鉴权服务用户资料查询信息查询可查询用户的准实时资料，如姓名、证件号码等信息余额查询信息查询查询用户余额准实时数据信息积分查询信息查询可查询用户的准实时积分值信息账单查询信息查询可查询用户的准实时消费账单信息PUK码查询信息查询可为用户提供查询PUK码的服务家庭充值/缴费业务受理可为家庭用户提供充值或缴费服务集团充值/缴费业务受理可为集团用户提供充值或缴费服务套餐变更业务受理可为用户提供各类产品套餐的变更服务营销方案业务受理可为用户提供营销方案的办理及撤销服务号源查询信息查询可提供号源的查询服务亲情组合及查询信息查询可为用户提供亲情号码组合受理及查询服务用户订购信息查询信息查询可提供用户的营销方案、已开通业务、附加功能、增值业务、梦网业务、自有业务、国际功能的查询服务查询GPRS流量信息查询可查询用户准实时的GPRS流量信息清单查询信息查询可查询用户准实时的清单信息客服系统应急功能在生产系统切换至应急系统后，客服系统应提供如下表格-1所示的基本业务及用户信息资料查询功能。表-1 客服系统应急功能表业务功能渠道功能域功能说明备注密码校验人工台/自动台信息查询可对用户输入的密码进行正确性校验用户资料查询人工台/自动台信息查询可查询用户的准实时资料信息余额查询人工台/自动台信息查询查询用户余额准实时数据信息积分查询人工台/自动台信息查询可查询用户的准实时积分值信息申请停复机人工台业务受理可为用户提供停机、复机的服务用户订购信息查询人工台信息查询可提供用户的营销方案、已开通业务、附加功能、增值业务、梦网业务、自有业务、国际功能的查询服务账单查询人工台信息查询可查询用户的消费准实时账单信息PUK码查询人工台信息查询可为用户提供查询PUK码的服务亲情组合及查询人工台业务受理可为用户提供亲情号码组合受理及查询服务查询GPRS流量人工台信息查询可查询用户准实时的GPRS流量信息清单查询人工台信息查询可查询用户准实时的清单信息套餐变更人工台业务受理可提供为用户办理套餐产品变更的服务查询有效期自动台信息查询可查询账户余额的有效期时间信息话费查询自动台信息查询可查询用户话费准实时信息欠费信息查询自动台信息查询可查询用户欠费准实时信息电子渠道应急功能.1网上营业厅网上营业厅在生产系统切换至应急系统后，可支持如下表格.1-1所示的业务受理、信息查询及其他辅助功能。表.1-1 网上营业厅应急功能表业务功能功能域功能说明密码验证业务受理可对用户输入的密码进行正确性校验用户资料查询信息查询可查询用户的准实时资料，如姓名、证件号码等信息余额查询信息查询查询用户余额准实时数据信息查询GPRS流量信息查询可查询用户准实时的GPRS流量信息账单查询信息查询可查询用户的消费准实时账单信息清单查询信息查询可查询用户准实时的清单信息网上充值卡充值业务受理可支持网上营业厅通过充值卡进行充值的服务停复机业务受理可为用户提供停机、复机的服务套餐变更业务受理可为用户提供各类产品套餐的变更服务亲情组合及查询业务受理可为用户提供亲情号码组合受理及查询服务用户订购信息查询信息查询可提供用户的营销方案、已开通业务、附加功能、增值业务、梦网业务、自有业务、国际功能的查询服务PUK码查询信息查询可为用户提供查询PUK码的服务.2掌上营业厅掌上营业厅在生产系统切换至应急系统后，可支持如下表格.2-1所示的业务受理、信息查询及其他辅助功能。表.2-1 掌上营业厅应急功能表业务功能功能域功能说明密码验证业务受理可对用户输入的密码进行正确性校验用户资料查询信息查询可查询用户的准实时资料，如姓名、证件号码等信息余额查询信息查询查询用户余额准实时数据信息查询GPRS流量信息查询可查询用户准实时的GPRS流量信息账单查询信息查询可查询用户的消费准实时账单信息清单查询信息查询可查询用户准实时的清单信息网上充值卡充值业务受理可支持网上营业厅通过充值卡进行充值的服务停复机业务受理可为用户提供停机、复机的服务套餐变更业务受理可为用户提供各类产品套餐的变更服务亲情组合及查询业务受理可为用户提供亲情号码组合受理及查询服务用户订购信息查询信息查询可提供用户的营销方案、已开通业务、附加功能、增值业务、梦网业务、自有业务、国际功能的查询服务PUK码查询信息查询可为用户提供查询PUK码的服务.3短信营业厅短信营业厅在生产系统切换至应急系统后，可支持如下表格.3-1所示的业务受理、信息查询及其他辅助功能。表.3-1 短信营业厅应急功能表业务功能功能域功能说明密码验证业务受理可对用户输入的密码进行正确性校验用户资料查询信息查询可查询用户的准实时资料，如姓名、证件号码等信息余额查询信息查询查询用户余额准实时数据信息查询GPRS流量信息查询可查询用户准实时的GPRS流量信息账单查询信息查询可查询用户的消费准实时账单信息清单查询信息查询可查询用户准实时的清单信息网上充值卡充值业务受理可支持网上营业厅通过充值卡进行充值的服务停复机业务受理可为用户提供停机、复机的服务套餐变更业务受理可为用户提供各类产品套餐的变更服务亲情组合及查询业务受理可为用户提供亲情号码组合受理及查询服务用户订购信息查询信息查询可提供用户的营销方案、已开通业务、附加功能、增值业务、梦网业务、自有业务、国际功能的查询服务PUK码查询信息查询可为用户提供查询PUK码的服务网络中断网络中断业务受理流程：1) 在网络出现问题时，应急系统只在本机进行缴费信息的记录，生成缴费记录文件，不做任何后续操作；2) 网络正常而生产系统未恢复时，执行应急缴费提交，根据配置的应急系统缴费流程，完成相关应急操作；3) 生产系统正常后，同步应急数据到生产系统。如图-1所示：图 1 网络中断业务受理流程图辅助功能除以上提及的影响用户的业务应急功能之外，为了更加的完善应急系统的支撑能力，应急系统应提供如下表格-1所示的基础辅助功能。如下表所示：表-1辅助功能表业务功能渠道功能域功能说明备注应急业务流水查询人工台信息查询可查询到应急系统中受理业务的应急流水信息(含操作员、受理时间、业务套餐等信息)公告营业前台、客服系统、电子渠道信息发布通知对用户的解释口径，影响范围等信息短信发送营业前台、客服系统、电子渠道信息发布在应急系统中受理业务，给用户发送短信模板需与生产系统中有所区别，提前告知用户业务的生效时间以正式短信内容为准。2.2.2接管时间要求应急系统的数据是生产系统以准实时的方式同步，应急系统在接收到应急切换命令后，30分钟内能完全接管定义好的生产系统的关键业务。2.2.3应急数据同步为支持应急系统的业务受理，应急系统需要从生产系统中复制以下数据：1) CRM数据库 业务参数及系统参数 客户资料 用户资料 帐户资料 付费关系 资源资料 。2) 客服数据库 工号信息 。3) 帐务管理数据库 业务参数及系统参数 三户资料 实时余额信息 存折信息 积分信息 。4) 计费数据库 实时账单信息 实时清单信息 。CRM数据库、客服数据库和帐务管理数据库中的数据，采用第三方软件（DSG realsync/Oracle goldengate/QUEST shareplex等）将应急业务需要的相关数据准实时从生产系统同步到应急系统。计费数据库中的数据通过应用改造的方式来同步，生产系统生成一份账单文件和清单文件送到应急系统，应急系统使用入库进程入到应急数据库中，保证两个系统的数据一致性。2.2.3应急数据回切在生产系统恢复后，应急系统需要把故障期间的业务受理数据提交到生产系统。同时服务开通工单表（日志）也需要合并到BOSS生产系统。应急交易数据提交需要将应急期间的业务受理交易数据和缴费交易提交到BOSS生产系统。应急交易数据提交需要对提交流量进行控制，避免对恢复后的生产系统正常处理产生影响。同时需要标识应急交易提交中发生错误的交易，供人工核对处理。对业务受理交易，将订单及台帐相关数据搬到生产系统，重跑相关订单，因资料修改并不是完全在完工流程中完成，有部分业务在登记时已经修改，需要改造现有的完工流程，增加修改资料的环节，且回切业务不需要发指令。对缴费类交易，应急系统发生的缴费相关数据导到ACT生产库，其中预存、结余数据需要更新到账务物理库和altibase。对查询类业务，还需要将相关日志，台帐等导到生产系统，以便后续的查询。2.2.3应急系统管理功能1) 应急系统版本管理对应急系统软件的版本进行检查、监控，记录生产系统与应急系统软件配置文件和运行环境参数的差异，保证应急系统可执行代码与生系统同步升级，并记录应用软件版本升级轨迹。主要包括版本注册、版本一致性检查、版本更新控制、版本发布管理、版本更新等内容。通过应急系统建立版本管理机制，自动完成生产系统、应急系统相应环境配置、软件版本号、软件更新日期等信息比对，对版本差异进行告警发送，提醒维护人员及时进行关注并处理。2) 应急系统数据管理为保证应急系统在必要的时候能够及时接管生产系统，应急系统与生产系统的数据需保持一致性、完整性，应在应急系统中建立起与生产系统的数据同步审查机制，并通过数据核对帮助生产系统发现可能出现的问题，进一步完善和优化生产系统和应急系统。应急系统数据管理主要包括：稽核配置管理、数据采集管理、数据比对管理、数据同步管理。对各数据管理各功能模块异常状态进行监控，异常时进行告警发送，提醒维护人员及时进行关注并处理。3) 应急系统切换管理包括对应急系统组织、人员、角色、权限的管理，明确应急系统组织架构，确保应急系统切换过程的有序进行。收到切换指令后自动修改或人工修改接口地址并测试，保证应急系统能够正常运行。生产系统恢复正常后，需要进行回切操作。切换管理系统主要包括：人员管理、权限管理、切换管理、回切管理。根据应急系统组织机构，对不同的人员角色赋予不同的权限，要求管理平台界面化展示当前状态，操作人员实施一键式切换和回切操作，避免人为操作失误带来的切换风险。4) 应急系统演习管理负责规划应急系统应急演习的相关流程与任务，通过系统切换和系统回切的操作，验证应急系统可用性和可靠性。5) 应急系统监控管理实时监控应急系统的所有设备是否处于健康状态，监控应急系统软件的关键点，建立故障告警机制，保证应急系统的可用性。（需要和Toptea/BOMC进行分工）。6) 应急系统公告管理告知应急切换原因，预计恢复时间，对用户的解释口径。第三章天津移动业务支撑应急系统技术研究233.1 持续数据保护技术(CDP)3.1.1定义持续数据保护(CDP)是一套技术手段，它可以捕获或跟踪数据的变化，并将其独立存放在生产数据之外，以确保数据可以恢复到过去的任意时间点。持续数据保护系统可以基于块、文件或应用实现，可以为恢复对象提供足够细的恢复粒度，实现几乎无限多的恢复时间点。3.1.2与现有数据保护手段对比CDP出现，是为有效弥补传统数据容灾保护手段不足而产生的。 CDP VS传统备份传统的数据保护解决方案专注在对数据的周期性备份上，因此一直伴随有备份窗口、数据一致性和对生产系统的影响等问题。实际上，传统数据保护技术中采用的是对“单一时间点（Single Point-In-Time）”的数据拷贝进行管理的模式，而CDP可以实现对“任意时间点（Any Point-In-Time）”的数据访问，因此可以大大提高数据恢复点目标（RPO）。备份技术实现的数据保护间隔一般为24小时，因此用户会面临数据丢失多达24小时的风险，采用快照技术，可以将数据的丢失量风险降低到几个小时之内，而CDP能够实现的数据丢失量可以降低到秒级。 CDP VS数据复制 （磁盘镜像）另外一种在数据容灾中常见的数据保护技术是复制技术，它可以通过与生产数据的同步获得数据的最新状态，但其无法规避有人为的逻辑错误或病毒攻击所造成的数据丢失。当生产数据由于以上原因导致数据遭到破坏时（例如数据被误删除），复制技术会将遭到破坏的数据状态同步到容灾数据存储，使容灾数据也受到破坏。而CDP系统可以使数据状态恢复到数据遭到破坏之前的任意一个时间点，因而消除了复制技术所含的风险。3.1.3总结为了保障业务支撑应急系统能够支持短时间的关键业务的运营生产，本系统选择持续数据保护(CDP)技术进行建设。3.2 基于J2EE的多层技术架构3.2.1J2EE技术介绍J2EE是Java2平台企业版（Java 2 Platform,Enterprise Edition）。J2EE核心是一组技术规范与指南，其中所包含的各类组件、服务