最近偶爾想起一部電影，當年被稱為《一個饅頭引發的血案》之陳凱歌導演的《無極》，對其有些生不逢時的惋惜。這部電影要是放在當下播出，應該比《小時代》和《爵跡》高出200個《梔子花開》...。。
呃～您沒走錯房間，這里是Genesys非官方個人作祟技術公眾號。偶只是借這個血案的名字想寫一篇技術文章而已，好吧，正文開始，主題：一個IVR技術運維失誤引發的故障處理復盤，鑒于客戶信息敏感，謝絕八卦咨詢。
首先咱們先上課～
眾所周知，Genesys看家的GVP平臺是久經考驗的IVR戰士～以其多種角色，多種功能，百般變化而著稱。系統可以支持的特性包括：
- VXML亦即IVR
- VXML+CCXML亦即DTMF控制會議橋
- Conference亦即會議
- Anncoucement亦即音樂服務
- RecordingClient亦即錄音
- CPD亦即外呼偵測
- Media亦即媒體服務
- Treatment亦即各種Tone
- MSML
GVP的本領這么多，自然是極好的。奈何軟件化的MediaServer平臺能力受制于所承載的Host性能，所以通常概念上我們會說一臺MediaServer（媒體服務器）能夠支持X百個端口，那要是客戶說我有上千上萬個端口呢？
能量不夠，數量來湊～謝謝
于是便有了資源管理器Resource Manager，提供LRG邏輯資源組的配置，將同氣相求的MCP（亦即Media Server）組隊一起打怪。所謂的“同氣相求”大致來說可以認為是：
比如都是專屬IVR的媒體服務或者專屬Recording的媒體服務
比如屬地化原則，媒體服務本地化響應，專業術語geo-location
那么好像就是這樣：
這個方案的架構是非常漂亮的，如果您覺得RM雙活還夠保險，還可以再為添加一對RM，構建GVP Multisite，充分解決信令擁塞瓶頸。
那么問題來了，GVP的報表怎么辦？G廠提供了貼心的IVR的報表服務器，GVP Reporting Server，可以提供IVR的CDR數據、業務峰值數據、傳輸時延數據亦即VAR數據，大概的數據流向示意圖如下：
所有的媒體服務器和資源管理器會將所有的Call數據傳遞給GVP Reporting Server，報表服務器經過數據處理后寫入GVP Reporting數據庫，同時提供Web Service給GA／GAX或者第三方網管使用。
用戶IVR的端口數如果過多（當然G廠很開心），也就是MCP的數量過多時，問題就出現了：
大規模的MCP在用戶業務忙時會發送大量的報表數據給Reporting Server，由于GVP Reporting Server使用ActiveMQ技術，當數據處理不及時或者與報表數據庫的連接發生中斷時，GVP Reporting Server只得采用最后一招，寫入本地硬盤，可要是硬盤塞滿會怎樣？
鏈式發應開始了...。
Reporting Server的硬盤塞滿，導致Hostdown；
Reporting Server的Host不可用，MCPRM找不到DataSink；
由于無法上傳報表數據，MCPRM將數據接入各自本地硬盤；
如果RM的硬盤也是塞滿了...。
那么整個GVP就offline。
在過去的五年里，此類故障發生過兩次，影響力巨大。那么就有人說了，你這么講我是不是可以理解你們的系統設計有缺陷呀？
怎么會呢？
MCP和RM的配置中均包含：
cdr.max_throughput
cdr.local_queue_max
ors.local_queue_max
sqa.local_queue_max
ors.reportinginterval
其實可以設置上傳速率和間隔時間，本地硬盤存儲容量，有效地管控風險。
同時，SCS的LCA和SNMP Master Agent也可以對Reporting Server所在Host的硬盤、CPU和進程進行監控，也可以對數據庫Host的監控。
同時，GVP Reporting Server還可以支持分布式部署（實時報表與歷史報表分離）和無數據庫部署（Nod Bmode）
真傳一句話：部署和運維時的一小步，后面省了多少步呀。
