外呼不通?如何排查
外呼不通时,不要慌张,首先你要对你的外呼系统的构造了如指掌,才可以顺藤摸瓜,找到问题所在。
了解外呼系统的架构:
不管外呼系统是什么样的:自己做的,外面买的。基本架构和原理都不会变,我给大家抽象出一个架构图:
上图是基于软交换核心的外呼系统主要分层架构。
有类似产品的对号入座,如果是硬交换、本地化部署方式的服务层核心基本原理是一致的。
自下而上简单介绍下:
- 资源层:各上游的通信资源服务商。
- 接入层:对接通信资源的接入服务或者设备
- 服务层:软交换的核心,云端部署软交换系统常常拆分为各种组件,集群化部署。
- 支撑层:包括整个服务的计费支撑管理,服务的监控,接口服务及呼叫系统特有的呼叫风控服务。
- 应用层:最上面是应用层,各种调用呼叫服务的产品和应用,比较常见的是人工外呼,自动外呼和AI外呼。
全局还是局部故障?
接下来我们就讲下外呼不通时,如何顺藤摸瓜,找到问题所在。
我们首先要做一个范围限定,外呼不通是个局部性事件,还是故障级别的全局情况?
如果是小范围内独立事件,那么重点去观察范围内的独特特征,比如业务的通信资源、产品功能配置、应用状态等。
确认是局部问题后,至少心态不会那么炸裂,接下来去认真分析具体日志,使用情况去定位分析测试。
如果是后者?那意味着出现了比较严重的情况,需要你争分夺秒,尽快定位问题并给出解决方案。
从哪里开始优先排查:
如果是局部性的外呼不通情况发生,我建议优先去资源层,问下资源供应商有无问题。
有人说,为什么?产品是我们自己的,我们自己去查岂不是最方便了?
说的没错,但恰恰因为资源层是不受你管理的“黑盒子”,才需要马上去沟通对接,同时开始自己的排查,否则查来查去,找不到原因,最后一问才发现,运营商的问题,白忙活一场。所以第一个起手动作大家牢记,先去对接上游资源服务商,确认资源问题情况,沟通时,记得带上明确现象、话单数据:包括主被叫号码,时间等。然后催促尽快给予回复。
如果发生的外呼不通是全局性故障,反而是资源层出现问题的可能性小,一般不太可能出现这么大范围的资源商全体扑街型事件,如果一旦发生,那么对应的一定有什么重要的不可抗力的事情发生了,好好安抚客户,等待解决吧。
首先看监控:
现在是争分夺秒排查故障的时刻了,接下来我们还是按照自下而上的顺序,去检查。
如果是全局性的故障,那么接入层、服务层、支撑层、应用层的任一和外呼有关的组件,都需要检查对应的监控告警和日志信息。
这些都是问题的突破口。
内部如果有完善的告警信息,可以马上去定位当前时刻的告警组件、问题时间点内的告警信息,找到故障的“疑似”问题点。
注意我说的是“疑似”,这个时候还需要给出更多的证据来证明结论。
所需要的证据,就来自于日志系统:
马上去查看日志系统的详细内容,和有经验的运维工程师,研发工程师一起,根据日志,更根据历史经验去尽快排查问题。
各个服务的异常指征应该都详细记录并管理的,作为运营外呼系统的专业人员,这是一项基本的建设要求,如果没有监控系统,出现问题如盲人摸象。
找到故障对应的服务后,启动故障处理预案,该替换的替换,该启动备份的启动备份,然后观察系统运行情况确认是否操作有效。当然做故障恢复动作时,要明确对业务的影响,给到业务和客户方一个通知。
人为的原因?
当检查所有接入层、服务层均正常,资源层运营商也反馈无异常,那么先恭喜,至少没有系统问题和严重事件的发生。
接下来我们把目光要转向支撑层和应用层。
支撑层的常见问题:
支撑层一般是账户,计费、管理、接口类产品,这里产品基本由内部人员操作。可以首先检查有无最近的操作,本操作导致的结果。从而排查是否由人为误操作导致问题发生。
不开玩笑,随着系统的复杂度越来越高,一些内部人为操作,往往导致无法外呼的故障发生。比如某人员将客户的外显号码禁用,账户整体欠费,路由配置更改等操作。都有可能直接导致外呼失败故障。
接口服务的话,和用户接口使用的场景有很大关系,一般接口服务都有日志,对于外呼失败的情况,如果客户的外呼接口情况没有接收到。那么马上就去排查下客户方网络和服务商接入之间的连通性。如果接口服务已收到请求,并且被接口服务日志所记录,可检查其中的错误信息,这些错误信息,自带了问题的特征,比如引用了错误的外显号码,接口频次超过额定标准,这些证据都可以马上收集到并定位到原因。
呼叫风控服务的话,作为对外呼行为的风险控制关键组件,也是重点排查的对象,如果客户的外呼行为已经触发了呼叫行为风控机制,则会直接返回失败的信息给到用户,这里也会抛出具体的失败原因,所以用户告障时如果明确的告知是因为呼叫风控服务导致,那么可以一步到位找到问题。
如果不是的话,结合客户的风控规则来检查呼叫行为是否超过了默认的呼叫时段、频次、内容风险的控制。根据这些来寻找问题。
操作的问题?
支撑层检查也没发现问题,那么我们的排查要点就只能是应用层了。
我们要有办法还原用户使用外呼动作的现场。
这里面需要对自己的产品非常熟悉。知道客户的哪些操作,产品的哪些配置、可能导致外呼的失败。
那么针对具体客户的呼叫使用场景,我们可以通过跳入客户后台、和客户沟通使用场景,澄清问题现象,借助远程连线、检查通话记录,检查功能配置项的方式来逐一检查。如果一个正常使用的客户,突发性的出现了外呼不同现象,优先的检查近期的配置更新。是不是有什么操作变动。
导致外呼失败的情况会有很多,学会从通话记录中快速判断,可以少走很多弯路:
如果呼叫在座席侧失败,那么优先检查座席配置、话机和软电话设置、或者客户侧的网络环境等
如果呼叫座席侧正常接通,呼叫客户侧失败,检查外显号码配置,外呼任务配置等等。
出问题不用怕,不会查问题才拉胯。
出现问题、解决问题时需要有非常清晰的头脑,对产品的熟悉,以及对客户使用的深入了解。
不要乱,学会从整体到局部,从大到小的方式逐一摸排定位,并且快速的去调动资源协查。
相信经过多次问题的洗礼,你也可以成为系统运营管理的专家,也能发现产品中更多的改进项目,可以把产品打造的更加强壮。
本文作者 @通信产品的那些事 。
版权声明
本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!