成果上报申请书-BOSS系统高可用性能力提升项目

附件 1：成果上报申请书 成果名称 BOSS 系统高可用性能力提升 成果申报单位 成果承担部门 /分公司 项目负责人姓名 成果专业 类别 * 支撑 网 成 果 研究 类别 * 现有业务优化 省 内 评审 结果 * 通过 关键词索引（ 3 5 个） 业务支撑网 ； BOSS； 电信级 文章摘要（ 200 字左右）： 在 市场 竞争 激烈 、 以客户为导向的今天，业务的发展、市场的开拓和客户满意度的提升等方面对业务支撑系统提出了更高的要求。对中国移动广西公司来说，提升系统的可靠性和可用性，构建电信级的业务支撑网系统，已成为增强企业核心竞争力、提升客户满意度的重要手段。 BOSS 系统做为业务支撑网的核心系统，系统庞大、架构复杂，自 BOSS1.5 上线以来，系统就一直受到稳定性差，故障频发且故障引发业务中断时间长的困扰。本项目将以科学的方法和手段深入分析目前系统症状，找出对策，以 7X24 小时不间断可用服务电信级 BOSS系统为目标，通过对系统逐步实施改造、优化，逐渐提高 BOSS 系统的可靠性和可用性， 探讨如何持续渐进的建设电信级的业务支撑系统的思路 。 省内试运行效果（ 300 字以上）： 从 2007 年 4 月份开始实施，截止到 9 月底取 得的效果： 1、系统平台层面 营业系统：提升营业数据库、中间件的处理能力，解决营业数据库 RAC 在节点主机宕机时不能正常互为接管问题。 客服系统：完成了网络优化改造和客服数据库单点故障改造。 帐务系统：提升帐务应用、数据库的处理能力，完成帐务数据库单点故障改造。 计费系统：完成扩容提升计费系统的处理能力。 CBOSS：完成 BES 配置集群、建立 CBOSS 应急系统 。 PRM/CHANNEL：完成从营业中间件分离出来，消除单点故障隐患。 结算系统：完成主机迁移提升系统处理能力，消除单点故障隐患。 即开即通：配置了双 机，负载均衡，完成了全区 BOSS 到 HLR 的备用路由的开通，通过路由切换脚本完成主备路由切换，主路由实现冗余，整个系统完成了消除单点故障的改造。 二卡合一：配置了双机，负载均衡，消除消除单点故障。 2、维护管理层面 完善并演练了各子系统的应急预案，其中做为核心系统的 营业系统的中间件在数据库后台之间的应急方案切换速度由原来的 2 个 多小时缩短到 30 分钟左右。 BOSS 网管本地化需求已完成部分功能，监控手段、维护流程得到进一步完善。 3、系统实施改造后， 不管是故障次数、故障影响业务时长均比上半年有了明显下降。 文章主体（ 3000 字以上，可附在表格后）： 根据成果研究类别，主体内容的要求有差异，具体要求见表格后的“填写说明”。 文章主体： 一、项目简介 （一）项目背景 在 市场 竞争 激烈 、 以客户为导向的今天，业务的发展、市场的开拓和客户满意度的提升等方面对业务支撑系统提出了更高的要求。对中国移动广西公司来说，提升系统的 可靠 性和可用性，构建电信级的业务支撑网系统，已成为增强企业核心竞争力、提升客户满意度的重要手段。 BOSS 系统做为业务支撑网的核心系统， 系统庞大、架构复杂， 自 BOSS1.5 上线以来，系统就一直受到稳定性差， 故障频发且 故障引发业务中断时间长的困扰。本项目将 以科学的方法和手段 深入分析目前系统症状， 找出对策， 以 7X24 小时不间断可用服务电信级 BOSS系统为目标，通过对系统逐步实施改造、优化，逐渐 提高 BOSS 系统的 可靠性和可用性， 探讨 如何持续渐进的 建设电信级的业务支撑系统的 思路 。 （二）项目实施过程 1、首先提出了电信级 BOSS 系统的定义 参照对电信级网络的定义 ， 提出了电信级水平的 BOSS 系统的定义： 电信级 BOSS 系统可认为与电信级网络相对应，是以可运营为核心，提供 7X24 小时不间断可用服务的业务支撑系统。应具备以下特性： 高可用性（ Availability）： 可以提供长时间不中断的、可用的服务； 高可管理性（ Serviceability）： 基于标准技术，可进行远程的故障管理、性能管理、配置管理、安全管理； 高可扩展性（ Scalability）： 支持平滑单点容量上的扩展性和多点地域上的扩展性； 高安全性（ Security）： 具有较高的安全特性。 2、总体思路 在对电信级 BOSS 系统逐步认识和 探讨 的基础上， 提出建立相关科学的评估方法和模型， 通过 对 BOSS 系统 现状分析、改造、完善 等阶段逐步 向 电信级 水平 的 BOSS 系统 演进 ，进而提高 BOSS 系统的高可用性。 进而并把相关的方法、经验用于指导日后 BOSS 系统的滚动建设。 3、实施过程简介 （ 1） 2007 年 4-5 月，提出电信级 BOSS 系统定义，探讨、 建立相关科学的评估方法和模型，据此对 BOSS 系统现状分析，从系统平台、应用系统、开发测试、日常维护管理等多个维度对目前的 BOSS 系统进行普查、分析，找出关键问题、缺陷所在。 （ 2） 2007 年 6-9 月， 根据分析出的问题、缺陷，结合现实条件，对已具备条件的，立即着手制定方案实施优化改造；对还未具体条件 的，制定策略方案后续实施 ，完成第一阶段系统平台层面的实施改造。 通过 BOSS2.0 工程、客服系统网络扩容改造工程、统一开通应急、 CBOSS 应急、二卡合一应急等维护项目来重点完善原系统的设计缺陷，解决性能瓶颈、单点故障问题 ,提高故障反映和处理速度； 通过 BOSS 测试系统扩容改造工程，为 BOSS 应用软件的在软件生命周期的各个阶段开展提供基本的质量保证。 加强了各工程的压力测试和异常测试。 通过演练来不断完善各子系统系统应急预案，熟悉应急流程，积累应急经验。 加强监控手段，完善维护流程。 建立了定期系统分析、维护机 制以及定期与集成商沟通交流机制。 完成了中间件在应用级的动态均衡优化测试，为下一步实施奠定基础。 （ 3） 2007 年 10 11 月，实施应用层面的优化改造，实现 BOSS 系统应用的动态均衡负载，真正实现应用的高可用性。 （三）项目创新性 1、首次提出了电信级水平的 BOSS 系统的概念和定义。 2、提出了 评估 电信级 BOSS 系统高可用性的 科学方法 。 3、提出了建设高可用性 BOSS 系统的思路 ， 用于指导对现有系统的改造和日后 BOSS 系统的滚动建设。 4、 提出 了 中间件在应用 层面 的 真正做到 动态均衡优化 的 解决方案。 （四）项目实 施效果 从 2007 年 4 月份开始实施，截止到 9 月底取得的效果： 1、系统平台层面 营业系统：提升营业数据库、中间件的处理能力，解决营业数据库 RAC 在节点主机宕机时不能正常互为接管问题。 客服系统：完成了网络优化改造和客服数据库单点故障改造。 帐务系统：提升帐务应用、数据库的处理能力，完成帐务数据库单点故障改造。 计费系统：完成扩容提升计费系统的处理能力。 CBOSS：完成 BES 配置集群、建立 CBOSS 应急系统 。 PRM/CHANNEL：完成从营业中间件分离出来，消除单点故障隐患。 结算系统：完成主机迁移提升系 统处理能力，消除单点故障隐患。 即开即通：配置了双机，负载均衡，完成了全区 BOSS 到 HLR 的备用路由的开通，通过路由切换脚本完成主备路由切换，主路由实现冗余，整个系统完成了消除单点故障的改造。 二卡合一：配置了双机，负载均衡，消除消除单点故障。 2、维护管理层面 完善并演练了各子系统的应急预案，其中做为核心系统的 营业系统的中间件在数据库后台之间的应急方案切换速度由原来的 2 个 多小时缩短到 30 分钟左右。 BOSS 网管本地化需求已完成部分功能，监控手段、维护流程得到进一步完善。 3、系统实施改造后， 不管是故障次 数、故障影响业务时长均比上半年有了明显下降。 二、项目详细内容 1、立项背景 在 市场 竞争 激烈 、 以客户为导向的今天，业务的发展、市场的开拓和客户满意度的提升等方面对业务支撑系统提出了更高的要求。对中国移动广西公司来说，提升系统的 可靠 性和可用性，构建电信级的业务支撑网系统，已成为增强企业核心竞争力、提升客户满意度的重要手段。 BOSS 系统做为业务支撑网的核心系统， 系统庞大、架构复杂， 自 BOSS1.5 上线以来，系统就一直受到稳定性差， 故障频发且 故障引发业务中断时间长的困扰。 下图为 2007 年上半年故障和投诉情 况统计： 2007 年 1 - 6 月 B O S S 系统故障统计12754525345106579563217024681 2 3 4 5 6月份次数0200400600800分钟故障次数 故障时长月度批量投诉情况7512 231015861547170141669313330510152 0 0 7 年1 月 2 0 0 7 年2 月 2 0 0 7 年3 月 2 0 0 7 年4 月 2 0 0 7 年5 月 2 0 0 7 年6 月 2 0 0 7 年7 月0500100015002000批量投诉次数 批量投诉用户数 可以看到： BOSS 系统稳定性差、故障频发且影响业务时间长。 上半年 BOSS 系统的故障主要集中在营业系统、二卡合一、 CBOSS 等关键系统上。 上半年， BOSS 系统出现不稳定以及不同程度的退服情况，造成批量投诉情况发生的次数以及人数均有较大幅度的上升 。 本项目将 以科学的方法和手段 深入分析目前系统症状， 找出对策， 以 7X24 小时不间断可用服务电信级 BOSS 系统为目标，通过对系统逐步实施改造、优化，逐渐 提高 BOSS 系统的 可靠性和可用性， 探讨 如何持续渐进的 建设电信级的业务支撑系统的 思路。 2、详细 技术 内容 项目目标： 提升 BOSS 系统的高可靠性和高可用性；探索如何持续渐进地向电信级水平的BOSS 系统演进 。 项目实施思路： 1、按业务关键程度进行梳理，从系统平台、应用系统、开发测试、日常维护管理等多个维度对目前的 BOSS 系统进行普查、分析，找出关键问题所在。 2、根据分析出的问题、缺陷，结合现实条件，对已具备条件的，立即着手制定方案实施优化改造；对还未具体条件的，制定策略方案后续实施。 3、第一阶段主要针对系统平台层面进行优化改造，重点解决解 决性能瓶颈、单点故障问题；制定应急措施，完善应急预案。 一、理论研究 提出了电信级水平的 BOSS系统的概念和定义及 对电信级 BOSS系统高可用性的评估方法和模型。 （一）电信级 BOSS 系统 参照对电信级网络的定义， 电信级 BOSS 系统可认为与电信级网络相对应，是以可运营为核心，提供 7X24 小时不间断可用服务的业务支撑系统。应具备以下特性： 高可用性（ Availability）： 可以提供长时间不中断的、可用的服务； 高可管理性（ Serviceability）： 基于标准技术，可进行远程的故障管理、性能管理、配置管理 、安全管理； 高可扩展性（ Scalability）： 支持平滑单点容量上的扩展性和多点地域上的扩展性； 高安全性（ Security）： 具有较高的安全特性。 1、 可用性 可用性是一个统计概念，具体计算方法是： 系统可用性（ Availability） = MTBF/(MTBF+MTTR) 其中： MTBF 指平均无故障时间， MTTR 指平均故障修复时间。 高可用性对于业务支撑系统非常重要。具体体现为可长时间不间断的提供服务。 设备的高可用性是设备软硬件架构和功能模块可用性的综合，主要影响对象包括：（ 1）硬件（ 2）操作系统 （ 3）中间件（ 4）数据库（ 5）应用软件。 系统的高可用性是通过高可用性组网技术实现。 2、 可管理性 可管理性对于运营商网络至关重要。电信级网络应当提供符合中国移动标准接口和标准协议的远程故障管理、性能管理、配置管理、安全管理等功能。电信级网络中的网元设备应支持开放标准管理接口连接集中网络管理系统。 3、 可扩展性 设备应支持设计规格范围内的线性扩展能力。在规格扩展范围内，系统性能不足时，可在纵向通过增加硬件模块、软件模块扩展系统的处理能力，也可在横向通过集群、 4 7 层交换等方式增加系统的可扩展性。 4、 安全性 系统安全性包括网络安全、主机安全、操作系统安全、数据库安全、应用安全等等，电信级 BOSS 系统应从组网和设备两个层次对安全性进行要求，以保证电信级电信级 BOSS系统和设备在管理面、控制面和数据面的安全，并符合萨班斯法案的要求。 （二）、电信级 BOSS 系统可用性评估 评估方法重点用于对业务支撑系统 进行电信级评估，作为优化系统结构、提高系统可用性的基础。 采用分层的方法对系统进行解析 、评估 ，针对每一层次分别进行分析和要求，再将低层次拼装为高层次系统。支撑业务 系统 可按业务提供粒度划分为 3 个层次 ,如图 2-1 所示： 业务整体方案层 ：指整个 BOSS 系统在全区范围内的部署方案，包括各子系统节点间的逻辑路由策略、异地容灾保护等。 业务系统层 ：指能够独立完成某项业务的本地站点 ,以及业务系统内部完成某类业务流程中一个独立功能环节的软硬件综合体，如：营业系统、客服系统等。 物理设备层 ：业务系统内部每一个有独立物理封装的设备、设备群及在设备上安装的系统平台软件，如：主机、防火墙、双机集群、 ORACLE RAC 等。 营 业 系 统 计 费 系 统 帐 务 系 统 客 服 系 统C B O S S业 务 系 统 层主 机 主 机交 换 机 交 换 机S A N 交 换 机S A N 交 换 机磁 盘 阵 列磁 盘 阵 列物 理 设 备 层防 火 墙 防 火 墙B O S S 系 统业 务 整 体 方 案 层图 2-1 系统层次结构图 在电信级 BOSS 系统特征中， 最重要 的特征是可用性 。系统的整体可用性体现在系统从微观到宏观的多个层面，保证电信级 BOSS 系统需要对系统中各个层面进行全面评估。 采用自底向上的研究方法，分物理设备层、业务系统层和业务整体解决方案层三个层面，在各层定义不同粒度的可用性指标，分别进行建模，进而在此基础上进行可用性综合评估。 物理设备层： 从物理设备故障概率的角度分析可用性。 业务系统层：用随机 Petri 网重点分析典型的逻辑系统：集群系统、双机备份等，分别进行建模并进行定量分析。对于给定拓扑的业务系统，可通过业务流程和物理设备层、业务逻辑设备层的模型求 解，定量的对业务系统进行可用性分析，得到整个系统的平均无故障时间，评估响应时延等指标。 业务整体 方案层 ： 主要涉及业务在各子系统节点间的逻辑路由策略、异地容灾保护等。 1、 可用性评估方法 （ 1）业务整体方案层可用性 系统的可靠性计算很大程度上取决于系统故障定义。系统故障定义不同，算法也不同。比如，系统中某些单元故障将导致整个系统瘫痪，而某些单元故障只会导致系统部分功能丧失。 根据 Bellcore SR-TSY-001171 以及 TL9000 中的相关定义，系 统级故障基本可以分为两大类： TSD(Total System Downtime)和 PSD(Partial System Downtime)。 计算系统的可靠性 /可用性指标主要是计算各个 Di（第 i 个单元的年中断时间Downtime） 。 首先需要进行一个简单的故障模式影响分析，以确定系统各组成单元中，哪些会引起系统 TSD，哪些会引起 PSD。然后主要的任务就是计算这些单元的 Di。 根据上面提供的故障定义，明确对 BOSS 系统可用性指标的定义。将整个系统的各种故障分别列出，然后根据故障的影响分别计算出单个故障的 Di。 参照通信设备业界网上运行数据统计方法标准 TL9000，对 于 BOSS 系统 的可靠性指标，采用如下的统计方法： SDTDTniii1)P( 其中： DT 整个 系统 的年中断时间； iDT 第 i 个 节点 的年中断时间； iP 第 i 个 节点 故障所影响容量； S 整个 系统 的总容量； n系统 中设备的台数。 （ 2）业务系统层可用性 由业务逻辑设备组成高可用性的业务系统，主要是减少业务逻辑间的耦合性， 增加冗余业务流程来实现，使得某个业务逻辑设备的单点故障不影响其它业务逻辑的功能，业务网逻辑设备的切换不影响其它业务逻辑。 在业务系统的设计中，应充分考虑增加串行业务流程的冗余度的同时，降低业务逻辑间的耦合性，以保证整个业务系统的高可用性。 图 2-2 见图 2-2 所示，在业务流程中，至少存在一条冗余业务链路，当主业务流程出现故障时（如 A1B1C1） ,业务能自动切换到备用业务流程： A2B2C2，并且要求此切换对客户是透明的。 存在双机切换的设备应该 避免直接串联，而通过中间的非双机切换设备来进行故障隔离或交叉连接来实现故障隔离，减少业务网逻辑设备间的耦合，任何业务部件的故障切换，都不会引起其它业务逻辑的切换。而主业务流程中任何一个业务逻辑的故障，使其它业务流程也进行切换，从而整个业务流程从主业务流程切换到备业务流程，若每业务流程主备切换成功率为 90，则整个业务流程切换成功率为： 0.9*0.9*0.9=0.729，业务可靠性大大降低。 （ 3）物理设备层可用性 各层面可用性最终体现到物理设备可用性指标的获取，物理设备可用性评估是电信级BOSS 系统可用性研 究的基础。 设备层分为硬件和软件两部分，软硬件可用性在特性上具有很大差别： 物理退化。软件不存在物理退化现象，硬件失效则主要由于物理退化所致。这就决定了软件正确性与软件可靠性密切相关，一个正确的软件任何时刻均可靠。然而一个正确的硬件元器件或系统则可能在某个时刻失效； 复杂性。软件内部逻辑高度复杂，而硬件设备间的内部逻辑较为简单，这就在很大程度上决定了设计错误是导致软件失效的主要原因，而导致硬件失效的可能性则相对很小。 唯一性。软件是唯一的，软件拷贝不改变软件本身，而任何两个硬件不可能绝对相同，概率方法更适合 应用于硬件可靠性预测。 由于上述种种原因，软件可靠性比硬件可靠性更难保证。 综合考虑软件失效和硬件失效，则系统可用度计算公式为： ni 1 AAA 软件硬件系统 串联部分可用性 设备的可用性度量包括可用性评估和可用性预测。 可用性评估指收集整理系统测试和系统运行期间得到的失效数据，并进行统计推理，断定系统当前的可用性。它是对从过去到当前点所得到的可用性的度量。其主要目的是评价当前可用性，并确定一个可用性模型是否为回溯的正确依据。 可用性预测指利用可知的任何软件度量与规程确定未来软件的可用性。 单一厂家提供的 设备通常提供整个设备的可用度，可以以该数据作为可用性预测的依据，并在系统上线运行后对其故障情况进行统计，并根据统计数据进行可用性评估；对于软硬件由不同厂家提供的设备，则需要分别对其可用性进行预测和统计。 硬件可用性 硬件的故障往往由于物理 (包括化学 ) 的机制所致 , 因而描述硬件可靠性的模型比较单一 , 硬件失效率符合浴盆曲线。 硬件可用性可通过可用度或年 停机时间 表示： 可 用度M T T RM T BFM T BFA 年 停机时间 Downtime 8760 60 (1-A) mins/yr。 MTBF 预 测方法 目前业界对于硬件 MTBF 的预测可以通过分析器件可用性、单元（如板卡）可用性以及系统可用性（如冗余设计中的备份关系）得到整个硬件设备的可用性指标。 MTBF 为失效率的倒数： MTBF=1/失效率； 其中： 失效率 是单位时间内设备的失效数占该时间段开始时正常工作设备总数的比值。它反映的是设备发生失效的相对速率即故障瞬时强度 串联结构的失效率是各单元失效率的累加； 并联（冗余系统）的失效率采用可修产品的马尔可夫模型计算。 一般电子设备的失效率 都遵循浴盆曲线规律，如图 2-3 所示 ： 图 2-3 浴盆曲线 MTTR预测方法 因设备的应用场景不同，维护方式不同，预计值或者经验值都仅是一个参考，如可以参考 BELLCORE GR 512，根据业界情况设定 MTTR。 表 2-1 GR 512 推荐的 MTTR Site Classification On-site repair time (hours) Dispatch time (hour) Total Service Restoral time (hours) Attended site 1 2 3 Unattended site 1 3 4 在系统招标时，厂 家应承诺 MTTR 时间，在可用性评估时，以此事件为准。 软件可用性 目前业界软件可靠性预计方法还不成熟，软件可用性的高低很大程度上取决于软件生产过程中开发流程和质量管理体系，可以通过对厂家软件开发流程和质量管理体系的检查、评估对其软件产品的可用性进行判断，以作为系统割接入网的依据。 软件可用性预计和 评估 软件可用性度量包括可靠性评估和可靠性预测。 可靠性评估指收集整理系统测试和系统运行期间得到的失效数据，并进行统计推理，断定系统当前的软件可靠性。它是对从过去到当前点所得到的可靠性的度量。其主要目的是评价当前可靠性，并确定一个可靠性模型是否为回溯的正确依据。 可靠性预测指利用可知的任何软件度量与规程确定未来软件的可靠性。可靠性领域中习惯将可靠性预测称为可靠性预计。 软件可靠性术语 软件可靠性领域的术语定义，主要有： 软件错误（ Software Error）：指在软件生存期间内的不希望或不可接受的人为的错误，其结果导致软件缺陷的产生，是一种人为的过程，相对于软件本身来说是一种外部行为。比如，将求平均值当作求最大值，和将输出电压值当作输出电流值等都是软件错误。 软件缺陷（ Software Defect）： 是存在于软件之中的那些不希望或不可接受的偏差，其结果是软件运行于某一特定的条件时出现软件故障，这时称软件缺陷被激活。以静态形式存在于软件内部。比如，少一个逗号、多一条语句等都是软件缺陷。当软件意指程序时，软件缺陷与软件 bug 同义。 软件故障（ Software Fault）：是指软件运行过程中出现的一种不希望或不可接受的内部状态，可能引起一个功能部件不能完成所要求的功能的一种意外情况，若故障不加处理，便可能产生失效，是一个动态行为。比如，软件处于执行一个多余循环过程时就是一个软件故障。 软件失效（ Software Failure）：软件运行时产生的一种不希望或不可接受的外部行为结果，也就是表现出的功能与用户需求不一致，功能部件执行其规定功能的能力终止，用户无法完成所需要的应用。 它们的关系如下：软件错误 软件缺陷 软件故障 软件失效。软件失效是最终表现在用户面前的结果。 软件开发流程保证 软件可靠性数据是可靠性评估的基础。 要进行有效的软件可靠性评估，首先必须 建立软件错误报告、分析与纠正措施系统。按照相关标准的要求，制定和实施软件错误报告和可靠性数据收集、保存、分析和处理的规程，完整、准确地记录软 件测试阶段的软件错误报告和收集可靠性数据。 如何提高软件可靠性 软件与硬件不同 , 不会因多次使用而发生失效 ， 软件的故障不是由于物理机制所造成的 , 软件不存在故障率呈增长趋势的耗损故障期 , 软件的缺陷 解决 一个就减少一个。 软件开发周期错误和软件故障分类的百分数分别如表 2-2 和表 2-2 所示。 表 2-1 软件开发周期各阶段错误的百分比 软件开发周期各阶段 需求分析 设计 编码与单元测试 综合测试 运行与维护 错误百分比（ %） 55 17 13 10 5 表 2-2 软件故障分类的百分比 故障分类 需求变化 逻辑设计 数据 相互 环境 人的因素 计算 文件提供 其他 故障分类百分比（ %） 36 28 6 6 5 5 5 2 7 由表 2-1、表 2-2 的统计数据表明，在软件生命周期的各个阶段都会可能发生软件错误或故障， 为了保证软件的可靠性，应在软件生命周期的各个阶段千方百计地减少缺陷。同时，统计数据也表明，软件错误的修改费用也是越晚越高的。 一个好的软件开发流程可以提高软件开发团队的工作效率，控制开发过程中的风险，保证软件开发进度并且提高软件产品质量 。 为保证软件的可靠性，应该在软件生命周期的各个阶段开展各项基本 的质量保证活动，以减少缺陷。 （三）建设高可用性 BOSS 系统的思路 BOSS 系统庞大而复杂，子 系统 繁多 。 根据以上的几个层面的分析，我们要建设高可用的电信级 BOSS 系统， 须要从物理设备层、业务逻辑层、系统整体 3 个方向进行设计考虑。 1、 物理设备层面的设计 物理设备层是系统可用性的最基本保障，因此，在考虑建设 高可用的电信级的 BOSS 系统时，必须首先在物理层面保障系统的高可用性，消除单点故障，这里主要包括硬件和软件两个方面。 （ 1） 硬件方面： 主要从以下几个方面考虑： 对于关键的业务系统，服务器主机方面必须考虑双 机集群，以满足系统基本的高可用性条件。目前主流的小型机设备供应商 IBM、 HP、 SUN 等都有相应的高可用性 HA（ High Availability）解决方案，其根本原则就是提供硬件设备的高可用性，即：在其中一台设备失效的情况下，另一台设备能自动接管原有的业务，以保持业务的连续性。 对于物理网络结构，必须提供备用的网络路由链路， 包括备用的网络设备（路由器、交换机、防火墙等）和传输电路等。 对于底层的数据库，也要考虑冗余备份。数据库存放的是业务系统的数据，是所有系统正常运行的基础，因此必须考虑实现 2 个或以上的数据 库实例以提供数据库的高可用性。目前主流的数据库产品提供商都有相应的 HA 解决方案，如： ORACLE 的RAC 等。 在设备选型时， 需要大到 电信级网络设备指标标准 (设备要求分 册 )要求，同时由于 UNIX 系统在可靠性、稳定性、抗病毒攻击等方面都比 WINDOWS 具有先天性的优势，而目前低端 UNIX 服务器价格已接近相同性能的 PC SERVER，因此在 BOSS 这样的关键业务支撑系统里，应尽量考虑使用 UNIX SERVER 而不是 PC SERVER。 （ 2） 软件方面： 对于一个高可用性的 BOSS 系统，有了冗余的硬件设计 只是最基本的设计要求，软件方面（系统软件和应用软件）则更为重要。没有软件的冗余设计，那么从业务系统来说是不具备高可用性条件的。 对于系统软件，在 BOSS 系统里最重要的是中间件。出于 BOSS 业务的关键性，在选择中间件软件时必须考虑产品的成熟性，以直接提升 BOSS 系统的高可靠性。 对于应用软件，与硬件不同 , 不会因多次使用而发生失效，软件的故障不是由于物理机制所造成的 , 软件不存在故障率呈增长趋势的耗损故障期 , 软件的缺陷解决一个就减少一个。因此， 为保证软件的可靠性，应该在软件生命周期的各个阶段开展各项基本的质 量保证活动，以减少缺陷。 2、 业务系统层的设计 物理设备层满足高可用性的条件后，只是在底层平台给予了系统高可靠性的条件，而业务系统层实现高可用性是系统具有高可用性的重要保障。为保证系统的高可用性，在业务系统的设计中，应从以下几个方面考虑： 充分考虑增加串行业务流程的冗余度的同时，降低业务逻辑间的耦合性，减少各子系统互相影响的深度，以保证整个业务系统的高可用性。 必须考虑各应用子系统的自动切换机制的实现。在中间件、应用系统等方面，应该在系统设计阶段和底层系统物理设备平台结合起来一起考虑各子系统的自动切换和回切 机制。在这个层面，可通过自行开发或借助第三方的软件或硬件来实现，如：四 /七 层交换机等。 3、 业务整体解决方案层的设计 建设电信级的 BOSS 系统，还需在业务的整体解决方案层进行相应的设计考虑，主要包括： 系统设计时需考虑各子系统的路由策略，通过冗余设计避免出现一个子系统失效而整个系统失效的情况发生； 考虑建设系统的异地容灾系统，分析业务的关键程度，并根据各子系统不同的等级来实现系统的数据级容灾和应用级容灾。 建立各子系统的应急方案。容灾系统是在“灾难时刻”才启用的，而应急方案是解决临时问题而启用的，其目的是更 快速的保障业务应用的连续性。 建立完善的网管系统，对各个网元进行实时监控，并对异常情况及时通过短信、邮件、声音等方式报警。 明确维护指标，完善系统维护流程，按 ITIL 的方法论，严格执行事件管理、问题管理、变更管理、配置管理等流程。 二、项目具体实施 （一） 实施思路 通过 BOSS 系统现状普查分析、改造优化、评估完善等阶段逐步向电信级水平的 BOSS系统演进，进而提高 BOSS 系统的高可用性。 1、 普查分析阶段 对现有 BOSS 系统软、硬件可用性情况逐一进行普查、分析，确定制约系统可靠性的短板、缺陷、单点故障隐患， 制定下一阶段性目标等。 2、 改造优化阶段 根据不同系统的发展范围、用户总数、经济受益和社会影响力等因素，将系统分为关键系统、一般系统两类，据此确定各系统整改的优先级别， 结合具体改造代价： 对于有现实条件的，开始实施改造； 对于目前受条件限制的，提出改造方案，并在后续落实。 3、 评估完善阶段 根据上面的 可用性评估方法或软件后评估体系进行阶段性的评估、总结，提出完善方案，持续进行整改。 （二） BOSS 系统现状分析 从系统平台、应用系统、开发测试环境、日常维护管理等多个维度对目前的 BOSS 系统进行普查、分析，针对 业务关键程度进行梳理。 1、 总体框架 下面是 2004 2007 年广西移动 BOSS 系统的发展过程： 时间 2004 2005 2006 2007 BOSS 系统 1.0 1.5 2.0 用户规模（万） 800 1000 1300 目前 BOSS 系统存在以下两个主要特点： （ 1）技术：网元较多、标准复杂、发展较快 包括主机 /操作系统、存储、网络 /安全、数据库、中间件、应用软件。 （ 2）架构：架构复杂、功能繁多、数据海量 业务支撑系统主要包括：营业系统、计费系统、帐务系统、客服系统、结算系统、 CBOSS等等 。 2、 系统平台 （ 1） 主机 通过普查分析，发现目前系统主要存在性能不足、单点故障等隐患，或者 硬件已具备冗余条件，但应用系统不具备自动切换的条件，虽然在某些环节上实现了高可用性，但系统整体上实际还达不到高可用性的要求 。 系统 网元 配置 说明 营业 营 业 数据 库节点 1 IBM P690(32CPU,128G 内存 ) cpu/内存利用率高，单台主机不能支撑全部数据库功能，实际上单点故障仍然存在 营 业 数据 库节点 2 IBM P690(32CPU,128G 内存 ) 营业中间件 1 IBM P690 分区 (12CPU,48G内存 ) 中间件与多个后台应用（如工单调度）部署在一起，性能不足，特别是内存 /交换区经常告警。 应用不具备自动切换能力，实际上单点故障仍然存在。 营业中间件 2 IBM P690 分区 (12CPU,44G内存 ) 营业中间件 3 IBM P690 分区 (8CPU,64G内存 ) 应急数据库 IBM P690 分区 (12CPU,40G内存 ) 同时在运行客服应急库，性能不足影响数据库复制 客服 客服数据库 IBM P690 分区 (12CPU,34G内存 ) 1、单点故障隐患 2、网卡没有配 成 Etherchannel 无线营业厅 IBM P650(8CPU,32G 内存 ) 1、单点故障隐患 2、应用不具备自动切换能力。 综 合 客服 后台 IBM P650(8CPU,64G 内存 ) 计费 计费应用 1 IBM P690 分区 (12CPU,35G内存 ) 1、单台主机不能支撑全部计费应用功能 2、应用不具备自动切换能力。 计 费 应用 2（ MDB） IBM P690 分区 (12CPU,47G内存 ) 计费数据库 1 IBM P690 分区 (8CPU,22G内存 ) 1、单台主机不能支撑全部数据库 功能 2、网卡没有配成 Etherchannel 计费数据库 2 IBM P690 分区 (8CPU,28G内存 ) 帐务 帐务数据库 IBM P690 分区 (8CPU,20G内存 ) 单点故障隐患 帐 务 应用 1（ MDB) IBM P690 分区 (12CPU,55G内存 ) 1、单台主机不能支撑全部帐务应用功能 2、应用不具备自动切换能力。 帐务应用 2 IBM P690 分区 (12CPU,35G内存 ) CBOSS cboss 应用 IBM P650(8CPU,48G 内存 ) 1、单台主机不能支撑全部帐务 应用功能 2、应用不具备自动切换能力。 3、网卡没有配成 Etherchannel cboss数据库 IBM P650(6CPU,12G 内存 ) PRM CHANNEL PRM/CHANNEL IBM P650(8CPU,32G 内存 ) 与无线营业厅共用一台主机，单点故障隐患 结算 结算应用 IBM P670(8CPU,48G 内存 ) 性能不足，单点故障隐患 结算数据库 IBM M85(6CPU,6G 内存 ) 性能不足，单点故障隐患 （ 2） 数据库 以营业数据库为例， 营业数据库做为整个 BOSS 系统的核心数据库，现状如下： 数据库运行情况 数据规模：规模从 2005 年底 1.8T 发展至 2007 年上半年 6.8T 系统备份：全库备份从 2005 年底 3.5 小时发展至 2007 年底 8小时 存在问题及风险 数据库表空间不能循环使用，历史工单数据保留时间过长导致数据库增长过大。 数据库数据规模增大，导致系统备份及后台事务时间窗增长； 数据库内单表记录数增大， 表和索引存在大量的碎片没有及时分析整理 ,数据处理效率降低，造成查询统计速度变慢，数据修改操作争用情况加剧； 业务高峰期，业务请求对资源的争用导致系统抗风险 能力降低，表现为系统速度变慢，故障增多，对表的维护操作时间增长。 数据表、索引数量不断增加，增加维护管理难度及应用复杂度。 单个节点主机宕机时另外一个节点不能正常接管数据库。 3、 网络 客服座席到客服系统、 BOSS 系统的网络链路，是 2 条 10*2M，总带宽是 20M（ 2 条链路是主、备关系）。自 07 年 2 月客服扩容改造之后，客服座席的网络流量增大，平时的链路带宽均值在 15Mbps 左右，高峰时达到链路速率的限制，出现了客服座席业务响应迟缓、数据丢失等故障现象。 图 3-1 客服座席网络拓扑 4、应用系统 （ 1）即开 即通 接口主机存在单点故障；没有备份路由； 出现网络故障时 人工干预太多，发生故障时自动化程度太低，存在无法快速处理的风险 。 （ 2）一级 BOSS（ CBOSS） 缺乏监控手段； 接口表记录太多导致一级 BOSS 接口处理不及时 ； 一级 BOSS 接口上发缓慢 ；用户状态、定购关系 目前只能通过第二天凌晨集团下发的错单文件进行检查。要实现实时监控，只能在组包上传的时候判断每个号码是否智能网号码，对系统资源消耗较大 。 （ 3）二卡合一 由于 BOSS 侧作为服务端，一旦要进行切换，必须要智能网一侧修改指向 IP 地址 。 5、开发、测试环境 设 备 数量 配置 使用说明 IBM P650 1 IBM P650， 8CPU(1.45G)， 32GRAM，2GE， 2FE， 2FC， 2*73GHdisk 测试数据库 IBM P570 1 IBM P570， 4CPU(1.45G)， 32GRAM，2GE， 2FE， 2FC， 2*73GHdisk 应用测试 设 备 数量 配置 使用说明 IBM S7A 1 IBM S7A， 12CPU(226MHz)，12GRAM， 1GE， 2FE， 2*9.1GHdisk 开发、源码编译 IBM S7A 1 IBM S7A， 12CPU(226MHz)，12GRAM， 1GE， 2FE， 2*9.1GHdisk，1*18.2GHdisk 开发、源码编译 BOSS 系统目前 开发环境 所用的两 台 IBM S7A主机 为 2002 年 BOSS 集中化工程建设的时候所购 ， 年代久远，设备陈旧， CPU 时钟频率太低，且生产厂家已不对其提供技术升级和板卡替换，造成性能无法提升，已不能 可以满足源码的开发和编译。 BOSS 系统 测试环境 所用的 机器 设备 配置（ CPU/内存） 较 低，部分测试不能做全区数据的测试，如帐务 MDB、计费 MDB 等需要大内存的环境 ，常常要借助部分生产环境来兼做测试，影响了生产环境的使用 。 同 时环境过于集中，不利于开展测试、管理、配置、变更和维护， 严重影响应用开发测试的进度和测试质量 ，进而影响到 BOSS 系统应用割接上线的质量和系统稳定性 。 应用程序在上线前缺乏严谨的测试计划，除了 功能测试外，缺乏各种异常测试、压力测试。 6、 维护管理 在维护管理方面主要存在下列问题： （ 1）维护指标不明确。 如对每个子系统的维护指标是什么？可用性要求是什么？ （ 2） 维护流程、应用上线控制不够规范，未能很好执行事件管理、问题管理、变更管理、配置管理等流程。 未能充分充分利用 BOSS 网管的监控、告警功能。 （ 3）没有 定期维护窗口，没有建立定期维护系统的机制。 （ 4）应急措施不力：应急方案没有经过演练来验证；系统平台或应用更改后没有及时对应急方案进行变更；做为核心系统的营业系统的在实施应急措施进行应用切换时，时间长（ 2 3 小时）。 （ 5）关键系统主机维护控制台放在机房，未能延伸至亚航办公室，导致主机宕机重启处理时间过长。 （三）具体措施 现阶段主要针对系统平台层面进行优化改造， 通过 2007 年 BOSS2.0 扩容改造工程、客服系统网络扩容改造工程 、建立应急系统等措施来 重点完善原系统的设计缺陷，解决性能瓶颈、单点故障问题。 重 点解决解决性能瓶颈、单点故障问题；制定应急措施，完善应急预案，减短故障处理时长、提高系统稳定性。 1、措施一：系统平台改造 （ 1）即开即通系统 增加一台主机，负载均衡互为备份； 网络改造增加备用路由。 通过脚本实现切换备用路由，并移交监控室进行实时监控和切换，保障在第一时间及时发现路由问题并加快备用路由切换速度 ,从而提高开机及时率。 （ 2）一级 BOSS（ CBOSS） 地 市 公 司B O S S网 络营 业 数 据 库1 0 . 1 8 2 . 1 1 . 1 3 5（ 营 业 中 间 件3）1 0 . 1 8 2 . 1 1 . 1 3 3（ 营 业 中 间 件2）1 0 . 1 8 2 . 1 1 . 1 3 1（ 营 业 中 间 件1）1 0 . 1 8 2 . 1 4 . 8 3(路 由 器)1 0 . 1 8 2 . 2 5 1 . 2 5 4（ 二 枢 纽 ）1 0 . 1 8 2 . 1 1 1 . 1 9 7（ 白 沙 ）网运传输线路N N H L R 1 N N H L R 2 B H H L R 2 监 控 发 现 网 元 断 连切 换 备 用 路 由1 0 . 1 8 2 . 1 1 . 1 4 71 0 . 1 8 2 . 1 4 . 3外 省 一 级 B O S S 系 统1 0 . 1 8 2 . 1 1 . 1 4 3( 一 级 B O S S 数 据 库 )1 0 . 1 8 2 . 1 1 . 1 4 1( 一 级 B O S S 应 用 )营 业 库计 费 库S N 路 由 器 1S N 路 由 器 2集 团 公 司 交 换 中 心1 0 . 1 8 2 . 1 1 . 2 9( 一 级 B O S S 应 急 数 据 库 ) 加强监控手段； 建立基于 BES 服务的 PARTITION 集群。 建立 CBOSS 应急系统。 更换 CBOSS 应用为多后台进程版本，实现一定程度的负载均衡 （ 3）客服系统 更换核心网络设备 ,扩容网络带宽、新增热备链路路由； 客服数据库新增一台主机配置成双节点 RAC。 （ 4）二卡合一 增加一台接口主机，负载均衡互为备份 （ 5）其他关键系统 营业系统：更换营业数据库主机；中间件主机扩 CPU/内存；解决营业数据库 RAC在节点主机宕机时不能正常互为接管问题。 帐务系统：帐务应用扩容 CPU/内 存；帐务数据库新增一台主机配置成双节点 RAC 。 计费系统：计费应用、计费数据库主机扩容 CPU、内存。 PRM/CHANNEL 系统：从营业中间件分离出来，配置 HA 双机互备，负载均衡。 结算系统：更换结算数据库和结算应用主机，配置 HA 双机互备。 2、措施二：应用系统改造优化 系统监控：梳理分析各个子系统的关键监控点，通过 BOSS 网管、脚本、存储过程等手段利用短信直接把告警发给维护人员，加快反应速度把故障消灭在萌芽状态。 CBOSS：针对影响集团公司五项考核指标的薄弱环节进行加强应急措施：如建立基于 BES 服务 的 PARTITION。 集群、建立应急系统、更换多后台进程版本等。 BOSS 全编上线：把控改造进度、严谨测试，精心组织、周密部署确保了全编版本割接成功。 3、 措施三：开发测试环境优化改造 改 造 后改 造 前测 试 环 境测 试 环 境开 发 环 境I B M S 7 A1 2 C P U , 2 4 G R A MI B M S 7 A1 2 C P U , 2 4 G R A MI B M P 6 7 0 L P A R4 C P U , 8 G R A M营 业 应 用 测 试C B O O S 测 试接 口 测 试客 服 测 试I B M P 6 7 0 L P A R4 C P U , 8 G R A M营 业 测 试 库P R M / C H A N N E LI B M P 5 7 08 c p u , 1 6 G R A M帐 务 测 试计 费 测 试经 分 1 . 5 测 试开 发 环 境I B M P 6 9 0 L P A R8 C P U ， 2 4 G R A MI B M P 6 9 0 L P A R8 C P U ， 2 4 G R A MI B M P 5 9 5 L P A R2 0 C P U ， 9 6 G R A M营 业 测 试 库营 业 发 布 库营 业 回 退 应 用I B M P 5 9 5 L P A R2 0 C P U ， 9 6 G R A M营 业 发 布 应 用营 业 培 训I B M P 5 9 5 L P A R2 0 C P U ， 9 6 G R A MP R M / C H A N N E L帐 务 M D B接 口I B M P 5 9 5 L P A R2 0 C P U ， 9 6 G R A M自 动 测 试 库客 服 测 试帐 务 应 用I B M P 5 9 5 L P A R2 0 C P U ， 9 6 G R A M营 业 测 试 应 用营 业 回 退 库I B M P 5 9 5 L P A R2 0 C P U ， 9 6 G R A M计 费 应 用计 费 M D BI B M P 6 5 08 C P U ， 2 4 G R A MP R M / C H A N N E L 前 台无 线 营 业 厅 前 台网 上 自 助 前 台I B M P 6 5 06 C P U ， 2 8 G R A MC B O S SI B M P 6 5 06 C P U ， 2 8 G R A M自 动 测 试 应 用1 、 配 置 低 处 理 性 能 不 足2 、 测 试 环 境 不 全3 、 B O S S 和 经 分 测 试 环 境 混 在一 起1 、 迁 移 到 2 台 I B M P 5 9 5 、 3台 P 6 5 0 ， 提 升 主 机 处 理 能力2 、 利 用 主 机 分 区 功 能 ， 实现 物 理 集 中 、 应 用 逻 辑 分开 通过 BOSS 测试系统扩容改造工程新增主机、资源整合，把旧的开发测试环境迁移到新的系统平台上 ，建立了开发、测试、发布、回退、培训等多个环境，为应用软件的在软件生命周期的各个阶段顺利开展提供保障。 严把应用开发测试进度控制，除了进行功能测试、集成测试外，加强进行各种压力测试、异常测试 。 4、 措施 四：优化 BOSS 运维流程 发挥 BOSS 网管系统作用：完善 BOSS 各子系统设备在 BOSS 网管系统上的配置，充分利用 BOSS 网管加强系统监控、告警，把故障消灭在萌芽状态。 建立周、月分析制度：通过各种性能收集、分析工具定时收集数据进行分析，找出应用瓶颈所在，提交应用集成商共同解决。 完善应急方案：通过演练来不断完善系