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

1、摘 要目前中国移动集团天津公司 NG-CRM/BOSS 系统的业务连续性保障体系有三种模式，一种是多节点负荷分担方式，该方式主要用于系统接入层和业务逻辑层，有效地降低了个别节点故障对业务的影响程度；一种是容灾模式，由于多年未升级，系统资源与生产中心已不匹配，在发生突发事件时，容灾系统不能在特定的时间要求内全部或部分恢复关键业务功能；一种是双机备份共享存储（以下简称本地 HA）方式，该方式主要用于系统核心层。对于系统核心层采用的本地 HA 模式来保障业务连续性，存在如下风险：1) 由于核心系统 IO 量较大，如发生系统单节点宕机等严重故障可能会造成由于 IO 未及时写入磁盘而产生的文件系统错误，

2、导致备机启动失败。2) 人为因素、数据库逻辑错误或者存储故障造成的数据损坏从而引起业务中断，本地 HA 将无法解决。NG-CRM/BOSS 系统全部业务要求 724 小时运行，存储阵列的使用强度大大增加，没有时间对存储系统进行定期维修和保养。因此，当使用一段时间后，存储系统的部件连续或同时出现故障的可能性增加。此外，随着存储系统的功能和性能越来越强，存储系统内部的控制软件也日趋复杂，就像一个操作系统，其本身也会出现故障或漏洞。部分省公司也曾经发生过由于存储故障造成业务系统长时间停机、数据丢失的重大故障。3) 在系统割接、平台软硬件维护或应用版本升级等情况下，本地 HA 都将可能无法满足业务连续

3、性要求。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

4、 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 cr

5、itical 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 foll

6、owing 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 er

7、ror 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

8、 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 s

9、ystem, 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

10、 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 al

11、l 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 风险应对措施 .9

12、2.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 体系结构比较

13、 .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 硬件配置方案和应用

14、部署图 .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 统一接入应用切换场景

15、.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致 谢 .1281第一章 绪 论1.1 研究背景中国移动业务支撑系统经过近几年的集中化改造建设和不断完善，经过NGBOSS（新一代业务运营支撑系统）建设，业务支撑系统已经在市场

16、拓展、客户服务等工作中发挥了重要的支撑作用，成为中国移动贯彻落实“服务与业务领先”战略的有力手段。日益激烈的市场竞争和不断提高的客户服务质量需求对 BOSS 业务支撑能力和可靠稳定运行的要求越来越高，从面向客户服务的角度而言，无论何时出现何种情况，都需要移动运营商提供不间断的业务支撑服务，以保证客户满意度、客户服务质量、企业信誉等不受影响，对企业而言也可避免财务损失，增强企业竞争力。与此同时，BOSS 集中化改造、NGBOSS 一阶段和二阶段建设在带来业务快速响应等众多优势的同时，也存在着系统故障点集中、风险集中的危险，如：系统故障、人为误操作、火灾、水灾、传输中断、电网停电等系统风险。因此，

17、适时、合理地规划和开展中国移动业务运营支撑系统应急保障体系建设，已经成为中国移动的重要任务。1.2 研究目的及意义为保证业务持续运营，NGBOSS 系统已经在系统架构上充分考虑其可靠性。NG-CRM/BOSS 系统的关键应用系统的服务器都进行了高可靠性（HA）设计，杜绝了单点故障导致业务中断。在本地高可靠性的基础上，为了在出现灾难情况时（如地震、水灾、火灾、瘟疫、人为灾难故障） ，能够有效对系统和应用进行恢复，NGBOSS 系统还建立了容灾备份系统，实现了数据及应用的容灾。2但是，在某些故障（如：数据库磁盘故障、软件错误等）发生时，HA 并不能解决问题，同时由于这些故障预计能够在短时间内（4

18、小时以内）能够解决，因此并没有必须进行容灾切换。在这种情况下，运营商需要有一个应急系统，能够支持短时间的关键业务的运营生产，保证客户感受不到业务的中断。通过业务支撑应急系统的建设，建立业务支撑网的应急风险预防、应急响应机制和恢复措施，保证在发生突发事件时，能够在特定的时间要求内，能够全部或部分恢复关键业务功能，提高关键业务连续运行能力，提升服务质量和服务水平，并降低运营风险，将业务损失降低到可接受的程度，以增强企业竞争力。1.3 研究的主要内容及论文结构本文主要是针对天津移动业务支撑应急系统技术方案的研究，通过对现状的分析，确认系统建设范围，设计系统功能及技术架构以完成整体的建设方案。并且通过

19、对应急场景的归纳总结，保证方案的可实施性和有效性。论文主要分为以下章节：第一章绪论，介绍了天津移动业务支撑应急系统的必要性和需解决的问题，提出了本文的研究内容及意义。第二章对目前天津移动业务支撑系统的现状分析，确认建设方向、建设范围及具体内容。第三章对天津移动业务支撑应急系统技术研究及选型。第四章介绍天津移动业务支撑应急系统的建设方案，包括系统架构设计、功能架构设计、各模块设计、数据流设计、部署方案等。第五章为天津移动业务支撑应急系统的应急场景的分析和确定，包含各子系统的应急场景及相关流程，为项目建设提供了验证依据。第六章为天津移动业务支撑应急系统演练方案及演练总结。第七章为结论与展望，对论文

20、工作进行了总结，展示了本系统开发的主要成果及丞待完善的方面。3第二章 天津移动业务支撑系统现状分析及应急建设需求2.1 系统现状及风险分析2.1.1 功能现状BOSS 系统主要包括产品管理、信息管理、融合计费、综合结算、综合帐务、采集预处理、服务开通、合作伙伴管理、基础管理等九大功能域，如下图2.1.1-1 所示。CRM 经 营分 析系 统BOS网 管合 作 伙 伴 系 统合 作 伙 伴 系 统 银 行 系 统银 行 系 统 国 内 其 他 运 营 商国 内 其 他 运 营 商宽 带P-BOSADCSCPVCNMSMISOARADIUSBOS系 统 功 能融 合 计 费计 费 预 处 理计 费

21、 引 擎批 价 依 据 管 理 错 单 管 理计 费 控 制控 制 范 围 管 理 详 单 管 理高 额 管 理融 合 计 费计 费 预 处 理计 费 引 擎批 价 依 据 管 理 错 单 管 理计 费 控 制控 制 范 围 管 理 详 单 管 理高 额 管 理产 品 管 理产 品 创 建 配 置 管 理 发 布 管 理产 品 变 更 产 品 退 出产 品 目 录 管 理产 品 管 理产 品 创 建 配 置 管 理 发 布 管 理产 品 变 更 产 品 退 出产 品 目 录 管 理 合 作 伙 伴 管 理资 质 管 理信 息 管 理业 务 管 理考 核 管 理服 务 管 理信 息 审 核 发

22、布合 作 伙 伴 管 理资 质 管 理信 息 管 理业 务 管 理考 核 管 理服 务 管 理信 息 审 核 发 布综 合 结 算结 算 预 处 理数 据 分 发结 算 报 表 处 理 重 单 检 查对 帐 处 理审 核 校 验 结 算 批 价结 算 调 帐错 单 回 收 处 理 结 算 帐 务 处 理结 算 回 退结 算 监 管综 合 结 算结 算 预 处 理数 据 分 发结 算 报 表 处 理 重 单 检 查对 帐 处 理审 核 校 验 结 算 批 价结 算 调 帐错 单 回 收 处 理 结 算 帐 务 处 理结 算 回 退结 算 监 管综 合 帐 务帐 务 管 理帐 务 处 理信 用 管

23、 理积 分 管 理综 合 帐 务帐 务 管 理帐 务 处 理信 用 管 理积 分 管 理采 集 预 处 理采 集预 处 理 服 务 开 通服 务 开 通 类 定 单 管 理工 单 管 理开 通 与 激 活服 务 开 通服 务 开 通 类 定 单 管 理工 单 管 理开 通 与 激 活基 础 管 理系 统管 理 业 务 局 数 据管 理 数 据 一 致 性管 理 统 计 报 表 管 理计 费 帐 务 稽 核基 础 管 理系 统管 理 业 务 局 数 据管 理 数 据 一 致 性管 理 统 计 报 表 管 理计 费 帐 务 稽 核信 息 管 理订 购 信 息 管 理 客 户 信 息 管 理 信 息

24、 提 供帐 户 信 息 管 理 用 户 信 息 管 理信 息 接 受 与 创 建信 息 管 理订 购 信 息 管 理 客 户 信 息 管 理 信 息 提 供帐 户 信 息 管 理 用 户 信 息 管 理信 息 接 受 与 创 建图 2.1.1-1 BOSS 系统功能架构图CRM 系统主要包括渠道管理、市场营销、销售管理、客服服务、客服管理、产品管理、资源管理和基础管理等八大功能域。功能结构如下图 2.1.1-2 所示。4市场营销销售管理客户服务客户管理基础管理报表统计 系统管理任务管理工作管理人员管理工单管理知识管理资源管理资源生命周期管理资源仓储管理资源信息管理营销活动管理营销信息管理销售活动管理商机管理销售文档管理订单管理服务请求管理客户维系管理客户信息管理帐户信息管理客户级别管理客户信用度管理特殊名单用户管理客户服务密码管理产品管理产品创建 产品变更产品退出配置管理 发布管理版本管理产品目录管理渠道基础平台 呼叫中心基础平台 经营分析系统宽带 P -B O S SB O S S中国移动外部系统外部合作伙伴B O S S总部