外呼不通？如何排查 | 人人都是产品经理

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

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

了解外呼系统的架构：

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

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

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

自下而上简单介绍下：

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

全局还是局部故障？

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

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

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

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

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

从哪里开始优先排查：

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

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

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

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

首先看监控：

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

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

这些都是问题的突破口。

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

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

所需要的证据，就来自于日志系统：

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

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

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

人为的原因？

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

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

支撑层的常见问题：

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

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

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

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

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

操作的问题？

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

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

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

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

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

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

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

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

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