广电BOSS（共7篇）
广电BOSS 篇1
BOSS系统作为软件层面的解决方案在本届CCBN展会中的位置不是很醒目,而广电厂商纷纷推出呈整合性特点的BOSS系统,融合了广电数字电视等业务和电信宽带等业务,并且已经在一些市、县级广电运营商中得到应用。但目前尚没有统一的标准,各地市均自成体系,造成一些资源浪费的问题。
整合广电和电信业务特点
CCBN2012上广电厂商展示的BOSS系统的特点是整合了广电和电信的业务,除了传统的互动业务和VOD业务,还加入了自助服务业务解决方案,支持网上营业厅、短信订购、充值卡系统和呼叫中心系统。据了解,大多数厂商自去年下半年便开始了这项工作,并且已与一些县级广电运营商合作应用。
例如数码视讯的GTBOSS运营支撑系统整合进了基于广电的VOD和基于电信的宽带用户管理等三网融合业务解决方案,以及套餐管理和区域定价管理等基础业务解决方案,同时也支持充值卡和呼叫中心系统等自主服务业务解决方案,是基于“三户模型”的架构。据介绍,此系统已经在上海及浙江的一些省、市、县级地区广电运营商中应用。
借鉴电信标准
广播电视规划院秦所长表示,由于广电之前的业务单一,随着各种增值业务的增多,广电的BOSS系统也在升级。需要借鉴电信运营商的国际BOSS系统标准,但是也要结合广电特殊的业务形式进行整合。
永新视博此次展出的广电综合业务支撑运营系统可以同时定制广电增值业务和IPTV业务,采取多业务的产品套餐和组合营销策略。据了解,目前负责这套BOSS系统的技术总监便拥有电信BOSS系统技术背景,借鉴电信BOSS系统技术经验,负责整合广电和电信业务支撑系统。另一方面,由于广电厂商更了解广电内容的制作流程和播出方式,拥有非常丰富的经验,不能从电信运营商那里照搬解决方案。
广电运营商区别于电信运营商BOSS系统最大的特点是在计费或增值业务支撑上,广电运营商比较注重内容。据永新视博介绍,他们已经做过上千个运营商的BOSS系统,此次展出的广电综合业务支撑运营系统提供融合计费、支持包月、按次、按时长、按流量等计费方式,以适应广电业务的打包计费方式。同时,支持Pro DRM数字电视授权、VOD以及宽带、互动游戏等增值业务的统一接入与统一认证。
资源存在浪费问题
通过采访了解到,目前BOSS系统存在的主要问题是资源浪费。广电厂商在软件和硬件上都进行了升级,可以支持多用户点播的需求,然而目前的用户数尚没有那么多,造成很多资源浪费。
目前广电和电信双向进入前景尚不明朗,并且广电厂商BOSS系统建设经验落后于电信运营商,广电厂商的整合性解决方案也是各做各的,应用于小范围的运营商。有业内人士指出:“NGB整体架构标准和全国运营主体的缺失,将成为广电系统在‘三网融合’初期最大的考验。对等的双向准入政策,可能会引发新一轮的网络建设高潮,造成大量的低水平重复建设。”
广电BOSS账务管理体系的构建 篇2
在市场竞争异常激烈的今天, 广电业务也随之拓展, 不断延伸, 由传统模拟电视单业务, 到数字电视、宽带、互动电视等多业务。传统模拟电视业务无法自动控制到户, 导致欠费用户停机、收费工作开展起来十分繁琐, 艰难。数字电视、宽带及互动电视作为新业务, 给广电带来了新机遇和新的技术变革。广电业务复杂和多样性同时也带来了业务计费的更高要求。网络多用途化的结果是广电企业同时承担多重较色, 而企业角色的体现便是计费的多样化。BOSS系统的搭建使广电运营能力得到更好提升, 更能快速响应用户的诉求及更好、更直接的控制到户, 而计费系统部分成为运营系统中一个不可缺少的核心, 在这个核心基础上, 所有业务办理变得简单易行, 用户的缴费及开通只需一个电话, 通过银行实时划扣即可完成, 用户欠费停机无需再人工上门剪线, 只需后台完成用户账务检查后的指令发送。
1 广州广电BOSS系统计费总体技术架构
BOSS系统采用了TNA技术无关性总体架构, 为提高系统效率, 计费账务系统将计费和帐务进行统一和融合。通过减少系统间错综复杂的接口, 提高数据和信息的实时性和准确性。
基于统一的架构和体系, 实现了从数据采集、融合计费处理引擎、实时帐务处理等一气呵成的处理流程, 并且增加了出错自动回滚等稽核保障机制, 整个技术架构主要分成系统管理层、业务处理层、数据层, 如图1所示。
计费帐务系统支持对全业务的融合计费, 尤其是对业务交叉捆绑的支撑能力非常强。不同的业务、不同的采集记录信息, 不同资费批价和组合优惠, 都可在同一计费平台上完成处理。其采用的融合计费引擎驱动技术实现机制, 屏蔽了以往的业务直接驱动的种种弊端, 使业务运营支撑能仅关注于引擎驱动的流程而无需关心具体的业务数据, 实现了相对稳定的计费流程固化。灵活的优惠引擎和实时触发、参数驱动的实时帐务机制, 满足某些业务对实时帐务的需求。而基于文件的记录组织, 保证了使用记录高效的存取、用户方便的使用, 节约了磁盘空间。参数化与插件化相结合的技术手段, 提高了系统的灵活性与可扩展性。融合计费引擎技术实现机制如图2所示。
2 计费系统功能
计费系统主要实现的功能有:
1) 多业务的融合计费;
2) 综合帐务处理和帐务管理;
3) 分摊结算。
计费系统主要面向有线电视网络多种业务提供服务使用记录的计费功能:数字电视、双向交互数字电视、有线宽带、Vo IP的统一计费。由于个性化营销以及客户需求, 会出现业务之间的交叉捆绑, 要求Billing必须具备融合计费的功能, 通过融合计费实现多业务的统一计费优惠、预付和后付融合等要求。
计费系统一个重要功能是为CRM提供客户帐单, 客户帐单作为客户使用付费的凭据, 是广电企业业务运营过程中的重要数据。为了满足日益增加的业务需求和客户需求, 计费能够提供多样的帐单生成方式:月结帐单、实时帐单、集团帐单等等, 同时根据企业运营的需要或客户个性化需求提供不同格式可自由定制的帐单以及灵活的、引擎驱动的多种优惠。
计费系统还提供面向内容提供商、第三方的分摊结算功能, 由于整个有线电视运营价值链的复杂化, 可能出现代理商、内容提供商、虚拟运营商等价值链参与方, 广电企业作为整个价值链的主导方应该为价值链有序运营提供可靠的保障手段, 要求计费系统必须具备支撑复杂价值链运营的分摊结算功能。分摊结算实现对多个价值链参与方的分摊结算关系的支撑, 支持灵活多变的分摊结算比例、结算优惠等。
BOSS系统账务系统产品功能域, 如图3所示。
3 广州广电新业务账务管理概况
3.1 各项业务计费规则
数字电视:计费周期为自然月, 月初预收当月费用;
宽带:计费周期为自然月, 可按日计费;
互动电视:月租计费周期为自然月, 月初预收当月费用, 点播等费用月末结算。
3.2 账务管理总计流程及部分流程说明
账务管理主要由计费 (即出账预演、月结、预出账) 、银行托收、欠费停机及结算等部分组成, 其总体结构如图4所示。
1.计费作为后续业务受理、银行托收、催停等工作的基础, 准确性尤其重要。计费系统月结计费流程有62个步骤, 每月月结出账平均用时7个多小时。计费流程中的每一步骤必不可少, 其为计费提供准确无误的保障。计费主要分为三个阶段:
第一阶段是准备阶段, 做本月出账前的准备工作, 从每月最后一天晚上7:00开始;
第二阶段是本月费用的计算, 生成最终用户账单和对账单进行欠费冲销, 要求是必须在每月最后一天的23:58分前开始执行, 一般用时2小时左右;
第三阶段是对下月用户费用进行预出账, 要求是必须在下月第一天进行, 一般用时3小时。
2.银行托收为企业资金回笼的重要环节, 也是后续停机工作的基础, 因此高效的扣费效率, 灵活的送托方式, 根据送托结果分析, 重新调整再次送托数据及方式, 方为确保高银行收费率及企业利益得到有效保障的方法。
1) 银行托收的灵活配置
为便于用户可缴纳各项业务费用, 广电企业支持多家银行代扣费业务, 而代扣渠道因各方面原因制约, 无法与相应银行均签署代扣协议。为确保收费率, 需拓展多家代扣渠道, 并在实际托收过程中需根据实际情况不断进行调整。因此, 在银行托收过程中, 灵活的系统配置方可满足当前广电企业的要求。
良好的账务管理须有完善灵活的后台支撑, BOSS系统银行托收模块有灵活配置功能, 见图5。
2) 银行托收可分为几个步骤进行
(1) 月初托收:即每月2号根据计费系统最终落地费用对办理银行托收的用户生成送行数据。根据后台配置各行代扣对象, 生成相应格式的送托文件进行扣费;
(2) 托收数据返回处理:银行托收数据文件返回后, 根据托收方式, 使用不同方法对文件进行入库处理, 入库数据需与银行汇总扣费情况可对无误后, 方可进行BOSS系统销账处理;
(3) 二次托收:各类银行扣费文件返回入库后, 对失败数据进行分析, 对非用户账户原因的数据重新生成送托数据, 送至不同于月初托收代扣对象进行扣费。
3.催缴停机工作对新业务的支撑起了重要的作用, 与传统的催缴方式相比, 新的催缴停机除了极大程度地节省人力物力, 还十分有效的达到预期的提醒、停机效果。
1) 催缴停机工作简介
催缴停机是由于用户已经或者即将产生欠费时, 系统对于用户进行的信控操作;
催缴停机主要用于在用户即将或者已经产生欠费时, 提醒用户交费, 用户逾期不交费时进行停机, 以减少用户产生的欠费。
2) 总体流程及关键点说明
总体流程如图6所示。
关键点说明:
催缴:对数字用户和互动电视用户, 发送催缴邮件指令到CA服务器上, 最终发到终端。对于预存不足指定数额的宽带用户有提醒功能。
停机:对欠费用户进行欠费暂停。
根据用户缴费方式不同, 处理方式会有所区别, 对于现金缴费用户, 计费后在指定时间即可进入催缴停机队列, 并进行停机处理;对于银行缴费用户, 需待银行扣费返回处理完毕后属于用户原因扣费失败的数据方可进入催缴停机队列, 而非用户原因扣费失败的数据仍待二次扣费后处理。
根据各项业务不同的计费规则, 于不同时间分别执行停机工作。如数字及互动的催缴工作于月中前开展, 停机于每月16日执行, 停机的结果是将用户的收视服务暂停, 有只停节目的类型, 而宽带的停机工作则于计费后立即开展。
停机前扣费:停机前再次尝试对用户托收, 避免用户银行账户充钱后仍被停机, 对于扣费成功用户终止停机工作, 扣费失败用户继续进入停机流程。
数据检查:系统生成催缴或停机数据后, 在各个关键时间段, 从各个角度进行核查, 避免错、漏情况出现, 以确保欠费用户百分之百催费及停机。
4 结束语
广州广电BOSS账务管理体系是结合实际运营管理经验构建的。经过多年的实施及考验, 证明该体系流程完善、稽查方法科学合理, 能够有效提升企业的运营能力, 成为广电企业高速发展的有力支撑。
摘要：广电经过多年的模拟历程, 现已进入了数字时代。数字时代带来了业务上翻天覆地的变革, 以往单一业务模式被打破, 形成了模拟、数字电视、互动电视和宽带并存的多业务格局。由于网络多用途化带来的各种新业务需求都对现有运营模式带来严峻的考验, 传统的模拟有线运营方式已经远远不能满足新业务需求。本文结合广州广电BOSS系统及实际运营管理模式, 介绍新形式下BOSS账务管理系统的构建, 并对其架构、功能、流程等方面进行详细阐述。
广电BOSS 篇3
一、BOSS系统的总体设计
1. 设计的基本原则。
在设计广电BOSS系统时, 依据广电的基本业务构架, BOSS系统的整体设计可才遵循“一个中心、三层结构”的基本原则, 其中所谓一个中心是指在设计过程中将计收费处理、结算处理、营业受理、信息统计、业务管理以及账务管理等各种数据资源进行合理的统一规划, 进而使得BOSS系统逐渐形成一个综合化、统一化、信息共享化以及模板化的支撑系统;“三层结构”是在设计和构建系统时, 其逻辑结构应遵循相应的三层标准, 即接入层、业务逻辑层、数据核心层。
2. 系统逻辑结构。
BOSS系统的内部构架中, 开放性的接入层、灵活性的业务逻辑层以及信息数据相对集中的数据核心层等三层结构共同构成了系统的逻辑结构, 其中结构中的数据核心层又可以分为服务子层、数据子层, 而且两个层次之间实现了其功能模块的互联调用, 此外, 各个层次的内部也使用其各自的功能模块结构。
(1) 数据核心层。在整个BOSS系统中, 数据核心层是其基础, 它的主要任务是将客户的档案、相关账务以及业务等信息资料数据进行集中统一存储, 同时将包含个人用户资料、使用记录以及服务记录在内的全部信息数据集中统一起来, 形成一体化的“统一的数据中心”, 但是在这个环节中, 所需数据的输入和输出都是通过其中的服务子层来完成的, 该层通过操作和访问相应的数据子层, 以实现以相同的接口方式, 为业务逻辑层提供其所需的基本数据以及相应的功能服务。
(2) 业务逻辑层。业务逻辑层是支撑整个系统正常运行的逻辑平台, 它通过对系统内部的相关原子服务进行重新组合来实现对数据核心层的各种信息数据进行相应的操作, 并使得各种应用功能模块逐渐适用不同的业务的业务需求, 此外, 它可以依据其功能划分成为多个业务模块, 比如受理业务模块、计收费处理模块、账务管理模块等。而且系统中的具体业务模块是通过调用其内部的相关原子服务功能来实现, 如果日后运营商推出其他新业务时, 只需要在原系统的基础之上增加相对应的业务模块以及相关的调度规则以及业务逻辑即可。
(3) 接入层。在BOSS系统中, 接入层是其客户界面, 也是运营支撑系统实现与外部相关数据进行交换的平台, 而且它包含了客户同系统进行相互交互的各种手段, 在这个环节中, 是准许客户使用各种多样、灵活的接入方法与业务逻辑层相关联的, 而且为了更好地实现服务的多样式, 满足客户的个性化、多样化以及跨区服务的要求, 客户可以直接通过相应的营业厅、电话等多种不同的方式连接到BOSS系统, 此外, 为了更好地将客户统一接入的概念体现出来, 在构建系统时可以使用Potalr技术来实现多种接入方式的统一连接接入。
一个中心、三层结构的基本建设原则, 在一定程度上确保了系统中存储数据的唯一性以及统一性, 而且也为客户提供了较为规范、完整的服务, 杜绝了只有一个客户却有多个账单产生的情况。此外, 系统内部的三个层次, 它们每个层次都需要完成不同的功能, 并依据系统内部逻辑上的不同组合来, 满足系统运行过程中所需的业务功能, 并在一定程度上提升了系统的灵活性以及可扩展性, 同时也符合运营商相关业务变化和发展的需求。
二、BOSS系统的维护开发方案
BOSS系统在设计、研究、开发完成之后, 伴随着业务量以及业务板块和经营模式的不断变化和调整, 因此广电网络的BOSS系统还需要不断升级和改革, 所以这就要为我们依此制定一套科学、完整的维护方案。
1. BOSS系统的版本管理。
对研究开发中的应用型业务系统软件, 其版本管理的任务主要是通过频繁的软件测试、修改以及相应的版本更新等, 对于已经开发完成的应用型系统软件, 其版块管理的任务主要是对软件进行升级、并更新软件功能以及设立相应的文档资料等。其中版本管理的基本要素有:软件的名称、版本号、使用时间、检测时间以及源代码本号等。
2. 对系统中技术资料进行相应的归档处理。
在业务系统软件投入使用之后, 要进行相应的归档处理, 各个版本之间的安装程序、信息参数、源代码以及软件文档等都需要进行分类处理, 并配分统一的归档编号, 认真保存, 此外还应依据实际情况填写相应的软件安装记录表。
对软件进行修改和调整时, 应有与其相对应的文档说明, 说明内容包含新版本与旧版本之间的功能差异以及相应的修改方案, 此外在修改源代码时, 需标注修改的人员以及日期。而对于业务系统内部的配置参数以及源代码要进行加密处理, 未经批准, 不得擅自借阅或复制。
3. 制定科学、合理的应用软件维护作业计划。
对BOSS系统制定相应的软件维护作业计划实际上就是对系统进行主动维护, 提高系统的使用性能并尽可能的降低系统故障发生率的有效手段。
在通过统计业务系统进行相应的业务数据统计分析时, 查询和找出系统在处理某些数据时遇到的瓶颈, 针对出现的瓶颈, 制定一个科学、合理的维护作业计划, 主要通过平衡负载或者增加资源等有效措施。
在通过分析业务系统在对相关业务数据进行分析整理时, 应与开发商一起查询和找出业务系统在运行过程中存在的问题, 并依此制定一个科学、合理的维护作业计划, 以提高软件系统的整体质量。
在实施维护作业计划前后, 都需据实填写维护作业登记表, 并将维护作业过程中相关的文档资料连通维护作业登记表一起合并保存并进行归档处理。
4. 设计、编码以及测试修改和测试。
BOSS系统应确保在非生产的环境中进行, 而且需要对BOSS系统的非生产环境以及生产环境进行严格区分。完成维护工作之后, 填写相应的维护记录, 维护记录填写的内容包括:程序名称, 源代码的行数;编写代码时所使用的设计语言;完成程序编写的日期;程序开发投入使用以后发生故障的次数等内容。
总结
随着社会的进步以及科学技术的不断发展, 广电网络BOSS系统的建设与维护已经受到越来越多的网络公司重视。这就要求我们要依据构建系统的基本原则切实做好系统的建设以及维护工作。
参考文献
[1]新一代移动BOSS解决方案[N].人民邮电, 2009-08-22.
广电BOSS 篇4
如何结合广播电视实际情况,运用信息技术在在整体层面上构建广电网络业务运营支撑系统(BOSS),以快速提升其运营水平、管理效率及服务能力,真正实现企业转型,成为全行业共同面临的课题。
起源
BOSS是业务运营支撑系统的简称,通常所说的BOSS系统涵盖了计费和结算系统、营业与账务系统、客户服务系统、决策支持系统等功能,可对各种业务功能进行集中、统一的规划和整合,是一体化的、信息资源充分共享的支撑系统,是网络运营商的一个综合业务运营及管理平台。
业界一个普遍的看法是,BOSS起源于电信。在电信业务运营的初期,由于系统建设经验不足,各业务系统建设分割独立,自成体系,数据无法共享,严重影响了业务运营和客户服务,基于此,建设一套统一的、能覆盖所有业务的综合业务运营支撑系统成为现实之需,而计算机技术的快速发展也为建设这样的系统提供了可能。特别是分拆出来的中国移动基于全程全网和管理众多增值业务的需要,提出了“业务支撑网建设五年规划”,率先在2002 年完成了初步的BOSS集中化和客户集中化,对多元化业务形成了支撑。随后以固网业务为主体的中国电信和中国网通等也纷纷完成BOSS系统主体建设。
在电信行业得到广泛应用的业务运营支撑系统被证明是一种精细化、集约化的管理工具,能够不断优化多元化业务运营能力,提升管理和服务水平,特别是可为各项基础业务以及增值业务的运营提供持续有力的支撑。
同样的道理,广电业务管理系统的信息化以SMS为开端,当时全国很多广电网络公司均部署了这套系统,但是随着有线电视数字化、双向化的转型,有线电视的业务逐渐多元化,除了直播频道之外,不仅包括付费频道、点播业务、宽带业务以及各类数据增值业务,而且还涉及到呼叫客服系统、线上/线下营业系统、缴费系统等外围配套设施,SMS已经越来越不适应企业需求。
其主要体现在:1)早期模拟电视或数字电视产品很少、运营模式单一,用户在订购模式上大多使用购买一年、半年等按时段订购,而随着广电业务的快速发展,由于SMS难以扩展不支持多业务,导致分业务独立建设,信息资源无法共享,客户资料不统一,难以打包优惠融合计费,非常不利于市场工作的开展;2)SMS系统在流程支持上重点解决信息管理问题,这在模拟电视乃至早期数字电视是没有问题的,但是在业务多元化时代对流程的支撑力度不足,不支持多产品、使用量的产品计费,不支持预后付费业务产品,非常不利于业务的上线、管理和结算。
正是在此背景下,广电网络逐渐从SMS升级过渡到BOSS,以提升自身的运营水平、管理效率和服务能力。
作用
整体而言,在目前的大环境下,广电网络建设BOSS主要可归纳为以下三方面的作用。
1. 增值业务的需要。
BOSS系统能够将现有分散的数字电视业务、互动电视业务、数据宽带业务以及众多的卡拉OK、教育、游戏、商城等增值业务进行全面整合,更为重要的是,广电网络公司依托BOSS系统,能够根据用户需求改变、竞争对手产品改变等反馈信息,快速将各类视频、宽带、增值业务等多业务进行整合,在业务流程上可以通过人工工单流转和电子工单流转对业务流程进行订制,并且可以按账期计费、出账,实现对不断变化业务流程的支持,从而获得用户认可,提高了市场竞争力。同时,通过向IT要生产力,运营商逐步从单一的频道传输角色向综合业务提供商角色转变。
2. 后网络整合的需要。
在一省一网整合政策推动下,目前全国绝大部分省份都已经完成了一省一网整合,而且这种整合正在从行政层面向网络及业务层面深化,之前各地市独立前端平台的管理系统需要迁移到统一的省网平台中去,在便于数字电视业务的统一管理和增值业务的统一运营的同时,发挥用户规模优势。因此,无论各地市的BOSS系统是否完备和具有前瞻性,网络整合的下一步都将需要建设全省统一的,适应多业务发展需要的BOSS系统。
3. 外围支撑的需要。
在三网融合背景下,有线电视所面临的市场竞争压力越来越大,这种竞争压力不单纯是业务层面的,更是管理与服务水平的竞争,用户理所当然的要拿广电的服务水平与电信乃至互联网的服务水平PK,他需要的是随时随地的业务咨询和开通,需要的是便捷的业务办理与支付。而广电网络传统的业务管理系统主要是从“客户”角度出发的,管理味道浓、服务味道弱,对这种新需求并不适应。而BOSS系统能够与客服体系、营业体系、支付系统等外围支撑形成统一系统,实现统一的客户模型、账务模型、产品模型,提高业务管理与服务水平。
因此,无论从哪方面来讲,BOSS已经成为广电网络必不可少的系统,所不同的只是系统的规模大小及部署前瞻性。
部署
对于正在转型中的广电网络,选择BOSS至少需要关注两个因素,其一是稳定性,因为运营商转型多业务之后,系统的复杂性变大,作为企业的核心产品,BOSS必须具备安全和可靠性;其二是可扩展性,随着广电网络的业务不断增长,其用户数、整合的业务内容不断增加,对BOSS的灵活性与可配置性要求将不断提高。
因此,虽然BOSS发源于电信,甚至很多广电行业的BOSS厂商背后或多或少都有电信行业的身影,但是广电在网络、业务等方面的特点却决定了广电BOSS绝不能照搬电信。其一,广电网络许多环节的设备和系统都不具有统一的接口标准规范,其对广电业务的统一运营造成了很多不便,无法像电信一样有非常统一的业务运营流程和规范;其二,广电网络相对分散,规模均较小,且各个网络之间没有互联互通,而电信网络不仅运营商互联互通,且是全程全网的。这些差异让广电BOSS的定制化色彩更浓,单用户成本也比电信高的多。
广电网络在建设BOSS系统过程中需要充分考虑与电信的各种差异性,才能真正为实际的业务运营带来支撑,否则这个BOSS就是一个好看不中用的系统。目前全国许多省份都已经上线BOSS系统,比如广州珠江数码、重庆有线、东方有线、山东广电网络、河北广电网络、江苏广电网络、新疆广电网络等,有一些是网络整合后建设新的统一系统,有一些是在原有建设基础上继续升级。但都不同程度地与BOSS系统建设厂商结成了紧密的合作关系,就是因为定制化、个性化的东西较多。
从包含模块来看,普遍包含了网上营业厅、CRM、PBOSS、鉴权平台、账务和计费管理以及综合结算功能,并且拥有与客服、网管及相关合作伙伴的接口,可实现业务的运营、分析与管理。
从部署实践来看,虽然BOSS对于业务、管理和服务水平的提升已经达成共识,但整个行业还是存在一些问题,主要包括:
(1)信息化投入比例偏低,影响了企业的持续性发展。
与电信6~8%的投入比例相比,广电网络通常都在3~4%左右,差了一倍多。同时,广电网络在BOSS建设年份投入很大,但是持久性的投入却不足,而BOSS系统更多的工作是在“润物细无声”的状态,需要持续性的投入和维护,如果信息化投入比例分摊到各年处于较低水平的话,将影响BOSS系统对业务支持的持续性演进。
(2)行业盘子太小造成技术迭代能力弱。
目前整个广电行业BOSS市场的规模仅为10亿级,与电信差了一个数量级以上,这还不算广电网络条块分割造成的厂商单用户投入更高的情况。在这种状况下,BOSS企业无论是重视程度还是投入精力均较为有限,行业规划、企业规划、人员派驻等均与电信的差别较大。这意味着基于原有BOSS框架下的迭代更新肯定要打折扣,对运营商新需求的反馈将较为迟缓。
(3)网络公司IT力量薄弱造成主导性不足。
目前,很多网络公司的IT部门要么是组建不久,要么是人员很少,无论是人力还经验均不足以应付越来越复杂的信息化建设要求。这就造成了很多地方BOSS系统建设均由厂商来主导,运营商比较被动。网络公司IT人员的重要性在于结合公司发展战略规划制订出信息化规划,并有效组织厂商力量参与,目前有一些网络公司已经意识到这一点,开始做一些规划和相关的标准规范。
上述问题不是一朝一夕能解决的,电信在BOSS上也付出了血的教训。结合有线电视2 亿多用户的盘子,需要聚合政府、运营商、厂商等多方面的力量一起来推动广电BOSS行业朝好的方向前进,少走弯路。
思考
互联网、移动互联网的快速发展对整个商业社会都提出了新的和挑战。一方面,借助于大数据、云计算等技术,企业与用户的接触更加扁平化、透明化,社会化营销、移动支付、免费+增值等各种模式不断涌现,这是一套完全不同于以往的游戏规则。除了业务层面的竞争之外,广电网络的BOSS及IT支撑也是非常重要的,能够为产品的快速迭代、用户精准分析、营销精准定位带来支持。
另一方面,广电网络的传统电视业务正日益面临着发展的天花板问题,靠用户增长驱动的时代正渐渐远去,广电网络亟需在用户运营层面有所突破,展开精细化运营,而这也不开BOSS系统等IT支撑的支持。
因此,广电网络在BOSS建设方面仍需要继续探索,以应对互联网的挑战,支持企业的进一步转型。
1. 精细化运营要求广电网络围绕BOSS建设下一代IT支撑系统。
以大数据、云计算为代表的新技术的显现让用户行为更加容易被感知,并反过来更好地指导运营企业的产品设计和改进。有线电视用户的消费特征是什么?使用行为是什么?如何指导我们的产品改进?如何完善我们的服务体系?这些都是需要广电网络进一步分析、解决的问题,需要广电网络运用大数据、云计算等技术,在现有传统业务和创新增值业务基础上展开精细化运营,将业务、产品、服务送达用户,获得认可,贯彻“用户体验为王“这一口号。
精细化运营要求广电网络必须抛弃粗放式经营之路,要向管道要收入,向用户要ARPU值。而这些都离不开广电网络IT信息化支撑体系的进一步完善,用信息技术去理解用户、经营用户。
从精细化运营角度对对业务支撑(BSS)、运营支撑(OSS)、管理支撑(MSS)和决策支撑(DSS)各域系统进行规划和设计,引入面向内容、用户层面的大数据分析技术,打造出BOSS系统、精分系统、客服系统、财务系统、网管系统、网格化管理系统等一整套具有广电特色的IT支撑体系,以支持企业应对激烈市场竞争,促进信息资产的保值与增值,将是BOSS系统建设未来的目标。
从上面可以看出,在精细化运营导向下,从BOSS系统出发,广电网络的IT信息化范畴已经大大外扩。
2. 重视BOSS系统整体规划以支持系统持续性演进。
从电信业的发展来看,目前一个普遍性的看法是电信运营商的发展经历了从语音产品到业务服务,再到用户运营的的多个阶段,而不同阶段对于BOSS系统的要求存在很大的差异性。为了避免推倒重来、前期投资浪费的局面,需要运营商对公司整体发展及相关信息化支撑有一个比较明晰的规划。在业务演进过程中,有一个整体性的演进判断,通过对BOSS系统功能模块的重新定义、删减等来实现系统升级。
对于广电网络来说,比电信运营商面临的局面更加复杂。不同地区的运营商发展水平参差不齐,有些地方仍以数字电视为主,有些地方的宽带及增值业务均已大规模上线,而有些地方还在忙着模转数。由于运营商在BOSS层面的需求差异很大,因此BOSS企业很难提供全行业性普适的东西,这就需要运营商对企业未来的发展方向、业务产品等有一个比较清晰的认识,哪个阶段该干什么事,从而在BOSS系统规划中能够短期与长期结合,做到有的放矢。虽然说规划对于保证10 年以上的目标是一个很困难的事情,但是起码得对3~5年有一个比较清晰的规划,5~10年有一个轮廓性规划。
3. 抓好人才队伍建设,形成主导力量。
由于广电网络目前缺乏IT技术人才,难以主导BOSS系统的建设,而厂商绝大部分具有电信行业背景,而广播电视行业的视频业务维度和数据维度均与电信存在很大差别,双方有时候连基本的需求沟通都存在一些困难,这无疑不利于功能完备的BOSS系统建设。
因此,无论是从企业内部培养,还是从企业外部招聘,广电网络需要有计划地抓好既懂传统广播电视技术,又懂IT技术的复合型人才队伍建设,既能够从网络公司大局出发去构建、规划,又能从广电的角度与厂商进行需求、建设、维护沟通,以支撑BOSS及整体IT支撑系统的建设。
广电BOSS 篇5
随着三网融合的发展，广电市场的竞争在不断激化，如何在现有数字平台上开展各项增值业务，成为了各广电运营商面前的头等问题。苏州有线经过深入考察比较，引入了数字电视多媒体视讯系统（Media Information System，以下简称MIS）。该产品主要功能是将多媒体信息内容（包括图文、音视频等内容）在指定频道、指定时段播出并可实时更新，通过数字机顶盒集成软件模块实现多媒体信息内容接收显示。通过该系统，数字电视用户能享受到更丰富实用的资讯信息，对数字电视将有全新的体验。但是其中的定点投放功能需要获得BOSS中的相关信息，因而，需要在BOSS和MIS之间建立一个接口，实现两者之间的通讯。笔者在项目实践中通过研究，从基于Socket的设计出发，提出了解决这一问题的一种思路和实现方案。
2 Socket概述
Socket也叫做套接字，是建立在传输层协议上的一种跨平台的应用程序进程之间通信规范。如图1所示，用一个抽象的“通道”来形容，它的两端就是两个Socket。Socket对于进程来说屏蔽了底层的通信软件以及各种操作系统之间的差异，它为进程提供的通讯接口使得进程在网络上的数据传输以及数据接收得以实现。对某个网络连接来说，Socket不会因为在服务器端还是在客户端而产生不同的级别，它是平等无差别的。
协议、远程IP地址、远程端口、本地IP地址、本地端口这个五个元素可以用来表征Socket。对于应用程序的进程来说，只要有协议、远程IP地址、远程端口即可以像使用文件句柄一样，直接对Socket进行读、写操作，以达到与远端进程进行通信的目的。
3 BOSS与MIS系统接口的设计与实现
3.1 业务需求
BOSS系统涉及业务办理、授权、客户服务、计费运营维护等，通常要求7×24小时运行，其数据的准确性及稳定的运行非常关键，若发生重大故障将会给运营商带来严重的社会压力及信誉损失，并且BOSS中所涉及的各种数据信息，牵涉到客户隐私和商业机密问题，不可能让MIS系统厂家直接对BOSS数据库进行操作。
鉴于以上原因，有必要在BOSS与MIS之间建立一个接口系统来实现两者之间的数据传递问题。
3.2 设计的基本思想
接口系统的结构如图2所示。
本接口系统通过Socket和如家MIS进行通信，它是整个系统的核心，是BOSS和MIS之间数据交换的接口。接口系统包括接口数据库、Web管理系统和Windows服务三部分。
(1）接口数据库
接口数据库起到了一个中转的作用，它存储了所要进行定点投放的信息，如投放时间、投放目标、投放信息等。
(2) Web管理系统
Web管理系统的作用是对定点投放的信息进行管理。它采用直接读取BOSS数据库的方式获得相应的BOSS信息，如机顶盒号码、智能卡号、小区信息、广电站信息等。然后可以对指定的单个机顶盒或某个小区涉及的用户进行信息的定点投放。
(3) Windows服务
这是整个系统的核心，担负着对定点投放信息的监视、读取以及与MIS系统之间的通信。它将接口数据库中的定点投放信息按照与MIS之间约定的封装规范进行封装，封装完毕后将消息发往MIS系统，并对MIS系统的返回信息进行解析。
3.3 接口数据库的实现
在这个项目中，针对系统功能的要求，笔者设计了如表1所示的数据库表结构，数据库平台使用的是Oracle 9i。
发送标识有以下几种分类：0代表信息未发送，1代表信息已经发送成功，2代表信息发送失败。默认情况下为0。
3.4 Web管理系统的实现
Web管理系统界面如图3所示，主要实现以下两类功能：
(1）单个定点信息投放
即允许操作员通过输入机顶盒号码、智能卡或客户证号等信息，对单个用户进行定点信息的投放，本系统中对应的功能模块是单卡发信息。
(2）批量定点信息投放
即允许操作员对某个小区、某个街道或者某个广电站下面的所有用户进行批量定点信息的投放，本系统中所对应的功能模块是小区发信息、街道发信息和单位发信息。
Web管理系统的一个关键技术是对Oracle数据库的读写。在Web管理系统的模块中，多次用到了对数据库的操作。为了增强系统的清晰度和简洁性，减少代码的重复性，提高系统开发的工作效率，笔者编写了一个DBOperation类，其结构如图4所示，专门用于与数据库的交互。
3.5 Windows服务的实现
Windows服务是在Windows操作系统下，运行于后台的一种可长时间运行的可执行应用程序。它们中的一些服务是随系统启动而自动的启动，也有些服务必须在用户的手工启动下才可以运行。对于那些自动启动的服务，它们的启动是随着Windows的启动或者重启之后用户登陆以前就开始执行，随着Windows的关闭而停止运行。用户可以通过选择控制面板—>管理工具—>服务来查看管理系统中的Windows服务，如图5所示。其中选中的服务MisService就是本接口系统对应的Windows服务。
作为整个接口系统的核心，Windows服务的关键技术涉及到Windows服务本身的实现以及与MIS之间的Socket通信。下面就这两个关键技术进行描述。
(1) Windows服务
本Windows服务采用.NET平台进行创建。在.NET平台中，把复杂的操作封装在.NET类中，简化了Windows服务的创建和控制过程。本接口系统的Windows服务的类结构如图6所示。
本服务添加了一个名称为timer1的System.Timers.Timer组件作为实践触发器，用于定时对接口数据库中的数据进行访问，查询是否有需要定点投放的信息。在OnStart方法中对timer1的属性进行设置，其中Interval表示触发频率，单位为毫秒，Enabled表示是否启用计时器，以定义的Interval的时间间隔激发事件timer1＿Elapsed。另外在OnStart方法中还对配置信息进行读取，获得对应的主机（host）和端口（port）信息，用于Socket连接。OnStop方法中设置了timer1的Enabled为false，表示停止计时器的运行。其中，对数据库的检查以及与MIS之间的通信放在了Check () 函数中。
为了增强服务的可移植性，减少代码的改动，本Windows服务还自定义了配置文件，用来管理服务的设置，配置文件采用XML形式，结构如下：
其中Host代表MIS所在的服务器的IP地址，Port代表MIS系统接收Socket信息的端口，Time Interval用于设置timer1时间间隔，DataSource存储着与接口数据库的连接字符串，LogPath表示本Windows的日志存放路径，本例表示日志文件存在C盘下的log文件夹里。每次更改配置文件后，需要重新启动服务才能生效。
.NET为服务的安装提供了Install Util.exe工具。选择Visual Studio Tools—>Visual Studio命令提示，会显示一个命令窗口，在此命令窗口中通过执行Install Util命令来进行安装或卸载Windows服务。
安装命令为：Install Util.exe服务名。
卸载命令为：Install Util.exe/u服务名。
(2) Socket通信
本接口系统中Socket通信涉及到发往MIS的Socket信息的封装、MIS返回信息的解析以及Socket本身的发送。所对应的结构如图7所示。
类ByteBuffer主要用于创建一个可变长的Byte数组，以方便Push数据和Pop数据；类Common是公用方法的集合；类Mis Interface主要用于对Socket信息的封装以及Socket信息的发送；类MisData主要是对Socket封装过程中的一些功能进行函数封装，以供MisInterface调用；类Write Log包含与日志相关的一些方法。
4 结束语
本接口系统在BOSS与MIS对接方面创全国广电先例，它在苏州广电的应用是成功的，在实践中已经得到了检验。接口系统把广电BOSS和MIS有机的联系在一起，实现了无缝连接。降低了由于建设MIS而对BOSS产生的风险，有效的保障了BOSS数据库的安全性。接口系统是建设MIS的基础，同时也是BOSS与MIS之间数据交互的纽带。
摘要：BOSS作为广电的核心生产系统, 如何实现与MIS进行数据交换显得至关重要。本文对两个系统进行深入的研究, 从基于Socket的设计出发, 提出了一个合理可行的接口应用方案。
关键词：Socket,BOSS,MIS,Windows,服务
参考文献
[1]朱三元等.网络通信软件设计指南.北京:清华大学出版社, 1995, 53-72.
[2]叶德谦, 马勤勇.使用ADO.NET实现对关系数据库的访问[J].电脑编程技巧与维护, 2002, (01) .
[3]杨静, 梁浩峰, 高鑫.用socket实现服务器/客户机的数据交换[J].甘肃科技, 2002, (7) .
[4]TCP/IP网络互联技术 (卷3) :客户-服务器编程与应用[M].Douglas Comer, David L Stevens.清华大学出版社, 2004年10月.
广电BOSS 篇6
关键词：BOSS广电业务,数字化整转,Oracle特性,容灾,备份,高可用
1 架构简介
目前BOSS系统生产中心有小型机2台, 配有磁盘阵列。容灾中心有容灾服务器1台, 配有磁盘阵列。系统的数据容灾通过Oracle Data Guard来实现。逻辑拓扑如图1所示。
如果考虑数据库Rman备份存储空间、数据库归档日志存储空间 (根据业务量不同可以考虑数据文件大小的三分之二左右) 、逻辑备份存储空间等因素, 面临数字化整转的广电企业有必要充分考虑并合理规划存储空间。下文也会讲解因前期考虑不到位而空间不足时的可选措施, 但这些措施以消耗CPU资源为代价的。
2 广电业务特色与Oracle特性
为了更好地提高性能, 除了很好地理解Oracle外, 理解广电业务及其数据是很有必要的, 如下通过具体案例来介绍几个重点因素。
2.1 日常业务与报表的分离
从生产系统运维的实际经验来看, 威胁系统稳定性的最大因素是在业务时间进行大量报表查询。具体体现在月底出账后的月统计报表、每周扎帐、业务相关部门节假日后进行的大并发报表查询等。随着数字化整转的顺利开展, 在BOSS系统中将会出现大量的用户数据及业务数据, 业务部门为了及时地了解数据的动态变化需要大量的客户及业务统计汇总数据。而此类数据提取方式会做成报表或者后台编写SQL直接提取等方式来处理, 一般广电BOSS的系统, 承担着多个分公司及外拓单位客户及业务资料, 因此很难避免这些单位同时查询统计数据。有效的解决的思路就是将报表系统和OLTP系统从业务和数据库层面进行分离。因业务层的分离涉及到程序的改动, 一般可以采取数据库层面的分离。
在数据量并不是很大的情况下 (也适用于单实例环境) , 也可以采取通过DB link方式 (或impdp/expdp的network_link方式) , 每晚将常用报表相关数据同步至报表库, 将报表查询Web应用与业务受理Web应用完全分离并直接读取报表库的方式也是值得尝试, 具体结构如图2所示。
如果业务层面也能实现直接读取报表库, 则完全可以避免报表查询对生产数据库服务器的压力 (尤其对内存结构的压力) 。
如果数据库不是很大, 也可以从采用生产库导出后传送到报表服务器并导入到报表库的同步方式, 这样对生产库几乎不会产生什么性能影响。
数据同步另一个理想方案是采用Oracle Data Guard的逻辑灾备 (Logical standby) 模式, 不过此模式对要求DBA具备一定的专业职能, 要求企业具备一定的硬件环境。
2.2 对关键业务采取针对性优化措施来排除性能瓶颈
平时可以通过针对业务部门进行调研、对其需求进行总结分析等措施来排除系统瓶颈。如下关于所谓的“BOSS系统慢”的几个常见问题:
(1) 营销计划变更时, 查询界面等待时间较长。
(2) 新装用户时, 查询标准地址等待时间较长。
(3) 资源查询、资源调配, 查询速度较慢。
(4) 营业厅下午做资源扎帐时, 等待时间较长, 做受理扎帐, 无数据显示。
(5) 下午6:30分, 报表权限打开后, 查询某某报表速度较慢。
实际上这几个问题就是天天困扰每个业务人员的问题, 针对这些问题提取相关SQL后进行针对性的分析和SQL优化后, 对于业务部门来说性能有了很大的提升。简要的分析结果如下:
问题1通过SQL优化得到了很大的改善。
问题2是项目初期因为数字化整转业务中安装地址不好找而实现的地址查询 (完全模糊) 功能模块, 如果针对此问题单纯从数据库层面考虑则优化的效果并不明显, 因此个人觉得有必要在程序层面改进查询方式更为有效。经询问业务部门, 改进后的查询方式 (半模糊) 也能满足他们现有的需求。
问题3的整个过程涉及到十几个表及DML操作, 而其中有些表既然已经接近几个亿的数据行数, 因此不仅对SQL语句进行优化, 而且对相关数据表进行了重构, 同时对过期数据进行了清理归档等。
问题4和5分析后发现不仅报表SQL需要优化, 而且相关业务核对流程也有待提高。因此独立建立报表库 (图2) 的同时对业务流程也进行了相应的调整。
2.3 TOP SQL的优化
随着数据量不断增长, 业务相关数据查询也开始呈现出低效。比如原有CA授权日志表、产品订购表、账本及账单详单表、业务受理记录表等, 在短短的一年中, 从百万行增加到千万行甚至几个亿行记录。如果没有对此采取相关措施, 服务器硬件配置总是显得不够, 需要扩容。
如图3所示, CPU占用率分布中16点左右发生CPU高消耗的来源实际上也是一个根据地址查询大量数据的SQL语句导致的。在SQL优化中希望记住的一点是SQL的优化离不开索引的优化, 但是索引的优化并不等同于SQL语句中where条件的字段上增加索引。很有必要根据数据访问路径和查询条件的特点, 创建战略性的组合索引。
2.4 合理规划及部署后台作业
通过如下查询语句, 我们很容易看到数据库存在的后台作业:
select*from dba_jobs job where job.BROKEN=’N’
BOSS系统涉及到综合业务、多种接口, 承担着很多任务, 因此相应的每天必须执行日帐、接口同步、托收、欠费催缴、OSD/MAIL发送、各类统计报表等很多任务。明确每个作业用途及执行时长, 合理安排其执行时间也是很有必要。曾经在Oracle的警告日志文件的夜晚时段经常出现checkpoint not complete提示, 合理调整完相关作业执行时间后出现的频率有了很大的改善。
2.5 充分利用Oracle新特性, 将常用参考表放到keep pool
BOSS系统虽然很庞大, 但是其中有些常用的小表, 例如产品、组织结构、营销计划、各类Enum (代表类别的元数据) 等。如果采用数据库为Oracle10g或以上版本的话, 我们可以将这类表的Default Pool属性设为Keep pool, 这样可以避免这类常用表的“过时”而引起不必要I/O的同时, 减少SQL解析量, 进一步提高系统性能。
2.6 Cursor相关初始化参数的调整
如果系统上SQL没有足够的共享则会出现大量不必要的解析调用, 这些解析会占用大量的CPU资源, 从而严重地影响系统的性能。解决问题的最佳方法还是应该在程序中使用绑定变量, 但是这又涉及程序的修改。如果无法通过修改程序使用绑定变量来解决这个问题, 那么修改CURSOR_SHARING应该是解决这个性能瓶颈的简单且行之有效的方法。
2.7 合理规划及安排备份策略
随着数据的不断增量, 系统备份所需要时间也会逐渐增长, 当数据库增加到500G以上时, 再不重视合理规划及安排备份策略, 这些因素将会成为系统性能问题。
BOSS数据是公司核心数据, 因此一般对此类重要的数据, 数据库将会运行在归档日志模式外, 还要实现Rman备份 (出于性能可以采用Rman增量备份) 、逻辑备份等。在实际应用中如下几点需要注意。
(1) 给数据库分配足够的备份空间
在数字化整转时期数据库的增长是非常快, 因此在存储的规划过程中要充分考虑相关因素。同时BOSS系统数据库是公司的核心数据, 因此数据库肯定会在归档模式下运行, 也需要足够归档日志 (Archived log) 空间, 否则系统会因归档日志空间满的原因导致经常挂起。这些因素从侧面反映BOSS系统稳定性和可靠性。
(2) 逻辑备份时段及出账时期的合理安排
一般除了Rman备份外, 附加采用逻辑备份来进一步保证数据的可恢复性。当数据库变得越来越庞大时, 每个月初的出账计算及销账等过程中, 如果没有合理安排数据库逻辑备份与出账时间关系, 将直接影响出账过程和效率。在特殊时期做一些特殊方法来避免系统资源竞争是很有必要的。
(3) 充分发挥Oracle备份恢复新特性
Oracle数据库备份还是离不开Rman备份。例如, 当初我们BOSS系统备份因空间不足, 而导致没法正常备份时, Rman压缩备份使得我们避免重复的硬件投资, 很轻易地度过难关。
3 突破局限、整体分析, 充分利用现有资源
从图3 CPU占用率分布中可以看出来, CUP占用率较高的时间段主要分布在两个时间段段, 即21:30至23:20和6:30至9:00。接下来将介绍怎样结合整体架构和业务特性避免高负载时间段的重现, 从而进一步提高BOSS系统的稳定性。
3.1 生产中心与灾备中心之间备份的分离
在数据库服务器上通过执行Crontab–l可以看到从6:00开始的数据库Rman增量备份。
从Oracle 10G的特性可以知道, 在Data Guard的Physical Standby环境下, Rman能够从Physical Standby上创建生产库的备份, 但此时Rman要求要具备Catalog database。如果按照该思路, 可以将生产库上的Rman备份迁移到灾备库, 则6:00至9:00的CPU高负载可以避免。当然, 如果灾备中心和生产中心之间网络带宽为100M并备份大小超过200G, 则不推荐采用此方法。因为一旦需要恢复, 则两点之间数据库备份数据的传输就会占用客观的时间。
另外, 仔细观察rman备份脚本也可以发现 (backup incremental level=0 as compressed backupset database) , 脚本中含compressed选项, 该选项是以CPU负载为代价而节省磁盘空间, 如果磁盘空间足够, 也可以取消compressed选项, 在我们的实际案例中取消后的CPU占用率分布如图4所示。
针对4:00开始的逻辑备份, 将其迁移至灾备中心也很容易实现。实现方式是先将容灾库状态改为只读方式 (open read only) , 打开后导出数据, 导出后将数据库状态改回mount状态后, 恢复Dataguard的日志应用模式即可。而这些处理过程可以通过脚本语句来实现, 不必天天人工参与。
3.2 日账、月账相关存储过程 (或包) 的调优
每日账务的批量处理过程分布在如图3 CPU占用率分布中的21:30至23:30时间段, 而这一时间段也是呼叫中心调用BOSS系统的高峰期。
将呼叫中心调用BOSS高峰期和日帐批处理时间段相互分开也是解决问题有效措施之一。这样可以避免在批处理过程中对Undo表空间的争用, 同时对CPU占用率的降低也有一定的贡献。
通过对账务相关存储过程的SQL进行优化也可以降低CPU占用率。对于存储过程的优化, DBMS_PROFIL-ER软件包可以帮助用户测试PL/SQL的性能。除此之外, 个人还是建议在对出账的整体过程有了一定认识的基础上, 再参考DBMS_PROFILER等工具, 进行全面的调整, 这样可以取消一些不必要的环节或有利于减少不必要的逻辑和物理读。
从Oracle Database 10g开始, Oracle在建库后就默认创建了一个名为GATHER_STATS_JOB的定时任务, 用于自动收集CBO的统计信息。缺省情况下, 这个job是从周一至周五的晚上22点开始执行, 运行8小时到次日凌晨6点;周末则是从周六凌晨0点开始执行两天。
通常情况下, 晚上22点及周末全天是用户使用的高峰期 (账务处理、呼叫中心调用、催缴) , 所以在此期间如果系统资源出现紧张, 需要将job运行的时间调整为跟业务高峰避开的时间段。
随着时间和业务的扩展, 在广电BOSS中将会两类数据变得越来越庞大, 其一是认证接口类, 其二是工单类。从实际经验来看, 曾经出现过部分表大小超过12G (未分区) 的情况, 这类数据不仅对性能, 而且针对备份恢复时间、CPU、系统I/O等产生负面影响。因此有必要建立相应的数据归档及清理机制。针对那些特殊大表, 根据相关表的表间关系, 可采取如下简便的处理方法:
(1) 清理之前, 对所要清理的表做一个逻辑备份, 以便今后查询。
(2) 根据归档计划周期 (时间点) , 查找满足条件的主键值。
(3) 导出满足条件的数据。
(4) 导入前清空已备份过的表。
(5) 重新导入。
对以上过程的几点说明:如果表中索引较多或表很大, 可以考虑先删除表上的索引后进行导入, 等导入完毕重建索引等方式, 这样可以减少导入时间。
4 展望高可靠高可用 (RAC+DG) 系统架构
如果将图1逻辑拓扑图中两个小型机之间“HA”改成“RAC”, 则可以搭建Data Gurad加RAC的Oracle所称为MAA架构 (Maximum Available Architecture) 。在这种架构中, 选择比较高效的存储方案是值得投入的, 因为在后期扩容中, 节点很容易增加, 但是存储的调整及升级不仅涉及到较大改动 (可能需要数据迁移) 。在节点数增加和性能的线性提升之间起到关键作用。
随着RAC Cache Fusion功能不断改进, 对各类应用程序的要求越来越降低, 但是根据BOSS系统表结构和业务特性进行长远考虑, 如下几点还是值得关注的:
(1) 在系统初始化初期, 应该对客户、账户、用户、受理记录等基表的常用查询关键字段 (客户编号、账户编号、用户编号、受理编号) 进行附加区域编码的编码方案。这样在未来3至5年生成的海量数据中, 通过根据这些关键字段对这些表进行分区等措施很容易减少不同节点之间Global Cache等待和Enqueue等待事件。也能保证节点数量和性能提升之间的线性增长。
(2) 用户资源、产品订购一类的表有必要在表结构和应用程序方面做些二次开发。这类表不但变更率较高 (建表时需要调整pct free参数) , 而且在单实例环境下锁相关等待事件 (LocksRelated Wait Events:Buffer Busy Waits、Latch Free等) 较严重的表。
(3) 在RAC中, 多个节点可以同时访问数据库, 因此针对BOSS系统的不同子模块建立不同服务 (services) 的方式分别部署到不同的节点, 也是提升系统稳定性和性能的有效措施。如再结合Oracle 10g的基于服务 (services) 的资源管理 (Resource Manager) 功能, 则完全能够避免关键业务和非关键业务之间的资源耗用冲突的现象。以报表模块为例, RAC和BOSS业务特性讲, 可以将报表子模块和OLTP业务的分离按不同服务分解到不同节点。
(4) 对于较繁忙的环境来说, 触发remastering事件的默认参数值通常过低, 因此导致了频繁的对象remastering。建议设置_gc_affinity_limit和_gc_affinity_minimum参数到一个较高值, 比如说1千万。将参数_gc_affinity_time设置为0也可以完全禁用DRM, 但是这也意味着再也无法手工remaster对象了 (这些是隐含参数, 在修改这些参数之前确认Oracle Support同意你的举动) 。
5 Oracle数据库性能调优重点公共部分
Oracle数据库性能优化的重点部分无非是实例 (SGA、PGA、Share Pool、redo bufer) 和数据库 (日志文件、临时文件、回滚段) 等大小的合理配置。在Oracle 10g中也推出了一系列顾问属性的动态视图, 这些视图有助于实例参数的正确调整。另外, 还需关注Oracle不同文件存储位置的合理部署来降低系统I/O。
6 存储的合理规划及分配
(1) 数据文件和归档日志文件与备份文件硬盘分离
对于数据库安全及性能, 数据文件与归档日志文件需要与备份文件硬盘分离。从安全性方面讲, 避免存储数据文件硬盘出现问题。从性能方面讲数据文件和归档日志文件的分离可以避免磁盘争用, 有效降低了log file parallel write的等待时间。
(2) 数据文件和索引的分离
数据和索引分别独立存储的数据存储结构具有非常重要的意义。表和索引相互分离、各自作为不同的对象存储是关系型数据库中最常见的数据存储方式。同样, 作为这些对象集合的数据文件和索引文件的分离在数据库性能的提升方面具有相当重要的作用。
7 总结
广电BOSS 篇7
作为“绿色运营”的先行者, 诚毅软件一直倡导“资源消耗更少、运营效率更高”的理念, 积极推动广电业务运营支撑技术向前发展, 不断地推陈出新。在诚毅软件的展台, 多样的BOSS解决方案、完善的服务体系、专业的现场演示吸引了大批广电业内人士驻足。此次我们《广播电视信息》的记者有幸采访到了诚毅软件的总经理邵山先生, 就广电现阶段对运营支撑系统的需求和BOSS未来的发展方向等问题进行了深入的交流探讨。
网络整合必须注重基础管理能力的建设
网络整合一直是近两年来广电发展的重中之重, 各地运营商也在积极地进行网络整合与改造, 目前的目标是先完成省网整合, 未来的发展趋势就是全国整合成一张网。邵总认为:“随着网络整合进程的发展, 越来越多的省完成了省网整合, 广电省级运营商拥有的用户量将急剧增加, 能开展的业务也会越来越多。在这种情况下, 广电省级网络运营商最迫切需求的就是具备基础的管理能力, 可以将各地的用户统一管理起来, 拥有自上而下统一推出业务的能力。目前有些广电运营商对自身基础管理能力的提高并不十分重视, 虽然说整个省的网络整合了, 但是在业务、用户管理等方面并不具有自上而下统一管理的能力。所以说, 现在发展的关键就是要建立能将全省的网络统一管理起来的运营支撑平台, 基础管理能力有了, 在业务方面, 运营商可以尽可能地借助产业链上的内容资源来发展。陕西省网就比较重视基础管理能力的建设和提高, 已经做到了全省用户的统一管理和全省业务的统一推进, 这也就是全省网络整合的真正目标。”
广电网络有其自身的特点, 各地的情况有着很大的不同。省级网络在具备了基础管理能力的同时, 又必须要考虑各个地区的具体情况。邵总谈及此时说道:“对省级运营商来说, 穿透的管理能力很重要。所谓穿透的管理能力就是要给下级公司一个自由度, 省级运营商不如当地的运营商了解当地的情况, 所以在业务制定上, 可以给经营实体一定的权限, 定出一个价格区间, 让分公司在当地用户的承受范围之内自由选择其价格。比如我们承建的陕西、贵州省网的运营支撑系统就是这样, 它可以做到分级管理、数据统一、统分结合, 在全省拥有一套完整的支撑系统的基础上, 保证多级管理, 比如两级或者三级, 这样既可以照顾地方利益, 保证地方上的自主经营权, 同时也可以方便省级运营商统一管理。”
量体裁衣打造适合广电实际需求的BOSS系统
目前, 在国家三网融合发展策略的推动下, 广电行业的运营模式已经由单一的基础业务走向丰富的全业务, 广电将面临数据服务业务、宽带互联网业务、多媒体通信业务、专网服务业务和物联网业务等新业务的运营挑战, 为了更好滴服务于用户, 广电运营商必须具备全业务的支撑能力。新的运营环境也使得广电运营商必须由“粗放式经营”向“精细化管理转变”, 满足用户个性化服务、差异化服务的需求。
下一代BOSS nine*正是根据三网融合中新广电、新网络、新业态的运营支撑需求, 从广电行业的现状与未来出发, 为广电运营商量身打造的全新运营支撑平台, 适合国家级、省级运营商等多层级、全业务的BOSS应用。下一代BOSS nine*采用了全新的技术框架和工作流技术, 使企业级构架富有更加的弹性和更简单的扩充整合能力, 形成了“企业数据服务中心、企业应用服务中心、企业用户体验中心”, 为广电带来了“简单、高效、智能”的全新体验。
邵总介绍说:“目前我们的几个省级的运营支撑平台已经完成了全业务的支撑, 下一步要做的就是全业务的管理。省级网络都在往全业务管理推进, 以西部为例, 陕西省网目前有线电视数字化用户已经达到320万户, 已开启了全业务运营时代, 山西省网正在搭建管理平台前端, 陕西友好网络的管理平台也在建设中。”