呃～您沒走錯房間，這里是Genesys非官方個人作祟技術(shù)公眾號。偶只是借這個血案的名字想寫一篇技術(shù)文章而已，好吧，正文開始，主題：一個IVR技術(shù)運維失誤引發(fā)的故障處理復(fù)盤，鑒于客戶信息敏感，謝絕八卦咨詢。

　　首先咱們先上課～

　　眾所周知，Genesys看家的GVP平臺是久經(jīng)考驗的IVR戰(zhàn)士～以其多種角色，多種功能，百般變化而著稱。系統(tǒng)可以支持的特性包括：

　　GVP的本領(lǐng)這么多，自然是極好的。奈何軟件化的MediaServer平臺能力受制于所承載的Host性能，所以通常概念上我們會說一臺MediaServer（媒體服務(wù)器）能夠支持X百個端口，那要是客戶說我有上千上萬個端口呢？

　　于是便有了資源管理器Resource Manager，提供LRG邏輯資源組的配置，將同氣相求的MCP（亦即Media Server）組隊一起打怪。所謂的“同氣相求”大致來說可以認(rèn)為是：

　　比如都是專屬IVR的媒體服務(wù)或者專屬Recording的媒體服務(wù)

　　比如屬地化原則，媒體服務(wù)本地化響應(yīng)，專業(yè)術(shù)語geo-location

　　那么好像就是這樣：

　　這個方案的架構(gòu)是非常漂亮的，如果您覺得RM雙活還夠保險，還可以再為添加一對RM，構(gòu)建GVP Multisite，充分解決信令擁塞瓶頸。

　　那么問題來了，GVP的報表怎么辦？G廠提供了貼心的IVR的報表服務(wù)器，GVP Reporting Server，可以提供IVR的CDR數(shù)據(jù)、業(yè)務(wù)峰值數(shù)據(jù)、傳輸時延數(shù)據(jù)亦即VAR數(shù)據(jù)，大概的數(shù)據(jù)流向示意圖如下：

　　所有的媒體服務(wù)器和資源管理器會將所有的Call數(shù)據(jù)傳遞給GVP Reporting Server，報表服務(wù)器經(jīng)過數(shù)據(jù)處理后寫入GVP Reporting數(shù)據(jù)庫，同時提供Web Service給GA／GAX或者第三方網(wǎng)管使用。

　　用戶IVR的端口數(shù)如果過多（當(dāng)然G廠很開心），也就是MCP的數(shù)量過多時，問題就出現(xiàn)了：

　　大規(guī)模的MCP在用戶業(yè)務(wù)忙時會發(fā)送大量的報表數(shù)據(jù)給Reporting Server，由于GVP Reporting Server使用ActiveMQ技術(shù)，當(dāng)數(shù)據(jù)處理不及時或者與報表數(shù)據(jù)庫的連接發(fā)生中斷時，GVP Reporting Server只得采用最后一招，寫入本地硬盤，可要是硬盤塞滿會怎樣？

　　Reporting Server的硬盤塞滿，導(dǎo)致Hostdown；

　　Reporting Server的Host不可用，MCPRM找不到DataSink；

　　由于無法上傳報表數(shù)據(jù)，MCPRM將數(shù)據(jù)接入各自本地硬盤；

　　如果RM的硬盤也是塞滿了...。

　　那么整個GVP就offline。

　　在過去的五年里，此類故障發(fā)生過兩次，影響力巨大。那么就有人說了，你這么講我是不是可以理解你們的系統(tǒng)設(shè)計有缺陷呀？

　　怎么會呢？

　　MCP和RM的配置中均包含：

　　cdr.max_throughput

　　cdr.local_queue_max

　　ors.local_queue_max

　　sqa.local_queue_max

　　ors.reportinginterval

　　其實可以設(shè)置上傳速率和間隔時間，本地硬盤存儲容量，有效地管控風(fēng)險。

　　同時，SCS的LCA和SNMP Master Agent也可以對Reporting Server所在Host的硬盤、CPU和進程進行監(jiān)控，也可以對數(shù)據(jù)庫Host的監(jiān)控。

　　同時，GVP Reporting Server還可以支持分布式部署（實時報表與歷史報表分離）和無數(shù)據(jù)庫部署（Nod Bmode）

　　真?zhèn)饕痪湓挘翰渴鸷瓦\維時的一小步，后面省了多少步呀。