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

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