大成基金呼叫中心系統系統升級與遷移方案一、 方案概述1. 工控機災備升級1) 本次升級目的創(chuàng)建呼叫中心工控機災備環(huán)境，采用雙機并聯模式互為熱備環(huán)境，避免工控機單點故障造成的呼叫服務中斷發(fā)生，并爭取

大成基金呼叫中心系統系統升級與遷移方案

一、 方案概述

1. 工控機災備升級

1) 本次升級目的

創(chuàng)建呼叫中心工控機災備環(huán)境，采用雙機并聯模式互為熱備環(huán)境，避免工控機單點故障造成的呼叫服務中斷發(fā)生，并爭取在有限硬件與線路條件下增加容量。

2) 目前工控機環(huán)境

● 線路環(huán)境：

目前客服共接入3條電信30B D線路，合計90路，經過與上海電信確認，所有線路均為雙向（呼入、呼出）線路。開發(fā)商在系統配置方面，限制30路專用外呼，60路專用呼入。需要特別說明的是：轉人工接入坐席時，需要占用2條線路（即坐席接聽需要額外占用1條線路）。 ● 硬件環(huán)境：

2塊Dialogic 的60路數字語音卡，1塊Dialogci 的4路傳真卡，語音卡通過BNC 接頭將120路中的90路線路與電話交換機E1卡進行連接，另外30路線路跳空。

● 負載極限：

全部為自動語音呼入：最大支持60客戶并發(fā)呼叫。

全部呼入轉人工：最大支持30客戶并發(fā)接聽（不考慮坐席接入數量）。 通常狀況：設自動語音服務客戶為X 名，轉人工客戶Y 名，容量為X 2Y=60，即：如果有10名坐席同時接聽電話，則同時并發(fā)支持40路自動語音服務。

傳真線路：最多支持4名客戶的并發(fā)傳真需求。

3) 升級目標環(huán)境

● 線路環(huán)境：

線路總數保持不變，修改系統配置，不進行呼入與呼出的限制，即90路均可支持呼入呼出。增加一條30路內中繼線路接入交換機，以增加轉

人工情況下的話務容量。

● 硬件環(huán)境：

將1張60路數字語音卡從現有環(huán)境遷移至新的工控機，同時保持該板卡與原電話交換機E1卡之間的鏈路。

增加一張4路傳真卡，供新工控機使用。

● 負載極限

全部為自動語音呼入：最大支持90客戶并發(fā)呼叫。

全部呼入轉人工：最大支持45客戶并發(fā)接聽（不考慮坐席接入數量）。 通常狀況：設自動語音服務客戶為X 名，轉人工客戶Y 名，兩臺工控機需要分別計算。一臺工控機容量為X 2Y=60，另一臺為30。則如果有10名坐席同時接聽電話，則同時并發(fā)支持70路自動語音服務。

傳真線路：最多支持8名客戶的并發(fā)傳真需求（依賴于電信線路分配策略）。

4) 災備原理

在正常運行時，CTI 與IVR 以一臺工控機（以下簡稱主工控機）為主程序運行環(huán)境，KCXP 、KCBP 等組件除在主工控機運行外，也在另一臺工控機（以下簡稱從工控機）獨立運行一套，

兩臺工控機在上述硬件升級與部署的基礎上，系統軟件（板塊驅動、CTI 、IVR 、KCXP 、KCBP 等）保證相同版本與相同配置參數。從工控機部署一套與主工控機相同的CTI 與IVR 程序，并存在一份KCXP 與KCBP 程序的副本，該副本中IP 參數配置均指向本機，正常運行時CTI 、IVR 以及KCXP 、KCBP 副本程序不啟動。

以下分別闡述主、從工控機出現故障的災備策略：

● 主工控機故障：

如板塊物理線路或板塊驅動出現故障，則關閉板卡驅動，其余服務保持正常運行；

如CTI 或IVR 程序出現故障，則手工停止主工控機所有服務，啟動從工控機CTI 與IVR 程序，從工控機停止KCXP 、KCBP 運行，啟動KCXP 、KCBP 副本，所有呼入全部轉入從工控機運行。

● 從工控機故障：

從工控機停止所有服務，所有呼入全部轉入主工控機運行。

5) 升級前期準備

● 硬件環(huán)境準備：

工控機已于今年初到位，需采購Dialogic4路傳真卡一塊，用于災難環(huán)境時備份環(huán)境可以繼續(xù)提供傳真服務，配備增加內中繼線路使用的轉接頭與線材。

● 軟件環(huán)境準備：

新到工控機的操作系統安裝、板卡驅動安裝、目前工控機程序環(huán)境備份，主、從工控機程序的部署。

● 其它：

提前在網站與呼叫中心IVR 語音公告發(fā)布系統升級公告，為保證應急情況，擬定停止正常呼叫中心服務的時間為周末兩天。

2. 上海至深圳系統遷移

1) 遷移原則

由于系統遷移過程涉及硬件、軟件、線路等諸多因素的變更，所以在本次遷移工作中，將依據如下原則進行：

● 保證測試的充分性，在最終遷移前保證至少一次遷移后實際環(huán)境的

業(yè)務模擬運行；

● 遷移過程包括災備環(huán)境的部署，在系統遷移至深圳的同時，分別于

深圳與上海保留部分災備環(huán)境。

2) 遷移策略

為了分散系統遷移過程存在的風險集中度，縮短遷移引起的業(yè)務中斷時間，本次遷移依據系統重要性的高低，參考業(yè)務開展現狀，采用分多個批次逐步遷移的策略。

遷移先后順序擬定為：

● 在線客服系統遷移

● TA 導入程序遷移

● 應用服務器與數據庫服務測試

● 應用服務器與數據庫服務遷移

● 短信與郵件發(fā)送程序遷移

二、 升級與遷移步驟

1. 工控機災備升級步驟

升級過程分為環(huán)境準備、升級實施、升級后集中監(jiān)測三個環(huán)節(jié)。

1) 環(huán)境準備

● 方案確定

本方案需要經信息技術部門與業(yè)務部門確認后方可實施。

● 硬件準備

依據本方案，完成Dialogic4路傳真卡的采購，準備內中繼線路使用線材。

2) 升級實施

為減小對呼叫中心正常業(yè)務的影響，升級實施過程需要在周末進行。步驟如下：

● 星期五

檢查軟、硬件環(huán)境是否與本方案有沖突（經過前期與開發(fā)商、上海電信、上海機房維護的多次反復溝通，應當不存在影響升級的主要目的因素）；

安裝新工控機操作系統；

主、從工控機的軟件備份與復制。

● 星期六上午

系統停機；

進行板塊遷移，由于新的工控機硬件環(huán)境較好，擬定為主工控機，現有工控機擬定為從工控機；

主工控機驅動安裝，主、動工控機分別進行線路撥測，以確保板塊硬件與驅動服務正常；

按照方案啟動主、從工控機各項服務，進行基本呼入、呼出與坐席人工接聽測試。

● 星期六下午

將數據庫與應用服務器切換至深圳測試環(huán)境，為后續(xù)的系統遷移工作進行測試與方案驗證，進行基本呼入、呼出與坐席人工接聽測試。監(jiān)測各項服務的運行狀態(tài)。

● 星期日上午

進行災難演練，分別模擬主、從工控機出現線路故障或軟件故障，根據本方案進行應急切換，進行基本呼入、呼出與坐席人工接聽測試。

● 星期日下午

留作本次升級實施過程中各項異常解決的時間緩沖。

3) 升級后集中監(jiān)測

周一在上海進行現場系統觀察，確保本次工控機災備升級可以不影響日常業(yè)務的開展，第一時間解決當日出現的故障。

2. 上海至深圳系統遷移步驟

1) 在線客服系統遷移

經過與在線客服系統提供商的交流，結合客戶服務部日前提出的在線客服系統需求匯總，該系統遷移方案適合較先實施。

為保證在線客服系統運行不受遷移影響，將在深圳機房搭建新的在線客服服務器，并以此環(huán)境為新需求上線測試以及在線客服系統版本升級測試的載體。步驟如下：

● 新服務器操作系統安裝；

● 新服務器各項服務部署（apache 、mysql 、php 等），復制現有環(huán)境數

據至新服務器作為測試數據；

● 進行新需求上線測試與系統版本升級測試；

● 啟用在線客服新域名，進行數據遷移，將網站在線客服入口更換為

新域名，完成系統遷移。

2) TA 導入程序遷移

由于TA 導入程序涉及大量遠程文件訪問與數據庫大批量數據的讀寫（超過100M 的文本數據導入數據庫），并發(fā)流量遠超過坐席接聽等日常業(yè)務的數據庫訪問強度，并且執(zhí)行之間基本處于非坐席接聽時間，所以TA 導

入程序的遷移，除完成功能遷移外，可以在基本不影響坐席接聽的前提下，作為深圳與上海機房之間大批量文件訪問、數據庫讀寫操作的測試。 TA 導入程序的遷移步驟較為簡單，在深圳機房新服務器部署即可，部署步驟包括：

● 將導入程序從上海服務器復制至深圳服務器；

● 停止上海服務器任務計劃；

● 在深圳服務器創(chuàng)建任務計劃；

● 在遷移完成后跟蹤觀察任務運行狀況。

3) 應用服務器與數據庫服務遷移測試

應用服務器與數據庫服務在執(zhí)行遷移之前，進行獨立的系統測試，目的在于進行方案驗證，通過對實際環(huán)境的觀測進行方案的調整和完善。

● 遷移測試與工控機災備環(huán)境的上線相結合，步驟如下：

● 深圳機房搭建應用服務器環(huán)境，數據庫使用目前DDS 同步軟件目的

端環(huán)境；

● 實際測試，參見【工控機災備升級步驟】部分【升級實施】小節(jié)的

【星期六下午】時間段計劃。

4) 應用服務器與數據庫服務遷移

在應用服務器與數據庫服務遷移測試之后，安排之后某周末時間進行實際遷移，遷移步驟包括：

● 停止DDS 數據同步軟件的源端與目的端服務，數據庫停機備份； ● 停止上海機房應用服務器服務，

● 啟動深圳機房應用服務器服務；

● 重新部署DDS 數據同步軟件的源端與目的端服務（深圳為源端、上

海為目的端）；

● 備份并修改工控機與數據庫連接服務的配置文件，指向深圳數據庫

服務器；

● 啟動深圳機房數據庫服務器；

● 啟動DDS 數據同步軟件；

● 進行基本呼入、呼出與坐席人工接聽測試。

5) 短信與郵件發(fā)送程序遷移

短信與郵件發(fā)送程序的遷移與TA 導入程序遷移類似，將上海服務器程序環(huán)境復制至深圳服務器即可。

并且，遷移之后可以在郵件發(fā)送程序修改后，由Exchange 服務遷移至新的郵件網關。

三、 升級與遷移后系統災備方案

1. 工控機災備

參見本文【方案概述】部分【工控機災備升級】一節(jié)的【災備原理】部分內容。

2. 在線客服災備

由于在線客服系統的遷移，實際深圳機房創(chuàng)建新的系統環(huán)境，上海機房的現有版本環(huán)境不做調整。因此新的在線客服系統如果出現故障，可以通過修改網站首頁入口的方式迅速切換回上海機房原有環(huán)境。

需要說明的時，上海部分座席需要同時保留舊版本的在線客服系統客戶端的安裝，用于災備應急服務使用。

3. TA 導入程序災備

由于TA 導入程序執(zhí)行頻度較低、對實時性要求相對較低，并且易于觀測，所有如果TA 導入程序出現異常，可以協同開發(fā)商在深圳環(huán)境較快解決。如果出現系統級異常（如硬件故障或操作系統異常），則可以手動調整并啟動上海服務器導入任務，完成應急情況的數據導入。

此外，TA 導入程序遷移至深圳機房后，也會擇期將其納入集中監(jiān)控體系。

4. 短信、郵件發(fā)送程序災備

短信、郵件發(fā)送程序現有環(huán)境作為備份環(huán)境進行保留，通過應用服務器的配置變更，可以在應急情況下較快的將發(fā)送渠道重新切換回上海。

5. 應用服務器災備

目前的應用服務器環(huán)境繼續(xù)保留，在應急情況重新啟動即可繼續(xù)提供服務，坐席可以通過不同的登錄入口區(qū)分登入深圳環(huán)境或是上海環(huán)境。

6. 數據庫環(huán)境災備

由于此次系統遷移會將DDS 同步軟件配置修改后繼續(xù)運行，所以上海機

房數據庫將作為實時數據備份。在深圳機房數據庫系統出現故障時，可以通過修改工控機與應用服務器配置文件的方式，在較短的時間內將數據源切換至上海備份環(huán)境。

此外，在本次系統遷移完成后，會擇期進行RAC 方案的實施，完成數據庫服務器的集群部署，進一步提供數據庫服務的性能與可靠性。