业务监控系统

业务监控系统（精选12篇）

业务监控系统 篇1

1 概述

1.1 背景

通信行业和移动互联网的高速发展, 使得行业竞争日趋激烈, 导致电信运营商对经营发展变化的反应速度要求越来越高。基于对VAC订购话单数据进行分析、建模的全业务监控体系, 从发展有效性、经营健康性和业务合规性三个方面着手, 从发展的有效性、经营健康性和业务规范性三个方面着手, 实现业务监控行为由被动监控向主动把控转型, 解决现有人工监控的诸多问题, 全方面提升业务监控的效率、效果。

如何对经营业务有效监控, 从订购数据中提取有效数据信息, 进行分析、建模, 建立完善的业务监控预警体系, 成为待解决的一大难题。

1.2 业务创新方向

创新1.预警信息自动推送、业务自动关停:

对重要异常波动指标快速定位, 实现定期、定向自动推送预警信息, 对紧急突发异常自动发送业务关停指令, 进行业务暂停受理。

创新2.信息快速传递:

利用邮件、短信、电话等多渠道进行信息反馈, 实现信息快速传递沟通, 提高问题解决效率。

创新3.支持指标定制:

各级单位可通过监控需求流程提出监控指标需求, 经评估审核通过后, 实现系统的固化支撑, 提升监控系统的可拓展性。

创新4.管理流程支撑配套:

根据管理需求, 在OA固化监控管理配套流程, 包括业务监控核查流程、整改流程及监控需求申请流程, 实现业务监控闭环管理。

1.3 整体方案

河北联通业务监控预警平台, 基于对VAC订购话单数据进行分析、建模, 实现对经营指标异动、发展有效性、业务合规性、经营健康度的快速精准定位, 并建立完善的监控预警信息传递和管理体制, 实现预警系统自动推送, 重大预警信息限时反馈, 建立和规范监控指标库和模型库, 聚焦业务发展重点, 强化可拓展性, 同时动态维护, 持续完善整个业务监控体系。

2 实施方案

2.1 系统逻辑结构图

2.2 系统功能说明

2.2.1 VAC数据采集清洗入库模块

主要负责和VAC系统实现数据采集, 对采集数据清洗以及清洗数据的入库操作。

1) 数据采集。数据采集功能负责从VAC系统采集数据, 然后把数据按照要求存放在指定的空间, 便于数据清洗模块进行数据的整理清洗。

2) 数据清洗。数据清洗模块负责对采集的VAC数据进行清洗, 把无效的或者异常的数据清除过滤, 有效的数据整理好便于数据入库处理。

3) 数据入库。数据入库模块负责对清洗好的数据进行入库或者合并成大文件, 便于数据分析处理。

2.2.2 数据分析业务处理模块

1) 数据计算。对清洗存储好的VAC数据, 要进行数据的分析处理, 得出业务的日常数据, 包括业务的发展均值、一年内的日均发展值、一月内的日均发展值、数据当前时间的日发展值等, 作为后期数据对比的依据。

2) 数据分析对比。对计算好的数据进行对比分析, 看业务日发展情况是否异常, 并对异常的业务作出标识, 便于管理人员及时处理, 甚至给管理人员发出短信通知。

3) 业务处理。对于一些异常严重, 并做好了阀值设置的业务, 业务处理模块直接根据调用业务处理接口, 对业务进行关停和开通处理。

2.2.3 系统管理模块

1) 用户管理。用户管理用于对管理平台的操作员进行业务维护。包括对操作员的增加、删除、修改、角色分配等操作。

2) 角色管理。角色管理主要对操作管理平台的各个角色进行增加、删除、修改等基本维护, 并且实现每个角色的权限分配。

3) 权限管理。主要负责管理平台的各个权限的增加、删除、修改等基本信息的维护, 包括权限所具备的菜单显现等维护。

4) 业务管理。业务管理是对业务的基本信息维护, 包括业务所在的业务平台、业务调用的接口地址、业务调用所需要的一些常用参数等等。

5) 阀值管理。主要是用于对用于设置一些业务的发展数据偏离平均值多少百分比就需要产生告警的动作以及告警通知。

6) VAC分析查询。VAC数据分析完毕之后, 可以让操作员对分析数据查询, 查看每个业务的发展情况, 做好推广和决策。

7) 业务异常告警。业务异常告警就是对设置了阀值的业务数据, 和分析对比出来的日常发展均值数据对比之后, 不同等级用不同颜色显示, 告知业务的异常信息, 便于维护人员的处理。

8) 业务处理。异常数据告警之后, 业务维护人员可以通过业务处理功能, 对现在开展的业务进行干预处理, 譬如暂停业务订购、或者减少推广等。

9) 业务处理日志。系统对业务任何处理都要做好记录, 包括对业务做的任何一次修改维护以及暂停操作, 便于维护人员的查询。

10) 统计报表。根据业务发展的需求, 会出各种各样的统计报表, 支持业务的发展以及业务决策。

11) 其他管理功能。其他一些功能主要是用于后期随着业务发展, 一些特殊业务和特殊的管理需求而开发的管理功能。

2.2.4 接口和数据

1) 数据采集接口。使用FTP方式进行传输, VAC提供FTP服务器, 数据分析采集模块负责到FTP服务器上取回文件数据, 并删除服务器上的文件数据。

2) VAC业务处理接口。根据后期业务发展, 需要VAC平台根据不同的业务参数提供相应的开通和暂停处理接口。

3) BSS业务处理接口。根据后期业务发展, 需要BSS平台根据不同的业务参数提供相应的开通和暂停处理接口。

3 系统实施效果

自平台上线使用开始, 月均通报15项业务订购量异常, 成功遏制了上百起不良订购现象及操作异常的发生, 降低用户投诉率。

对业务发展进行了有效的监管, 有效的避免了业务恶意订购的出现, 提高业务发展监管效率, 有效的减少了用户投诉量。

4 后记

实现了对经营指标异动、发展有效性、业务合规性和经营健康度的快速精准定位, 并建立健全监控信息传递和管理机制, 实现预警信息的系统自动推送、重大预警信息的限时在线反馈, 以各级经营单位为使用主体, 建立和规范监控指标库和模型库, 聚焦经营发展重点, 强化可拓展性, 待续完善整个监控体系。

摘要：随着用户量的增长、服务质量的提高以及产品业务订购量的加大, 对经营发展变化的反应速度要求越来越高。如何对经营业务有效监控, 从订购数据中提取有效数据信息, 进行分析、建模, 建立完善的业务监控预警体系, 成为待解决的一大难题。本文针对业务监控预警管理系统建设, 重点从业务数据分析、提升业务监控及监控预警三个方面进行了讨论, 并初步提出整体的系统解决方案及方案效果总结。

关键词：数据分析,业务监控,监控预警

业务监控系统 篇2

（讨论稿）

为进一步细化典当业务审计内容，及时发现问题、堵塞漏洞、规范操作、降低风险，促进同祥典当事业持续健康发展，根据《典当管理办法》和同祥集团、同祥投资公司制定的相关规章制度、操作规范等，制订本审计要点。

一、当物事项审计

是指《典当管理办法》中规定的当物事项。《办法》明确规定不得收当的财务内容包括：

（一）依法被查封、扣押或者已经被采取其他保全措施的财产；

（二）赃物和来源不明的物品；

（三）易燃、易爆、剧毒、放射性物品及其容器；

（四）管制刀具，枪支、弹药，军、警用标志、制式服装和器械；

（五）国家机关公文、印章及其管理的财物；

（六）国家机关核发的除物权证书以外的证照及有效身份证件；

（七）当户没有所有权或者未能依法取得处分权的财产；

（八）法律、法规及国家有关规定禁止流通的自然资源或者其他财物。

二、横向审计

横向审计是指按照典当业务种类实施审计，典当业务种类较

多，在横向审计时，应严格把握不同业务的各自特点，明确审计要点。

（一）房地产抵押典当业务，审计要点：

1、审查借款合同，看条款是否合理，内容是否完整，书写是否正确，印（章）押是否齐全。

2、审查抵押登记手续，看是否到当地房（地）产管部门办理了合法有效的房（地）产抵押登记。

3、审查折当率（抵押贷款金额占抵押品价值的比率），看是否符合公司规定（60%），是否有擅自提高折当率现象。

4、审查公证手续，看是否办理了合法有效的《强制执行公证》或《委托过户公证》。

5、审查抵押品处置准备，看是否出具了《同意借款夫妻声明》、《共有房产抵押声明》、《二套房证明》或《第三人同意租住证明》。

6、审查抵押品价值，评定抵押品估价是否合理。

7、审查客户还款记录（收当、续当的时间及次数），评价客户潜在风险。

8、审查客户信用，看费息缴纳、赎当、续当的主动性、及时性。

9、审查“评估软件”使用，看是否坚持了每笔放款业务均通过“软件”评估打分，是否与人工评价相一致，“软件”数据库更新是否及时（按季）。

10、审查贷款帐表、帐据，看本类贷款与会计报表、业务报

表、当票、抵押品登记薄等是否相符。

（二）机动车质押典当业务，审计要点：

1、审查借款合同及必备证件资料，如车辆登记证书、行车本、保险单、发票、税票、车钥匙。

2、审查质押登记手续，看是否到当地车辆管理部门办理了合法有效的质押登记或办理了有效的GPS定位装置并适时跟踪监测。

3、审查车辆过户手续是否齐全。

4、审查贷款额与车辆估值的比率。

5、审查收当、续当时间及次数。

6、审查费息缴纳及续当的及时性。

7、审查“评估软件”使用，是否与人工评价相一致，“软件”数据库更新是否及时（按季）。

8、审查贷款帐表、帐据，看本类贷款与会计报表、业务报表、当票、抵押品登记薄等是否相符。

（三）股权质押典当业务，审计要点：

1、审查借款合同及必备证件资料。

2、审查是否到当地工商管理部门办理了合法有效的股权质押登记手续。

3、是否办理了强制执行公证或委托公证。

4、审查贷款额与股权价值的比率。

5、审查该公司近期财务报告。

6、审查收当、续当时间及次数。

7、审查费息缴纳及续当的及时性。

（四）动产（物资）质押典当业务，审计要点：

1、审查借款合同及必备证件资料。

2、审查贷款额与质押物资价值的比率。

3、审查物资是否移库、签订租赁合同专库保管，或指定第三方监管等手续。

4、是否坚持现场看守监控质押物资并做好记录。

5、审查收当、续当时间及次数。

6、审查费息缴纳及续当的及时性。

（五）民品典当业务，审计要点：

1、审查借款合同及必备证件资料。

2、审查贷款额与质押物资价值的比率。

3、审查当物凭证，主要包括黄金、白银及其制品，翠玉首饰，手表，电子产品等，查看是否符合典当管理办法的规定。

4、审查当物来源，查看当物是否有正当的来源凭据。

5、审查当物，查看是否在典当物品登记表上对当户姓名、单位、居民身份证号码及当物名称、数量、规格等逐项登记。当物是否封包、封袋要求按品种类别，先后顺序存列、摆放整齐。查看库房当物的出入库管理制度。

6、审查当物查验检测记录。

7、审查收当、续当时间及次数。

8、审查费息缴纳及续当的及时性。

（六）股票配额典当业务。审计要点：

1、审查借款合同及必备证件资料。

2、审查典当行、借款人、开户人签订三方协议，是否明确规定开户人仅提供账户使用权，不承担任何风险也不分享任何收益。

3、审查是否设置警戒线和平仓线。

4、审查是否设置专人监控并定期记录监控情况。

5、审查收当、续当时间及次数。

6、审查费息缴纳及续当的及时性。

（七）应收账款质押典当业务，审计要点：

1、审查借款合同及必备证件资料。

2、审查贷款额与应收账款价值的比率。

3、审查应收账款的回收期是否在六个月以内。

4、审查是否在人民银行征信系统办理登记（先登记、后放款）。

5、审查是否取得债务人的还款认可。

6、审查收当、续当时间及次数。

7、审查费息缴纳及续当的及时性。

（八）信用业务，审计要点：

1、审查借款合同及必备证件资料。

2、审查有无担保人及担保资料的合规性。

3、审查是否经过有权审批人的审批，审批程序是否规范。

4、审查收当、续当时间及次数。

5、审查费息缴纳及续当的及时性。

6、根据不同信用形式审查相应的资料。

三、纵向审计

（一）贷前审计

1、审查是否有典当业务调查报告，审查调查报告的内容。

2、审查借款客户提供的资料是否齐全。

3、审查贷款申报流程，审查是否符合公司规定的审批权限规定。

（二）贷中审计

1、审查其放款流程，是否符合公司的要求。

2、审查当票、支款凭证、支付指定书、费息率等内容是否正确齐全。

3、查看各环节的工作内容和方法，是否存在漏洞。

（三）贷后审计

1、审查档案、当物是否有专人保管，如何管理。

2、审查贷后跟踪，是否定期调查、回访客户情况，是否有工作底稿和调查报告。

3、审查逾期贷款、绝当贷款的处置方案、时间安排以及落实效果。

银行核心业务系统发展指引 篇3

在银行的整个IT蓝图中，核心业务系统是负责处理和管理核心银行产品的生产系统。所谓的“核心”银行产品，就业务而言，其实也就是指银行主营业务中向客户提供的存款、贷款、中间业务等产品和相关的服务。因为这些都是最主要的、最常使用的银行产品，所以银行核心业务系统必须具备可靠性强且能支持大数据量任务处理的能力。在一定程度上，核心业务系统是一个商业银行日常运作的基础，核心业务系统的先进程度对整个银行的运作有着至关重要的影响，一套专业化的核心业务系统在优化业务流程、提高生产效率和盈利能力方面的重要性越来越被银行高管层所重视。近年来，核心银行业务系统升级的浪潮由国外延伸到中国，传统核心业务系统对银行业务变化发展的适应性问题越来越浮上台来。

这里我们分别从影响银行发展的大环境和银行内部发展所采取的措施，来看传统核心业务系统的逐渐失势。

银行业务发展大环境推动系统发展

一是客户需求环境不断变化，金融产品的创新需求层出不穷。金融产品的创新，從规划设计到营销和维护，都离不开一个具有灵活架构的核心业务系统的支持。二是市场竞争短兵相接，外资银行不断涌入中国市场。国内商业银行需要知己知彼，首先要透彻了解自身的业务经营状况，才能在此基础上制订合理的业务策略。三是增强风险控制能力，应对银行上市浪潮的冲击。这就要求银行的业务系统能够帮助银行对业务流程进行规范和集约化管理，以提高生产效率，有效控制操作风险。

这些变化的直接影响，是给银行的IT系统，尤其是核心业务系统，带来了新的要求。绝大多数银行现有的核心业务系统，受到原来设计理念和技术手段的限制，难以对新出现的业务需求进行支持，甚至可能成为商业银行业务发展的瓶颈。通过建设具备先进设计理念的新一代核心业务系统，并在实施过程中进行配套的全行数据集中和流程重组来实现业务经营的规范化和集约化，是我国商业银行提升自身竞争力的必然途径。

银行内部发展的需求催生新系统

为了在激烈的市场竞争中占据一席之地，银行内部也正在进行着全面、深刻的变革，这些变革涉及到银行经营管理的方方面面，从组织架构、业务模式、激励机制，到产品创新、客户服务、风险管理，而作为支撑银行业务高效运转的核心系统，必须充分满足这些新的需求：一是深入理解客户，努力提升客户满意度的需求。二是建立快速产品创新体系，提供特色金融服务的需求。三是实施数据标准化，持续提升管理信息化水平的需求。四是IT技术创新，应用系统架构体系优化的需求。

不可否认，国内很多银行使用传统核心业务系统在柜台服务方面实际上与国际银行业并没有大的差距，有的地方做得更好，但是一涉及到对组织结构、经营理念、管理架构和业务流程进行重组，以及绩效考核、风险管理等严重依赖信息体系的领域，就显得严重的滞后了。并且，大部分商业银行用于处理核心银行业务的IT 系统均是由银行自主开发，或直接购入的较成熟系统，经过多年的运行之后其维护成本迅速升高，系统架构封闭，不易于加入新的功能且易宕机。同时，系统的设计不是以客户为中心，并且不同应用系统之间难以进行信息的共享，因此已慢慢难以适应业务发展的需要。

新老核心系统的差异

随着IT应用的发展，国内银行核心业务系统的发展历程基本上可以归纳成四大阶段：替代手工操作的电算化登记薄概念的单机版时代，各业务系统独自处理的主机终端模式时代，以数据集中、面向交易为特点的综合业务系统时代和面向客户、产品化的“新一代”。其中综合业务系统普遍被认为是传统的核心业务系统，这种说法也是相对于目前“新一代”核心业务系统而言的。

核心业务系统的简单对比

系统架构—“以账户为中心”与“以客户为中心”的系统架构是新一代核心业务系统与传统业务系统的主要区别所在。传统核心业务系统是以账户为中心进行设计的，使得业务数据的存储、维护和展现等操作都在账户层面进行。账号里还包含机构号等与客户本人不太相关的管理要素，造成客户只能跟着机构走，一旦机构撤销，客户必须更换存折之类的种种不合理现象，致使银行的客户服务能力下降，甚至会导致客户流失。同时，客户完整关系视图的信息在以账户为中心的架构下也难以获得。而新一代核心业务系统采用以客户为中心的设计，通过惟一的客户信息文件将不同应用系统中属于同一客户的账户连接起来，并且在客户信息文件中定义不同客户之间的相互关系，来形成客户完整的关系视图。以客户为中心的核心业务系统帮助银行获得更多客户层面上的信息，作为正确制订业务策略的基础，令银行管理者能够实现更为精细化的风险管理和差异化服务。

设计理念—“二次开发”与“参数化设计和灵活的架构”所提供的业务需求反应能力。传统核心业务系统中，在设计开发时没有考虑足够的灵活性，只具备支持已有产品的处理能力，通常需要IT人员在原系统的基础上进行二次开发，来满足新的业务需求。这种二次开发的方式与一般的系统开发一样，需要经历从功能设计、编程实现、测试到最后系统上线的整个过程，开发周期很长，同时费用昂贵。而新一代核心业务系统在系统设计开发的环节上考虑了未来可能出现的新业务需求，从而确保系统的灵活性。更为重要的是，新核心业务系统将系统中与产品相关参数进行了规范和组织，引入了“产品工厂”的概念。银行的业务人员可以通过直接使用产品工厂对相关参数进行设置，自己在系统中创造金融产品，大大缩短了产品开发周期，加快了金融创新产品上市的速度。

技术手段—是否能够提供高可靠性的全天候服务是衡量两代核心业务系统的重要指标。随着网上银行、ATM等自助服务设备的普及，银行需要具备向自己的客户提供全天候“7*24”服务的能力。受到技术手段的限制，现有的银行业务系统通常需要在每天特定的一段时间内执行批量操作处理，将当天发生的所有交易入账。在这段批量处理的时间段内，系统不能向客户提供服务。新一代核心业务系统，通过各种技术手段，例如多个数据库互为备份、多线程技术等等，尽量缩短批量操作窗口，进而实现真正的全天候服务。

流程再造—模块化设计是新一代核心业务系统另外一个突出的特征。以往的银行业务系统都是以流程为导向设计的系统。当银行的业务流程发生变化的时候，就要对系统进行重新开发。而模块化设计的思路，把相关的功能集中到功能模块中，通过对不同的功能模块进行组合，来实现银行的业务流程。而一旦银行的业务流程发生变化，系统可以通过参数的设置对功能模块进行重新安排来支持新的业务流程。模块化设计使得核心业务系统具有了更大的灵活性。

“大”、“小”核心的理念。传统的核心业务系统一般都是核心系统和部分简单管理系统模块的结合体，同时实现了属于信贷管理、风险管理、财务管理业务中部分流程管理的功能。新一代核心业务系统的定位是一个快速交易系统。他剥离了大部分事后管理功能，把与交易无关的处理都交给了外围系统。但是基础数据和架构设计上缺乏对管理系统的支持，这是与“小核心、大外围”的理念是一致的。

不难发现，在银行核心业务系统进入数据大集中阶段后，银行对未来核心业务系统建设和改造有诸多共性的要求。当然，各商业银行对核心业务系统还是有较大的差异化需求，对其业务范围、设计理念、技术路线和建设方式等方面的要求也各有不同。

核心业务系统建设着眼点

涵盖商业银行通用业务。要求系统所提供的金融产品，可以为银行业务提供一站式、全方位的专业服务：包括个人银行业务、对公银行业务、同业银行业务、理财银行业务、国内清算，国内外支付等等，具有广泛的通用性。

以客户为中心。将客户唯一标识的理念融入整个银行IT系统，在细分客户、分层服务的前提下，为优质客户提供量身定制的服务，实现统一的客户信息视图、统一的客户押品及额度管理、统一的客户协议管理以及统一的集团和客户群管理等功能。

模型化与参数化的产品定制开发模式。抽象银行各类业务的属性及关系，形成银行产品模型，并基于模型，缩短金融产品的发布周期，快速将产品推向市场。需要核心业务系统具有基准产品模型和产品工厂，对产品进行统一编码和控制管理，支持组合产品和子产品；支持按银行的管理要求从产品开发、产品定义、产品营销、产品服务，一直到产品分析、考核等各阶段对产品进行分类管理。

“流程银行”的业务流程处理方式。围绕客户和市场需求设置流程，将经营组织结构和各种资源完全围绕业务流程而展开，将银行的服务从质量、成本、时间、风险、法规五个原则贯彻到前、中、后台的流程中。结合国内现状，不仅需要分业务线垂直经营和管理，可能还需要“条块结合”的管理。核心业务系统需要实现核算、结算、监督、操作型客户关系管理等大量中后台业务进行集中处理；实现组织机构的管理层级灵活设定，实现柜员权限完备而灵活的设定；在统一的会计核算机制下，提供丰富的多维度考核数据源，包含机构、客户、渠道、产品等信息，支持以业务单元为主的矩阵考核方式；将分开、重复的多道工序进行合并，减少不必要的流程环节和手工操作，实现业务直通式处理（STP）。

面向服务（SOA）的架构设计理念。这种以服务为导向的架构支持不同渠道对共享服务的重复使用。这就要求系统能支持组件化的设计和开发方法，将服务单元松耦合在一起；组件实现的功能单元能被有效管理和高效、方便的重用；服务具有明确定義的接口，使核心系统的交易能通过多种协议对外提供服务。

数据逻辑集中、统一标准规范。核心系统需要对银行的客户数据、业务数据、风险数据进行系统分析和评价，满足各地域在监管上的对数据的要求，提高科学决策和风险管理水平。这就要求核心业务系统能具有高效处理能力，支持大规模的交易量；统一业务处理、账务处理，满足地域特色业务的要求；基础设施具有极高的稳定性和容错能力，保障系统7*24小时稳定运行。

除了上面提到的几个特点之外，对多语言、多币种的支持、清晰的接口定义、实时数据更新以及系统技术平台的可扩展性和低维护成本都是新一代核心业务系统应具备的特性。

系统建设策略的思考

核心业务系统的选择

解决了为什么要对核心业务系统升级或再造的问题，那么接下来我们要面对的是如何选择新一代核心业务系统并成功实施发挥其核心竞争力作用的问题。

一般来说，国内厂商自行研发的核心系统与当前银行的需求更相符合，其优势主要在于它是针对中国金融市场而产生的，产品本地化和客户化程度比较好；厂商深刻理解中国市场，更能贴近和理解客户需求；能满足本地特色和报表的需要；同时许多较领先的厂商还有强大的本地支持力量。但这些系统在发展中的中国金融市场不到10年的运行经验，缺乏国际大银行服务经验，且产品本身及风险管理功能等不够成熟。近几年来，国内一些领先的IT开发商开始加强国际合作，尝试开发同国外水平相当的核心业务系统，目前已有相当大的突破。

相比较而言，国外引进的核心系统有成熟的产品和客户为中心的设计，能够覆盖更全面的国际化银行业务功能，可适应银行产品的增加和变化；资产和资金类业务功能、分析功能及风险管理功能比较完善，且在成熟的金融市场环境中已经经历了近30年的洗礼，其项目实施管理和采用的技术比较先进，在全球很多国家都有成功案例。而国外厂商面临的问题是：我国金融市场化程度不高，监管框架、相关法规制度与国际标准还存在较大差异，银行治理结构、内部经营管理体制、操作方式等方面的不同，这些都加大了国外核心业务系统本地化和客户化的工作量。同时，国外厂商缺乏对国内金融市场和客户的了解，以及与国内银行客户良好默契的合作经验，其产品也在一定程度上缺少对国内业务的适应性，本地特色和报表的需求均不能满足，系统还需要做本地化和客户化工作。为适应国内的财会准则以及人民银行、银监会等监管机构的监管要求，国外的核心业务系统必须做出适当修改。

可以看出，国内外的银行核心业务系统各有优势。从近两年的实践看，立足国内系统的“补丁路线”正在演变为“本土进化”，而青睐国外系统的“一步到位”也在提倡“引进消化”。那么“国外先进的产品和本地化的实施服务”就成为成功引进国外先进的银行核心业务系统的关键。

银行核心系统的引进并不仅仅是个IT项目，而是一个伤筋动骨的银行业务流程再造的工程。正所谓应用系统建设“三分业务和技术，七分管理和沟通”，成功引进核心系统的关键就在于能否通过科学的项目管理和良好的客户沟通，极大地满足客户的需求，并使客户的商业价值和竞争优势通过项目的实施而得到充分的提升。银行新一代核心业务系统的建设还需要以银行的管理架构和业务流程同步再造互为前提。这样银行对系统支持服务的依赖和要求就很高，应用系统的维护成本比较大，而往往银行又不能投入与项目开发阶段相当的高额维护费用。在这样的历史条件下，如果国外厂商没有通过本地化的方式来把握银行需求，完善支持队伍，往往就会造成系统开发不下去。因此，在国内目前的经济环境和技术环境下，国外厂商单独完成国内银行应用系统的建设，项目实施和后续维护的风险是很大的。

核心业务系统的构建

在这里，我们提出一种模式，其前提是对国外银行核心业务系统的引进，项目实施模式则是银行用户、本地化的应用服务商和国外产品开发商密切合作，共同完成。

为稳健实施核心业务系统建设项目需要重视以下几项工作。

首先，构建一个比较稳健、适度灵活的IT架构，围绕标准化、适应性、可配置等原则，打造一个具备根据需求提供服务、基于服务提炼产品能力的应用体系，整体技术设施具备支撑银行发展战略的能力。要求核心业务系统不仅能够满足国内现有的银行业务，而且还需满足未来金融市场需求，使商业银行能够很快地适应未来业务发展需要。

其次，要继续保持先进系统的特色，包括：

“以客户为中心”的理念：提升数据的准确性和规范性，以全行唯一的客户号识别客户，通过客户号勾连所有业务和产品，账户、产品、抵押品、合同等关联信息集中体现，关键客户信息保持同步，客户信息、签约信息等动态更新等。

交易与核算分离：通过分录引擎使得交易与核算完全分离，银行内部账务不会对客户服务产生影响，客户账号不会受到内部核算、网点、货币等的影响。

全行一本账：各级机构的账务与总行一点清算，损益等内部账务集中管理，财务报告统一管理，提高资金运作效率和风险控制能力。

灵活丰富的参数定制：以“机构、客户、产品、交易、核算”参数模型为基础，进行合并、提炼，抽象业务控制要素，创新建模，不做简单的要素堆砌，保持参数的层次性和高提炼性，只要在模型提炼的范围内，新产品通过参数定制无需系统开发，满足客户服务快速响应的要求。

内控管理支持：在柜员管理、客户身份识别、交易授权、账务核算、对账管理等，实现从柜员到客户、从交易到账务等多维度、全方位控制，降低授权环节风险，提高自动化水平。

具体到技术上的创新和突破，则主要包括：清晰的核心银行系统定位、总线级的集成架构、松耦合的设计理念、科学的数据库分区手段、快速可扩展的夜间交易重入、并行的批处理作业调度、高吞吐的联机批量能力、高效稳定的短交易模式等。

再次，强调“以我为主”的实施策略。在实施中我们通常会遇到国外产品大多缺乏支持大规模交易经驗，银行内部旧有观念难以转变，国外厂商支持能力不足等重重困难和挑战。那么，如果本地化的应用服务商能够很好地完成对外购系统的学习、消化和吸收工作，掌握新核心银行系统的核心技术，具备“以我为主”的开发能力，同时充分调动行内外技术资源，就能高效地加大自主创新力度，努力降低科技外包风险；同时，在实施管理也不能一蹴而就，在项目建设期存在较大的集成性风险，在有限的时间内，业务流程的再造、人力资源的保证和业务需求和IT建设需要无缝衔接，风险非常大。而在上线和试运行以后，还会有适应性的风险，银行的各个环节都会出现一些排异现象。因此需要采用合理的手段来控制可能出现的风险：

统一领导、全面考虑。在银行中推行新的核心业务系统往往会引起原有组织结构和业务流程的变化，造成领导层和员工的不适应，甚至对新系统的抗拒。需要及早理清项目之间、工作之间的前后关系和衔接关系，处理好流程再造与技术建设的关系，以及各IT系统之间的关系。核心系统与外围系统、外围系统之间、基础系统与应用系统、新系统与老系统之间，都有建设先后、顺利连接、安全切换的问题都需要进行统一的领导和整体的规划考虑，在计划与进度之间、质量与风险之间做出平衡和把控。同时，参与各方也要正视差异、互为进退，共同面对和分担项目风险。

团队协调、适当取舍。由于进度方面的要求，在项目建设过程中，需要将不同的任务分配给多个小组，采用并行的方式来完成。此时团队间的协调显得尤为重要，当分歧出现时，管理团队内部（银行项目管理与服务商项目管理）、业务团队、技术团队测试团队之间需要坦诚相待、精诚合作，建立通畅的沟通机制和问题跟踪与解决机制，在需求变更、开发难度、项目进度、实施成本等方面适当取舍，做出最有利的决策。

当然，我们还要重提一个观念，就是：核心业务系统建设成功与否，是以银行的管理架构和业务流程同步再造互为前提的。先进的银行核心业务系统为银行的管理架构重组以及流程再造提供了基础，但不能替代那些非IT系统层面的改革。

这种银行用户、本地化的应用服务商和国外产品开发商共同合作的模式应该是一种长期的合作，而不能止步于系统的成功上线。有的银行考虑到系统维护和运营成本，会采取自行维护或将其交给国内服务商，而将国外产品开发商摒弃在外，这种做法是缺乏远见的。我们必须承认，在一段时间内，国外经验的先进性及其在实际应用领域的指导作用，仍然是我们需要花大力气认真学习与充分借鉴的，而保持与国外厂商的长期合作关系，对于国内银行迅速融入国际化程度日渐提高的激烈的市场竞争环境，将会起到事半功倍的作用。

企业综合业务监控系统应用研究 篇4

1. 综合业务监测对煤化工业的重要性

煤化工是以煤为原料, 经过化学反应生成化工、能源产品的工业。由于煤化工是新兴行业, 既包括煤炭转化技术, 又包括化学工业技术, 生产条件特殊, 不仅有高温、高压的生产条件, 同时又有易燃易爆气体及有毒有害气体, 属高危生产行业, 在生产过程中, 容易发生财产损失和人员伤亡事故。因此实施安全生产在线监测, 对煤化工生产企业的科学管理, 避免重特大事故的发生, 具有特别重要的意义。随着国家对煤化工产业安全生产的要求不断提高和企业自身现代化建设的需要, 大型企业都陆续实施实时监测监控系统。监控系统的实施对于改善煤化工企业的安全状况, 提高煤化工企业的生产效率和现代化水平起到了重要作用。

二、综合业务监测系统具有的功能

1. 多种方式和环境全方位展示企业生产经营信息。

在管理者的桌面、电视屏以及手机、IPad等手持终端上实时浏览工厂运行状况, 企业经营管理状况、工厂人员定位等。

2. 所有信息集成到门户首页, 登录首页即进入的信息超市。

3. 将那些只能在中央控制室才能看到的信息和数据, 通过多业务集成和Web技术发布到任何有权限的桌面和终端。

4. 不仅穿透性展示了过程管理层、执行管理层、经营管理层和决策支持层数据, 同时集成了工厂CCTV视频信号、安防保卫信息、巡检及人员定位信号。

5. 集成已有生产、经营、管理信息。综合应用业务平台不再是传统意义上的信息管理或IT技术, 它所涉及的范围更为广泛, 并注重于对底层数据和信息的管理。好比一座架在经营决策管理层和基本生产单位之间的桥梁, 能够有效填补相互之间的空隙。

6. 实现企业效率

企业信息网络平台建成后, 通过对生产、经营、管理等信息的集成, 可以使企业上层经营计划管理与下层生产经营控制管理进行有效地粘合, 将企业的生产、经营集成为一个高效运转、高效自动化的整体。从而实现企业对生产经营及时、准确、全面地监控管理, 进一步提高企业生产经营决策的科学性, 提高企业的生产效率, 为企业创造更大的经济价值。

三、关键技术和实施策略

1. OPC技术

OPC (OLE for Process Control) 是为过程控制设计的OLE技术, 由一些世界上占领先地位的自动化系统和硬件、软件公司与微软 (Microsoft) 紧密合作而建立的, 相对于传统的方式, OPC技术把软硬件厂商区分开来, 使得双方的工作效率有了很大的提高。

2. DCS技术

DCS所谓的分布式控制系统或称之为集散系统, 是相对于集中式控制系统而言的一种新型计算机控制系统, DCS是一个由过程控制级和过程监控级组成的以通信网络为纽带的多级计算机系统, 综合了计算机 (Computer) 、通讯 (Communication) 、显示 (CRT) 和控制 (Control) 4C技术, 其基本思想是分散控制、集中操作、分级管理、配置灵活、组态方便。

3. PLC相关技术

PLC (Programmable Logic Controller, 可编程控制器) 是一种电气自动化控制装置, 它使用可编程存储器内部储存用户设计的指令, 这些指令用来实现特殊的功能, 诸如逻辑运算、顺序操作、定时、计数以及算术运算和通过数字或模拟输入/输出来控制各种类型的机械或过程。

4. 实时数据库技术

实时数据库 (RTDB-Real Time DataBase) 是数据库系统发展的一个分支, 是数据库技术结合实时处理技术产生的。实时数据库可用于工厂过程的自动采集、存储和监视, 可在线存储每个工艺过程点的多年数据, 可以提供清晰、精确的操作情况画面, 用户既可浏览工厂当前的生产情况, 也可回顾过去的生产情况。

5.net

NET是Microsoft XML Web services平台。XML Web services允许应用程序通过Internet进行通讯和共享数据, 而不管所采用的是哪种操作系统、设备或编程语言。Microsoft.NET平台提供创建XML Web services并将这些服务集成在一起之所需。组成.net软件技术组件之一, “智能”客户端应用软件和操作系统, 包括PC、PA、手机或其他移动设备通过互联网、借助Web Services技术, 用户能够在任何时间、任何地点都可以得到需要的信息和服务。

四、综合业务监测系统模型

1. 综合业务监测系统传输模型

建立高速、开放、安全、可靠的煤化工综合业务监测网络传输平台, 解决所有生产自动化子系统传输物理通道和接入问题;对所有子系统进行数据采集、处理、存储、发布, 完成一个信息集中管控/网络发布平台, 同时, 在企业信息管理网络中通过Web权限认证可以看到安全、生产实时信息。

目前, 煤化工综合监测系统越来越多地采用现场总线或以太网作为站内的通信网, 将自动化销售终端、基地公用工程计量系统以及其他过程控制系统与上层监控主站连接起来。由于多总线之间协议的不一致性, 导致了上层监控软件和下层硬件设备之间通信的兼容性问题, 只能局限于专用的软件开发商和硬件生产商。

现采用OPC (OLE for Process Control) 技术统一上层监控软件和下层硬件设备之间的通信, 使系统监控主站具有很好的开放性和可移植性。基于OPC技术的监控主站的设计与实现可以完全脱离下层接口硬件, 监控软件被设计成整个监控系统框架中的一个OPC客户端的方式运行, 因此在上层监控软件和下层硬件设备之间的关键是OPC服务器, 它可实现上层和下层通信。通过OPC数据接口, 对数据源进行数据采集, 将此信息传送到实时数据库, 经过一系列的处理以后, 传送到综合业务监测平台, 实现对现场状况的动态监控。

五、综合业务监测系统结构及功能实现

1. 网络硬件架构

网络主干采用单模光纤传输 (传输速率1000M) , 将所有生产自动化监控系统设备控制层子系统连接到此网络平台上, 调度指挥通过此平台可监视各子系统内设备的运行状态, 收集所需的生产和安全参数。

网络系统设计针对信息集成、结构分层、层间相对独立的原则, 网络系统的建设根据应用的不同层次, 作如下设计:

信息层:建设信息管理网, 采用标准TCP/IP协议和以太网技术, 实现厂区各个管理部门的网络连接, 实现人、财、物以及工程项目管理的综合自动化, 能对产品运输和化工生产状况进行实时监视, 为管理决策提供依据。

控制层:建设综合自动化控制网, 采用工业以太网+现场工业总线来实现, 将整个区域控制器和设备监控站所采集的信息和控制信号传送给有关系统。

设备层:在设备控制层主要是工厂专业控制子系统。整个综合业务监测系统中的远程监测监控系统采用Web客户/服务器、浏览器/服务器模式将分布在不同地域的设备监测资源连接在一起, 从而实现远程监测的广域网络化。

2. 数据采集、存储和管理

为了保证所有采用不同协议的不同设备、不同控制系统信息都能集成到一个统一开放的平台上, 在设计中采用了PI系统, 为全厂范围数据采集、存储和管理建立一整套单一、开放、集成的一体化应用平台。这种数据库系统可以集成所有工厂的过程数据。支持OPC通信协议, 直接与实时数据库连接。在通讯协议级实现串口 (包括RS232、RS485、RS422等) 、以太网、各种现场总线 (包括CAN、LonWorks、Profibus等) 通讯网络的相互转换, 还可以直接采集4-20mA、DI等物理信号。这种全厂范围内的数据库结构可保障工厂的管理部门使用一致的数据。

1) 数据的采集

为了保证数据采集的准确和可靠性, 对实时数据库采集模块进行了接口的开发设计, 该接口不仅采集包括甲醇厂所使用的霍尼韦尔系统的接口 (TDC3000, TPS, Pla ntScape, Scan3000) , 还提供与烯烃厂、聚甲醛厂所采用DCS系统的连接接口, 系统可采集实时数据, 同时还能采集非连续的数据, 如实验室的分析数据, 物料的移动数据及操作改变等。并将LIMS实验室信息管理系统的数据统一到本平台上来。

2) 数据的存储和处理

作为一体化应用平台, PI需要对实时数据、并发事件信息、事务性数据和应用数据的进行管理。在系统内部实现要保证实时数据库和关系数据库 (Oracle) 的无缝连接, 以方便管理应用软件的开发。系统支持毫秒级实时采集, 保存累计时限可达10年之久。该系统可对每一个数据进行出错检查, 剔除跳变的值, 坏值, 并给予可信度显示, 确保数据的可靠性。为了保证管理人员能及时了解生产状况, 及时发现问题并解决问题, 在全厂范围内的内网PC上均可通过访问公司主页获取现场实时数据。可通过事件监视模块的触发, 及时预警工艺故障、设备故障和仪表故障, 通知相关人员处理以减少非正常停车或波动。

通过实时数据库相关应用和基于Web的信息发布技术解决了所有底层数据的接入问题和上层应用的集成问题, 为了满足多业务综合监测的需要, 同时将工业通讯和视频信号以及楼宇自控信息接入到系统平台上来, 以便进行综合业务的集中指挥和控制。通过.net技术将所有信息系统和监控系统整合到门户上, 企业各级管理人员通过单点登录系统进入综合业务平台后, 即进入了包括应用系统、控制系统、实时系统、监测系统等在内的一站式综合信息超市。H

项目背景

宁东是国家批准规划建设的13个亿吨级大型煤炭基地、7个煤化工基地、以及国家第二批循环经济示范园区, 宁夏将宁东能源化工基地确定为自治区“一号工程”。党和国家领导人中有八个常委包括总书记和温总理先后到基地视察。神华集团对基地信息化建设也高度重视, 将神华宁煤做为信息化试点单位, 率先实施, 煤化工公司作为与集团公司众多煤炭单位完全不同的行业, 具有资金密集、技术密集、人才密集的特点, 其信息化建设更具挑战性和紧迫性。

摘要：本文介绍了基于OPC技术、网络技术和组态软件技术相结合的远程监控系统是如何实现的。同时介绍了各个部分的技术核心、功能以及如何接口和集成, 为综合业务的集成提供了参考价值。

业务监控系统 篇5

综合业务系统电子汇兑业务管理办法

第一章 总则

第一条

为规范湖南省农村信用社综合业务系统电子汇兑业务管理，确保电子汇兑业务高效、安全、稳定开展，加速资金周转,防范支付风险，依据中国人民银行《支付结算办法》和《农信银资金清算中心有限责任公司章程》，以及《湖南省农村信用社综合业务系统操作规程》，特制定本办法。

第二条

湖南省农村信用社结算中心(简称省中心)是农信银资金清算系统的直接参与者,信用社(含农村合作银行,下同)是农信银资金清算系统的间接参与者,适用本办法。

第三条

电子汇兑业务是参与者受理客户委托，将款项通过农信银资金清算系统及时汇划异地收款人的行为。

第四条

电子汇兑业务逐笔实时处理业务，省中心与农信银清算中心全额清算资金。信用社综合业务系统按清算关系日终清算各参与社的汇差资金。

第五条

支付信息由纸凭证转换为电子信息，或电子信息转换为纸凭证，具有同等的支付效力。支付信息经过确认才产生支付效力。

支付信息由纸凭证转换为电子信息，电子信息产生支付效力，纸凭证失去支付效力；电子信息转换为纸凭证，纸凭证产生

１ 支付效力，电子信息失去支付效力。

第六条

信用社办理电子汇兑业务，应保证各级清算账户有足够的资金办理汇兑业务。

第七条

农信银清算系统运行工作日和系统运行时间由农信银清算中心统一规定，各参与者应严格按规定时间接发业务信息。

第八条

农信银清算中心根据清算系统运行情况和业务需要可以调整系统运行工作日和运行时间。

第二章 业务管理

第九条

电子汇兑业务由发起社发起，经省中心、省中心前臵机、农信银清算中心、收款清算行，至收款行止。

第十条

电子汇兑业务信息经确认才产生支付效力。汇兑业务信息经农信银资金清算系统传输过程的确认，应符合农信银清算中心规定的信息格式，并按规定编核密押。

第十一条

信用社将电子汇兑业务信息实时发送至农信银清算中心，农信银清算中心检查业务信息的合法性和清算账户可用额度，对通过检查的业务进行实时全额清算后，将已清算通知发送至省中心，并将业务信息转发接收行。如果省中心清算账户可用额度不足，则将该笔业务纳入日间排队。

第十二条

信用社对已发送的电子汇兑业务需要撤销的，应通过综合业务系统发送撤销请求。农信银清算中心未清算资金的，立即办理撤销；已清算资金的，不能撤销。

２ 第十三条

信用社对已发送的电子汇兑业务需要退回的，应通过综合业务系统发送退回请求。

信用社收到退回请求，未贷记接收人账户的，立即办理退回。已贷记收款人账户的，不得办理退回，应当通知付款行由付款人与收款人协商解决。

信用社对收到的有差错的电子汇兑业务，应当主动通过综合业务系统向付款行查询后办理退回。

第十四条

信用社对有疑问或发生差错的电子汇兑业务，应当使用查询查复格式报文，在当日至迟下一个法定工作日发出查询。信用社收到查询，应当在收到查询信息的当日至迟下一个法定工作日予以查复。

第三章 安全管理

第十五条

信用社办理电子汇兑业务应执行严格的岗位权限控制，根据岗位设臵分别授予相应操作权限，各岗位之间不得越权操作。

第十六条

信用社办理电子汇兑业务人员须经过综合业务系统的学习和培训合格后才能上岗，未经培训人员不得上岗。

第十七条

信用社必须坚持印、押、证分管制度及交接制度，严格对印、押、证使用的管理。

第十八条

省中心设臵通讯密钥，用于对业务数据进行加密处理。通讯密钥应由业务管理人员负责录入，并留存备份。

第十九条

电子汇兑业务各种凭证、报表与存储业务数据

３ 的磁介质属于会计档案的组成部分，各参与者应按《湖南省农村信用社会计档案管理办法》（湘信联办[2005]29号）规定的期限和要求妥善保管。

第四章 纪律和责任

第二十条

各参与者应当遵守本办法以及其他相关规定，加强内部控制管理，保证系统安全运行及业务的正常处理。

第二十一条

省中心的职责

（一）负责按时登录农信银资金清算系统，保证系统前臵机操作端在农信银资金清算中心始终处于正常登陆运行状态；负责系统前臵机操作端管理、日终数据处理与核对及系统维护。

（二）负责农信银资金清算账户的管理，负责省内信用社参与者的行号申报、变更和撤销。

（三）负责办理电子汇兑业务不明来账的转汇、退汇和查询。

（四）负责对辖内参汇社的业务检查、指导、管理和监督。

第二十二条

县、区（市）中心的职责

（一）负责对辖内参与社的业务检查、指导、管理和监督。

（二）负责辖内参与社汇差资金清算和核对。

（三）及时反映系统和解决运行中的各种问题。

第二十三条

信用社的职责

（一）及时发起、接收电子汇兑业务，每天核对来往账和汇差资金。

（二）及时处理查询、查复业务。

４

（三）严格遵守业务操作规程。

（四）及时反映系统和解决运行中的各种问题。

第二十四条

各参与者在办理电子汇兑业务过程中出现以下行为，将依据有关规定承担相关责任。

（一）发起社发送数据不及时，影响客户和他行资金使用的，发起社应承担相应赔偿责任。

（二）接收社违反规定故意拖延支付，截留、挪用资金，影响客户和他行资金使用的，接收社应承担相应赔偿责任。

（三）参与者如因人为原因造成业务数据不能准时传输或发现危害资金安全等问题未能及时报告，影响农信银清算系统正常运行或导致资金损失的，其经济损失由该参与者承担。

（四）因汇划凭证要素不详，接收社未经查询查复，进行账务处理造成资金损失的，由接收社自行负责；发起社收到查询未及时查复，影响客户资金周转的，由发起社负责承担相应赔偿责任。

第五章 附则

第二十五条

通过综合业务系统办理电子汇兑业务的信用社，应按《国家计委、中国人民银行关于制定电子汇划收费标准的通知》（计价格【2001】791号）向申请人（即客户）收取相应费用；省中心按成本收取各参与社的汇划费用，由省中心定期从清算账户划收。

第二十六条

接收电子汇兑来账业务，应使用省联社统一

５ 规定格式的电子汇兑专用凭证，并纳入重要空白凭证管理

第二十七条

各参与单位必须严格遵守本办法，县、区（市）级联社可参照本办法，根据辖内情况制定辖内管理办法。

第二十八条

本办法自农村信用社电子汇兑业务开办之日起施行。

集成系统研发助期刊业务发展 篇6

一、用户需求分析

根据期刊工作的具体实际，业务集成系统应能满足以下基本需求。

（1）首先满足读者网上投稿的要求。实现网上投稿也是开展计算机编审的基本前提，网上没有稿源，则难以实现计算机编审。

（2）满足通联编辑网上进行统计分发的需求，以便把作者来稿及时统计，并发给相关栏目编辑。

（3）满足栏目编辑在网上进行文字、图表编辑的需求，同时，还要满足栏目编辑在网上进行稿件查询、修改、转发，以及与作者联系，与主编讨论审修事宜。

（4）满足主编调阅稿件修编情况，并与作者、编者之间交流，还可满足主编对审定稿件进行发布形式处理。

（5）满足网络编辑在网上编排发布电子文稿。

（6）满足编辑对编审工作所需要的各类信息数据进行查询、浏览。

（7）满足在网上进行组稿，并组织广大读者进行网上研讨。

（8）满足网络管理员进行网上信息管理。

（9）对通联编辑、栏目编辑、网络编辑及管理员、主编等设置相应的工作平台，并赋给相应的工作权限。

（10）满足网络编审和手工传统编审的并行运作，以达到现实与理想的统一。

二、期刊业务系统具有的特点

该系统与其他业务系统综合集成后，主要有以下特点：一是办刊无纸化。即从读者投稿到编辑部选稿、编稿、审定、发布全程可实现无纸化。 二是办公自动化。全社工作人员可依托杂志社局域网，利用办公自动化设备和自动化办公平台，实现办公业务的自动化。三是杂志传播网络化。杂志社可通过网络将杂志信息传播给读者。四是编审业务远程化。编辑人员在外地可通过信息网络，杂志社网站开展稿件编辑与审定业务。

三、期刊业务集成系统的设计

经过认真分析，将用户所需要的功能分解，归纳整理，由投稿与编审系统、论文数据库、信息发布平台、网上办公平台、网络版五个分系统分别实现。在对每个分系统设计时，必须做到既要考虑每部分功能的独立性，又要考虑信息的共享性，既要考虑实用性，又要考虑可拓展性，避免系统设计与实际应用有较大的偏差。

1、投稿系统：投稿系统就是全面分析当前投稿方式利弊的基础上，采用作者自行登记注册个人真实信息方式，在其成为有效用户后，提供上载文章的窗口。在投稿系统里，作者还可更改个人信息，查询个人投稿和刊稿的历史记录以及编辑对稿件的处理意见等。这样，既减少了编辑的工作量，又使作者可随时管理个人信息。

2、编审系统：编审系统是本课题的核心。当前，不少期刊编辑部对稿件的处理流程大体上是：首先对打印的稿件进行审读，其次编辑稿件的电子版，第三步是复审编辑处理的稿件，第四步打印编排后的稿件并由相关编辑校对，最后刊发。许多环节都需要打印和传递稿件，造成出版周期长，人力物力消耗巨大。因此，编审系统可根据自身工作流程，围绕解决上述矛盾进行设计，主要包括稿件筛选（过滤）、稿件提交、稿件初审、稿件分发、稿件转发、稿件编辑、稿件签发（主编终审）、信息发布、用户管理、、基本信息查询、新闻审阅、作者改稿、发布通知等13个方面。

3、数据库和信息发布平台：从数据处理的角度来说，编审系统的稿件处理、网络版及纸墨版的发布就是在数据库的基础上进行数据处理的过程。因此，数据库是期刊网络编审系统运行的数据基础和稿件处理流程所围绕的核心，是系统功能实现的关键。根据系统中数据处理所涉及的内容和范围，以及系统各个子模块所涉及的输入输出数据，同时考虑到杂志社办公的需求，系统规划并建立3个主题数据库，主要包括稿件处理数据库、论文数据库、办公信息库。

4、信息发布平台：为能使主编和各个栏目编辑在系统中进行交流，可为主编设置信息发布平台，主要让主编发布有关杂志信息和上级有关精神，还可进行会议通知、以待、得交流等。信息发布平台必须具有强大的信息管理功能，因此，研制内容包括：可方便增加、修改删除信息；可对信息类别进行管理；能根据需要，授权不同用户管理信息发布平台；通知能自动更新并弹出信息窗口等。

5、网上办公平台：在杂志业务工作中，编辑除对稿件进行编辑修改、刊发，还包括对非网上来稿进行登计，这是编审系统功能的延伸。稿件刊发后需要注明稿件的刊用期数、字数等关键信息等工作。因此，网上办公平台研制主要包括稿件登记、刊用登记、刊用稿统计、稿费管理、资料管理等五个方面的内容。

业务实时监控方案 篇7

一、目标

本方案提供了一种基于数据库日志, 通过结合使用数据实时复制产品如Golden Gate、流处理产品如Stream和内存库如Timesten, 实现对业务受理数据进行及时监控的方法。主要目标是:

1、解决了数据获取的时效性问题。提供了一种基于数据库日志的实时数据获取方法, 数据处理与存储采用流技术与内存技术, 全过程不写磁盘, 在低生产系统开销的情况下提升整体数据获取跟分析的性能。2、实时与准实时数据应用能力。提供高效的实时统计、实时监控与准实时分析能力, 将数据应用的响应时间由传统的天级提升到分钟、小时级。3、辅助快速决策。实时与准实时的数据, 能提供了更广阔的应用场景, 如基于异常业务销售、办理波动, 迅速变更渠道资源如人员排班等工作, 又如库存变更与物流配送时间点合理安排, 提升厅店效率, 实现减员增效。最终实现将传统的业务分析从辅助决策长期目标向提供实时运营, 协助提高企业管控能力, 从而提升了企业数据信息的价值。

二、技术方案

本方案主要组成部分包括数据获取模块、数据处理模块、数据存储模块、数据应用模块、系统管理模块五个部分。各模块的功能具体说明如下:

1、数据获取模块。数据获取模块包括数据实时获取和数据实时加载两个子模块。当业务系统数据库因业务受理、业务回退等种种原因产生数据变动时, 数据获取子模块根据预定义需要监控的表, 通过数据复制产品实时捕获数据库相关变化LOG并转化成可识别的数据格式, 传递到流处理模块或内存库。数据加载子模块获取的数据按既定逻辑要求加载到数据存储模块, 过滤清洗掉与实时分析需求无关的数据, 降低数据存储的压力, 并保证目标系统与源系统的数据一致性。

2、数据存储模块。数据存储模块采用内存数据库作为存储介质, 对数据的进行集中存储与管理, 一方面避免了数据在处理过程中的大数据量交易数据落地写磁盘对分析性能的影响, 保障了处理过程的及时性;另一方面内存数据库也为外部频繁的数据实时读取、调用与分析提供了高效的响应能力。

3、数据处理模块。数据处理模块包括实时数据汇总与准实时数据分析两个子模块。实时数据汇总依托流处理的强大在线汇总能力, 获取并提交展示对及时性要求最高、逻辑相对简单的信息。准实时数据分析基于内存数据库, 按照既定的周期如每10分钟, 对加载的数据做轻度汇总, 并进一步的分析挖掘, 最终提交逻辑相对复杂的分析结果。

4、数据应用模块数据应用模块在获取数据处理模块的结果, 并构建各类业务场景, 如实时统计, 实时监控, 准实时分析等。实时统计面向业务量、收入等最核心的指标, 展示当前累计发展量, 尤其在短期促销时可更显性查看成果。实时监控通过监控波动率, 设定阀值门限等, 及时掌握收入风险、渠道交易异常、库存情况等, 用于管控风险。准实时分析不仅对业务数据做简单的汇总, 还可以通过设定多个维度, 实现更细致的分析, 如各渠道横向对比, 基于时间序列的纵向对比等。

5、系统管理模块。系统管理模块是系统稳定、高效运行的有效保障, 包括调度管理、负载均衡、异常控制等。调度管理具备任务管理、依赖管理、并发管理等功能, 按时间定时生成或者按照事件触发任务, 在满足系统能力或优先级要求时派发, 控制整个系统程序有条不紊执行。负载均衡主要对主机集群的管理, 将应用均衡分配到各主机节点, 充分发挥集群的性能, 以应对实时、准实时分析带来的高并发、高负荷分析与访问。异常控制则在系统出现异常时, 如设备故障、程序故障时, 提供临时解决方案, 确保系统的高可用性。

三、结语

业务监控系统 篇8

随着信息技术的迅猛发展,现代企业对于信息资源的依赖性越来越强。现在,电网公司为了提升管理能力和业务水平,建设了许多信息系统,如营销、生产管理系统等。这些系统规模较大,各类业务应用的特点清晰、专业,实现的技术路线也千差万别,如何对复杂度、差异度、专业度如此之高的业务系统进行统一的监控成为电网企业首先需要考虑的问题。对业务系统监控的关键是建立一套统一的业务系统指标模型。

1 研究背景

对设备或软件运行情况的监控一般采用2种方式:有代理和无代理方式。有代理方式一般通过在被监控的设备或软件中安装插件,以代理的方式来采集运行数据;无代理方式一般通过标准协议与被监控设备或软件通信,实现运行数据的采集。业务指标监控系统对设备、软件的运行监控采用的是基于标准协议的无代理方式。如果对业务系统的运行和应用数据监控也采用简单网络管理协议(Simple Network Management Protocol,SNMP)无代理方式,可以为统一监控技术路线打下基础。

SNMP被网络设备、主机甚至中间件等支持,主要应用于综合网管系统,目的是探测和管理网络上的设备、服务等软、硬件,发现其异常的情况或对其进行控制。它由一组网络管理的标准组成,这些标准包括应用层协议(Application Layer Protocol)、数据库模型(Database Schema)和数据资源。

通常,在一个基于SNMP的系统中,有许多资源,如设备、软件等被管理,而且每个被管对象都可以被一个或多个管理端所管理。每个被管理对象上运行一个软件,这个软件被称为SNMP代理(SNMP Agent)。SNMP代理通过SNMP向管理端发送信息。一般情况下,SNMP代理发送的信息主要是变量。管理端通过GET、GETNEXT和GETBULK等相关的SNMP命令获取信息,或者是SNMP代理没有被调用或访问,使用TRAP或INFORM等相关协议发送数据。管理端也可以发送配置更新或控制的指令,通过SET协议命令发送到被管对象的SNMP代理上,从而实现对被管对象的控制和操作,达到主动管理系统的目的。配置和控制命令只有当被管对象发生变化,比如网络设备上的路由配置、中间件的性能参数等需要修改的时候使用。而使用监控命令则通常是常规的日常工作。可以通过SNMP读取或修改的变量都是以层次的方式进行组合,管理信息库(Management Information Base,MIB)则定义了这些信息和其他元数据(例如变量的类型和描述)的类型。

2 指标模型

为了保证业务系统的健康运行,促进业务系统的使用,提升管理水平和业务能力,必须对业务系统的运行情况进行监控,及时了解业务系统的状态,发现和解决问题。

业务系统监控的基础和关键是业务系统的指标模型。合理的指标模型能够准确、充分地反映业务系统的情况,为业务系统正常运行提供有力的支撑,提高信息系统运行效率,提高服务质量,降低运营的成本。

参考其他系统的监控指标,如Web Logic、Windows系统等,提出了业务系统的运行指标,这些指标包括响应时长、健康运行时长、在线人数、日登录人数、连接会话数、数据库表空间总使用情况、服务器CPU平均使用情况等。它们反映了业务系统的运行情况,如系统已经稳定运行了多长时间,最多有多少用户使用系统,系统对服务器和数据库的压力有多大等。

运行指标只能反映系统的运行状态,不能反映业务系统中核心业务逻辑或流程的运行和使用情况,因此在运行指标的基础上,本文建立了业务系统的业务指标。业务指标主要指反映业务系统业务水平情况的指标,不同的业务系统有不同的指标内容,反映该业务系统特有的核心的业务逻辑,例如投资管理的累计项目总数,协同办公的公文处理数、档案条目数,生产管理的日工作票数、日操作票数等。

在这2类指标的基础上,提出了一个评分模型。这个评分模型可以根据每个业务系统的实际情况,为运行指标和业务指标赋一个权重。这样,为每一个指标点设置了分数点,根据业务系统每个指标的指标值计算出一个分数,然后统计出总体得分。这个总体得分反映了该业务系统的总体情况,包括运行情况和业务实用情况,为从总体上掌握一个业务系统的运行情况提供了基础与依据。

这2类指标和评分模型共同作用,准确、全面地反映了业务系统的运行情况,为运维人员和领导发现问题,促进系统实用提供了基础和依据。运行指标和业务指标2类模型共包括了85个指标,覆盖了所有业务系统的各个方面。当指标模型建立后,根据SNMP标准的要求,需要对指标模型进行固化,只有固化在MIB中,以对象标识符(Object ID,OID)的形式存在,才可以被SNMP代理识别并被管理端访问。

3 MIB设计

MIB是被网络管理协议访问的管理对象数据库,它包括所有可以通过SNMP代理被管理端访问或者设置的变量。MIB是数据对象的集合,代表网络中所有可以管理的资源,如硬件、服务等。每个MIB对象一般是一个数据变量,它代表被管理对象的某一个方面的信息。

要实现基于SNMP对业务系统进行监控,首先需要完成监控数据MIB的定义。从MIB定义、申请注册、通用性、安全性和扩展性的角度来考虑,将国家电网公司的私有MIB的根节点定义在MIB节点(.iso.org.dod.internet.private.enterprises),对象标识符为.1.3.6.1.4.1的节点之下。该私有节点的定义如下:

MIB节点:.iso.org.dod.internet.private.enterprises.sgcc

OID:.1.3.6.1.4.1.3333

今后所有需要扩展的定义都将在此根节点下进行,最终形成一个树形的层次结构。对业务系统的监控从应用的角度来考虑,将对十大业务系统的监控定义的根目录放在以下节点:

MIB节点:.iso.org.dod.internet.private.enterprises.sgcc.ITbusiness.KPI

OID:.1.3.6.1.4.1.3333.1.1

每个业务系统的关键运行指标都以这个节点为父节点,并按国家电网公司信息系统十大业务、每个业务包含的各个应用系统分别定义需要监控的KPI节点。

以财务管理系统为例,其节点如下:

MIB节点:.iso.org.dod.internet.private.enterprises.sgcc.ITbusiness.KPI.fico.erpfico

OID:.1.3.6.1.4.1.3333.1.1.1.1

以上节点代表的是ERP财务管理系统,财务管控系统的节点如下:

MIB节点:.iso.org.dod.internet.private.enterprises.sgcc.ITbusiness.KPI.fico.ficos

OID:.1.3.6.1.4.1.3333.1.1.1.2

这2个系统相关的应用系统监控指标就定义在类似于以上节点树的叶子节点上。

通过以上方式的定义,实现了国家电网公司十大业务应用下所有业务系统的运行指标和监控指标的固化,以后无论是添加一个业务系统,还是添加运行指标和业务指标,都可以很方便地维护这个树形结构。这样既实现了目前监控的需要,又方便了以后MIB的拓展,方便了各类应用监控指标的统一定义。

4 SNMP Agent设计

SNMP代理(SNMP Agent)可以是一种硬件设备,如主机、交换机、网桥、路由器和集线器等,也可以是一个软件服务,如net-snmp等。这些设备或服务上的SNMP代理都必须能够接收来自管理端发来的命令信息,并且这些代理的状态也必须能够被管理端监控。SNMP代理响应管理端的命令请求进行相应的操作,也可以在没有请求的情况下向管理端发送信息。

业务系统监控的SNMP代理架构如图1所示。

该代理包括以下功能模块:

1)OID请求响应,负责响应客户端发过来的OID请求,并将该OID对应的数据返回给客户端;

2)OID采集逻辑标准定义管理,负责定义每个OID数据采集的逻辑,如调用API获取该OID的数据或者在业务系统的数据库中执行SQL获取数据;

3)业务数据源定义管理,负责管理每个业务系统的数据源,如API访问的路径、数据库访问的URL、用户名、密码等;

4)通用指标数据获取模块,负责通过调用业务系统提供的API获取相应OID的数据;

5)通用数据库查询模块,负责通过在业务系统的数据库中执行查询SQL获取相应OID的数据。

在这些功能模块的上层是SNMP代理的通信标准。这个通信标准保证了任何一个标准的SNMP客户端,只要了解了业务系统SNMP代理的地址、团体名,就可以基于SNMP发送命令请求,以获取相应OID的数据。

业务系统的SNMP代理准确地说是一种SNMP服务,它不直接部署在业务系统,即被管对象上,也不是业务系统的一个组件。这个服务只负责维护业务系统所有指标数据的OID、获取方式,这种获取方式可能是一个数据库查询的语句或者一个可以调用的接口方法等,以及处理来自客户端的SNMP请求。因此,虽然按照SNMP的通用叫法,这个模块被称之为业务系统的SNMP代理,但是基于这个模块实现的监控系统依然可以被认为是一种无代理的监控方式。

5 结语

本文根据电网公司业务系统的实际情况,参考其他成熟系统的监控指标,提出了电网公司业务系统的监控指标模型,包括运行指标和专业指标,从2个方面全面地反映业务系统运行和使用情况。然后,基于SNMP将这些指标固化到MIB中,从而既满足了指标定义的统一和监控的需要,又方便了以后指标的扩展。

在业务指标模型的基础上,本文建立了一套评价模型和业务系统指标监控系统,为采用SNMP无代理方式监控业务系统打下了基础,方便以后与其他监控系统一起组成统一监控平台,对提高运维人员的效率,促进业务系统的实用化水平,提升应用水平,降低管理成本具有重要的意义。

摘要：电网公司通常存在大量的业务系统,这些业务系统规模较大,应用特点清晰、专业,实现的技术路线千差万别,因此如何对这些业务系统进行统一的监控就成为电网企业必须要解决的重要问题。文章通过研究SNMP协议的标准、实现技术和探测方法,对基于SNMP的业务系统指标模型和监控系统进行研究,最终实现了基于SNMP的业务指标监控系统,为统一监控技术路线打下坚实的基础,对提高业务系统的使用水平和运维人员的效率,降低管理成本具有重要的意义。

关键词：SNMP,业务指标,模型,监控系统

参考文献

[1]宋宇澄.电力监控和数据采集系统[J].电子技术,1996(11):10–12.

[2]刘澜涛,李淼,高福祥.基于SNMP的网络资源管理系统的设计与实现[J].中国教育网络,2009(1-2):101–103.LIU Lan-tao,LI Miao,GAO Fu-xiang.Design and Implementation of Network Resource Management System Basedon SNMP[J].China Education Network,2009(1-2):101–103.

[3]安晓嵘,李孝安.分布式网络管理系统中SNMP Agent的研究[J].科学技术与工程,2006(11):1565–1568.AN Xiao-rong,LI Xiao-an.The Research o f t h e S N M P A g e n t i n t h e N e t w o r k Management System[J].Science Technology and Engineering,2006(11):1565–1568.

[4]曾自怡.SNMP协议在电力通信电源远程监控管理中的应用[J].电力信息化,2010,8(3):79–81.

[5]吴晓葵.利用SNMP获取网络资源信息[J].现代电子技术,2004(16):45–48.WU Xiao-kui.Get Network Resource Information Using SNMP[J].Modern Electronic Technology,2004(16):45–48.

业务监控系统 篇9

1黄河水利委员会视频监控站点接入方式选择

随着图像采集技术日趋成熟, 通信传输技术高速发展, 今后治黄领域将有越来越多的视频监视系统建设满足流域的防汛减灾、应急抢险、工程监视、水政监察等综合业务的需求, 可以提高流域防汛减灾、水资源管理和水利工程管理等工作的现代化水平。

黄河需建设视频监控的站点大部分位于黄河滩区, 地处偏僻, 无光缆覆盖。所以视频监控通信传输通道如果选用有线的方式, 只能选择自建光缆线路或者租用公网线路的方式, 自建光缆线路实施难度较大且费用昂贵;租用公网线路需要布设视频监控点至最近距离的公网接入点的光缆, 且需要承担每年的公网租用费用, 费用也较高。

由于黄河滩区内大部分地区有居民活动, 因此运营商在滩区附近布设有通信基站, 滩区内有3G或4G网络覆盖。在黄河沿岸建设视频监控点, 只要3G或4G信号强度达到要求, 即可选择无线传输的方式, 无需布设光缆线路即可将黄河防汛站点的图像通过公网传输至监控中心。该方案不仅前期投入费用低, 且无需后期维护费用。因此在黄河沿岸大堤布设视频监控点选择无线视频监控系统是优选的方案。

2 3G视频监控系统在黄河防汛业务中的应用

自2010年起黄河3G无线传输视频监视系统已经在黄河流域宁夏、内蒙古、山西、陕西、河南、山东应用了移动及固定视频传输系统, 取得了良好的应用效果[2]。

3G远程视频监视系统由无线视频监视点、传输网络和视频监视中心组成。无线视频监视点采集的实时信息经过传输网络传送至监视中心, 实现实时监视;监视中心的各种监视指令经过传输网络下达到无线视频监视点, 实现远程控制。传输通道采用3G无线接入方式。但该系统受3G带宽不足的限制, 无法传输高清视频图像, 目前3G网络速度快的话可以达到1M, 速度慢的几十个字节, 因此只能作为辅助传输手段;无线信道的误码率比较高, 特别是当终端设备处于移动状态时, 可用带宽和误码率指标有较大幅度下降, 可用带宽经常发生波动, 高带宽的视频监控数据易发生丢包, 可靠性不高。

且3G无线视频监控系统的运行费用较高且很难下降, 并且共享信道资源的公众通信系统, 在应急情况下发生局部性负荷剧增时, 有可能造成不可容忍的延时甚至阻塞问题。

3 4G视频监控系统在黄河防汛业务的应用前景

2014年12月4日, 工信部给中国移动、中国电信、中国联通三家运营商发放TD-LTE牌照。各电信运营商均在加大对4G基站的建设规模及进度[3]。

4G技术在通信技术中属于一种全新的概念。它集3G与WLAN技术于一体, 能够高质量地传输视频图像, 图像传输质量能达到高清电视画质的程度。4G技术的下载速度可达到100Mbps, 上传的速度也可达到20Mbps, 比目前的拨号上网方式快10倍左右。它可以提供更加稳定和高速的无线移动网络, 理论的下载峰值可达到每秒百兆左右, 传输一个视频监控文件可能仅需几分钟时间。4G技术可以轻松满足高清无线视频监控对于带宽的要求。另外, 4G网络不论是稳定性、费用等方面或将带来新的突破。

4G技术具有高带宽、可移动性的优点, 可实现对黄河流域视频高清图像的实时传输, 大大提高监控画面质量, 弥补现有3G移动视频传输系统带宽不足、传输画面质量只能达到标清的缺憾。使得黄河防汛视频图像无线传输达到高清画质成为可能。

为研究黄河沿岸视频监控高清图像传输的实用性、可靠性, 黄河水利委员会进行了4G高清图像传输实验点的建设, 在壶口瀑布进行了4G视频监视点的建设, 通过高清摄像机与4G路由器相连接, 将采集到的视频图像通过4G移动网络传输至黄河水利委员会, 黄河水利委员会可在远程实现对壶口瀑布水清实时情况进行查看, 其清晰度有了极大改善, 远程观看可达到高清的效果。且系统稳定、延时小、可靠性强。

4新时期黄河无线视频监控发展规划

随着运营商对4G基站建设范围的增大, 黄河沿河范围4G型号的覆盖范围将会逐步加大, 在今后无线视频监控系统建设的过程中, 可将原有的3G视频监控系统进行改造, 升级为4G视频监控系统。在新建视频监控点时根据现场信号测试情况优先选择4G传输通道, 提高黄委视频监控的传输质量及时效。同时对黄河水利委员会已建的视频监控管理平台进行整合, 实现在同一平台上对3G、4G及有线接入方式的视频监控点进行统一管理。具体如下:

现地视频监控点:

固定视频监控点可分为升级改造及新建。如原有的3G视频监控点现场经测试4G信号较强, 可将原有3G路由器更换为4G路由器, 同时更换流量卡。新建视频监控点经现场测试信号强度选择通信模式。如现场只有3G信号, 则进行3G视频监控点的安装调试。如现场3G、4G信号均较强则优先选择4G通信模式, 进行4G视频监控点的安装与调试。

移动监控点:增加手持终端与车载终端。

手持终端:同时为沿线基层单位配备手持视频终端, 通过3G或4G网络, 方便用于单人移动与中心进行沟通, 也可配置为智能手机, 安装客户端后登录, 与中心进行交流。

车载终端:在移动的车载设备上, 配置便携式视频终端接入视频的输入 (摄像机) 、输出 (电视或投影) 设备, 音频的输入 (麦克) 、输出 (音箱、功放、调音台) 。通过3G、4G网络或卫星网络, 与中心进行交流。

监控中心:

除配备服务器、存储设备、大屏幕之外, 主要对原有的各个视频监控管理平台进行整合, 实现在同一平台上对黄河水利委员会视频监控能源的统一管理。整合思路如下:原来已经建立的监控系统里, 配置监控接入网关, 在不用更改前端已有的监控系统的情况下, 通过网络连接原有的监控系统, 用于完成前端硬盘录像机的注册、管理及监控视音频的转发。保留原有投资, 将原有系统接入。同时在监控中心配备可视指挥调度平台及高清解码器, 在监控中心可随时与所辖下属单位进行音视频通话, 结合监控图像资源, 与一线的单兵车载进行音视频互通。

5结束语

随着运营商对4G网络覆盖和系统容量的增加, 4G网络覆盖范围将不断扩大, 使得黄河沿岸重要防汛站点4G移动视频监控点的大规模建设成为可能。并可将4G视频监控应用范围扩展至治黄事业的多个领域, 为治黄的视频需求提供高带宽、高可靠性、灵活多样化的服务。

参考文献

[1]赵胜男.3G无线视频监控业务发展状况及策略分析[J].电信科学, 2010 (09) :3-6.

[2]王永刚, 章坚武.3G视频监控系统中关键技术的研究与实现[J].现代电子技术, 2011 (19) :24-25.

业务监控系统 篇10

日益激烈的市场竞争和不断提高的客户服务质量需求对业务支撑系统 (简称:BOSS系统) 业务支撑能力和可靠稳定运行的要求越来越高, 从面向客户服务的角度而言, 需要中国移动提供不间断的业务支撑服务, 以保证客户满意度、客户服务质量等不受影响, 增强企业竞争力。

2009年期间, 由于数据库故障、生产机房网络故障等原因, 造成广西BOSS系统当年累计退服时长达近20个小时、故障期间因无法缴费、充值后无法开机等问题造成的用户投诉/抱怨工单件数共5000多件, 严重影响了本地客户的满意度和使用感知。由于数据库故障和网络故障等突发性问题可控度不高, 因此如何降低故障处理期间对用户的影响、更进一步地考虑实现故障期间系统不中断运行, 成为广西公司业务发展和客户满意度提升工作面临的一项紧迫任务。

2 研究思路

根据广西公司运营支撑水平的实际情况, 采用关键业务应急的方案, 建设一个覆盖BOSS系统各主要业务受理渠道 (包括:营业前台、短信厅、网厅、客服系统、IVR充值等) 关键业务的应急系统。当BOSS系统出现重大故障的情况下, 应急系统对外提供各类关键业务的受理, 确保业务服务连续性, 满足客户最迫切的业务需求。

由于涉及较多渠道和系统, 切换环节众多, 手工切换时间较长, 而且存在人为误操作的风险, 为了达到快速切换和减少人为操作风险的目的, 应急系统提供应急切换统一操作管理平台, 提供自动快速的应用切换手段, 缩短服务重启等耗时长的操作时间。

用户在应急系统办理业务, 使用的是生产系统同步过来的数据, 并且在应急系统办理的业务数据, 在生产系统恢复正常后, 同步回生产系统, 保证用户在生产系统中正常的办理业务和使用服务。因此必须保证应急系统和生产系统之间的数据同步, 采取有效手段保障两个系统之间的数据一致性, 从而保证业务受理和数据的准确性。

3 建设方案

3.1 系统部署

广西生产中心和应急中心的双中心体系采用同城异址的建设方式、保证了硬件设备的独立性, 生产中心部署生产设备, 容灾中心部署应急设备, 保证灾害或故障发生时系统冗余可用。其中生产中心设在608第三机房、容灾中心设在608第二机房。

根据广西公司的实际情况, 当前广西公司应急系统硬件配置约为生产系统的1/2、业务承载能力约为生产系统的1/2, 性能足够支撑当前应急系统中提供的关键业务。

应急系统部署分为三层结构:

(1) 客户端:生产系统和应急系统的客户端的PC机是共享的。应急系统和生产系统之间的切换, 通过F5的请求指向修改来完成。在启动应急系统时, 营业员只需要通过统一的URL重新登录即可。

(2) 应用服务器:生产系统的WEB服务和中间件服务部署在生产中心主机上, 应急系统的WEB服务和中间件服务部署在容灾主机上。生产系统和应急系统的切换/回切通过F5实现。当BOSS系统出现故障时, 通过F5将前台业务请求接入到应急系统。生产系统恢复正常后, 通过F5进行回切, 将请求发送到生产系统。

(3) DB层:应急系统使用的是生产系统的克隆库, 克隆库与生产库是互相独立的。应急系统数据同步采用DSG方式从生产库中同步至应急库。

3.2 体系架构

广西生产系统及应急系统逻辑架构相同、部署的应用程序一致, 减少了程序部署和系统升级的复杂度、也保证了应急系统的可用性。应急系统采用B/S结构的处理方式。首先采用B/S结构的业务受理界面, 是BOSS系统设计的主流发展方向, 可以方便系统的升级, 利用前台用户的使用, 收敛后台的业务流程等优点;其次, 采用B/S结构, 使得生产系统与应急系统的受理界面互不影响, 便于快速实现系统的切换, 也避免了对现有前台营业受理界面修改对系统的影响。

BOSS应急系统架构可以分为三层结构, 分别为接入层、业务层、数据层。

(1) 接入层:跟用户接触的各个渠道的接入方式, 包括:营业厅WEB方式接入、网厅、IVR自动语音充值管理平台接入等。

(2) 业务逻辑层:进行各种业务操作和业务规则处理。采用组件技术实现, 将所有的业务逻辑都封装在组件中, 并利用组件提供业务服务。

(3) 数据层:主要功能是存储核心数据, 包括用户资料数据、卡资源数据、号码资源数据等。

3.3 系统功能

应急系统功能包括两大部分:应急系统管理和应急业务受理。

1) 应急系统管理:包括应急切换控制、应急系统初始化、应急业务数据恢复等功能。

(1) 应急切换控制:包括应急自动切换平台和应急切换后台控制。

i.应急自动切换平台:对整个应急切换操作进行了整合, 实现全自动化应急系统应用切换与回切, 有效避免了人为误操作的风险;并设计了申请、审批两级操作流程, 操作人员和管理人员能通过平台进行切换操作管理。切换的时候生成前台切换通知, 告知操作员启用应急系统, 并提示能办理哪些业务;当从应急系统回切到生产系统时, 告知系统已经恢复正常, 可正常办理业务。

ii.应急切换后台控制:控制营业前台、各渠道系统和接口连接到应急系统还是生产系统。后台自动切换功能采用切换消息发布服务器+切换消息接收代理进程模式实现, 有效降低自动切换平台的复杂度。将应用程序的实际切换操作封装成可执行脚本、仍放置在应用主机上, 相应地在应急主机部署了一套切换代理进程, 由代理进程解析切换请求、调用执行脚本完成实际切换操作。

(2) 应急系统初始化:应急系统使用的数据库是BC复制库, 每天凌晨会全量备份并覆盖应急系统数据库中的数据, 然后通过DSG增量同步定时同步生产系统和应急系统的数据, 由于应急系统与生产系统在业务控制的细节上的差异, 所以, 每次同步完成后应急数据库中的数据还不能直接用于应急系统, 要进行一些数据上的清理与准备工作。

(3) 应急业务数据恢复:针对在应急系统受理的业务, 在BOSS系统恢复正常后, 自动同步受理的业务数据到生产系统。

2) 应急业务受理:由于业务支撑系统中各个系统以及外围系统的关联性, 要实现对应急系统的业务受理和服务功能使用, 除了受理业务的各个渠道要进行业务受理功能改造外, 相关的后台 (如计费、开通) 和外围系统 (如充值卡平台) 也需要进行相关的改造。主要改造的系统和功能如下:

(1) 受理渠道改造

各受理渠道要实现对应急系统的改造, 一方面需要支持实时读取应急切换标记, 另一方面需要修改系统内部业务受理的实现模式, 将跨子系统或跨库等跳出自身系统范围内的功能调用都改造成不执行实际调用, 仅保存数据在应急数据库中, 待生产系统恢复正常之后进行数据恢复时再执行实际外部系统接口调用;同时, 还需要提供生产系统恢复正常之后的数据恢复方式, 并保证数据正确性与生产系统正常受理结果一致。下面列出具体改造点:

i.实时读取应急切换标记

通过应急控制平台界面进行切换时, 应急控制系统向受理渠道发送应急切换标记, 受理渠道要能及时获取, 并切换到应急状态;实现方式可以为socket或中间件接口, 由应急控制平台连接或调用。

ii.调用跨库跨系统接口逻辑修改

当应急标记切换之后, 受理渠道内部业务受理逻辑进行修改, 以适应应急系统的软、硬件环境。

iii.数据恢复的实现

受理渠道提供生产系统恢复正常之后, 应急期间办理的业务恢复手段, 同时提供稽核恢复数据正确性的手段。

在生产系统恢复正常后, 需要把应急系统受理的业务数据以业务办理当时场景的信息恢复到生产系统。应急系统的数据恢复, 是一个后台进程 (多线程) , 恢复进程启动后, 会按受理时间顺序检索应急工单主表所受理的业务记录, 并根据业务类型, 去相关的业务记录表中获取业务数据, 再分别调用生产系统中的对应的后台服务, 将应急业务的业务数据送给生产系统的后台受理服务接口中, 由生产系统的后台受理完成应急业务在生产系统中的再受理过程, 从而保证数据正确性与生产系统正常受理结果一致。通过生产环境执行业务受理过程, 对应的用户编号、工单编号等通过序列号产生器产生的编号存在不相同的情况, 相同的情况机率也非常小, 避免了将应急系统数据库相关序列号值同步到生产环境的问题。

为了缩短业务中断的时间, 应急系统回切回生产系统后, 应急系统办理业务的数据恢复回生产系统的同时, 生产系统对外提供业务办理, 应急业务数据恢复完成前, 在应急系统办理过业务的用户不能在生产系统办理业务, 以保证数据的一致性。

(2) 相关系统改造

i.充值卡平台

当应急系统启动时, 充值卡平台需要将原来BOSS生产系统提供的调用接口, 转发到BOSS应急系统提供的调用接口, 完成充值流程。

ii.统一开通平台

统一开通平台与应急系统走接口表的方式, 应急系统把需要开通的记录插入接口表中, 由统一开通平台负责后续的开通指令拼装和发送, 并回写开通结果到接口表, 不需要与应急系统程序进行交互, 直接由统一开通平台读取接口表数据。具体接口表的字段或格式与生产系统类似。

统一开通平台在完成开通操作之后, 根据HLR的结果, 将开通处理结果回写到接口表中, 应急系统调度进程定时读取接口表开通结果, 更新应急受理工单状态。

iii.计费平台

应急系统新装开户完成之后, 需要将新用户资料上发给计费平台, 计费平台与应急系统走接口表的方式实现数据交互, 应急系统在完成开户受理之后, 将新的用户资料插入到接口表中, 计费平台定时从接口表获取新的用户资料到应急MDB系统进行计费, 避免出现用户高额欠费等问题。另外, 其它如产品变更、计划变更等与计费相关的资料上发规则处理原则一致。

4 应用效果

应急系统建设完成后, 根据集团公司《业务支撑网应急保障管理办法》要求, 广西公司定期进行应急系统切换的应急演练。演练按照各个流程进行操作, 演练的结果达到了预期的目的:

(1) 应急系统和生产系统之间的切换/回切, 通过应急调度管理界面进行切换, 后台通过F5的请求指向修改来完成, 各个受理渠道的切换过程可以在10分钟之内完成, 较好的保证了BOSS重要业务受理的连续性。

(2) 在应急系统受理的缴费、停开机等涉及HLR开通的业务, 能实时发送到开通系统和HLR, 处理效率跟生产系统相比没有明显降低。

(3) 当生产系统恢复正常, 从应急系统切换回生产系统后, 把应急系统受理的业务数据以业务办理当时场景的信息恢复到生产系统。通过后台进程 (多线程) 进行生产系统数据恢复, 在恢复过程中, 在应急系统办理过业务的用户暂时限制在生产系统办理业务, 对其它用户则没有影响, 因此一旦应急系统回切到生产系统后, 即可正常为用户办理业务, 对业务连续性起到了较好的保障。

(4) 应急系统回切回生产系统后, 在生产系统恢复正常并且数据恢复完成后, 经过稽核, 生产系统和应急系统的数据一致, 确保了应急业务受理的数据一致性要求。

5 小结和展望

中国移动广西公司通过建设BOSS应急系统, 实现了当BOSS系统出现重大故障时, 能够快速切换到应急系统, 在各个渠道提供关键业务的受理, 提升了BOSS系统重要业务的服务连续性, 对提升客户服务满意度起到良好的效果。

下一步将考虑扩大应急系统业务受理的范围, 并且通过技术手段对应急调度自动切换的功能进行优化, 进一步缩短应急切换及回切环节的耗时, 同时考虑将应急后台自动切换的关键步骤及流程展现在应急自动切换平台界面上, 有助于操作及管理人员实时监控后台切换管理过程, 对切换过程中的异常情况及时发现处理。

参考文献

[1]中国移动通信有限公司《业务支撑网应急保障管理办法1.0.0》, 2010年11月

肇庆市防雷业务管理系统 篇11

关键词：防雷业务;管理;系统

随着防雷事业的发展，防雷检测机构管理日渐规范，防雷技术服务内容不断增加，客户群体不断扩大，业务信息数量日益增加，以往的管理方式存在着手工重复工作，效率低下、错误率高、信息保密性差等缺点。因此，对业务信息及时的进行处理，对整个业务流程进行监控，更好的开展风险防控工作，将全所数据组织成统一的数据平台并采用信息化管理显得尤为迫切。本系统是基于肇庆市防雷业务现代化水平不断提高，业务量不断增大，提高检测服务效率，加强业务过程监控，紧密结合肇庆市防雷业务运行管理现状，充分利用信息技术开发完成的。

1、系统特点

本系统采用JAVA语言开发，遵循J2EE规范，多层结构体系，MySQL数据库，WINDOWS操作系统，是跨平台网络化的文件、档案及资料综合管理系统。系统采用了多层结构的设计原理，具有集中的请求和访问控制，以数据驱动实现业务应用，基于MVC模式灵活的页面合成技术，使内容存储与表相分离，具有强大的安全和事务处理能力。同时，软件具有较强的自构建能力，可以很方便地定义库结构、增加功能、设置界面、设计报表，以及增加各种文档类型，以适应较广泛业务的个性化需求。

2、系统组成

本系统主要针对防雷检测机构管理内部各项业务设置，包括新建建筑物技术服务、防雷装置定期检测、雷灾事故调查、仪器设备管理、行政办公、档案管理、系统维护几大模块，其中新建建筑物技术服务包括新建建筑防雷装置设计技术评价、雷电灾害风险评估、新建建筑防雷设施分层检测、新建建筑防雷设施竣工检测四项业务。每个技术服务机构人员根据权限不同可以办理不同的业务，系统框图如下：

3、系统功能

3.1系统管理模块

3.1.1用户、用户组管理：用户注册，管理员审核批准，包括添加、修改、删除、检索用户组名称及组内用户信息，查看、增加、删除组内用户等功能。

3.1.2权限管理：系统管理采用权限分级管理，第一级为所领导和系统管理员，可以浏览、更改所有内容，第二级为检测组长，可以浏览、操作本组范围内的内容，第三级为检测员，只能浏览、操作与自己相关的内容。

3.1.3 系统参数维护：包括添加、修改、删除系统参数等功能，该功能只能由系统管理员来操作。

3.1.4主表维护：包括新建表、修改表、删除、检索表。系统将数据表分为三类：一是系统模板表;二是系统业务表;三是系统提示数据表。该功能只能由系统管理员来操作。

3.2新建防雷装置技术服务模块

该模块主要分为新建建筑物防雷设计技术评价、雷电灾害风险评估、新建建筑防雷设施分层检测、新建建筑防雷设施竣工检测四项业务，模块功能主要管理新建项目从报送资料开始一直到竣工检测的业务流程、业务数据统计、分类查询、进度查询、业务超时报警等功能，将以往的工作流程固化在信息系统内，并加入风险防控内容，全程监控业务动作，严格各项业务完成时限。

3.3防雷装置定期检测模块

该模块主要将众多检测单位相信信息记录在系统，并按照检测时间的顺序排列，提前一个月提醒所长安排当月检测任务，新建建筑竣工检测完成一年以后自动转入定期检测，系统自动监控到期未检测项目，并提醒接受任务的组长尽快安排检测业务，检测人员现场检测完成后输入检测数据并自动生成检测报告。

3.4雷电灾害调查模块

该模块要求雷灾调查人员录入每次雷电灾害相关信息，系统自动分类统计雷电灾害类型、雷灾数量、财产损失情况、意见建议等数据。

3.5仪器设备管理模块

该模块负责管理全所全部仪器，包括计量检定仪器和非计量检定仪器，从设备采购、检定、使用、维修、直到报废，全程监控设备情况，定期提示未检定设备送检，定期提示设备维护、校准、比对等工作。

3.6档案管理模块

本模块负责全所各类归档档案的类型、密级、保管期限、输入待归档案卷宗的全宗号、目录、借阅情况记录，方便全部档案资料分类统计、查询。

3.7行政办公模块

此模块包含固定资产管理、人事管理、公章管理、考勤管理、消息管理、首页信息发布6个子模块，负责全所行政办公管理

4、结束语

业务监控系统 篇12

1 基于校园卡的图书馆业务系统的实现

我校图书馆采用汇文文献信息服务系统, 与校园卡系统对接, 实现了校园卡在图书馆办理借、还书、超期罚款等图书馆相关功能。汇文系统中存储的是读书条码, 校园卡识别的是学工号, 将汇文管理系统中借书证条码和校园卡学工号进行对应, 即可实现用校园卡办理图书馆业务。实际采用校园卡和借书证并存的过渡方式, 逐步淘汰借书证, 最终实现校园卡在图书馆业务中的应用。

1.1 数据库对接

校园卡数据库提供学生信息, 按照图书馆的数据需求, 开放视图, 汇文系统来读取同步数据。图书馆数据库将读书信息和学生信息进行对应, 实现信息共享。

对接系统采用C/S架构, 通过加入第三方服务器, 各业务终端运行第三方接入客户端, 安装校园卡读卡器, 用读取校园卡信息。将校园卡学工号直接和图书馆数据库中读书信息进行对应, 实现图书借阅流通、扣款等业务。

1.2 IC卡使用

校园卡常用的是非接触式IC卡, 又称射频卡, IC卡是可读写的多功能卡, 而且容量大、灵敏度高、安全性能好, 我校目前采用的是Mifare1卡。

在校园卡系统中, 校园卡有校内金融服务和身份认证两大功能。在图书馆中使用校园卡身份认证标准, 图书馆无需制卡。

2 图书馆业务系统对接构成

2.1 图书借阅系统

我校图书管理系统, 在校园卡系统第三方应用程序接口API基础上进行二次开发。应用程序接口API主要包括:操作员签到/签退、修改密码、统计、查询、挂失/解挂、转账、对账等。为实现汇文系统与校园卡系统的对接, 两家公司密切合作, 成功开发了系统接口程序, 并解决了系统间数据交换及安全问题。实现了使用校园卡在图书馆的图书流通、超期罚款、丢书赔偿等功能。[2]

2.2 智能门禁管理系统

智能门禁系统是图书馆安全管理的第一步, 需要完成身份认证、参数设置、信息管理等功能。通过代理服务器第三方接入一卡通网络, 实现门禁系统可以同步一卡通数据库的信息, 完成对门禁系统的有效控制。通过门禁控制, 可以快捷的记录读者数量和工作人员考勤, 便于管理。

2.3 电子阅览系统

电子阅览在原有网络基础上, 用校园卡上机管理系统。在代理服务器上安装运行上机管理端软件、出入验证端软件, 在终端机器上安装客户端软件, 实现在代理服务器上进行身份认证、刷卡上下机、扣费等功能, 完全满足电子阅览室的高效、自助管理。

2.4 自助复印业务

自助复印系统可实现持校园卡自助复印, 方便快捷。传统复印业务通常是专人管理, 收取现金。造成人员使用效率低和资金违规等问题。通过将复印机设置为读卡器控制模式, 受控于EPOS。在POS机中设置费率, 并给EPOS授权, 接入校园卡系统中。将复印机与EPOS用专用接口线连接起来, 实现自助复印机接入校园卡系统, 学生可以用校园卡直接刷卡进行复印、扣费。

3 关键技术

3.1 安全问题

基于校园卡的业务有身份认证和资金支付两种功能, 所以图书馆业务系统与校园卡对接首先要解决的就是确保校园卡使用的安全。为了从根本上保证系统的安全, 在网络的构架上采用两个独立的网络, 增加前置机或代理服务器, 以满足开放系统和封闭系统之间的数据安全交换, 为图书馆业务系统成功对接提供安全保障。

3.2 数据交换接口

数据交换是实现系统对接的关键技术, 为了满足系统间的信息交换, 需建立两者之间关联和交换机制。为此, 我们将学生、教师的学工号作为唯一身份识别标识, 在图书馆读者库和校园卡数据库中将该字段进行唯一对应。师生信息来源于校园卡系统, 规范图书馆系统中的用户身份有效性认证, 图书馆各子系统通过前置机或者代理服务器读取校园卡系统数据。数据交换的实施, 避免了不同系统用户信息的重复录入、提高了办事效率, 保证了数据的一致性。

4 校园卡在图书馆业务中的优点

4.1 高效方便的服务师生

优良的服务是现代化读书馆永恒的精神。与校园卡系统对接, 不仅提高了图书馆的管理水平, 更好的服务于师生。简化管理、减少多卡、多证的麻烦, 提高了自助服务能力。例如:原来办卡要经历多个部门、耗时长。业务整合后, 只需在校园卡中心办理就可以完成相关业务。校园卡的挂失可以在校内任一台圈存机或者校园网上完成, 并在校园卡系统中生效。

4.2 严格规范财务管理

对接后的图书馆业务系统, 提高了管理效率和管理水平, 降低了管理成本。不仅避免了原有图书馆中的收支现金, 减少了漏洞, 从根本上规范了财务管理;而且, 图书馆的账务全部并归到学校财务, 便于统计分析, 为财务预决算提供重要依据。[3]

5 图书馆业务系统对接后存在的问题

校园卡系统是一个复杂的工程。将图书馆系统与校园卡系统对接, 解决了一些问题。然而, 对接系统还存在数据同步不及时、网络不稳定、设备故障多及部门协调力度差等问题。

5.1 设备或网络故障和数据同步问题

图书馆管理系统是数字化校园网络中的一部分, 必须与校园卡系统数据保持实时共享、实时更新。[4]实际中, 校园卡服务器设备或网络故障、系统设置的数据更新频率不一致直接导致在校园卡系统中开户、销户、挂失等业务发生后, 图书馆系统中不能及时生效, 就会引起连锁反应, 影响图书馆业务的正常运行。

5.2 多部门协作问题

图书馆业务的集成, 涉及到图书馆和校园卡管理、校园网管理、财务管理等问题, 需要校内各部门协同。另外, 还需要开发商之间的配合, 开放数据接口, 以达到系统间的数据交换、统一认证。

6 结语

校园卡在图书馆的应用使得图书馆管理向现代化水平迈进了质的一步。对接过程不仅涉及到系统整合的技术问题, 还涉及到网络安全、管理模式等问题。为了适应新变化, 我们要改变观念, 培养和造就一支懂技术、懂管理的人才队伍, 让系统更好的为师生服务。

参考文献

[1]刘恩涛.校园卡与图书馆应用系统集成的研究与实现[J].科技情报开发与经济, 2008 (18) .