呼叫中心系统系统升级与迁移方案

大成基金呼叫中心系统系统升级与迁移方案一、 方案概述1. 工控机灾备升级1) 本次升级目的创建呼叫中心工控机灾备环境，采用双机并联模式互为热备环境，避免工控机单点故障造成的呼叫服务中断发生，并争取

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

一、 方案概述

1. 工控机灾备升级

1) 本次升级目的

创建呼叫中心工控机灾备环境，采用双机并联模式互为热备环境，避免工控机单点故障造成的呼叫服务中断发生，并争取在有限硬件与线路条件下增加容量。

2) 目前工控机环境

● 线路环境：

目前客服共接入3条电信30B D线路，合计90路，经过与上海电信确认，所有线路均为双向（呼入、呼出）线路。开发商在系统配置方面，限制30路专用外呼，60路专用呼入。需要特别说明的是：转人工接入坐席时，需要占用2条线路（即坐席接听需要额外占用1条线路）。 ● 硬件环境：

2块Dialogic 的60路数字语音卡，1块Dialogci 的4路传真卡，语音卡通过BNC 接头将120路中的90路线路与电话交换机E1卡进行连接，另外30路线路跳空。

● 负载极限：

全部为自动语音呼入：最大支持60客户并发呼叫。

全部呼入转人工：最大支持30客户并发接听（不考虑坐席接入数量）。 通常状况：设自动语音服务客户为X 名，转人工客户Y 名，容量为X 2Y=60，即：如果有10名坐席同时接听电话，则同时并发支持40路自动语音服务。

传真线路：最多支持4名客户的并发传真需求。

3) 升级目标环境

● 线路环境：

线路总数保持不变，修改系统配置，不进行呼入与呼出的限制，即90路均可支持呼入呼出。增加一条30路内中继线路接入交换机，以增加转

人工情况下的话务容量。

● 硬件环境：

将1张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) 升级前期准备

● 硬件环境准备：

工控机已于今年初到位，需采购Dialogic4路传真卡一块，用于灾难环境时备份环境可以继续提供传真服务，配备增加内中继线路使用的转接头与线材。

● 软件环境准备：

新到工控机的操作系统安装、板卡驱动安装、目前工控机程序环境备份，主、从工控机程序的部署。

● 其它：

提前在网站与呼叫中心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. 短信、邮件发送程序灾备

短信、邮件发送程序现有环境作为备份环境进行保留，通过应用服务器的配置变更，可以在应急情况下较快的将发送渠道重新切换回上海。

5. 应用服务器灾备

目前的应用服务器环境继续保留，在应急情况重新启动即可继续提供服务，坐席可以通过不同的登录入口区分登入深圳环境或是上海环境。

6. 数据库环境灾备

由于此次系统迁移会将DDS 同步软件配置修改后继续运行，所以上海机

房数据库将作为实时数据备份。在深圳机房数据库系统出现故障时，可以通过修改工控机与应用服务器配置文件的方式，在较短的时间内将数据源切换至上海备份环境。

此外，在本次系统迁移完成后，会择期进行RAC 方案的实施，完成数据库服务器的集群部署，进一步提供数据库服务的性能与可靠性。