呼叫中心系统系统升级与迁移方案怎么写(呼叫中心系统系统升级与迁移方案设计)

大家好，下面小编就和大家分享一下如何写呼叫中心系统升级迁移方案(呼叫中心系统升级迁移方案设计)。很多人还不知道。以下是详细的解释。现在让我们来看看！

大成基金呼叫中心系统升级迁移方案

一、计划概述

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计划，并完成数据库服务器的集群部署，以进一步提高数据库服务的性能和可靠性。

以上说明了如何编写呼叫中心系统升级迁移方案(呼叫中心系统升级迁移方案设计)。这篇文章写完了，希望对大家有所帮助。如果信息有误，请联系边肖进行更正。