大家好，下面小编就和大家分享一下如何写呼叫中心系统升级迁移方案(呼叫中心系统升级迁移方案设计)。很多人还不知道。以下是详细的解释。现在让我们来看看！
大成基金呼叫中心系统升级迁移方案
一、计划概述
1.工业计算机灾难恢复升级
1)本次升级的目的
为呼叫中心的工控机创建容灾环境，采用双机并行的方式作为互为热备的环境，避免工控机单点故障造成的呼叫服务中断，在有限的硬件和线路条件下努力增加容量。
2)当前的工业计算机环境
●线路环境:
目前客服接入电信30B线路3条，共计90条。经上海电信确认，所有线路都是双向的(呼入和呼出)。系统配置方面，开发商限制30路专用去话，60路专用来话。需要特别注意的是，当切换到人工接入座席时，需要占用两条线路(即座席应答时需要占用一条额外的线路)。●硬件环境:
Dialogic的两个60通道数字语音卡和Dialogci的一个4通道传真卡。语音卡通过BNC连接器将120个信道中的90个信道与电话交换机e 1卡相连，另外30个信道跳空。
●负载极限:
所有自动语音来电:最多支持60个客户并发呼叫。
将所有来电转人工:支持最多30个客户同时接听(不考虑座席接入数量)。通常有X个自动语音服务客户和Y个人工客户，容量为X 2Y = 60，即如果10个坐席同时接听电话，可以同时支持40个自动语音服务。
传真线路:支持多达4个客户的并发传真需求。
3)升级目标环境
●线路环境:
总线路数不变，修改系统配置，所以不限制呼入和呼出，即90条线路都可以支持呼入和呼出。添加一条30路中继线接入交换机，以增加交换机数量
,人工条件下的通行能力。
●硬件环境:
将一个60频道的数字语音卡从现有环境迁移到新的工业计算机，同时保持该卡与原电话交换机E1卡之间的链接。
为新的工业计算机添加一个4路传真卡。
●负载极限
所有自动语音来电:最多支持90个客户并发呼叫。
来电全部转人工服务:最多可同时接听45个客户(不考虑接入席位数)。通常自动语音服务客户数为X，人工客户数为y，两台工控机需要分别计算。一台工控机的容量是X 2Y=60，另一台是30。那么如果10个坐席同时接听电话，将同时支持70个自动语音服务。
传真线路:支持多达8个客户的并发传真需求(取决于电信线路分配策略)。
4)灾难恢复原则
正常运行时，CTI和IVR以一台工控机(以下简称主工控机)作为主程序运行环境，KCXP、KCBP等组件在另一台工控机(以下简称从工控机)中独立运行。
在两台工控机硬件升级部署的基础上，系统软件(板驱动、CTI、IVR、KCXP、KCBP等。)确保相同的版本和相同的配置参数。从工控机上部署一套与主工控机相同的CTI和IVR程序，还有KCXP和KCBP程序的副本。此副本中的IP参数配置指向本机，正常运行时不启动CTI、IVR、KCXP和KCBP复制程序。
主、从工控机发生故障时的灾难恢复策略如下:
●主要工业计算机故障:
如果板的物理电路或板驱动出现故障，板驱动将被关闭，其他业务将保持正常运行；
如果CTI或IVR程序失败，手动停止主工控机的所有服务，启动从工控机的CTI和IVR程序，停止从工控机运行KCXP和KCBP，启动KCXP和KCBP的拷贝，所有来电转到从工控机运行。
,●来自工业计算机故障:
从工控机停止所有服务，所有来电转到主工控机运行。
5)升级前准备
●硬件环境的准备:
今年年初已经安装了工业计算机，需要购买一个对话式4路传真卡。在灾难环境中使用时，备份环境可以继续提供传真服务，并配有适配器和电线，以增加内部中继线路的使用。
●软件环境准备:
安装操作系统、安装板卡驱动程序、备份当前工控机程序环境、部署主从工控机程序。
●其他:
提前在网站上公布系统升级公告和呼叫中心IVR语音公告。为保证紧急情况，计划周末停止正常呼叫中心服务两天。
2.从上海到深圳的系统迁移
1)迁移原则
由于系统迁移过程涉及硬件、软件、布线等诸多因素的变化，本次迁移将遵循以下原则:
●确保测试的充分性，并在最终迁移前至少确保一次迁移后的实际环境。
业务模拟运营；
●迁移过程包括灾难恢复环境的部署。同时当系统迁移到深圳时，它分别是
深圳、上海预留部分容灾环境。
2)迁移策略
为了分散系统迁移过程中的风险集中，缩短迁移造成的业务中断时间，本次迁移根据系统的重要性和业务发展现状，采用多批次逐步迁移的策略。
迁移顺序如下所示:
●在线客户服务系统迁移
● TA进口商迁移
●应用服务器和数据库服务测试
,●应用服务器和数据库服务的迁移。
●短信和邮件发送程序的迁移
二、升级和迁移步骤
1.工业计算机灾难恢复升级步骤
升级过程分为环境准备、升级实施和升级后集中监控三个环节。
1)环境准备
●方案确定
这个方案需要信息技术部和业务部门确认后才能实施。
●硬件准备
根据该方案完成Dialogic4路传真卡的采购，并为内部中继线路准备好电线。
2)升级和实施
为了减少对呼叫中心正常业务的影响，升级实施过程需要在周末进行。步骤如下:
●星期五
检查软硬件环境是否与本方案冲突(经过前期与开发商、上海电信、上海机房反复沟通，应该没有影响升级的主要目的因素)；
安装新的工业计算机操作系统；
主从工控机的软件备份和拷贝。
●周六上午
系统关闭；
对于板块迁移，由于新的工控机有较好的硬件环境，所以计划作为主工控机，现有的工控机计划作为从工控机；
主工控机驱动安装，主工控机和动态工控机分别拨测线路，保证板块正常硬件和驱动服务；
按照方案启动主从工控机的服务，进行基本的呼入、呼出和席位人工应答测试。
●周六下午
,将数据库和应用服务器切换到深圳测试环境，测试和验证后续系统迁移的方案，进行基本的呼入、呼出和座席人工应答测试。监控各种服务的运行状态。
●周日早上
进行灾难演练，分别模拟主从工控机线路故障或软件故障，按照此方案进行紧急切换，进行基本的呼入、呼出和席位人工应答测试。
●周日下午
它被保留作为一个时间缓冲区，用于解决本次升级实施过程中的各种异常情况。
3)升级后的集中监控
周一在上海进行现场系统观察，确保本次工控计算机灾备升级不能影响日常业务的开展，第一时间解决当天发生的故障。
2.从上海到深圳的系统迁移步骤
1)在线客服系统的迁移
经与在线客服系统提供商沟通，结合客服部近期提出的在线客服系统需求汇总，系统迁移方案适合提前实施。
为了保证在线客服系统的运行不受迁移的影响，将在深圳机房新建一台在线客服服务器，以此环境作为在线测试在线客服系统新需求和版本升级测试的载体。步骤如下:
●安装新的服务器操作系统；
●部署新服务器的各种服务(apache、mysql、php等。)并复制现有环境的数量。
显示新的服务器作为测试数据；
●进行新需求的在线测试和系统版本升级测试；
●启用在线客服新域名，进行数据迁移，将网站在线客服入口替换为
新域名，完成系统迁移。
2) TA进口商迁移
由于ta导入程序涉及大量的远程文件访问和数据库大量数据的读写(超过100M的文本数据导入数据库)，并发流量远超坐席接听等日常业务的数据库访问强度，且执行基本在非坐席接听时间，所以TA导入。
,程序的迁移，除了完成功能迁移外，还可以在基本不影响代理人答题的前提下，作为深圳和上海机房之间大规模文件访问和数据库读写操作的测试。TA导入程序的迁移步骤比较简单，在深圳机房部署新服务器即可，部署步骤包括:
●将导入程序从上海服务器复制到深圳服务器；
●停止上海服务器任务计划；
●在深圳服务器创建任务计划；
●迁移完成后，跟踪观察任务的运行状态。
3)应用服务器和数据库服务的迁移测试
在迁移之前，应用服务器和数据库服务进行独立的系统测试，目的是通过观察实际环境来验证方案，调整和完善方案。
●迁移测试结合工控机在线容灾环境，步骤如下:
●深圳机房将搭建应用服务器环境，数据库使用目前的DDS同步软件。
终端环境；
●实际测试请参考“工控机容灾升级步骤”一节中的“升级实施”。
【周六下午】时间段计划。
4)应用服务器和数据库服务的迁移
在应用服务器和数据库服务的迁移测试之后，实际的迁移将安排在稍后的周末。迁移步骤包括:
●停止DDS数据同步软件的源和目的服务，停止数据库进行备份；●停止上海机房的应用服务器服务，
●启动深圳机房应用服务器服务；
●重新部署DDS数据同步软件的源和目的服务(深圳是源和上层。
大海是目的地)；
●备份和修改工控机和数据库连接服务的配置文件，指向深圳数据库。
服务器；
●启动深圳机房数据库服务器；
●启动DDS数据同步软件；
●进行基本的呼入、呼出和座席人工接听测试。
,5)短信和电子邮件发送者的迁移
短信和邮件发送器的迁移类似于TA导入器的迁移。把上海服务器的程序环境复制到深圳服务器上就可以了。
而且，迁移后，修改邮件发件人后，Exchange服务可以迁移到新的邮件网关。
三、系统升级和迁移后的灾难恢复计划
1.工业计算机灾难恢复
请参考本文方案概述部分工控机容灾升级中的容灾原理。
2.在线客户服务灾难恢复
由于在线客服系统的迁移，实际深圳机房创建了新的系统环境，上海机房现有版本环境没有调整。所以，如果新的在线客服系统出现故障，可以通过修改网站首页入口，快速切换回上海机房原有环境。
需要说明的时候，上海部分席位需要同时保留安装旧版在线客服系统客户端，用于容灾和应急服务。
3.TA导入程序灾难恢复
由于TA导入程序执行频率较低，实时性要求相对较低，易于观察，如果TA导入程序出现任何异常，在深圳环境下配合开发者可以快速解决。如果出现系统级异常(如硬件故障或操作系统异常)，可以手动调整并启动上海服务器导入任务，完成紧急数据导入。
此外，TA导入程序搬到深圳机房后，也将有选择地纳入集中监控系统。
4.短信和邮件发送程序的灾难恢复
SMS和电子邮件发送程序的现有环境被保留作为备份环境。通过改变应用服务器的配置，可以在紧急情况下快速将发送通道切换回上海。
5.应用服务器灾难恢复
当前的应用服务器环境继续保留，在紧急重启的情况下可以继续提供服务。代理可以通过不同的登录入口登录深圳环境或上海环境。
6.数据库环境灾难恢复
因为本次系统迁移将修改DDS同步软件的配置并继续运行，上海机
,住房数据库将用作实时数据备份。当深圳机房数据库系统出现故障时，通过修改工控机和应用服务器的配置文件，可以在短时间内将数据源切换到上海备份环境。
此外，在系统迁移完成后，将适时实施RAC计划，并完成数据库服务器的集群部署，以进一步提高数据库服务的性能和可靠性。
以上说明了如何编写呼叫中心系统升级迁移方案(呼叫中心系统升级迁移方案设计)。这篇文章写完了，希望对大家有所帮助。如果信息有误，请联系边肖进行更正。
相关导读：呼叫中心系统系统升级与迁移方案怎么写(呼叫中心系统系统升级与迁移方案设计)
相关内容：呼叫中心系统系统升级与迁移方案怎么写(呼叫中心系统系统升级与迁移方案设计)