外呼不通?如何排查

0 评论 4453 浏览 6 收藏 11 分钟

当你使用的外呼系统呼叫不通时,你知道该如何排查吗?本文保姆式教程手把手教你如何排查,并且从排查过程管中窥豹,了解外呼系统的工作原理和产品设计思路。一起来看看吧。

外呼不通时,不要慌张,首先你要对你的外呼系统的构造了如指掌,才可以顺藤摸瓜,找到问题所在。

了解外呼系统的架构:

不管外呼系统是什么样的:自己做的,外面买的。基本架构和原理都不会变,我给大家抽象出一个架构图:

外呼不通?如何排查

上图是基于软交换核心的外呼系统主要分层架构。

有类似产品的对号入座,如果是硬交换、本地化部署方式的服务层核心基本原理是一致的。

自下而上简单介绍下:

  • 资源层:各上游的通信资源服务商。
  • 接入层:对接通信资源的接入服务或者设备
  • 服务层:软交换的核心,云端部署软交换系统常常拆分为各种组件,集群化部署。
  • 支撑层:包括整个服务的计费支撑管理,服务的监控,接口服务及呼叫系统特有的呼叫风控服务。
  • 应用层:最上面是应用层,各种调用呼叫服务的产品和应用,比较常见的是人工外呼,自动外呼和AI外呼。

全局还是局部故障?

接下来我们就讲下外呼不通时,如何顺藤摸瓜,找到问题所在。

我们首先要做一个范围限定,外呼不通是个局部性事件,还是故障级别的全局情况?

如果是小范围内独立事件,那么重点去观察范围内的独特特征,比如业务的通信资源、产品功能配置、应用状态等。

确认是局部问题后,至少心态不会那么炸裂,接下来去认真分析具体日志,使用情况去定位分析测试。

如果是后者?那意味着出现了比较严重的情况,需要你争分夺秒,尽快定位问题并给出解决方案。

从哪里开始优先排查:

如果是局部性的外呼不通情况发生,我建议优先去资源层,问下资源供应商有无问题。

有人说,为什么?产品是我们自己的,我们自己去查岂不是最方便了?

说的没错,但恰恰因为资源层是不受你管理的“黑盒子”,才需要马上去沟通对接,同时开始自己的排查,否则查来查去,找不到原因,最后一问才发现,运营商的问题,白忙活一场。所以第一个起手动作大家牢记,先去对接上游资源服务商,确认资源问题情况,沟通时,记得带上明确现象、话单数据:包括主被叫号码,时间等。然后催促尽快给予回复。

如果发生的外呼不通是全局性故障,反而是资源层出现问题的可能性小,一般不太可能出现这么大范围的资源商全体扑街型事件,如果一旦发生,那么对应的一定有什么重要的不可抗力的事情发生了,好好安抚客户,等待解决吧。

首先看监控:

现在是争分夺秒排查故障的时刻了,接下来我们还是按照自下而上的顺序,去检查。

如果是全局性的故障,那么接入层、服务层、支撑层、应用层的任一和外呼有关的组件,都需要检查对应的监控告警和日志信息。

这些都是问题的突破口。

内部如果有完善的告警信息,可以马上去定位当前时刻的告警组件、问题时间点内的告警信息,找到故障的“疑似”问题点。

注意我说的是“疑似”,这个时候还需要给出更多的证据来证明结论。

所需要的证据,就来自于日志系统:

马上去查看日志系统的详细内容,和有经验的运维工程师,研发工程师一起,根据日志,更根据历史经验去尽快排查问题。

各个服务的异常指征应该都详细记录并管理的,作为运营外呼系统的专业人员,这是一项基本的建设要求,如果没有监控系统,出现问题如盲人摸象。

找到故障对应的服务后,启动故障处理预案,该替换的替换,该启动备份的启动备份,然后观察系统运行情况确认是否操作有效。当然做故障恢复动作时,要明确对业务的影响,给到业务和客户方一个通知。

人为的原因?

当检查所有接入层、服务层均正常,资源层运营商也反馈无异常,那么先恭喜,至少没有系统问题和严重事件的发生。

接下来我们把目光要转向支撑层和应用层。

支撑层的常见问题:

支撑层一般是账户,计费、管理、接口类产品,这里产品基本由内部人员操作。可以首先检查有无最近的操作,本操作导致的结果。从而排查是否由人为误操作导致问题发生。

不开玩笑,随着系统的复杂度越来越高,一些内部人为操作,往往导致无法外呼的故障发生。比如某人员将客户的外显号码禁用,账户整体欠费,路由配置更改等操作。都有可能直接导致外呼失败故障。

接口服务的话,和用户接口使用的场景有很大关系,一般接口服务都有日志,对于外呼失败的情况,如果客户的外呼接口情况没有接收到。那么马上就去排查下客户方网络和服务商接入之间的连通性。如果接口服务已收到请求,并且被接口服务日志所记录,可检查其中的错误信息,这些错误信息,自带了问题的特征,比如引用了错误的外显号码,接口频次超过额定标准,这些证据都可以马上收集到并定位到原因。

呼叫风控服务的话,作为对外呼行为的风险控制关键组件,也是重点排查的对象,如果客户的外呼行为已经触发了呼叫行为风控机制,则会直接返回失败的信息给到用户,这里也会抛出具体的失败原因,所以用户告障时如果明确的告知是因为呼叫风控服务导致,那么可以一步到位找到问题。

如果不是的话,结合客户的风控规则来检查呼叫行为是否超过了默认的呼叫时段、频次、内容风险的控制。根据这些来寻找问题。

操作的问题?

支撑层检查也没发现问题,那么我们的排查要点就只能是应用层了。

我们要有办法还原用户使用外呼动作的现场。

这里面需要对自己的产品非常熟悉。知道客户的哪些操作,产品的哪些配置、可能导致外呼的失败。

那么针对具体客户的呼叫使用场景,我们可以通过跳入客户后台、和客户沟通使用场景,澄清问题现象,借助远程连线、检查通话记录,检查功能配置项的方式来逐一检查。如果一个正常使用的客户,突发性的出现了外呼不同现象,优先的检查近期的配置更新。是不是有什么操作变动。

导致外呼失败的情况会有很多,学会从通话记录中快速判断,可以少走很多弯路:

如果呼叫在座席侧失败,那么优先检查座席配置、话机和软电话设置、或者客户侧的网络环境等

如果呼叫座席侧正常接通,呼叫客户侧失败,检查外显号码配置,外呼任务配置等等。

出问题不用怕,不会查问题才拉胯。

出现问题、解决问题时需要有非常清晰的头脑,对产品的熟悉,以及对客户使用的深入了解。

不要乱,学会从整体到局部,从大到小的方式逐一摸排定位,并且快速的去调动资源协查。

相信经过多次问题的洗礼,你也可以成为系统运营管理的专家,也能发现产品中更多的改进项目,可以把产品打造的更加强壮。

本文由 @通信产品的那些事 原创发布于人人都是产品经理,未经作者许可,禁止转载。

题图来自Unsplash,基于CC0协议。

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!