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

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

摘要

目前中国移动集团天津公司NG-CRM/BOSS系统的业务连续性保障体系有

三种模式，一种是多节点负荷分担方式，该方式要紧用于系统接入层与业务逻辑

层，有效地降低了个别节点故障对业务的影响程度；一种是容灾模式，由于多年

未升级，系统资源与生产中心已不匹配，在发生突发事件时，容灾系统不能在特

定的时间要求内全部或者部分恢复关键业务功能；一种是双机备份共享存储（下

列简称本地HA）方式，该方式要紧用于系统核心层。关于系统核心层使用的本

地HA模式来保障业务连续性，存在如下风险：

1）由于核心系统10量较大，如发生系统单节点宕机等严重故障可能会造成

由于10未及时写入磁盘而产生的文件系统错误，导致备机启动失败。

2）人为因素、数据库逻辑错误或者者存储故障造成的数据损坏从而引起业

务中断，本地HA将无法解决。NG-CRM/B0SS系统全部业务要求7X24小时运

行，存储阵列的使用强度大大增加，没有的时候间对存储系统进行定期维修与保

养。因此，当使用一段时间后，存储系统的部件连续或者同时出现故障的可能性

增加。止匕外，随着存储系统的功能与性能越来越强，存储系统内部的操纵软件也

日趋复杂，就像一个操作系统，其本身也会出现故障或者漏洞。部分省公司也曾

经发生过由于存储故障造成业务系统长时间停机、数据丢失的重大故障。

3）在系统割接、平台软硬件保护或者应用版本升级等情况下，本地HA都

将可能无法满足业务连续性要求。

4）生产机房发生火灾、泡水等情况下，多节点负载分担与本地HA模式都

不能保障业务连续性。

本文将从应急系统的系统架构、建设实现、系统测试各方面关于上述风险及

问题进行研究并逐一解决。

关键词：业务支撑系统应急系统运营商

ABSTRACT

AtpresenttheTianjinNG-CRM/BOSSbusinesscontinuitysecuritysystemhas

threemodes,oneisamulti-nodeloadbalancingmode,thismodeismainlyusedfor

systemaccesslayerandbusinesslogic,effectivelyreducingtheindividualnode

failuresthedegreeofinfluenceofthebusiness;adisasterrecoverymode,duetoyears

ofnotupgraded,thesystemresourcesandproductioncenterdoesnotmatch,not

withinaspecifictimerequirementsinwholeorinpart,torestorecriticalbusiness

functionsintheeventofanemergency,disasterrecoverysystem;adoublebackup

sharedstorage(hereinafterreferredtoasthelocalHA)mode,whichismainlyused

forthecoreofthesystemlayer.ThelocalHAmodeforthesystemcorelayerto

protectbusinesscontinuity,thefollowingrisks:

1)duetothelargeamountofcoresystemIO,suchastheoccurrenceofaserious

failureofthesystemsingle-nodedowntimemaycauseIOisnotwrittentodiskfile

systemerrors,leadingtothebackupmachinefailedtostart.

2)datacorruptioncausedbyhumanfactors,databaselogicen,ororstoragefailure

causingbusinessinterruption,localHAwillnotresolve.AllofNG-CRM/BOSS

systemrequirements7x24hourstorun,greatlyincreasetheintensityofuseofthe

storagearray,donothavetimeforregularrepairandmaintenanceofthestorage

system.Therefore,whenusedforaperiodoftime,thecomponentsofthestorage

systemcontinuouslyoratthesametimeincreasetheprobabilityoffailure.Inaddition,

withthegrowingfunctionalityandperformanceofstoragesystems,storagesystems

withinthecontrolsoftwarearebecomingincreasinglycomplex,asanoperating

system,whichitselfwillbefailureorvulnerability.Someprovinceshavealso

undergonemajorfailureofthebusinesssystemforalongtimedowntime,dataloss

duetoastoragefailure.

3)inthesystemcutover,platformhardwareandsoftwaremaintenanceor

applicationupgrade,thelocalHAmaynotbeabletomeettherequirementsof

businesscontinuity.

4)productionengineroomfire,flooddamageandothercircumstances,

multi-nodeloadbalancingandthelocalHAmodecannotguaranteebusiness

continuity.

Fromtheemergencysystemarchitecture,construction,implementation,system

testingallaspectsoftherisksandproblemsandsolvethemonebyone.

KEYWORDS：NG-CRM/BOSS,EmergencySystem,TelecomOperators

目录

目录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总结28

第四章天津移动业务支撑应急系统的建设方案29

4.1应急系统定位29

4.2应急系统与外围系统边界32

4.3应急系统目标33

4.4应急系统架构34

4.4.1功能架构35

4.4.2数据流设计40

4.4.3物理部署46

4.4.4外围接口切换47

4.4.5应急系统安全设计47

4.4.6数据模型设计48

4.5应急系统建设方案50

4.5.1应急受理子系统50

4.5.2应急管理平台系统71

4.6应急系统硬件及平台软件建设方案78

4.6.1硬件平台方案78

4.6.2硬件配置方案与应用部署图84

4.6.3网络环境86

4.6.4系统软件86

第五章天津移动业务支撑应急系统应急场景的分析与确定87

5.1应急场景87

5.1.1应用分析87

5.1.2分业务分析93

5.1.3针对风险点的应急分析93

5.2建设场景94

5.2.1正常场景94

5.2.2场景1网上营业厅应用切换场景94

5.2.3场景2短信营业厅应用切换场景97

5.2.4场景3联指应用切换场景99

5.2.5场景4客服应用切换场景102

5.2.6场景5外围接口应用切换场景104

5.2.7场景6统一接入应用切换场景106

5.2.8场景7CRM应用全切场景108

5.2.9场景8全切场景Ill

第六章天津移动业务支撑应急系统演练115

6.1演练场景115

6.2演练范围115

6.3演练流程115

6.3.1生产系统切换到应急系统流程115

6.3.2应急系统回切生产系统流程118

6.4演练总结121

第七章结论与展望124

参考文献125

发表论文与参加科研情况说明126

致谢错误!未定义书签。

第一章绪论

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.1T

所示。

BOSS系统功能

采集预处理融合计费综合帐务服.务开通

1I帐务皎理、

I采策I计费预处理1彳费控制I详单管理I工单管理I

第林理二经营

1I1j开通与激活

|预处理|计费引擎||控制范围管理]|充额管理分析

I」!」用替翌

r系统

CRM服务开通类定中管界

批价依据管理I也里型I和分管8!-lLP

产品管理信息管理

产品目录管理1配置管理11产品退出信息接受与创建客户信息管理11用户信息管理1

产品创建1产品变更发布管理1订购信息管理帐户信息管理11信息提供

综合结算

1结算预处理11重单检查1结算批价11结算帐务处理

1数据分发1L对帐处理1结算调帐]1结算回退1

宽带BOSS

1结算报表处理1审核校验错单回收处理结算监管

P-BOSS111网管

■:基础管理

「统计报表管理

「系统

业务局数据数据一致性1-

1管通II管理11管理I计费帐务稽核

ADCSCPVC][.萼.11mS110A]|RADIUS||合作伙伴系统|银行系统；国内其他运营商

图2.1.1-1BOSS系统功能架构图

CRM系统要紧包含渠道管理、市场营销、销售管理、客服服务、客服管理、

产品管理、资源管理与基础管理等八大功能域。功能结构如下图2.1.1-2所示。

客户/合作伙伴/业务管理者/营销人员/销售人员/客服人员

营业

渠道基础平台呼叫中心基础平台短信WAP彩信EMAIL门户自助终端•••

终端

CRM系统功能

渠道运营支撑渠道运营管理

分析㈡管理dfol

市场营销活动管理车肖售商机管理销售活动管理客户服务请求管理

营销管理服务

营销信息管理订单管理销售文档管理客户维系管理

客户信息管理客户信用度管理产品创建产品变更资源生命周期管理

统客户产品资源

帐户信息管理客户服务密码管理产品退出版本管理资源调度管理

管理管理管理

客户级别管理特殊名单用户管理配置管理发布管理资源仓储管理0BOSS

客户信息视图产品目录管理资源信息管理

委?工作管理

人员管理知识管理报表统计系统管理任务管理工单管理

黑等撑网谦国向据嘉垂皿

图2.1.1-2CRM系统功能结构图

2.1.2软硬件配置现状

B0SS/CRM生产中心配有8台满配置的IBMP595小型机，主机处理能力达到

3420万tpmC,主机配置如下表：

表2.1.2-1BOSS/CRM系统主机配置情况表

单台设备配置情况

序数量CPU

系统划号（台）数CPU主内存

分主机名称型号量频(GHz)(GB)

1计费数据库Cluster11102.348

2账务数据库Cluster11122.372

P595F

3账务应用Cluster11402.3340

4连指122.316

5计费数据库Cluster?1102.348

B

6账务数据库Cluster21122.372

OP595G

S7账务应用Cluster21402.3360

生S

8连指122.316

产系

连指服务器P630

中统9121.458

心10采集1P650B41.4532

B80

C1olcoml122

R2网厅前置1P650C41.458

单台设备配置情况

序数量CPU

系统划号（台）数CPU主内存

分主机名称型号量频(GHz)(GB)

M3DSMPWEB1P570A82.230

系

4ESOP测试1P570B2.2

统830

5CRM前置142.220

P570C

6PB测试1122.270

7CRMWEB21201.9128

8一级BOSS（落地方）1161.936

9电子渠道WEB服务器1P595A81.948

10ESOP1181.948

11客服APP1181.964

12CRMWEB11201.9128

13一级BOSS（落地方）2161.936

14电子渠道WEB服务器1P595B81.94S

15ESOP2181.948

16客服APP2181.964

17CRMTUX21162.3128

18接口TUX1142.364

P595C

19统一接入平台1102.364

20CRM数据库Cluster11242.3128

21CRMTUX11162.3128

22接口TUX1142.364

P595D

23统一接入平台1102.364

24CRM数据库Cluster21242.3128

25一级BOSS（平台，发起方）182.348

26BPM、容错探针1122.396

27Crm/actdb测试1P595E162.3128

28客服DB11102.380

29pbossdb182.364

30topteadb1P595F22.316

31一级BOSS（数据指令）182.348

32服务开通1122.396

33计费账务应用测试1P595H162.3160

34客月艮DB21102.380

35pbossapp182.364

36NG编译181.748

37短信、充值营业厅181.748

P690C

38CRM开发181.732

39营销/一致性181.732

单台设备配置情况

序数量CPU

系统划号（台）数CPU主内存

分主机名称型号量频(GHz)(GB)

40CRM前置机181.748

41DSMPWEB181.748

P690D

42NG测试app181.720

43历史数据库1181.740

BOSS/CRM系统存储配置情况如下表所示。

表2.1.2-2BOSS/CRM系统存储配置情况表

磁盘阵列

序

数量

系统划分号设备型号磁盘配置裸容量（TB）

（套）

1IBMESS800147.0

BOSS系统

生产中心2IBMDS8300178.0

CRM系统3IBMDS8300141.0

BOSS系统

容灾中心4IBMDS8300193.0

CRM系统

磁带库

序

数量

系统划分号设备型号裸容量（TB）

（套）

生产中心BOSS/CRM共用5IBMTS35841120

容灾中心BOSS/CRM共用6IBMTS35841222

SAN交换机

序

数量

系统划分号设备型号端口情况

（台）

7IBMM482每台配有5*32个光纤端口

生产中心BOSS/CRM共用

8IBMM142每台配有5*16个光纤端口

9IBMF325每台配有32个2Bb/s光纤口

2.1.3网络组织现状

为了充分保证BOSS/CRM系统的安全、可靠性，目前BOSS/CRM系统网络共

分为三层：SAN存储层、核心网络层（内网）、接入网络层（外网DMZ）。其中，

计费应用、帐务应用、CRM数据库、集中采集、测试、备份、统计分析、结算等

核心服务器直接通过SAN交换机实现磁盘阵列、磁带库的存储与备份;计费应用、

帐务应用、CRM数据库、集中采集、联机指令、测试、备份、统计分析、结算等

核心服务器属于关键生产服务器，处于核心网络层，分别连接在移通大厦20层

2台Catalyst6509核心内网交换机及移通大厦22层2台QuidwayS8505核心

内网交换机上；考虑到系统的安全可靠性，把与外界联系紧密的服务器，如中间

件、WEB、一级BOSS接口、DSMP接口、防病毒、认证、桌面管理系统、SOC服务

器连接在IP1260防火墙上的DMZ区，即4台C4506交换机上；与0A、客服、

采集、营业厅等系统的连接均通过异构防火墙连接在接入的Catalyst6509交换

机上。接入交换机Catalyst6509（外网）、千兆防火墙IP1260、核心交换机

Catalyst6509（内网）构成BOSS系统的高速数据通道，使用负荷分担的方式进

行工作，确保系统稳固、可靠的运行。

此外，随着世纪大道IT机房的启用，MIS、统一信息平台与经营分析系统

将陆续搬迁至相应机房；目前在世纪大道机房设有4台Catalyst6509交换机，

分别与移通大厦机房、南开工业园机房对应连接，实现信息化系统及经营分析系

统与BOSS系统的互联。

网络结构如下图所示。

「世纪大道;

；怖彳相宿「高4「为春充而一；!

ii

1cisco服二_Cisco

；BOSS系统'1；；BOSS系统:

心

c,sco

,,则甲甲6511望南M一OHB|C^°；

；WSM型S午FWSM

I.WSM

cisco^B<5isco।cisccTSCISCO

6509缩I温）6509|6509目寸gSl6509

，联网出G

.SNS5200Q联网访问DMZjx

南开工业园

移通大厦

-和平河西分公司

河北河东分公司蜷，|XB南开红桥分公司

1

图2.1.3-1BOSS及CRM系统网络结构图

BOSS/CRM系统网络设备配置情况如下表所示。

表2.1.3-1天津公司BOSS/CRM系统网络设备配置情况表

序设备名称或者型数

要紧配置及说明备注

号号量

分别配置2x48个10/100Base-T

Catalyst65O9交换

12电口，2x16个千兆光口，1个移通20楼，核心

机

48口千兆光口。

分别配置2x48个10/100Base-T

Catalyst65O9交换

22电口，2x16个千兆光口，1个南开工业园，核心

机

48口千兆光口。

Catalyst65O9交换分别配置2x48个10/100Base-T

32移通20楼，连接外网

机电口,2x16个千兆光口

Catalyst6509交换分别配置2x48个10/100Base-T南开工业园，连接外

42

机电口，1x16个千兆光口网

分别配置1个操纵卡（含2个

Catalyst4506交换光口）、1x6口GE卡，1个

52移通20楼

机2GE+32口10/100M板卡,1个

18口光口板卡

分别配置1个操纵卡（含2个

Catalyst4506交换光口）、1x6口GE卡，1个

62南开工业园

机2GE+32口10/100M板卡，1个

18口光口板卡

NOKIAIP1260千

72分别配置2个双端口千兆卡移通20楼

兆防火墙

NOKIAIP1260千

82分别配置2个双端口千兆卡南开工业园

兆防火墙

华为S8505交换分别配置1个48口10/1000电

92移通22楼，核心

机口板卡，1个48口光口板卡

2.1.4风险分析

目前天津公司NGBOSS系统的业务连续性保障体系有三种模式，一种是多

节点负荷分担方式，该方式要紧用于系统接入层与业务逻辑层，有效地降低了个

别节点故障对业务的影响程度；一种是磁带库、CDP与存储底层复制实现的数

据级容灾（下列简称数据容灾）方式，该方式事实上只是实现了系统中要紧业务

数据的备份,没有实现应用级容灾，不能在发生突发事件时,在特定的时间（RTO）

要求内，能够全部或者部分恢复关键业务功能；一种是双机备份共享存储（下列

简称本地HA）方式，该方式要紧用于系统核心层。关于系统核心层使用的本地

HA模式来保障业务连续性，存在如下风险：

1）由于核心系统10量较大，如发生系统单节点宕机等严重故障可能会造成由

于10未及时写入磁盘而产生的文件系统错误，导致备机启动失败。

2）人为因素、数据库逻辑错误或者者存储故障造成的数据损坏从而引起业务中

断，本地HA将无法解决。NG-CRM/B0SS系统全部业务要求7X24小时运

行，存储阵列的使用强度大大增加，没有的时候间对存储系统进行定期维修

与保养。因此，当使用一段时间后，存储系统的部件连续或者同时出现故障

的可能性增加。此外，随着存储系统的功能与性能越来越强，存储系统内部

的操纵软件也日趋复杂，就像一个操作系统，其本身也会出现故障或者漏洞。

部分省公司也曾经发生过由于存储故障造成业务系统长时间停机、数据丢失

的重大故障。

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业务建设范围

应急系统基础建设阶段包含渠道及要紧功能如下：

营业前台应急功能

在生产系统切换至应急系统后，营业前台渠道应支持如下表格221.1-1所示

的业务受理、信息查询及其他辅助功能。

表221.1-1营业前台应急功能表

业务功能功能域功能说明