1、大成基金呼叫中心系統系統升級與遷移方案方案概述1. 工控機災備升級1）本次升級目的創建呼叫中心工控機災備環境，采用雙機并聯模式互為熱備環境，避免 工控機單點故障造成的呼叫服務中斷發生，并爭取在有限硬件與線路條 件下增加容量。2）目前工控機環境線路環境：目前客服共接入3條電信30B+D線路，合計90路，經過與上海電信確 認，所有線路均為雙向（呼入、呼出）線路。開發商在系統配置方面， 限制30路專用外呼,60路專用呼入。需要特別說明的是：轉人工接入 坐席時，需要占用2條線路（即坐席接聽需要額外占用1條線路）。硬件環境：2塊Dialogic的60路數字語音卡，1塊Dialogci的4路傳真卡，語音卡

2、通 過BNC接頭將120路中的90路線路與電話交換機E1卡進行連接，另外 30路線路跳空。負載極限：全部為自動語音呼入：最大支持 60客戶并發呼叫。全部呼入轉人工：最大支持30客戶并發接聽（不考慮坐席接入數量）。 通常狀況：設自動語音服務客戶為 X名，轉人工客戶 Y名，容量為 X+2Y=60即：如果有10名坐席同時接聽電話，則同時并發支持40路自 動語音服務。傳真線路：最多支持4名客戶的并發傳真需求。3）升級目標環境線路環境：線路總數保持不變，修改系統配置，不進行呼入與呼出的限制，即 90 路均可支持呼入呼出。增加一條30路內中繼線路接入交換機，以增加轉人工情況下的話務容量硬件環境：將1張60

3、路數字語音卡從現有環境遷移至新的工控機， 同時保持該板卡 與原電話交換機E1卡之間的鏈路。增加一張4路傳真卡，供新工控機使用。負載極限全部為自動語音呼入：最大支持 90客戶并發呼叫。全部呼入轉人工：最大支持45客戶并發接聽（不考慮坐席接入數量）。 通常狀況：設自動語音服務客戶為 X名，轉人工客戶Y名，兩臺工控機 需要分別計算。一臺工控機容量為 X+2Y=60另一臺為30。則如果有10 名坐席同時接聽電話，則同時并發支持 70路自動語音服務。傳真線路：最多支持8名客戶的并發傳真需求（依賴于電信線路分配策 略）。4）災備原理在正常運行時，CTI與IVR以一臺工控機（以下簡稱主工控機）為主程序運行環

4、境,KCXR KCBF組件除在主工控機運行外，也在另一臺工控機（以下簡稱從工控機）獨立運行一套，兩臺工控機在上述硬件升級與部署的基礎上，系統軟件（板塊驅動、CTk IVR、KCXR KCBP等）保證相同版本與相同配置參數。從工控機部署一 套與主工控機相同的CTI與IVR程序，并存在一份KCXP與KCBFF1序的 副本，該副本中IP參數配置均指向本機，正常運行時CTIIVR以及KCXR KCBFgiJ本程序不啟動。以下分別闡述主、從工控機出現故障的災備策略：主工控機故障：如板塊物理線路或板塊驅動出現故障，則關閉板卡驅動，其余服務保持正常運行；如CTI或IVR程序出現故障，則手工停止主工控機所有服

5、務，啟動從 工控機CTI與IVR程序，從工控機停止KCXR KCBF行，啟動KCXP KCBF®本，所有呼入全部轉入從工控機運行。從工控機故障：從工控機停止所有服務，所有呼入全部轉入主工控機運行5）升級前期準備硬件環境準備：工控機已于今年初到位，需采購 Dialogic4路傳真卡一塊，用于災難環境 時備份環境可以繼續提供傳真服務,配備增加內中繼線路使用的轉接頭 與線材。軟件環境準備：新到工控機的操作系統安裝、板卡驅動安裝、目前工控機程序環境備份, 主、從工控機程序的部署。其它：提前在網站與呼叫中心IVR語音公告發布系統升級公告，為保證應急情 況，擬定停止正常呼叫中心服務的時間為周末兩

6、天。2. 上海至深圳系統遷移1）遷移原則由于系統遷移過程涉及硬件、軟件、線路等諸多因素的變更，所以在本次遷移工作中，將依據如下原則進行：保證測試的充分性，在最終遷移前保證至少一次遷移后實際環境的 業務模擬運行；遷移過程包括災備環境的部署，在系統遷移至深圳的同時，分別于 深圳與上海保留部分災備環境。2）遷移策略為了分散系統遷移過程存在的風險集中度，縮短遷移引起的業務中斷時 問，本次遷移依據系統重要性的高低，參考業務開展現狀，采用分多個 批次逐步遷移的策略。遷移先后順序擬定為：在線客服系統遷移TA導入程序遷移應用服務器與數據庫服務測試應用服務器與數據庫服務遷移短信與郵件發送程序遷移升級與遷移步驟1

7、. 工控機災備升級步驟升級過程分為環境準備、升級實施、升級后集中監測三個環節。1）環境準備方案確定本方案需要經信息技術部門與業務部門確認后方可實施。硬件準備依據本方案，完成Dialogic4路傳真卡的采購，準備內中繼線路使用 線材。2）升級實施為減小對呼叫中心正常業務的影響，升級實施過程需要在周末進行。步驟如下：星期五檢查軟、硬件環境是否與本方案有沖突（經過前期與開發商、上海 電信、上海機房維護的多次反復溝通，應當不存在影響升級的主要 目的因素）；安裝新工控機操作系統；主、從工控機的軟件備份與復制。星期六上午系統停機；進行板塊遷移，由于新的工控機硬件環境較好，擬定為主工控機，現有工控機擬定為從

8、工控機；主工控機驅動安裝，主、動工控機分別進行線路撥測，以確保板塊硬件與驅動服務正常；按照方案啟動主、從工控機各項服務，進行基本呼入、呼出與坐席人工接聽測試。星期六下午將數據庫與應用服務器切換至深圳測試環境，為后續的系統遷移工作進行測試與方案驗證，進行基本呼入、呼出與坐席人工接聽測試。監測各項服務的運行狀態。星期日上午進行災難演練，分別模擬主、從工控機出現線路故障或軟件故障， 根據本方案進行應急切換，進行基本呼入、呼出與坐席人工接聽測 試。星期日下午留作本次升級實施過程中各項異常解決的時間緩沖。3）升級后集中監測周一在上海進行現場系統觀察，確保本次工控機災備升級可以不影響日常業務的開展，第一時

9、間解決當日出現的故障。2. 上海至深圳系統遷移步驟1）在線客服系統遷移經過與在線客服系統提供商的交流，結合客戶服務部日前提出的在線客服系統需求匯總，該系統遷移方案適合較先實施。為保證在線客服系統運行不受遷移影響，將在深圳機房搭建新的在線客服服務器，并以此環境為新需求上線測試以及在線客服系統版本升級測試的載體。步驟如下：新服務器操作系統安裝；新服務器各項服務部署（apaches mysql、php等）,復制現有環境數據至新服務器作為測試數據；進行新需求上線測試與系統版本升級測試；啟用在線客服新域名，進行數據遷移，將網站在線客服入口更換為新域名，完成系統遷移。2）TA導入程序遷移由于TA導入程序涉

10、及大量遠程文件訪問與數據庫大批量數據的讀寫（超過100M的文本數據導入數據庫），并發流量遠超過坐席接聽等日常業務 的數據庫訪問強度，并且執行之間基本處于非坐席接聽時間，所以TA導入程序的遷移，除完成功能遷移外，可以在基本不影響坐席接聽的前提下，作為深圳與上海機房之間大批量文件訪問、數據庫讀寫操作的測試。TA導入程序的遷移步驟較為簡單，在深圳機房新服務器部署即可，部署步驟包括：將導入程序從上海服務器復制至深圳服務器；停止上海服務器任務計劃；在深圳服務器創建任務計劃；在遷移完成后跟蹤觀察任務運行狀況。3）應用服務器與數據庫服務遷移測試應用服務器與數據庫服務在執行遷移之前，進行獨立的系統測試，目的

11、在于進行方案驗證，通過對實際環境的觀測進行方案的調整和完善。遷移測試與工控機災備環境的上線相結合，步驟如下：深圳機房搭建應用服務器環境,數據庫使用目前DDS同步軟件目的端環境；實際測試，參見【工控機災備升級步驟】部分【升級實施】小節的【星期六下午】時間段計劃。4）應用服務器與數據庫服務遷移在應用服務器與數據庫服務遷移測試之后，安排之后某周末時間進行實際遷移，遷移步驟包括：停止DDS數據同步軟件的源端與目的端服務，數據庫停機備份；停止上海機房應用服務器服務，啟動深圳機房應用服務器服務；重新部署DDS數據同步軟件的源端與目的端服務（深圳為源端、上海為目的端）；備份并修改工控機與數據庫連接服務的配置

12、文件，指向深圳數據庫服務器；啟動深圳機房數據庫服務器；啟動DDS數據同步軟件；進行基本呼入、呼出與坐席人工接聽測試。5）短信與郵件發送程序遷移短信與郵件發送程序的遷移與T酣入程序遷移類似，將上海服務器程序 環境復制至深圳服務器即可。并且，遷移之后可以在郵件發送程序修改后，由 Exchange®務遷移至新 的郵件網關。升級與遷移后系統災備方案1. 工控機災備參見本文【方案概述】部分【工控機災備升級】一節的【災備原理】部 分內容。2. 在線客服災備由于在線客服系統的遷移，實際深圳機房創建新的系統環境，上海機房 的現有版本環境不做調整。因此新的在線客服系統如果出現故障，可以 通過修改網站首

13、頁入口的方式迅速切換回上海機房原有環境。需要說明的時，上海部分座席需要同時保留舊版本的在線客服系統客戶 端的安裝，用于災備應急服務使用。3. TA導入程序災備由于TA導入程序執行頻度較低、對實時性要求相對較低，并且易于觀測, 所有如果TA導入程序出現異常，可以協同開發商在深圳環境較快解決。如果出現系統級異常（如硬件故障或操作系統異常），則可以手動調整并 啟動上海服務器導入任務，完成應急情況的數據導入。此外，TA導入程序遷移至深圳機房后，也會擇期將其納入集中監控體系。4. 短信、郵件發送程序災備短信、郵件發送程序現有環境作為備份環境進行保留，通過應用服務器 的配置變更，可以在應急情況下較快的將發送渠道重新切換回上海。5. 應用服務器災備目前的應用服務器環境繼續保留，在應急情況重新啟動即可繼續提供服務，坐