最近偶尔想起一部电影，当年被称为《一个馒头引发的血案》之陈凯歌导演的《无极》，对其有些生不逢时的惋惜。这部电影要是放在当下播出，应该比《小时代》和《爵迹》高出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）
真传一句话：部署和运维时的一小步，后面省了多少步呀。
