座席客户端软件异常,包括停顿、无响应、自动掉线等

1、查看座席PC是否断网,如网线松动、脱落等。

2、网络硬件如无问题,查看是否有网络配置的问题,如IP冲突、DHCP服务失效等。

【案例1】

现象:坐席电脑会出现浏览器卡死现象,话机偶尔注册失败。

据话务员反映:该现象大约会每一两个小时出现一次。

分析:根据某次操作现象发现:在坐席登陆呼叫中心的状态下,然后断开局域网会出现浏览器卡住。
另外该问题区域存在这样的情况:该区域所有话机15个均为动态IP,还有16台电脑,网管只给该dhcp区域指派了30个ip。
话机会出现偶尔注册失败的状况,由此分析出可能是因为dhcp服务不能完全满足所有终端。
等解决了ip话机的问题,浏览器卡死问题也随之解决。

解决方法:扩充IP池大小,话机和电脑全部设置成固定IP。而后电话没再出现注册失败,电脑没再出现浏览器卡死。

【案例2】

现象:坐席登陆自动离线。

从坐席的日志消息看有如下消息
Send STIPCCMsg_HeartBeat_Agent2ACD(AgentID=8008) failed in SendHeartBeatToACD()

从日志看,8008坐席与ACD的心跳连接失败,基本定位是网络问题,后查看网络是因为有坐席电脑的ip地址与呼叫中心一体机的ip冲突导致的,修改ip地址恢复正常。

3、IE浏览器出现问题也会导致座席软件不正常,这一般也和网络配置有关。

【案例3】

现象:客户在使用北京联宇的业务系统时,发现使用一段时间会造成IE程序未响应情况

客户使用的的业务系统是北京联宇公司开发的的,通过与我们的坐席条作对接来进行电话的呼出,呼出。系统使用的是BS结构。坐席电脑加入了域控。

客户反映在系统上线后,很多坐席人员发现在拨打完两三个电话后,当提交完通话记录后就会出现IE浏览器出现未响应的情况,需要关闭进程,重新登录。但使用完一段时间后又会出现上述问题。

最初怀疑是两家在对接上的问题,发现之前使用的坐席条版本跟后来用的不一样,于是对所有坐席都更新到目前使用的1.1.049的版本。更新完后,问题依旧。

联宇公司人员又对剖分坐席的的操作系统进行了更换。将5台电脑换成了64位的操作。发现没有出现类似问题。但给客户全换成64位不现实。

后来发现在IE出现未响应时,通过任务管理器的资源管理器发现IE的线程在500多时就死掉。打开等待链发现占用的都是NetworkService这个服务。

正常在运行业务时,打开的页面在关闭后会释放掉线程。但发现那些出问题的电脑在打开业务系统其它操作界面后,线程会不断积累,不会释放。当积累到500我时就出现程序未响应。

后来发现是客户在DNS中输入的地址是一台域控服务器的地址,但在做域控时没有做DNS的双向解析。通过修改设置后。发现IE程序的线程数不会自动累积。问题解决。

4、服务器负荷重会导致座席软件掉线,出现掉线现象后观察下服务器负荷。

【案例4】

现象:客户反映使用一段时间后。坐席条会全部变红,部分坐席成员的业务系统的坐席条显示状态异常。

解决过程:到达现场后。先询问客户使用情况,反映今天上午10点54分,11点08分左右。坐席条突然全部变红了,后来经重启后才恢复正常。通过日志查询,发现坐席是全部断开了。

一开始怀疑是网络原因。在一台坐席电脑上一直ping一体机IP地址,发现网络是正常的。并没有出现掉包现象。在15点30分,客户电脑又出现了全部变红的现象。先查看网络状态,发现ping包一直正常,没有延迟和丢包现象。查看CPU占用情况,发现mysqld这个服务占用了大量CPU,接近200左右。

怀疑是这个进程导致了程序的异常。通过相关命令查询,发现该进程是在调取录音时才产生的。询问坐席人员使用情况,他们反映每天都会不定时的查询录音。因为他们需要查录音里带的满意度调查。于是找了两三个人同时点开录音程序。发现一点开CPU就占用接近200,然后坐席就全部变红。而且需要一段时间CPU占用率才能恢复正常。

经了解,业务系统为第三方软件公司开发,坐席人员使用业务系统里的录音查询功能来查询录音,当他们点开录音查询菜单栏,会先直接进行所有录音的查询,然后才通过选取时间段来查询。从单个坐席查询结果看到目前大概有13万7千8百多条数据。所以当有两三个人在同时点录音查询的时候就会产生几十万条数据的并发处理,从而导致CPU过高。

处理结果:将此现象反馈给了第三方软件开发人员,并配合他们的研发人员修改了录音查询功能。改成点开录音查询菜单栏时不做任何查询,需要选取时间段才能执行查询。然后又叫了四个坐席,让他们同时查询一段时间内的录音。发现只要不是查询所有的录音数据,如查询一个月的。CPU占用率最多达到43%。查询速度也比之前快。查询完后CPU占用率就恢复正常。不像之前一直维持在100%之上。