某运营商话务呼出系统偶发性访问失败分析

话务呼出系统可以有效提升外呼通话的接通率，是运营商内部重要的业务系统之一，也是提升品牌形象、提高了宽带服务质量的重要方式。偶发性访问失败会直接导致业务瘫痪，有损用户服务体验。

问题描述

短短一个月内，该业务系统出现偶发性访问失败数次，用户通过很多手段排查定位此故障的真正原因依然未果。科来通过与用户沟通并立刻在该系统服务器区出口部署科来网络回溯分析系统（RAS），开始对该系统流量进行监测。

在部署科来网络回溯分析系统（RAS）的几天后，该系统再次出现大面积无法访问，页面无法正常打开。通过RAS提取出问题时段的系统服务器通信数据流量，我们终于发现导致用户无法正常访问话务呼出系统的直接原因。

分析结果

科来为用户进行故障重现描述：根因并非是该业务系统内出现问题，而是网络中数据库部分出现故障间接导致本次大面积访问失败。由于数据库出现故障造成无法及时断开连接，导致数据库的连接数撑爆。数据库无法正常工作，所以才造成用户无法正常访问该系统应用。

方案价值

案例中对于业务系统故障的分析难点在于其特有的偶发性，因此存在较大分析难度。科来网络回溯分析系统（RAS）能够重现故障现象并从不易觉察的异常数据流量中发现问题突破点，对隐性故障问题实现精细化挖掘分析，快速发现故障点，清晰定位查明故障原因，为客户最终解决故障问题、界定直接责任提供了准确的流量依据。

这也为我们积累了难得的运维经验，有时业务系统的问题并非其自身原因，极有可能是与之相连的上下游部分出现问题间接导致故障的发生，运维过程需更具大局观，不可单独割裂只看复杂网络中某一部分。

分析过程

1、配置回溯分析系统，在相关的业务访问逻辑进行抓包分析：

营业厅外网(130.XX.XX.46)F5(130.XX.XX.27)服务器(134.XX.XX.92-95)数据库(134.XX.XX.86)

2、通过对该业务系统的监控分析，发现在发生故障的时间段存在大量访问被重置的情况，如下图所示：

通过对该时间段的会话分析，发现客户端在与服务端建立三次握手，发送POST请求之后，服务端也回复了ACK进行确认。但等了几秒甚至至几百秒服务器都没有数据响应，客户端直接把会话断开，直接回复了RST关闭会话。如下图所示：

那么，什么原因导致应用没有回复数据响应呢?

通过对数据库134.XX.XX.86的监控，应用需要向数据库调用数据，是不是数据库端出现问题?

在同一个时间点，发现数据出现了异常，数据库的连接数比正常的情况下多了很多。数据库一般是长连接，所以客户端的连接数一般不会很多，会设定相关连接数上限，对单个客户端连接数的上限设定为100个。

但通过对数据库半个小时分析，发现服务器134.XX.XX.94半个小时的连接数达到了229个，134.XX.XX.93的连接数达到了132个，明显超过了这个设定的100个连接数的上限值。

所以，该段时间内的数据库连接数很高，导致数据库响应缓慢或者数据库无法响应，间接就导致了客户端去访问应用，然后无法正常打开，如下图所示：

通过对客户端134.XX.XX.94访问数据库的会话进行详细分析，客户端发送请求之后，数据库这一端没有及时发送数据进行响应，等了264秒之后客户端在发了fin中断连接，然后需要再建新连接，但数据库134.XX.XX.86这边5分钟之后才发响应数据以及fin包，该连接还保持着，这样就导致数据库134.XX.XX.86的连接数过多，数据库无法正常响应数据。如下图所示：

所以通过以上分析，由于数据库没有及时断开连接，数据库端出现问题，导致客户端的连接数超过上限。通过客户反馈该时间段的数据库的连接数已经超过正常值，由于数据库无法正常响应数据，间接就导致客户端无法正常调取数据及正常访问应用，应用服务器的连接数就撑爆了连接池，数据库监控如下：

解决方案

定位了问题发生的原因后，我们与该业务系统应用及数据的管理员进行沟通，请其升高(134.XX.XX.92-95)服务器的最大DB连接数配置，从而提高系统容错瓶颈。

调整后，该系统恢复正常。同时应用(134.XX.XX.92-95)连接数恢复正常，如下两图所示：

-END-