BOSS系统提升研究

2024-05-09

BOSS系统提升研究（通用3篇）

BOSS系统提升研究篇1

0引言

BOSS系统由BSS系统(业务支撑系统)和OSS系统(运行维护支撑系统)两部分组成,也就是说BOSS系统是一个综合性支撑系统,身兼业务与运行维护两大功能［１］。以前BOSS系统仅为广电系统实现计费服务,后来由于广电系统的业务越来越多,BOSS系统也从最初的计费功能发展到了具有多功能模块的系统,提升的系统不仅为用户服务,还能与其它运营商在服务质量和管理水平上竞争, 从而使BOSS系统功能得到进一步提升。

1三网融合下BOSS系统提升意义

随着计算机技术及网络技术的发展,有线电视系统也得到高速发展。在未进行三网融合之前,有线电视业务种类单一,仅为用户提供单向有线服务,计费及标准都非常简单。当时的计费系统只对用户的收费情况进行统计,并记录一些基础性的数据及资料,包括用户数据的整理以及用户资料的记录和管理。如果在系统中发现有些用户没有缴费,就会采用人工派送的方法进行缴费单派送进行催缴,如果用户迟迟不缴费,则中断该用户的电视信号。当时的系统仅仅是一个功能极其简单的信息管理系统。

在三网融合的背景下,各种各样的竞争在各大有线电视网络运营商之间越演越烈,使得各大运营企业都不得不对网络系统进行双向化改造和数字化改造。随着数字技术、宽带业务范围的扩展和近几年云计算服务的快速发展,各大运营企业都很关注管理系统问题,根据需求逐步建立起多个子系统,包括有线电视用户管理系统和宽带网络业务管理子系统等等,以对各种不同业务实现自动化管理。这些对各种子系统的投入和建设无疑及时提高了公司的管理效率,但同时,这种对多套系统建设的方式无形中加大了成本,对系统的运行和维护增加了很多难度;使用这样的多套系统,用户资料分散,每个系统都有自己的数据库,各数据库中的用户资料之间没有关联,每个子系统的业务产品之间也没有任何关系,用户对各种服务的缴费均要分开结算,当然也无法实现运营商产品捆绑等销售策略,这无疑阻碍了业务市场的扩展和公司的发展。

BOSS系统功能提升可以有效解决这个问题。BOSS系统的提升不仅方便广电系统开展各种新业务,还能完善其运营模式。BOSS系统的提升不仅加快广电系统的产业化进程,还能提高运营管理水平,提高核心竞争力。因此,BOSS系统的提升为各大运营企业提供了可靠的、统一的业务运营支撑环境,且更加灵活。在三网融合大环境下对BOSS系统的提升有利于我国广电事业的生存与发展。

2 BOSS系统提升原则

BOSS系统提升建设应当遵循以下几点:

(1)使能化。由于业务运营企业运营过程中不断精细化,应该将IT信息技术与业务运营企业的经营与发展策略紧密结合,以适应市场日益激烈的竞争。同时,提升的BOSS系统应该具备灵活度、响应速度以及支撑能力。

(2)网络化。应该对运营企业突破地域限制,提供全网统一化运营技术支撑。

(3)互动性。提升的BOSS系统能与各商业银行的业务系统无缝对接,除了有线电视自助缴费外,还应实现广电账户与各个商业银行之间其它相关业务的对接。

(4)安全性。BOSS系统应设置各种安全的、可靠的策略,如预防系统突然崩溃的备份和恢复策略,阻止可疑数据包的防火墙策略等。BOSS应用系统还应具备良好的可维护性,实现实时的在线监控以及快速的故障处理等。

(5)界面友好。BOSS系统应具备友好的界面,保证操作简单。

3 BOSS系统框架结构及层次划分

提升的系统采用当前流行的B/S结构,体现出系统的简便性与安全性。该设计只需一台带有浏览器的计算机连接互联网,便可以使用安装了浏览器的客户端进行操作。为了增强系统的可扩展性,在系统中使用商业级别的中间件WebLogic。为了提高系统的安全性,在系统结构中增加了防火墙设置。除此之外,系统中设置了各种安全策略,安全访问控制,只允许已经登记在系统中具有权限的计算机才能访问系统。

根据BOSS系统提升的基本功能,系统划分为3个层次:数据层、业务层、接入层,如图1所示。

(1)接入层。该层主要为客户端服务,为客户端用户提供人机交互界面及与其它系统的接口。

(2)业务层。该层主要负责处理各种标准核心业务数据处理如计费与账务等,还负责与其它外部业务处理,如与商业银行进行对接等。该层还负责与接入层之间的业务调度及与数据层之间的数据调度等。

(3)数据层。该层主要为数据存储服务,包括存储业务及用户的各种数据,还可利用接口服务器连接到数据库,取得数据。

4 BOSS系统提升功能模块设计

BOSS系统提升功能划分为如图2所示的几大管理模块。

BOSS系统提升功能架构自上而下各层功能:第一层为用户接入平台,第二层为业务管理、业务开通以及接口管理,第三层为工作管理,第四层为数据管理,最底层为IT基础平台。接口管理主要负责与内外其它系统的接口。BOSS系统提升将工作流平台作为系统底层平台,通过消息总线调度业务管理、工作管理和数据管理的各个模块功能,实现对业务流程的管理。

5 BOSS系统提升技术

(1)J2EE技术。BOSS系统提升采用的平台是业界主流的J2EE平台。J2EE不仅支持各种平台,还支持多种规模。系统采用的设计模式为MVC,其中M对应数据层,V对应视图层,C对应控制层。该模式把一个应用的输入、处理以及输出流程分离为模型层、视图层、控制层3个层次。按照这种设计模式,可以减少代码复制,减少代码维护量,即使模型改变了也能很容易进行维护［２］。

(2)主流CA接口。为了更加方便快捷地进行用户接口开发,系统采用了多种主流的CA接口和付费接口。在信息系统使用中不可避免会出现各种故障及错误,为了更加有利于故障排除以及错误信息的追踪,系统提供很多种日志记录信息,这些日志记录能制约人员的错误操作及非法操作。

(3)Oracle数据库技术。结合BOSS系统相关业务特点,选择Oracle 10为数据库管理系统。

(4)B/S结构。B/S结构最为显著的特点就是界面友好,操作起来非常简单。在系统设计时就已经考虑到用户的操作习惯,设计了友善的人机界面,使用很简单的操作步骤便可实现系统功能。

(5)工作流技术。运营管理系统是BOSS系统的一个重要组成模块,该系统是基于工作流技术的。基于工作流技术的管理系统已经成为现代企业应用系统不可或缺的重要组成部分［３］。

6结语

面向业务单一的企业内部业务运维管理系统适应广电业务的多样化需求。本文从三网融合下的BOSS提升重要意义入手,系统阐述了BOSS提升系统的架构和功能。BOSS提升使用业界普遍采用的J2EE平台技术,集成EAI技术以及工作流技术等,结构设计合理,具有友好的操作界面。基于集群环境设计BOSS提升系统技术成熟、稳定以及网络化,具有良好的可扩展性及灵活性,能够支持多种业务接口,经过多次测试,收到了预期效果。该系统能够很好地满足多业务运营需求,进一步提升了企业的运营管理水平,具有一定的推广价值。

摘要：分析了三网融合下对BOSS系统进行提升的必要性,在此基础上对BOSS系统提升原则、框架结构以及关键技术进行了分析与探讨。BOSS系统的提升,很好地满足了多业务运营的需求,提升了各大运营企业的运营管理水平,具有一定的推广价值。

关键词：三网融合,BOSS,系统提升

BOSS系统日志分析研究与应用篇2

当前营业员和用户在业务支撑系统 (简称:BOSS系统) 办理业务出现问题和故障的时候, 通常由用户打10086投诉或者营业员报障给后台维护人员进行故障分析和处理。这个处理流程很耗时间, 影响问题的解决效率。

在BOSS系统的各个渠道查询或受理业务的过程中, 都有可能会因网络、数据库、应用系统等各方面原因抛出异常错误信息, 这类错误信息记录在BOSS系统各主机的日志文件中, 由于BOSS系统每天产生大量的日志文件, 从日志文件中定位查找错误信息需要花费大量的时间, 对维护人员处理问题和故障带来不便, 影响问题的及时发现和处理实效性。

2 研究思路

考虑从主机的日志文件中及时地收集到这种系统异常错误信息, 并自动入库进行分析, 维护人员就能及时的了解BOSS系统当前的运行情况, 发现系统问题, 查询错误信息, 能够在营业员或客户投诉之前就可以去核查解决, 提升问题处理的及时性和效率, 保障系统健康稳定的运行, 从而提高系统业务支撑水平, 提升营业员和客户的内外部满意度。

3 实现方案

建立BOSS系统日志分析管理平台, 对BOSS系统主机产生的各种日志进行日志异常分析和日志管理, 针对主机系统产生的大量日志文件进行处理:日志采集, 日志管理, 日志分析, 日志综合告警执行以及执行前流程审批权限设立、分析结果处理执行中的流程跟踪、分析结果处理执行后的日志留痕。通过日志分析管理平台, 维护人员能够方便的查看日志的分析结果、以及日志异常产生的次数和时间段, 如系统错误产生的次数、产生的时间段、业务执行人员信息记录、业务执行影响等信息, 从另一个角度去分析主机的稳定情况以及运行效率, 以往一些不容易察觉的异常信息, 通过对日志分析规则的配置和数据采集, 也会在系统中体现出来, 从而提高系统维护管理的水平。

3.1 日志分析平台系统架构

系统架构说明:

1) 采集客户端:运行在生产主机上的采集客户端程序, 负责收集相关日志, 预处理并通过socket方式发送给采集服务端。

2) 采集服务:采集服务端对消息进行缓存, 由消息处理器进行异步处理, 生成消息首先放入内存, 同时发给实时告警, 当内存中的记录数达到配置的阀值时写入文件数据库。

3) 告警处理:实时告警收到消息后根据告警规则配置进行处理, 并将结果入库。

4) 查询服务:查询服务接收web端和统计进程的查询请求, 从文件数据库和采集服务端的内存中查询符合条件的记录返回给调用端。

3.2 日志分析平台系统功能

系统功能说明:

1) 日志监控采集:从各渠道的业务主机上实时读取新生成日志信息。由于BOSS系统各台主机上每天生成的日志信息量很庞大 (达到830G) , 因此部署的客户端程序要能够实时采集日志, 并且对主机性能不会造成大的影响。设计上采用客户端部署日志爬虫程序, 实时采集日志并传送给服务端, 采集传送时间<5分钟, 并且程序运行对主机资源的消耗<5%, 对生产主机的性能影响可忽略不计。

2) 日志规整处理:对采集完成的的日志文本信息, 按照既定格式统一进行规整处理, 便于后续的存放和分析。

3) 消息缓冲处理:将规整好的日志信息, 送入待发往消息中心的缓冲区中。

4) 消息发送处理:将缓冲区中存在的日志信息, 取出发往消息中心;对发送出错的消息, 记录关联信息到错误重发文件中。

5) 错误重发处理:根据错误记录文件检索需要重新发送的日志信息, 将消息再次发送。

6) 日志分析处理:对日志进行分析, 从有利于维护人员定位分析问题的角度出发, 全方位提取错误的信息并进行归类分析, 如业务调用路径分析、业务调用关系分析、调用函数分析、异常效率分析等, 对分析出来的信息在WEB界面进行关联展现, 便于对信息全方位的查看和分析。

7) 统计告警查询:根据错误信息进行归类, 达到一定阀值的进行告警 (阀值可以进行手工调整) , 对告警的详细信息在WEB界面进行统一展现, 并对错误信息进行统计, 对外提供查询。

3.3 系统处理流程

从总体流程来看, 整个日志处理过程分为三大部分:

1) 采集流程:通过采集配置-日志采集引擎根据配置信息从指定主机日志文件中采集关键信息-持久化采集信息-数据入库。

日志采集要求对多个大容量的日志文件进行实时的采集, 采集的方式主要以全量采集和增量采集为主, 可开启多个采集进程进行同时采集, 采集引擎根据配置信息里的采集关键词, 以及需要采集的日志文件名称, 在对应的主机日志文件中查找存在关键词的行。

2) 告警流程:当采集的信息数量达到事先设定的阀值时, 会产生告警信息 (包括发送短信到维护人员手机和页面告警两种方式) 。

3) 分析流程:业务日志分析查询-日志分析程序分析采集信息-得出分析结果-返回查询操作-用户查看分析结果视图。

以上日志采集、告警和日志分析组成了整套日志采集分析流程。在采集时只需要添加采集配置信息以及采集关键词, 后台采集程序即会自动根据配置信息, 到相应的主机日志文件中采集, 无需人工干预。当采集的信息数量达到事先设定的阀值时, 会进行告警 (见图4) , 同时将采集信息入库。采集信息入库后, 要查询日志关键信息, 只需要登录日志分析管理平台进行查询 (见图5) , 查询方式可以按天, 按日志文件名, 产生日志的日期等。平台会自动根据日志采集信息生成统计图型, 方便维护人员对一段时间内的采集信息进行评估, 并提供日志信息导出功能。

4 应用效果

BOSS系统日志分析管理平台2011年12月上线后, 通过部署在CRM系统一台中间件主机上的日志采集客户端程序对日志文件进行统一采集, 发送到日志分析服务器上进行统一管理和展现, 取得较好的应用效果:

1) 采集处理对中间件主机的CPU使用率的影响很小 (<5%) , 可以忽略不计, 满足性能要求。

2) 提升工作效率:维护人员通过日志分析平台的前台界面查看日志信息, 节省了维护人员频繁登录各台主机搜索日志的大部分繁琐的工作。平台上线前, 维护人员面对庞大的日志记录, 定位目标信息至少需要15分钟;平台上线后, 维护人员在系统上选择对应主机IP和关键词信息即可查看日志信息, 1-2分钟内即可定位, 日志信息定位效率提升10倍以上。

3) 加强系统监控:平台上线前维护人员需要手工登录各个系统, 并查看刷新的日志记录是否存在异常, 大量异常信息无法实时捕捉到, 无法进行系统的实时监控;平台上线后, 日志采集程序在各个主机平台实时采集分析日志信息, 实时定位异常信息点, 并告警通知相关维护人员, 保证了各系统7*24小时的实时监控, 提升了系统的稳定性。

4) 缩短故障处理时间:平台上线前, 故障处理人员需要登录对应主机, 查看系统日志进行故障分析, 过程需要20分钟甚至更久;平台上线后, 故障处理人员只需登录平台系统在监控和告警管理界面能查看故障信息, 就能进行故障定位, 只需要5分钟甚至更少时间, 故障定位处理时间缩短15分钟以上。

5 小结和展望

日志分析管理平台对BOSS系统的日志信息实现了统一配置采集, 统一日志信息展现, 去除人工搜索日志信息带来的时间浪费, 维护人员不用再登陆到各个主机上搜索日志, 只需登陆到日志平台查询各种日志信息, 减少重复的人工操作和对主机资源的浪费;平台对采集到的日志进行错误信息实时告警, 方便了维护人员对故障问题的发现、定位和解决, 提高问题解决的实效性, 对提升前台和客户满意度起到较好的效果。

2012年6月, 日志采集客户端部署在CRM三台中间件主机上运行。后续将根据实际使用情况部署到其他主机上运行。

参考文献

[1]《广西移动BOSS应用服务评估分析项目技术建议书》神州数码思特奇信息技术股份有限公司[Z].2011.

[2]《广西移动BOSS应用服务评估分析—BOSS系统改造项目技术建议书》亚信联创科技 (中国) 有限公司[Z].2011.

BOSS系统提升研究篇3

关键词：业务支撑系统,DNS,高可用技术,跨数据中心

1 引言

1.1 DNS技术在BOSS系统中的重要性

随着DNS技术在BOSS系统中的应用越来越广泛, 其在简化BOSS系统管理和维护工作、提高BOSS系统应急容灾切换效率等方面的效果日趋显著, 同时, DNS自身的容灾和高可用保护手段也越来越重要。

目前, DNS技术广泛应用在BOSS系统的外部接入上, 用于提供对外服务的域名。在BOSS系统内部, 由于系统规模越来越庞大、结构越来越复杂, 因此对DNS技术的需求也越来越迫切。以某运营商为例, 经过几年的高速发展, 目前已经拥有600台小型机分区、400台PC SERVER、60套数据库;从结构上又分为接入层、web层、应用层、数据库层等, 每层之间存在大量的连接关系, 需要进行相关的管理配置和维护。如果采用传统基于IP的配置连接方式, 需要分散到很多设备中进行管理连接关系, 造成IT架构复杂, 配置变更时工作量很大;在BOSS系统进行应急容灾切换时, 由于涉及大量系统配置变更, 造成切换时间过长等问题。

采用DNS技术后, 由于可以实现将分散的IP复杂连接关系变为域名方式进行集中的管理、维护, 因此能很好地解决上述问题, 但另一方面也造成DNS本身变为BOSS系统的一个非常核心、重要的部件, 所以必须充分考虑其自身容灾和高可用保护手段。

1.2 当前DNS技术的局限性

传统DNS自身保护手段存在较大弊端, 出现故障时接管延时较长或需要较多配置修改, 难以实现跨数据中心的高可用。

为解决DNS本身的高可用问题, 目前一般采用主/备模式或数据中心内部高可用模式, 能在一定程度上获得高可用性, 但仍然存在问题。譬如, 当首选DNS无法提供解析服务时, 每次系统仍会首先尝试通过首选DNS服务器获取服务;只有解析操作失败后, 才会从备用DNS服务器进行解析。这就造成当主用DNS服务器失效时, 每次解析都会有一定时间的延时;当业务量比较大时, 尤其是短连接类业务可能会出现大量超时。再如, 采用数据中心内部的高可用模式, 能在数据中心内部出现单点故障时获得DNS的高可用保护;但在整个数据中心出现故障的情况下, 则没有保护或者只能采用主/备模式, 存在较大的运行风险。如图1所示。

2 解决方案

为解决上述问题, 某运营商BOSS系统使用跨中心DNS集群方式以实现高可靠性DNS组网。在DNS故障时, 无需做任何干预, 首先在同数据中心实现本地接管;如有问题则自动跨中心接管, 中间几乎无数据丢包。

在此基础上, 将BOSS系统内部IP的配置统一修改为域名方式, 结合少量应用的优化改造, 实现在DNS集群中对域名、IP进行集中管理, 包括外部接入、主机连接、数据库连接等。同时, 在BOSS系统应急容灾切换过程中, 不需要直接修改每个应用的连接配置, 只需在DNS中修改域名和IP的对应关系, 从而避免了应用的重启, 使应急容灾切换时长大大缩短。

2.1 跨数据中心DNS集群搭建

利用4台硬件负载均衡器, 构建跨数据中心的DNS集群, 基于VRRP协议, 实现实时切换和BOSS系统连接关系的集中化管理维护, 在共青团和开发区中心分别部署2台负载均衡设备。其中, 开发区的2台负载均衡和共青団的其中1台负载均衡形成一个VRRP组, VRRP组的虚地址是提供DNS服务的IP地址, 该跨站点集群, 作为主用DNS;另一台共青团中心的作为单独的备用DNS服务器。如图2所示。

DNS设备集群通过浮动IP提供DNS解析服务。平时浮动IP位于开发区中心主用设备。当开发区中心主用设备出现故障时, 服务由开发区中心另一台备用设备接管;当开发区中心两台设备不可用或中心网络无法访问时, 共青团中心的备用设备接管服务, 从而实现了跨中心的负载均衡冗余。

发生故障时, 先切换到本中心备用设备;如果数据中心故障, 就切换到另一中心的备用设备, 切换过程中IP保持不变, 使客户端应用无感知。备用DNS可提供极端情况下的应急, 也可以手工修改IP代替主用集群工作。

实际测试证明:

(1) 切换测试中, 浮动IP切换时间在4秒内;

(2) 切换后, DNS服务正常;

(3) 随切换测试进行压力测试, 业务未受影响。如图3所示。

2.2 应用进行适应性改造

结合构建跨中心DNS集群, 进行BOSS系统适应性改造, 实现内、外部链接关系由IP方式修改为域名方式。

(1) BOSS系统内部连接关系梳理

进行BOSS系统内部连接关系梳理, 共涉及302个改造点, 见表1.

(2) BOSS系统的配置修改

需要对BOSS系统主机进行配置修改, 包括对主机配置、解析顺序等进行变更。

对UNIX主机, 需要配置/etc/resolv.conf和/etc/netsvc.conf文件;对LINUX主机, 需要配置/etc/resolv.conf和/etc/nsswitch.conf文件。以AIX主机为例:

修改/etc/netsvc.conf时, 需注意=号旁边需留空格

nameserver后面配置的IP为DNS集群VIP。所有客户端2个nameserver配置的顺序为先主后备。

【配置文件权限修改】

用以下命令修改刚才配置的DNS配置文件的权限, 否则会导致数据库联接异常。

(3) 对BOSS应用的改造和修改

对应用的修改和适应性改造部分, 主要包括:

1) 修改web服务器jdbc配置文件, 将IP访问改为域名访问;

2) 修改交易中间件和应用服务器等主机上的配置文件tnsnames.ora, 将其中通过IP方式访问数据库的部分修改为通过域名访问;

3) 修改应用内部相关配置文件如*.conf, *.xml等, 将其中通过IP访问数据库改为域名方式;

4) 对应用进行适应性改造, 支持自动重连技术, 即:在因各种故障下连接失效的情况下, 能支持一定间隔后的再次尝试连接。

另外, 应用实现了自动重连后, 可实现在DNS服务器上IP变更后应用无需重启, 从而大大简化维护复杂度, 有效节省容灾切换时间。当然, 需要梳理出不支持自动重连的应用和中间件, 然后逐一改造。

2.3 本方案技术关键点

主要是跨数据中心二层网络打通和心跳技术考虑。首先, 由于是跨站点集群, 要求能够使用如网络心跳等可以远距离连接的心跳技术, 而不能使用串口等心跳。其次, 多节点集群考虑。考虑到跨中心网络、传输等的可靠性低于本地连接, 因此应使用至少3个节点, 这样既保障本地热备可靠性, 又能实现跨中心切换。第三, 需要跨中心二层网络打通。因为一般网络心跳技术要求集群内设备在同一子网, 如图4所示。

2.4 脑裂现象考虑

由于集群跨数据中心, 因此需要采取手段以防止集群出现脑裂现象。本方案通过几种方式进行规避:一是将DNS集群部署在单独的VLAN子网中, 对外通过路由访问。二是在网络设备层, 通过技术手段 (如优先级设置) 保证网关唯一。当发生类似跨中心间网络中断故障、出现“双主”情况时, 因为整个网络路由网关唯一, 所以保证了只会有一个站点的DNS服务器仍能对外提供服务。三是通过构建多中心互联环状全冗余架构, 实现网络稳定性, 避免脑裂现象, 如图5所示。

3 运行效果

通过构建跨数据中心DNS集群, 在BOSS系统运维方面效果显著。

(1) 实现跨数据中心的DNS无缝切换机制

基于VRRP协议构建的跨数据中心DNS集群, 实现了数据中心内部和跨数据中心的DNS自动保护机制, 无需客户端做任何配置修改, 且零时延。

而传统DNS方案, 由于缺乏跨数据中心保护功能且无缓存功能, 在主用DNS故障下链接备用DNS时, 每次都要尝试链接主用DNS, 导致等待超时, 短链接效率很低, 且配置维护复杂。

本方案支持跨数据中心实时切换, 全自动、效率高, 且基于硬件, 时延几乎为零, 维护工作量低。

(2) 实现BOSS内、外部连接关系的集中简单管理

通过将BOSS系统内、外部连接关系改造为DNS方式集中管理, 实现了系统变更、设备入网等场景下的“一点维护、全局生效”功能, 解决了庞大系统架构下的运维复杂难题;在进行配置变更时, 需要维护的主机、应用、中间件等变更点大幅减少。如图6所示。

(3) 实现应急容灾系统的快速接管和切换

BOSS系统通过DNS集群建设, 结合应用适应性改造, 在应急容灾切换场景下大幅缩短了容灾切换时长, 简化了操作步骤。

1) 无需应用重新启动:可通过DNS集中切换IP, 新链接直接连到容灾端;

2) 无需应用修改配置:DNS集群中集中修改IP, 无需专门在每个主机上修改;