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

天津移动业务支撑应急系统设计与实现DESIGNANDIMPLEMENTATIONTOTIANJINCMCCNGCRM/BOSSEMERGENCYSYSTEM领域计算机技术研究生李珅指导教师窦友众企业导师张根泉天津大学软件学院二零一三年三月独创性声明本人声明所呈交的学位论文是本人在导师指导下进行的研究工作和取得的研究成果，除了文中特别加以标注和致谢之处外，论文中不包含其他人已经发表或撰写过的研究成果，也不包含为获得天津大学或其他教育机构的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均已在论文中作了明确的说明并表示了谢意。学位论文作者签名签字日期年月日学位论文版权使用授权书本学位论文作者完全了解天津大学有关保留、使用学位论文的规定。特授权天津大学可以将学位论文的全部或部分内容编入有关数据库进行检索，并采用影印、缩印或扫描等复制手段保存、汇编以供查阅和借阅。同意学校向国家有关部门或机构送交论文的复印件和磁盘。（保密的学位论文在解密后适用本授权说明）学位论文作者签名导师签名签字日期年月日签字日期年月日摘要目前中国移动集团天津公司NGCRM/BOSS系统的业务连续性保障体系有三种模式，一种是多节点负荷分担方式，该方式主要用于系统接入层和业务逻辑层，有效地降低了个别节点故障对业务的影响程度；一种是容灾模式，由于多年未升级，系统资源与生产中心已不匹配，在发生突发事件时，容灾系统不能在特定的时间要求内全部或部分恢复关键业务功能；一种是双机备份共享存储（以下简称本地HA）方式，该方式主要用于系统核心层。对于系统核心层采用的本地HA模式来保障业务连续性，存在如下风险1由于核心系统IO量较大，如发生系统单节点宕机等严重故障可能会造成由于IO未及时写入磁盘而产生的文件系统错误，导致备机启动失败。2人为因素、数据库逻辑错误或者存储故障造成的数据损坏从而引起业务中断，本地HA将无法解决。NGCRM/BOSS系统全部业务要求724小时运行，存储阵列的使用强度大大增加，没有时间对存储系统进行定期维修和保养。因此，当使用一段时间后，存储系统的部件连续或同时出现故障的可能性增加。此外，随着存储系统的功能和性能越来越强，存储系统内部的控制软件也日趋复杂，就像一个操作系统，其本身也会出现故障或漏洞。部分省公司也曾经发生过由于存储故障造成业务系统长时间停机、数据丢失的重大故障。3在系统割接、平台软硬件维护或应用版本升级等情况下，本地HA都将可能无法满足业务连续性要求。4生产机房发生火灾、泡水等情况下，多节点负载分担和本地HA模式都不能保障业务连续性。本文将从应急系统的系统架构、建设实现、系统测试各方面对于上述风险及问题进行研究并逐一解决。关键词业务支撑系统应急系统运营商ABSTRACTATPRESENTTHETIANJINNGCRM/BOSSBUSINESSCONTINUITYSECURITYSYSTEMHASTHREEMODES,ONEISAMULTINODELOADBALANCINGMODE,THISMODEISMAINLYUSEDFORSYSTEMACCESSLAYERANDBUSINESSLOGIC,EFFECTIVELYREDUCINGTHEINDIVIDUALNODEFAILURESTHEDEGREEOFINFLUENCEOFTHEBUSINESSADISASTERRECOVERYMODE,DUETOYEARSOFNOTUPGRADED,THESYSTEMRESOURCESANDPRODUCTIONCENTERDOESNOTMATCH,NOTWITHINASPECIFICTIMEREQUIREMENTSINWHOLEORINPART,TORESTORECRITICALBUSINESSFUNCTIONSINTHEEVENTOFANEMERGENCY,DISASTERRECOVERYSYSTEMADOUBLEBACKUPSHAREDSTORAGEHEREINAFTERREFERREDTOASTHELOCALHAMODE,WHICHISMAINLYUSEDFORTHECOREOFTHESYSTEMLAYERTHELOCALHAMODEFORTHESYSTEMCORELAYERTOPROTECTBUSINESSCONTINUITY,THEFOLLOWINGRISKS1DUETOTHELARGEAMOUNTOFCORESYSTEMIO,SUCHASTHEOCCURRENCEOFASERIOUSFAILUREOFTHESYSTEMSINGLENODEDOWNTIMEMAYCAUSEIOISNOTWRITTENTODISKFILESYSTEMERRORS,LEADINGTOTHEBACKUPMACHINEFAILEDTOSTART2DATACORRUPTIONCAUSEDBYHUMANFACTORS,DATABASELOGICERRORORSTORAGEFAILURECAUSINGBUSINESSINTERRUPTION,LOCALHAWILLNOTRESOLVEALLOFNGCRM/BOSSSYSTEMREQUIREMENTS724HOURSTORUN,GREATLYINCREASETHEINTENSITYOFUSEOFTHESTORAGEARRAY,DONOTHAVETIMEFORREGULARREPAIRANDMAINTENANCEOFTHESTORAGESYSTEMTHEREFORE,WHENUSEDFORAPERIODOFTIME,THECOMPONENTSOFTHESTORAGESYSTEMCONTINUOUSLYORATTHESAMETIMEINCREASETHEPROBABILITYOFFAILUREINADDITION,WITHTHEGROWINGFUNCTIONALITYANDPERFORMANCEOFSTORAGESYSTEMS,STORAGESYSTEMSWITHINTHECONTROLSOFTWAREAREBECOMINGINCREASINGLYCOMPLEX,ASANOPERATINGSYSTEM,WHICHITSELFWILLBEFAILUREORVULNERABILITYSOMEPROVINCESHAVEALSOUNDERGONEMAJORFAILUREOFTHEBUSINESSSYSTEMFORALONGTIMEDOWNTIME,DATALOSSDUETOASTORAGEFAILURE3INTHESYSTEMCUTOVER,PLATFORMHARDWAREANDSOFTWAREMAINTENANCEORAPPLICATIONUPGRADE,THELOCALHAMAYNOTBEABLETOMEETTHEREQUIREMENTSOFBUSINESSCONTINUITY4PRODUCTIONENGINEROOMFIRE,FLOODDAMAGEANDOTHERCIRCUMSTANCES,MULTINODELOADBALANCINGANDTHELOCALHAMODECANNOTGUARANTEEBUSINESSCONTINUITYFROMTHEEMERGENCYSYSTEMARCHITECTURE,CONSTRUCTION,IMPLEMENTATION,SYSTEMTESTINGALLASPECTSOFTHERISKSANDPROBLEMSANDSOLVETHEMONEBYONEKEYWORDSNGCRM/BOSS,EMERGENCYSYSTEM,TELECOMOPERATORS目录目录4第一章绪论111研究背景112研究目的及意义113研究的主要内容及论文结构2第二章天津移动业务支撑系统现状分析及应急建设需求321系统现状及风险分析3211功能现状3212软硬件配置现状4213网络组织现状6214风险分析8215风险应对措施922应急建设需求11221业务建设范围11222接管时间要求15223应急数据同步15223应急数据回切16223应急系统管理功能17第三章天津移动业务支撑应急系统技术研究1931持续数据保护技术CDP19311定义19312与现有数据保护手段对比19313总结2032基于J2EE的多层技术架构20321J2EE技术介绍20322J2EE四层模型20323J2EE结构223243J2EE优势24325J2EE和NET体系结构比较26326总结29第四章天津移动业务支撑应急系统的建设方案3041应急系统定位3042应急系统与外围系统边界3343应急系统目标3444应急系统架构35441功能架构36442数据流设计41443物理部署47444外围接口切换48445应急系统安全设计48446数据模型设计4945应急系统建设方案51451应急受理子系统51452应急管理平台系统7246应急系统硬件及平台软件建设方案79461硬件平台方案79462硬件配置方案和应用部署图85463网络环境87464系统软件87第五章天津移动业务支撑应急系统应急场景的分析和确定8951应急场景89511应用分析89512分业务分析94513针对风险点的应急分析9452建设场景95521正常场景95522场景1网上营业厅应用切换场景96523场景2短信营业厅应用切换场景98524场景3联指应用切换场景100525场景4客服应用切换场景103526场景5外围接口应用切换场景105527场景6统一接入应用切换场景107528场景7CRM应用全切场景109529场景8全切场景112第六章天津移动业务支撑应急系统演练11661演练场景11662演练范围11663演练流程116631生产系统切换到应急系统流程116632应急系统回切生产系统流程11964演练总结122第七章结论与展望125参考文献126发表论文和参加科研情况说明127致谢128第一章绪论11研究背景中国移动业务支撑系统经过近几年的集中化改造建设和不断完善，经过NGBOSS（新一代业务运营支撑系统）建设，业务支撑系统已经在市场拓展、客户服务等工作中发挥了重要的支撑作用，成为中国移动贯彻落实“服务与业务领先”战略的有力手段。日益激烈的市场竞争和不断提高的客户服务质量需求对BOSS业务支撑能力和可靠稳定运行的要求越来越高，从面向客户服务的角度而言，无论何时出现何种情况，都需要移动运营商提供不间断的业务支撑服务，以保证客户满意度、客户服务质量、企业信誉等不受影响，对企业而言也可避免财务损失，增强企业竞争力。与此同时，BOSS集中化改造、NGBOSS一阶段和二阶段建设在带来业务快速响应等众多优势的同时，也存在着系统故障点集中、风险集中的危险，如系统故障、人为误操作、火灾、水灾、传输中断、电网停电等系统风险。因此，适时、合理地规划和开展中国移动业务运营支撑系统应急保障体系建设，已经成为中国移动的重要任务。12研究目的及意义为保证业务持续运营，NGBOSS系统已经在系统架构上充分考虑其可靠性。NGCRM/BOSS系统的关键应用系统的服务器都进行了高可靠性（HA）设计，杜绝了单点故障导致业务中断。在本地高可靠性的基础上，为了在出现灾难情况时（如地震、水灾、火灾、瘟疫、人为灾难故障），能够有效对系统和应用进行恢复，NGBOSS系统还建立了容灾备份系统，实现了数据及应用的容灾。但是，在某些故障（如数据库磁盘故障、软件错误等）发生时，HA并不能解决问题，同时由于这些故障预计能够在短时间内（4小时以内）能够解决，因此并没有必须进行容灾切换。在这种情况下，运营商需要有一个应急系统，能够支持短时间的关键业务的运营生产，保证客户感受不到业务的中断。通过业务支撑应急系统的建设，建立业务支撑网的应急风险预防、应急响应机制和恢复措施，保证在发生突发事件时，能够在特定的时间要求内，能够全部或部分恢复关键业务功能，提高关键业务连续运行能力，提升服务质量和服务水平，并降低运营风险，将业务损失降低到可接受的程度，以增强企业竞争力。13研究的主要内容及论文结构本文主要是针对天津移动业务支撑应急系统技术方案的研究，通过对现状的分析，确认系统建设范围，设计系统功能及技术架构以完成整体的建设方案。并且通过对应急场景的归纳总结，保证方案的可实施性和有效性。论文主要分为以下章节第一章绪论，介绍了天津移动业务支撑应急系统的必要性和需解决的问题，提出了本文的研究内容及意义。第二章对目前天津移动业务支撑系统的现状分析，确认建设方向、建设范围及具体内容。第三章对天津移动业务支撑应急系统技术研究及选型。第四章介绍天津移动业务支撑应急系统的建设方案，包括系统架构设计、功能架构设计、各模块设计、数据流设计、部署方案等。第五章为天津移动业务支撑应急系统的应急场景的分析和确定，包含各子系统的应急场景及相关流程，为项目建设提供了验证依据。第六章为天津移动业务支撑应急系统演练方案及演练总结。第七章为结论与展望，对论文工作进行了总结，展示了本系统开发的主要成果及丞待完善的方面。第二章天津移动业务支撑系统现状分析及应急建设需求21系统现状及风险分析211功能现状BOSS系统主要包括产品管理、信息管理、融合计费、综合结算、综合帐务、采集预处理、服务开通、合作伙伴管理、基础管理等九大功能域，如下图2111所示。CRM经营分析系统BOS网管合作伙伴系统合作伙伴系统银行系统银行系统国内其他运营商国内其他运营商宽带PBOSADCSCPVCNMSMISOARADIUSBOS系统功能融合计费计费预处理计费引擎批价依据管理错单管理计费控制控制范围管理详单管理高额管理融合计费计费预处理计费引擎批价依据管理错单管理计费控制控制范围管理详单管理高额管理产品管理产品创建配置管理发布管理产品变更产品退出产品目录管理产品管理产品创建配置管理发布管理产品变更产品退出产品目录管理合作伙伴管理资质管理信息管理业务管理考核管理服务管理信息审核发布合作伙伴管理资质管理信息管理业务管理考核管理服务管理信息审核发布综合结算结算预处理数据分发结算报表处理重单检查对帐处理审核校验结算批价结算调帐错单回收处理结算帐务处理结算回退结算监管综合结算结算预处理数据分发结算报表处理重单检查对帐处理审核校验结算批价结算调帐错单回收处理结算帐务处理结算回退结算监管综合帐务帐务管理帐务处理信用管理积分管理综合帐务帐务管理帐务处理信用管理积分管理采集预处理采集预处理服务开通服务开通类定单管理工单管理开通与激活服务开通服务开通类定单管理工单管理开通与激活基础管理系统管理业务局数据管理数据一致性管理统计报表管理计费帐务稽核基础管理系统管理业务局数据管理数据一致性管理统计报表管理计费帐务稽核信息管理订购信息管理客户信息管理信息提供帐户信息管理用户信息管理信息接受与创建信息管理订购信息管理客户信息管理信息提供帐户信息管理用户信息管理信息接受与创建图2111BOSS系统功能架构图CRM系统主要包括渠道管理、市场营销、销售管理、客服服务、客服管理、产品管理、资源管理和基础管理等八大功能域。功能结构如下图2112所示。市场营销销售管理客户服务客户管理基础管理报表统计系统管理任务管理工作管理人员管理工单管理知识管理资源管理资源生命周期管理资源仓储管理资源信息管理营销活动管理营销信息管理销售活动管理商机管理销售文档管理订单管理服务请求管理客户维系管理客户信息管理帐户信息管理客户级别管理客户信用度管理特殊名单用户管理客户服务密码管理产品管理产品创建产品变更产品退出配置管理发布管理版本管理产品目录管理渠道基础平台呼叫中心基础平台经营分析系统宽带PBOSSBOSS中国移动外部系统外部合作伙伴BOSS总部客户/合作伙伴/业务管理者/营销人员/销售人员/客服人员省业务支撑网外部系统OAMIS业务支撑网网管系统客户信息视图CRM系统功能短信WAP彩信EMAIL营业终端DSMP渠道管理渠道运营支撑渠道运营管理门户自助终端资源调度管理图2112CRM系统功能结构图212软硬件配置现状BOSS/CRM生产中心配有8台满配置的IBMP595小型机，主机处理能力达到3420万TPMC，主机配置如下表表2121BOSS/CRM系统主机配置情况表单台设备配置情况系统划分序号主机名称数量（台）型号CPU数量CPU主频（GHZ）内存（GB）1计费数据库CLUSTER111023482账务数据库CLUSTER111223723账务应用CLUSTER1140233404连指1P595F223165计费数据库CLUSTER211023486账务数据库CLUSTER211223727账务应用CLUSTER2140233608连指1P595G223169连指服务器1P63021458BOSS系统10采集1P650B4145321OLCOM11B8022生产中心CR2网厅前置1P650C41458系统划分序号主机名称数量（台）单台设备配置情况型号CPU数量CPU主频（GHZ）内存（GB）3DSMPWEB1P570A822304ESOP测试1P570B822305CRM前置1422206PB测试1P570C1222707CRMWEB2120191288一级BOSS（落地方）11619369电子渠道WEB服务器18194810ESOP118194811客服APP11P595A8196412CRMWEB11201912813一级BOSS（落地方）216193614电子渠道WEB服务器18194815ESOP218194816客服APP21P595B8196417CRMTUX21162312818接口TUX114236419统一接入平台110236420CRM数据库CLUSTER11P595C242312821CRMTUX11162312822接口TUX114236423统一接入平台110236424CRM数据库CLUSTER21P595D242312825一级BOSS（平台，发起方）18234826BPM、容错探针112239627CRM/ACTDB测试1162312828客服DB1110238029PBOSSDB1P595E8236430TOPTEADB1P595F2231631一级BOSS（数据指令）18234832服务开通112239633计费账务应用测试1162316034客服DB2110238035PBOSSAPP1P595H8236436NG编译18174837短信、充值营业厅18174838CRM开发181732M系统39营销/一致性1P690C81732系统划分序号主机名称数量（台）单台设备配置情况型号CPU数量CPU主频（GHZ）内存（GB）40CRM前置机18174841DSMPWEB18174842NG测试APP18172043历史数据库11P690D81740BOSS/CRM系统存储配置情况如下表所示。表2122BOSS/CRM系统存储配置情况表磁盘阵列系统划分序号设备型号数量套磁盘配置裸容量TB1IBMESS8001470BOSS系统2IBMDS83001780生产中心CRM系统3IBMDS83001410BOSS系统容灾中心CRM系统4IBMDS83001930磁带库系统划分序号设备型号数量套裸容量TB生产中心BOSS/CRM共用5IBMTS35841120容灾中心BOSS/CRM共用6IBMTS35841222SAN交换机系统划分序号设备型号数量台端口情况7IBMM482每台配有532个光纤端口8IBMM142每台配有516个光纤端口生产中心BOSS/CRM共用9IBMF325每台配有32个2BB/S光纤口213网络组织现状为了充分保证BOSS/CRM系统的安全、可靠性，目前BOSS/CRM系统网络共分为三层SAN存储层、核心网络层（内网）、接入网络层（外网DMZ）。其中，计费应用、帐务应用、CRM数据库、集中采集、测试、备份、统计分析、结算等核心服务器直接通过SAN交换机实现磁盘阵列、磁带库的存储和备份；计费应用、帐务应用、CRM数据库、集中采集、联机指令、测试、备份、统计分析、结算等核心服务器属于关键生产服务器，处于核心网络层，分别连接在移通大厦20层2台CATALYST6509核心内网交换机及移通大厦22层2台QUIDWAYS8505核心内网交换机上；考虑到系统的安全可靠性，把与外界联系紧密的服务器，如中间件、WEB、一级BOSS接口、DSMP接口、防病毒、认证、桌面管理系统、SOC服务器连接在IP1260防火墙上的DMZ区，即4台C4506交换机上；与OA、客服、采集、营业厅等系统的连接均通过异构防火墙连接在接入的CATALYST6509交换机上。接入交换机CATALYST6509（外网）、千兆防火墙IP1260、核心交换机CATALYST6509（内网）组成BOSS系统的高速数据通道，采用负荷分担的方式进行工作，确保系统稳定、可靠的运行。此外，随着世纪大道IT机房的启用，MIS、统一信息平台和经营分析系统将陆续搬迁至相应机房；目前在世纪大道机房设有4台CATALYST6509交换机，分别与移通大厦机房、南开工业园机房对应连接，实现信息化系统及经营分析系统与BOSS系统的互联。网络结构如下图所示。图2131BOSS及CRM系统网络结构图BOSS/CRM系统网络设备配置情况如下表所示。表2131天津公司BOSS/CRM系统网络设备配置情况表序号设备名称或型号数量主要配置及说明备注1CATALYST6509交换机2分别配置2X48个10/100BASET电口，2X16个千兆光口，1个48口千兆光口。移通20楼，核心2CATALYST6509交换机2分别配置2X48个10/100BASET电口，2X16个千兆光口，1个48口千兆光口。南开工业园，核心3CATALYST6509交换机2分别配置2X48个10/100BASET电口，2X16个千兆光口移通20楼，连接外网4CATALYST6509交换机2分别配置2X48个10/100BASET电口，1X16个千兆光口南开工业园，连接外网5CATALYST4506交换机2分别配置1个控制卡（含2个光口）、1X6口GE卡，1个2GE32口10/100M板卡，1个18口光口板卡移通20楼6CATALYST4506交换机2分别配置1个控制卡（含2个光口）、1X6口GE卡，1个2GE32口10/100M板卡，1个18口光口板卡南开工业园7NOKIAIP1260千兆防火墙2分别配置2个双端口千兆卡移通20楼8NOKIAIP1260千兆防火墙2分别配置2个双端口千兆卡南开工业园9华为S8505交换机2分别配置1个48口10/1000电口板卡，1个48口光口板卡移通22楼，核心214风险分析目前天津公司NGBOSS系统的业务连续性保障体系有三种模式，一种是多节点负荷分担方式，该方式主要用于系统接入层和业务逻辑层，有效地降低了个别节点故障对业务的影响程度；一种是磁带库、CDP和存储底层复制实现的数据级容灾（以下简称数据容灾）方式，该方式其实只是实现了系统中主要业务数据的备份，没有实现应用级容灾，不能在发生突发事件时，在特定的时间（RTO）要求内，能够全部或部分恢复关键业务功能；一种是双机备份共享存储（以下简称本地HA）方式，该方式主要用于系统核心层。对于系统核心层采用的本地HA模式来保障业务连续性，存在如下风险1由于核心系统IO量较大，如发生系统单节点宕机等严重故障可能会造成由于IO未及时写入磁盘而产生的文件系统错误，导致备机启动失败。2人为因素、数据库逻辑错误或者存储故障造成的数据损坏从而引起业务中断，本地HA将无法解决。NGCRM/BOSS系统全部业务要求724小时运行，存储阵列的使用强度大大增加，没有时间对存储系统进行定期维修和保养。因此，当使用一段时间后，存储系统的部件连续或同时出现故障的可能性增加。此外，随着存储系统的功能和性能越来越强，存储系统内部的控制软件也日趋复杂，就像一个操作系统，其本身也会出现故障或漏洞。部分省公司也曾经发生过由于存储故障造成业务系统长时间停机、数据丢失的重大故障。3在系统割接、平台软硬件维护或应用版本升级等情况下，本地HA都将可能无法满足业务连续性要求。4生产机房发生火灾、泡水等情况下，多节点负载分担和本地HA模式都不能保障业务连续性。215风险应对措施针对上述系统风险，可以通过应急系统的建设加以规避，以提高关键业务连续运行能力。应急系统是本地HA、多节点负载分担等业务连续保障模式的轻量级补充，可实现关键业务的快速恢复。本地HA是系统核心层的整体恢复体系，通过启动HA可以全面接管核心层生产系统。多节点负载分担可以在生产机房未发生火灾等情况下，确保业务连续性。归纳起来，主要有两种情况下须进行生产系统至应急系统的切换一种是主动应急，生产系统进行平台版本升级、应用版本上线、软硬件更换、数据库扩容等例行维护工作情况下，为了保障关键业务连续性，需要将生产系统切换到应急系统。一种是被动应急，生产系统的关键业务发生故障而且故障修复时间大于30分钟的情况下，生产系统应切换到本地应急系统。具体如下1人为或数据库逻辑等因素引起的数据损坏数据库的逻辑错误或人为的操作失误可能会导致生产中心关键系统数据库均不可用，在此情况下须启用应急系统。2应用版本升级场景目前NGCRM/BOSS系统有稳定的新业务上线流程，在上线前有着严格的测试流程。但是由于NGCRM/BOSS业务关联性强，前期的测试有可能没有覆盖所有的业务流程。上线后，可能造成系统运行不稳定或者部分业务受理结果不正确。在此情况下，必须采取措施，避免错误继续扩大，同时需要回退更新。3前台业务受理中断场景由于系统硬件、软件、网络故障导致实体、电子渠道业务受理中断，引起客户投诉与抱怨，为了降低客户投诉率，可以切换至应急系统满足关键业务的连续性受理。4系统割接场景在进行系统割接时，为了不影响用户满意度以及集团的考核，可以切换到应急系统来满足关键业务的连续性。（如自动台的余额查询、空中充值等）。5硬件维护场景在系统维护过程中，可能会出现IBM/SUN/HP主机、网络设备、存储设备硬件维护或硬件微码升级的情况，可以切换到应急系统来保证关键业务的连续性。（如IBM/SUN/HP硬件更换）。6平台软件维护场景在系统维护过程中，可能会出现数据库需要补丁升级需要重启等情况，可以切换到应急系统来保证关键业务的连续性。（如ORACLE/TEXUDO/WEBLOGIC软件补丁升级）。7前台业务受理中断场景由于系统硬件、软件、网络故障导致实体、电子渠道业务受理中断，引起客户投诉与抱怨，为了降低客户投诉率，可以切换至应急系统满足关键业务的连续性受理。8生产机房发生火灾或泡水情况22应急建设需求221业务建设范围应急系统基础建设阶段包括渠道及主要功能如下2211营业前台应急功能在生产系统切换至应急系统后，营业前台渠道应支持如下表格22111所示的业务受理、信息查询及其他辅助功能。表22111营业前台应急功能表业务功能功能域功能说明备注开户业务受理可为客户建立档案、开通客户订购的移动服务及客户付费信息充值业务受理可为用户进行充值的服务充值应至少包括前台现金充值、充值卡充值、空中充值三种。缴费业务受理可为用户进行缴费服务停复机业务受理可为用户提供停机、复机的服务补换卡业务受理可实现对SIM卡的写卡处理，实现IMSI码与ICCID码绑定，同时开通鉴权服务用户资料查询信息查询可查询用户的准实时资料，如姓名、证件号码等信息余额查询信息查询查询用户余额准实时数据信息积分查询信息查询可查询用户的准实时积分值信息账单查询信息查询可查询用户的准实时消费账单信息PUK码查询信息查询可为用户提供查询PUK码的服务家庭充值/缴费业务受理可为家庭用户提供充值或缴费服务集团充值/缴费业务受理可为集团用户提供充值或缴费服务套餐变更业务受理可为用户提供各类产品套餐的变更服务营销方案业务受理可为用户提供营销方案的办理及撤销服务号源查询信息查询可提供号源的查询服务亲情组合及查询信息查询可为用户提供亲情号码组合受理及查询服务用户订购信息查询信息查询可提供用户的营销方案、已开通业务、附加功能、增值业务、梦网业务、自有业务、国际功能的查询服务查询GPRS流量信息查询可查询用户准实时的GPRS流量信息清单查询信息查询可查询用户准实时的清单信息2212客服系统应急功能在生产系统切换至应急系统后，客服系统应提供如下表格22121所示的基本业务及用户信息资料查询功能。表22121客服系统应急功能表业务功能渠道功能域功能说明备注密码校验人工台/自动台信息查询可对用户输入的密码进行正确性校验用户资料查询人工台/自动台信息查询可查询用户的准实时资料信息余额查询人工台/自动台信息查询查询用户余额准实时数据信息积分查询人工台/自动台信息查询可查询用户的准实时积分值信息申请停复机人工台业务受理可为用户提供停机、复机的服务用户订购信息查询人工台信息查询可提供用户的营销方案、已开通业务、附加功能、增值业务、梦网业务、自有业务、国际功能的查询服务账单查询人工台信息查询可查询用户的消费准实时账单信息PUK码查询人工台信息查询可为用户提供查询PUK码的服务亲情组合及查询人工台业务受理可为用户提供亲情号码组合受理及查询服务查询GPRS流量人工台信息查询可查询用户准实时的GPRS流量信息清单查询人工台信息查询可查询用户准实时的清单信息套餐变更人工台业务受理可提供为用户办理套餐产品变更的服务查询有效期自动台信息查询可查询账户余额的有效期时间信息话费查询自动台信息查询可查询用户话费准实时信息欠费信息查询自动台信息查询可查询用户欠费准实时信息2213电子渠道应急功能22131网上营业厅网上营业厅在生产系统切换至应急系统后，可支持如下表格221311所示的业务受理、信息查询及其他辅助功能。表221311网上营业厅应急功能表业务功能功能域功能说明密码验证业务受理可对用户输入的密码进行正确性校验用户资料查询信息查询可查询用户的准实时资料，如姓名、证件号码等信息余额查询信息查询查询用户余额准实时数据信息查询GPRS流量信息查询可查询用户准实时的GPRS流量信息账单查询信息查询可查询用户的消费准实时账单信息清单查询信息查询可查询用户准实时的清单信息网上充值卡充值业务受理可支持网上营业厅通过充值卡进行充值的服务停复机业务受理可为用户提供停机、复机的服务套餐变更业务受理可为用户提供各类产品套餐的变更服务亲情组合及查询业务受理可为用户提供亲情号码组合受理及查询服务用户订购信息查询信息查询可提供用户的营销方案、已开通业务、附加功能、增值业务、梦网业务、自有业务、国际功能的查询服务PUK码查询信息查询可为用户提供查询PUK码的服务22132掌上营业厅掌上营业厅在生产系统切换至应急系统后，可支持如下表格221321所示的业务受理、信息查询及其他辅助功能。表221321掌上营业厅应急功能表业务功能功能域功能说明密码验证业务受理可对用户输入的密码进行正确性校验用户资料查询信息查询可查询用户的准实时资料，如姓名、证件号码等信息余额查询信息查询查询用户余额准实时数据信息查询GPRS流量信息查询可查询用户准实时的GPRS流量信息账单查询信息查询可查询用户的消费准实时账单信息清单查询信息查询可查询用户准实时的清单信息网上充值卡充值业务受理可支持网上营业厅通过充值卡进行充值的服务停复机业务受理可为用户提供停机、复机的服务套餐变更业务受理可为用户提供各类产品套餐的变更服务亲情组合及查询业务受理可为用户提供亲情号码组合受理及查询服务用户订购信息查询信息查询可提供用户的营销方案、已开通业务、附加功能、增值业务、梦网业务、自有业务、国际功能的查询服务PUK码查询信息查询可为用户提供查询PUK码的服务22133短信营业厅短信营业厅在生产系统切换至应急系统后，可支持如下表格221331所示的业务受理、信息查询及其他辅助功能。表221331短信营业厅应急功能表业务功能功能域功能说明密码验证业务受理可对用户输入的密码进行正确性校验用户资料查询信息查询可查询用户的准实时资料，如姓名、证件号码等信息余额查询信息查询查询用户余额准实时数据信息查询GPRS流量信息查询可查询用户准实时的GPRS流量信息账单查询信息查询可查询用户的消费准实时账单信息清单查询信息查询可查询用户准实时的清单信息网上充值卡充值业务受理可支持网上营业厅通过充值卡进行充值的服务停复机业务受理可为用户提供停机、复机的服务套餐变更业务受理可为用户提供各类产品套餐的变更服务亲情组合及查询业务受理可为用户提供亲情号码组合受理及查询服务用户订购信息查询信息查询可提供用户的营销方案、已开通业务、附加功能、增值业务、梦网业务、自有业务、国际功能的查询服务PUK码查询信息查询可为用户提供查询PUK码的服务2214网络中断网络中断业务受理流程1在网络出现问题时，应急系统只在本机进行缴费信息的记录，生成缴费记录文件，不做任何后续操作；2网络正常而生产系统未恢复时，执行应急缴费提交，根据配置的应急系统缴费流程，完成相关应急操作；3生产系统正常后，同步应急数据到生产系统。如图22141所示应急缴费本机记录应急缴费提交网络非正常网络正常生产系统提交生产系统正常图22141网络中断业务受理流程图2215辅助功能除以上提及的影响用户的业务应急功能之外，为了更加的完善应急系统的支撑能力，应急系统应提供如下表格22151所示的基础辅助功能。如下表所示表22151辅助功能表业务功能渠道功能域功能说明备注应急业务流水查询人工台信息查询可查询到应急系统中受理业务的应急流水信息含操作员、受理时间、业务套餐等信息公告营业前台、客服系统、电子渠道信息发布通知对用户的解释口径，影响范围等信息短信发送营业前台、客服系统、电子渠道信息发布在应急系统中受理业务，给用户发送短信模板需与生产系统中有所区别，提前告知用户业务的生效时间以正式短信内容为准。222接管时间要求应急系统的数据是生产系统以准实时的方式同步，应急系统在接收到应急切换命令后，30分钟内能完全接管定义好的生产系统的关键业务。223应急数据同步为支持应急系统的业务受理，应急系统需要从生产系统中复制以下数据1CRM数据库业务参数及系统参数客户资料用户资料帐户资料付费关系资源资料。2客服数据库工号信息。3帐务管理数据库业务参数及系统参数三户资料实时余额信息存折信息积分信息。4计费数据库实时账单信息实时清单信息。CRM数据库、客服数据库和帐务管理数据库中的数据，采用第三方软件（DSGREALSYNC/ORACLEGOLDENGATE/QUESTSHAREPLEX等）将应急业务需要的相关数据准实时从生产系统同步到应急系统。计费数据库中的数据通过应用改造的方式来同步，生产系统生成一份账单文件和清单文件送到应急系统，应急系统使用入库进程入到应急数据库中，保证两个系统的数据一致性。223应急数据回切在生产系统恢复后，应急系统需要把故障期间的业务受理数据提交到生产系统。同时服务开通工单表（日志）也需要合并到BOSS生产系统。应急交易数据提交需要将应急期间的业务受理交易数据和缴费交易提交到BOSS生产系统。应急交易数据提交需要对提交流量进行控制，避免对恢复后的生产系统正常处理产生影响。同时需要标识应急交易提交中发生错误的交易，供人工核对处理。对业务受理交易，将订单及台帐相关数据搬到生产系统，重跑相关订单，因资料修改并不是完全在完工流程中完成，有部分业务在登记时已经修改，需要改造现有的完工流程，增加修改资料的环节，且回切业务不需要发指令。对缴费类交易，应急系统发生的缴费相关数据导到ACT生产库，其中预存、结余数据需要更新到账务物理库和ALTIBASE。对查询类业务，还需要将相关日志，台帐等导到生产系统，以便后续的查询。223应急系统管理功能1应急系统版本管理对应急系统软件的版本进行检查、监控，记录生产系统与应急系统软件配置文件和运行环境参数的差异，保证应急系统可执行代码与生系统同步升级，并记录应用软件版本升级轨迹。主要包括版本注册、版本一致性检查、版本更新控制、版本发布管理、版本更新等内容。通过应急系统建立版本管理机制，自动完成生产系统、应急系统相应环境配置、软件版本号、软件更新日期等信息比对，对版本差异进行告警发送，提醒维护人员及时进行关注并处理。2应急系统数据管理为保证应急系统在必要的时候能够及时接管生产系统，应急系统与生产系统的数据需保持一致性、完整性，应在应急系统中建立起与生产系统的数据同步审查机制，并通过数据核对帮助生产系统发现可能出现的问题，进一步完善和优化生产系统和应急系统。应急系统数据管理主要包括稽核配置管理、数据采集管理、数据比对管理、数据同步管理。对各数据管理各功能模块异常状态进行监控，异常时进行告警发送，提醒维护人员及时进行关注并处理。3应急系统切换管理包括对应急系统组织、人员、角色、权限的管理，明确应急系统组织架构，确保应急系统切换过程的有序进行。收到切换指令后自动修改或人工修改接口地址并测试，保证应急系统能够正常运行。生产系统恢复正常后，需要进行回切操作。切换管理系统主要包括人员管理、权限管理、切换管理、回切管理。根据应急系统组织机构，对不同的人员角色赋予不同的权限，要求管理平台界面化展示当前状态，操作人员实施一键式切换和回切操作，避免人为操作失误带来的切换风险。4应急系统演习管理负责规划应急系统应急演习的相关流程与任务，通过系统切换和系统回切的操作，验证应急系统可用性和可靠性。5应急系统监控管理实时监控应急系统的所有设备是否处于健康状态，监控应急系统软件的关键点，建立故障告警机制，保证应急系统的可用性。（需要和TOPTEA/BOMC进行分工）。6应急系统公告管理告知应急切换原因，预计恢复时间，对用户的解释口径。第三章天津移动业务支撑应急系统技术研究持续数据保护技术CDP311定义持续数据保护CDP是一套技术手段，它可以捕获或跟踪数据的变化，并将其独立存放在生产数据之外，以确保数据可以恢复到过去的任意时间点。持续数据保护系统可以基于块、文件或应用实现，可以为恢复对象提供足够细的恢复粒度，实现几乎无限多的恢复时间点。312与现有数据保护手段对比CDP出现，是为有效弥补传统数据容灾保护手段不足而产生的。CDPVS传统备份传统的数据保护解决方案专注在对数据的周期性备份上，因此一直伴随有备份窗口、数据一致性和对生产系统的影响等问题。实际上，传统数据保护技术中采用的是对“单一时间点（SINGLEPOINTINTIME）”的数据拷贝进行管理的模式，而CDP可以实现对“任意时间点（ANYPOINTINTIME）”的数据访问，因此可以大大提高数据恢复点目标（RPO）。备份技术实现的数据保护间隔一般为24小时，因此用户会面临数据丢失多达24小时的风险，采用快照技术，可以将数据的丢失量风险降低到几个小时之内，而CDP能够实现的数据丢失量可以降低到秒级。CDPVS数据复制（磁盘镜像）另外一种在数据容灾中常见的数据保护技术是复制技术，它可以通过与生产数据的同步获得数据的最新状态，但其无法规避有人为的逻辑错误或病毒攻击所造成的数据丢失。当生产数据由于以上原因导致数据遭到破坏时（例如数据被误删除），复制技术会将遭到破坏的数据状态同步到容灾数据存储，使容灾数据也受到破坏。而CDP系统可以使数据状态恢复到数据遭到破坏之前的任意一个时间点，因而消除了复制技术所含的风险。313总结为了保障业务支撑应急系统能够支持短时间的关键业务的运营生产，本系统选择持续数据保护CDP技术进行建设。32基于J2EE的多层技术架构321J2EE技术介绍J2EE是JAVA2平台企业版（JAVA2PLATFORM,ENTERPRISEEDITION）。J2EE核心是一组技术规范与指南，其中所包含的各类组件、服务架构及技术层次，均有共同的标准及规格，让各种依循J2EE架构的不同平台之间，存在良好的兼容性，解决过去企业后端使用的信息产品彼此之间无法兼容，企业内部或外部难以互通的窘境。322J2EE四层模型J2EE使用多层的分布式应用模型，应用逻辑按功能划分为组件，各个应用组件根据他们所在的层分布在不同的机器上。事实上，SUN设计J2EE的初衷正是为了解决两层模式CLIENT/SERVER的弊端，在传统模式中，客户端担当了过多的角色而显得臃肿，在这种模式中，第一次部署的时候比较容易，但难于升级或改进，可伸展性也不理想，而且经常基于某种专有的协议，通常是某种数据库协议。它使得重用业务逻辑和界面逻辑非常困难。现在J2EE的多层企业级应用模型将两层化模型中的不同层面切分成许多层。一个多层化应用能够为不同的每种服务提供一个独立的层，以下是J2EE典型的四层结构运行在客户端机器上的客户层组件运行在J2EE服务器上的WEB层组件运行在J2EE服务器上的业务逻辑层组件运行在EIS服务器上的企业信息系统ENTERPRISEINFORMATIONSYSTEM层软件如图3221所示图3221J2EE四层结构客户层组件J2EE应用程序可以是基于WEB方式的,也可以是基于传统方式的。WEB层组件J2EEWEB层组件可以是JSP页面或SERVLETS按照J2EE规范，静态的HTML页面和APPLETS不算是WEB层组件。正如下图3222所示的客户层那样，WEB层可能包含某些JAVABEAN对象来处理用户输入，并把输入发送给运行在业务层上的ENTERPRISEBEAN来进行处理。图3222WEB层组件图业务层组件业务层代码的逻辑用来满足银行，零售，金融等特殊商务领域的需要,由运行在业务层上的ENTERPRISEBEAN进行处理下图3223表明了一个ENTERPRISEBEAN是如何从客户端程序接收数据，进行处理如果必要的话,并发送到EIS层储存的，这个过程也可以逆向进行。有三种企业级的BEAN会话SESSIONBEANS,实体ENTITYBEANS,和消息驱动MESSAGEDRIVENBEANS会话BEAN表示与客户端程序的临时交互当客户端程序执行完后,会话BEAN和相关数据就会消失相反,实体BEAN表示数据库的表中一行永久的记录当客户端程序中止或服务器关闭时,就会有潜在的服务保证实体BEAN的数据得以保存消息驱动BEAN结合了会话BEAN和JMS的消息监听器的特性,允许一个业务层组件异步接收JMS消息。图3223业务层组件图企业信息系统层企业信息系统层处理企业信息系统软件包括企业基础建设系统例如企业资源计划ERP,大型机事务处理,数据库系统,和其它的遗留信息系统例如，J2EE应用组件可能为了数据库连接需要访问企业信息系统。323J2EE结构这种基于组件，具有平台无关性的J2EE结构使得J2EE程序的编写十分简单，因为业务逻辑被封装成可复用的组件，并且J2EE服务器以容器的形式为所有的组件类型提供后台服务因为不用自己开发这种服务,所以我们可以集中精力解决手头的业务问题1容器和服务容器设置定制了J2EE服务器所提供得内在支持，包括安全，事务管理，JNDIJAVANAMINGANDDIRECTORYINTERFACE寻址,远程连接等服务，以下列出最重要的几种服务J2EE安全SECURITY模型可以让你配置WEB组件或ENTERPRISEBEAN,这样只有被授权的用户才能访问系统资源每一客户属于一个特别的角色，而每个角色只允许激活特定的方法。你应在ENTERPRISEBEAN的布置描述中声明角色和可被