呼叫中心整体外包需求方案点对点应答第二部分技术要求.docx

上传人:b****3 文档编号:11488234 上传时间:2023-06-01 格式:DOCX 页数:15 大小:24.36KB
下载 相关 举报
呼叫中心整体外包需求方案点对点应答第二部分技术要求.docx_第1页
第1页 / 共15页
呼叫中心整体外包需求方案点对点应答第二部分技术要求.docx_第2页
第2页 / 共15页
呼叫中心整体外包需求方案点对点应答第二部分技术要求.docx_第3页
第3页 / 共15页
呼叫中心整体外包需求方案点对点应答第二部分技术要求.docx_第4页
第4页 / 共15页
呼叫中心整体外包需求方案点对点应答第二部分技术要求.docx_第5页
第5页 / 共15页
呼叫中心整体外包需求方案点对点应答第二部分技术要求.docx_第6页
第6页 / 共15页
呼叫中心整体外包需求方案点对点应答第二部分技术要求.docx_第7页
第7页 / 共15页
呼叫中心整体外包需求方案点对点应答第二部分技术要求.docx_第8页
第8页 / 共15页
呼叫中心整体外包需求方案点对点应答第二部分技术要求.docx_第9页
第9页 / 共15页
呼叫中心整体外包需求方案点对点应答第二部分技术要求.docx_第10页
第10页 / 共15页
呼叫中心整体外包需求方案点对点应答第二部分技术要求.docx_第11页
第11页 / 共15页
呼叫中心整体外包需求方案点对点应答第二部分技术要求.docx_第12页
第12页 / 共15页
呼叫中心整体外包需求方案点对点应答第二部分技术要求.docx_第13页
第13页 / 共15页
呼叫中心整体外包需求方案点对点应答第二部分技术要求.docx_第14页
第14页 / 共15页
呼叫中心整体外包需求方案点对点应答第二部分技术要求.docx_第15页
第15页 / 共15页
亲,该文档总共15页,全部预览完了,如果喜欢就下载吧!
下载资源
资源描述

呼叫中心整体外包需求方案点对点应答第二部分技术要求.docx

《呼叫中心整体外包需求方案点对点应答第二部分技术要求.docx》由会员分享,可在线阅读,更多相关《呼叫中心整体外包需求方案点对点应答第二部分技术要求.docx(15页珍藏版)》请在冰点文库上搜索。

呼叫中心整体外包需求方案点对点应答第二部分技术要求.docx

呼叫中心整体外包需求方案点对点应答第二部分技术要求

呼叫中心整体外包需求方案点对点应答

第二部分技术要求

一、系统性能要求

(一)硬件要求

结合合肥市政府热线整合实际情况,对于现有的应用服务器、数据库服务器、存储设备(磁盘阵列、磁带库、光盘库等)、网络设备、业务终端设备(业务处理台、管理维护台)、防火墙、PBX/ACD、CTI服务器、IVR服务器、语音/传真服务器、业务座席、同步录音设备及相关的配套设备要充分利用。

答复:

硬件配置将按呼叫中心和业务层两方面进行建设,是满足系统硬件要求。

呼叫中心将提供电信级的大型呼叫中心平台,其基本架构是:

采用多台小型机保证呼叫应答处理,通过负载均衡提高系统资源使用效率。

台席设备采用目前主流高性能、高质量设备。

业务层将在保证新需求合理实现的前提下,对应用服务器和数据库服务器进行升级换代,采用可支撑主要业务层面功能的设备,包括采用中高档企业级的服务器、路由器。

后面将对具体参数和配置进行说明。

 

1.计算机系统平台技术性能要求:

服务器采用诸如CLUSTER等可靠性结构、容错结构或其它可靠性技术。

答复:

满足。

系统的硬件和软件相互配合,提供一定的故障管理能力。

答复:

满足,硬件将采用双机热备机制,并建立备份系统。

软件将建立事务处理服务、系统日志、标准故障数据警告机制,保证故障时数据的安全。

保证各类被中断的传送数据的完整性和准确性。

答复:

满足,软件通过建立事务处理服务,保障硬件故障数据传输的完整和准确。

数据传输应有不同的主备路由。

答复:

满足。

系统应具有一定的安全性和保密性。

答复:

满足。

系统不易崩溃或受破坏,具有良好的恢复能力。

答复:

满足。

系统应提供多级密码口令或使用硬件钥匙。

答复:

满足。

系统有完善的用户组管理,控制不同用户的权限。

答复:

满足。

网络及数据库系统可进行访问控制。

答复:

满足。

2.计算机系统网络性能要求:

在网络业务量和业务种类不断增长的同时,保持网络的高吞吐量并持续提供充足的带宽资源。

网络必须通过各种手段防止网络拥塞的发生;当网络拥塞发生后能有效地恢复正常状态。

定义服务层次和业务级别。

从骨干核心到外围边缘网络部件协调工作,以维持从边缘到核心一致的高吞吐量,去除网络瓶颈。

具有高可靠性和安全性。

答复:

满足。

3.存储设备联机存储数据要求保留12个月以上;脱机存储在未做明确要求前长期保存,统计分析数据要求保留2年以上。

答复:

满足。

采用定期转储机制,满足以上要求

4.要求PBX(用户交换机)采用标准的CTI链路,作为整个合肥市长热线整合接入的前置交换/排队设备,以TCP/IP或X.25协议接入整个系统局域网中。

要求PBX支持中国七号信令和一号信令,与PSTN、GSM等交换网络连接,对于远端坐席需要增加相应的远端模块或板卡。

答复:

满足。

5.CTI服务器的主要作用是将传统的交换机技术与计算机网络技术结合起来,完成交换机信息的提取和控制交换机,是热线整合系统的技术基础之一。

CTI主要完成监控PBX交换机系统发生的各种语音事件,并进行智能化的处理。

答复:

满足。

6.其他系统设备及网络设备参照国家相关规范要求。

答复:

满足。

7.相关外部设备包括共享高清晰度打印设备、高速外存设备和备份设备、鼠标、光盘机等。

各部分设备通过合肥市热线整合系统内部的骨干局域网网络设备互连,达到数据共享和外围设备共享目的。

答复:

满足。

对以上要求各点进行详细配置说明如下:

●系统硬件选型

合肥市市长热线呼叫中心系统部署所需的各类设备均采用目前华为定型产品,已优于当前用户要求。

合肥市市长热线业务处理系统部署所需的硬件设备包括:

WEB应用服务器和数据库服务器。

对于应用服务器和数据库服务器分别采用双机热备,保证系统安全稳定的运行,系统服务器的部署如下:

服务器名称

应用部署

主要系统软件

数据库服务器

市长热线业务处理系统数据库

Windows2003Server、

Oracle数据库

WEB应用服务器

市长热线业务处理系统应用程序

Windows2003Server、

WebLogic中间件

服务器选型原则

对于系统主机选择主要考虑以下系统消耗:

1、主机系统正常运行所需消耗(主要指操作系统消耗);

2、数据库运行所需开销;

3、中间件运行所需正常开销;

4、联机事务处理消耗。

5、应用系统和网络管理开销。

根据以上要求,对服务器主机平台作如下方案:

主机CPU个数的选择主要基于对系统数据作业量的估计。

通过仔细分析系统的目前及未来的数据处理负载,提出相应的CPU选择方案。

在选择时,一般遵循以下原则:

系统的总体性能完全满足应用的业务量的要求;

提供一定程度上的系统性能冗余,以使系统具有较强的抗峰值能力,并使系统有扩展的余地;

充分考虑目前的业务模式,和未来5年的业务增长。

一般对于CPU的处理能力,有一个一般公认的测试标准,即TPCC值,它标志着服务器对数据库操作的相对处理能力,我们可以以TPCC值作为参考,再结合以往的经验来最终确定CPU的具体数量。

如果要保持快速的响应能力,应当为CPU保留20%至40%的富余量。

一般的,主机处理能力需求的计算方法可参考如下:

TPM=TASKx80%xSxF/(TxC)

其中:

TASK:

为每日业务统计峰值事务处理量。

T:

为每日峰值事务处理时间,假设每日80%事物处理量集中在每天的4小时,即240分钟内完成:

T=240。

S:

为实际业务事务处理操作相对于标准TPC-C测试基准环境交易的复杂程度比例。

由于实际的业务事务处理的复杂程度与TPCC标准测试中的交易存在较大的差异,须设定一个合理的对应值。

以普通一次综合查询事务处理为例,一笔事务处理往往需要同时打开大量数据库表,取出其相关数据进行操作,相对于TPC-C标准作业的复杂度,要复杂很多;根据科学的统计结果和经验数据,每笔事务操作相比较于TPC标准测试中的每笔业务的复杂度此值可设定为10~20。

C:

为主机CPU处理余量。

实际应用经验表明,一台主机服务器的CPU利用率高于80%则表明CPU的利用率过高会产生系统瓶颈,而利用率处于70%左右时,是处于利用率最佳状态。

因此,在推算主机性能指标时,必须考虑CPU的冗余,设定C=70%。

F:

为系统未来5年的业务量发展冗余预留。

TPM=TASKx80%x15xF/(240x0.7)

本次方案中根据数据处理的具体应用推荐使用至强处理器(Xeon)的中档PC服务器。

应用服务器内存容量的计算以操作系统、应用软件和数据库对内存的需求为基础。

我们从这三个方面来估算内存的需求量:

1)操作系统

操作系统对内存要求很高,内存的大小决定了系统中进程调度活动的频繁程度,内存空间大,就可以提高进程的运行效率。

为了能够充分发挥操作系统的性能优势,为操作系统留出1GB内存空间,TCP/IP通信部分约占用0.25GB,故:

操作系统对内存的需求=1+0.25=1.25GB

2)应用软件

应用软件的基本内存需求以64MB作为基础,每处理一笔联机作业所启动应用约须占用5MB内存,为保证忙日忙时业务的正常进行,则应用软件对内存的需求=64MB+峰值每秒钟的作业数*5MB

按目前15个坐席忙时(早8点至晚10点)日呼叫量每天1000次估计推算出全天30个坐席忙时2500次呼叫,则每小时平均呼叫次数=2500次/14小时=180次,每秒作业次数=180次/3600秒=0.05次/秒,考虑峰值情况,峰值每秒钟的作业数=0.05*20=1(笔/秒)

则应用软件对内存的需求=64+1*5=64+5=70MB=0.07GB

3)数据库

为数据库保留较大的共享内存空间可以明显提高数据库的性能,建议为数据库保留的内存空间为1024MB,此外每个用户占用内存容量为4MB(根据目前台席设置数及委办局情况,建议数据库的最大连接数设置为60),故:

数据库对内存的需求=1024M+最大数据库用户连接数*4MB

=1024M+240M=1264MB=1.3GB

综上所述,主机系统对内存容量总的需求为操作系统、应用软件和数据库三部分之和,考虑20%冗余,则:

主机系统内存容量总需求=(1.25+0.07+1.3)/(1-0.2)=2.62/0.8=2.096GB

由于上述数据不考虑后端委办局人员使用情况,同时考虑到系统的整体效率和系统可扩展性,我们建议配置内存数量≥4GB。

应用服务器内置硬盘配置

内置硬盘配置取决于:

操作系统数据对换,系统程序,应用程序,数据库系统及部分应用数据和Raid技术等。

一般建议用户使用Raid1和Raid5两种,常用的Raid方式是,如果服务器有两块等容量的磁盘,可以将这两块磁盘做成Raid1模式,如果有4块或4块以上的磁盘可以做成Raid5模式。

目前呼叫中心坐席标准配置30个,可扩充至60个。

忙时15个坐席(早8点至晚10点)日呼叫量每天1000次,呼叫时长平均141秒。

推算出30个坐席日呼叫量约2500次。

数据库日记录包括用户基本信息、事件信息、处理相关信息,以合计2000字算,以每个汉字2字节计算,每次平均日产生数据库记录=2字节*2500字*2000条=10000000字节=5000000byte=5000K=5M。

月产生记录5M*30天=150M,基于用户要求,对数据库内容保存12个月,则年数据库容量大小为150M*12月=1800M,考虑到其他数据库系统存储内容(如系统日志等),年数据库容量大小约为2000M。

由于用户系统不设置专门转储设备(如磁带机),数据按5年转储一次计算,则数据库服务器总容量=2000M*5=10000M=10G。

考虑到用户对数据存储的安全性和数据备份机制的实现要求,在本案中建议用户在数据库服务器中安装3块73G硬盘,做成Raid5模式

应用服务器上至少配置2块等容量的磁盘并以做成Raid1模式。

综合以上服务器选型原则,我们推荐的服务器设备如下:

 

名称

设备型号

数量(台)

产品配置

数据库服务器

IBMSystemx3500

2

Xeon四核1.86G(8M)×2,4GBDDR2-FBD内存,10000转73GSCSI×3,RAID5,2个10/100/1000Mbps(电口)/可选双电源;

应用服务器

IBMSystemx3500

2

Xeon四核1.6G(8M)×2,2GBDDR2-FBD内存,10000转73GSCSI×2,RAID1,2个10/100/1000Mbps(电口)/可选双电源;

(二)软件要求

8.系统软件要求

开放系统;

界面友好;

具有较强的网络管理和通信处理功能。

答复:

系统采用基于WEB的J2EE体系结构,保证系统的高效运行、高可靠性运转、易于扩展升级、易于使用和零维护量的客户端。

提供功能强大的前台座席软件,座席可以方便的使用这些软件。

支持网络化远程管理。

9.数据库要求

数据库系统应采用关系数据库结构,并满足以下要求:

支持软、硬件容量,在线备份/恢复;

C2级以上数据安全控制机制;

数据库封锁机制;

支持多种数据库开发工具;

支持网络管理;

支持多种网络协议。

答复:

满足。

采用ORACLE数据库,可以充分满足上述要求。

(三)性能技术要求

对于因系统处理能力的增强和业务功能的增加需要新增的设备,需要提供的业务处理能力测算。

所有设备配置必须有主备用设备。

关键设备的要能够实现热切换和自动切换。

答复:

满足。

二、系统集成要求

(一)系统软件要求

10.支持Windows界面,能采用声、光、电、电话呼叫、发短信到手机等方式报警。

11.支持CiscoWorks,HpOpenview,IBMMessageQ等管理软件和系统软件。

12.支持SNMP网络协议。

13.对合肥市热线整合系统的业务主机,网关服务器,通讯服务器等关键设备的系统、资源、服务进程运行状况实施监控及告警措施,对各种资源(CPU,内存,硬盘,I/O通道,系统进程,应用进程)使用情况有直观描述并能保存到日志中。

14.对网络系统能提供端口状态及流量方面的信息,对故障能监控及告警。

15.对数据库系统的主要性能指标、资源使用情况(如库表空间、连接数等)有监控预警及告警措施;

答复:

满足。

(二)数据库要求

应采用大型数据库平台,以满足大容量数据的处理及管理。

所采用的数据库系统应具备:

16.支持ANSI/ISOSQL-89、ANSI/ISOSQL-92。

17.支持并行处理技术。

18.数据库系统应具有良好的伸缩性。

19.具有良好的开放性,支持异种数据库的互访。

20.支持多种复制功能(如:

实时复制、定时复制、双向复制、多点方式下的N向复制、复制转发、复制范围可整表复制或表中部分行复制或修改单元复制)。

21.支持联机事物处理(OLTP);支持联机分析处理(OLAP);要求能够实现数据的快速装载、高效的并发处理和交互式查询。

22.支持C2级以上安全标准、多级安全控制。

23.可靠性:

数据库软件系统应具有强的容错能力、错误恢复能力、错误记录及预警能力。

24.应避免数据库死锁的出现,一旦死锁能够自动解锁。

25.支持联机、脱机备份等。

答复:

满足。

(三)系统软件的性能指标

系统软件应支持多种业务的统一处理,系统的性能应达到或超过国家的有关规定。

答复:

满足。

(四)系统管理软件与网管及应用系统的接口

系统管理软件与网管及应用系统间的接口可采用统一的API接口方式,系统监控与管理支持常用的网络管理平台,能实现集成的对网络与应用系统的监控与管理。

答复:

满足。

(五)应用软件设计要求

26.基本要求:

模块化设计;

设计应具有灵活性和易扩展性;

具有优化高效的设计方法;

软件模块的设计应具有相对的独立性;

软件易升级。

答复:

满足。

(六)设计与开发

27.软件工程方法

应用系统软件设计必须遵循软件工程方法,实施阶段化的过程管理和评审,具备并且能够提交软件开发文档。

答复:

满足。

28.面向对象的分析与设计

采用通用的支持软件工具,定义应用软件的类和对象。

答复:

满足。

29.大型关系数据库

要求采用ORACLE、INFORMIX、SYBASE等大型关系数据库。

答复:

满足。

30.CTI平台

支持标准的CTI-LINK,易于实现系统扩展。

答复:

满足。

31.中间件

保证系统处理的高效率,支持异构系统互连通信。

答复:

满足。

32.系统管理

实现设备管理、网络管理和业务管理。

答复:

满足。

(七)业务支持

业务平台的设计与实现必须满足以下要求:

33.基于工作流的业务描述与定义。

34.业务管理,包括业务定义和业务的维护,即增加、删除和修改,提供基于工作流的图形界面或脚本编辑环境。

35.基于话务模型的业务能力设计

系统的业务处理能力的分析要基于公认的话务模型;对新业务要分析其特性,依据实验结果或在合理假设的前提下,计算系统必备的业务处理能力。

36.组件化的技术

应用组件化的技术,保证业务功能的易维护和扩展。

37.基于中间件的业务实现

实现业务逻辑与数据的分离,保证业务维护和数据维护的独立性,保障数据安全。

答复:

满足。

(八)设计原则

合肥市热线整合系统的应用软件必须遵循如下设计原则:

38.规范性

规范性是约束合肥市热线整合系统设计、开发、实施和维护管理的标准和规范。

规范性原则规定合肥市热线整合系统的设计、开发、实施和维护管理必须遵循中国国家标准、信息产业部有关通信行业通用的规范以及通用的国际规范,保证合肥市热线整合系统与合肥市的其他电子政务系统,如合肥市电子政务信息处理统一平台、合肥市劳动与社会保障系统、110系统、有线电视系统等,能够根据需要实现有效的连接。

39.开放性

开放性是约束合肥市热线整合系统外部接口和内部子系统间接口的标准和规范。

开放性原则规定合肥市热线整合系统的各种接口在遵循规范性原则的基础上,保证合肥市热线整合系统可以集成不同设备厂商、系统或平台供应商、软件供应商的产品;保证合肥市热线整合系统的设备管理、系统扩容和业务维护不依赖于单一设备厂商、系统或软件供应商的产品。

40.先进性

先进性是约束合肥市热线整合系统使用软件技术水平的规范。

先进性原则规定合肥市热线整合系统采用先进的软件技术和业务管理手段,以保障合肥市热线整合系统具有高效、全面和稳定等良好品质。

软件系统采用面向对象的分析与设计、组件化的技术和模块化的业务构造与系统构造方式。

41.扩展性

扩展性是约束合肥市热线整合系统满足业务需求长远目标和未来可用的规范。

扩展性原则规定合肥市热线整合系统的系统容量、处理能力和业务范围具有良好的扩展能力。

42.安全可靠性

安全可靠性是约束合肥市热线整合系统信息安全和业务稳定运行的规范。

安全可靠性规定合肥市热线整合系统必须满足电信级的可靠性指标,保证7x24小时的服务;保证合肥市热线整合系统在运营过程中与相关系统信息交换过程的安全;保证合肥市热线整合系统业务管理体系的安全。

43.易用性

易用性是约束合肥市热线整合系统服务手段便利的规范。

易用性原则规定合肥市热线整合在两个方面容易使用:

一方面是方便普通的群众和投资者,另一方面是方便合肥市热线整合系统的管理人员。

44.业务独立性

业务独立性是约束合肥市热线整合系统可以实现多厂商环境的规范。

业务独立性原则规定合肥市热线整合系统的接入部分与业务实现相关的处理部分之间必须相互独立。

答复:

满足。

(九)设备要求

45.主机设备

主机平台要求采用业界成熟的小型机系统或高性能高可靠性的PC系统。

所选择的主机平台应该满足以下特性:

高安全性:

具有多种安全防护手段防止各种非法的入侵和破坏。

高性能价格比:

主机系统应具有很好的性能价格比,保证在实现整体系统的高性能要求下较低的系统建设成本。

高可扩展性:

当业务量增加或增加新业务时,主机能以增加节点、处理器、内存等方式提供更高的性能来满足新的要求。

主机系统设备应具有适当的扩充能力,包括CPU的扩充、内存容量的扩充及I/O能力的扩充等;并可支持CPU的板级升级和群集内节点数的平滑扩充。

高可靠性:

主机系统需7*24小时连续运行,同时系统应具有良好的容错能力。

系统应支持冗余/高可用的配置,保证系统无单点故障。

系统整机平均无故障时间(MTBF)不低于80000小时。

服务器应支持当前较为流行的数据库系统。

易于管理与使用:

主机平台应提供简单灵活的操作管理界面,保证系统的易使用性。

同时系统应容易实现优化运行,以提高系统的运行和处理效率。

技术支持和响应:

主机平台厂商应在国内设有备件库,而且对所提供的主机型号应有足够的备件支持。

主机平台还应保证能够得到足够的技术支持,保证系统的顺利实施以及确保在主机系统发生故障时24小时内对故障进行响应。

46.存储设备

磁盘阵列设备是综合营帐系统中数据联机存储的关键资源,要求有很高的安全可靠性。

根据实际需要,磁盘阵列设备应可与多种厂家的主机系统相连。

磁盘阵列设备应能够提供多种与主机系统的连接方式,如SCSI-2、FC-AL等。

磁盘阵列设备应支持多种RAID存储方式,包括RAID0+1、RAID5等。

磁盘阵列设备应具有较强的平滑扩充能力,包括系统存储容量的扩充及I/O能力的扩充等。

磁盘阵列应支持先进的存储备份方式,例如支持存储区域网(SAN)技术等。

要求对磁盘阵列的结构、功能特点、性能、可靠性、配置和扩充能力等作详细的描述并提供相应的说明资料。

答复:

满足。

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > IT计算机 > 电脑基础知识

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2