呃～您没走错房间，这里是Genesys非官方个人作祟技术公众号。偶只是借这个血案的名字想写一篇技术文章而已，好吧，正文开始，主题：一个IVR技术运维失误引发的故障处理复盘，鉴于客户信息敏感，谢绝八卦咨询。

　　首先咱们先上课～

　　众所周知，Genesys看家的GVP平台是久经考验的IVR战士～以其多种角色，多种功能，百般变化而着称。系统可以支持的特性包括：

　　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）

　　真传一句话：部署和运维时的一小步，后面省了多少步呀。