故障排除工具和信息 - Amazon Connect

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

故障排除工具和信息

以下工具和信息可帮助排除 Amazon Connect 的问题。

  • 实例 ARN - 与 AWS Support 联系时提供您的实例 ARN(亚马逊实例名称),以便他们可以查看您的 Amazon Connect 实例中的活动。您可以在 Amazon Connect 控制台中选择实例的别名,然后在“概述”页面上找到您实例的 ARN。

  • 通话录音 - 这非常有用,不仅可展示并确定报告的行为,还可以排除座席端的音频问题。Amazon Connect 中的录音在对话的实例端完成,在这之前,音频会遍历座席的连接。由此,您能够确定音频问题是仅在通话的座席端存在,还是在座席收到的音频中存在。您可以在联系搜索报告中找到与联系人关联的通话录音。

  • 联系记录中的联系人 ID - 在联系 AWS 支持时提供。

  • 座席桌面性能/处理日志 - 可帮助排除本地资源/网络争用。

  • 联系人控制面板 (CCP) 日志 - 用于跟踪座席操作和计时。要下载 CCP 日志,在 CCP 中选择设置齿轮,然后选择下载日志。日志会保存到浏览器的默认下载目录中。

  • 网络使用率日志记录/监控 - 专用于与座席位于同一网络分段中时的延迟和丢包。

  • 私有 WAN/LAN 网络图 - 概述边缘路由器到 AWS 的连接路径以说明网络遍历。

  • 防火墙允许列表访问 - 用于验证该 IP/端口范围已添加到允许列表中,如 设置网络 中所述。

  • 音频捕获和分析工具 - 在座席的工作站上计算延迟。

  • AWS 区域延迟测试工具 - 使用端点测试实用程序工具

使用 Streams API 收集有用信息

如果希望全面地跟踪并排除问题,建议收集有关整体通话质量的数据。无论在何时遇到通话质量差的问题,座席都可以使用下表中所示的处置项表,记录当前时间和对应的处置代码。您也可以使用 Streams API 将您自己的报告和问题功能纳入自定义的 CCP 中,将这些处置连同对应的呼叫信息写入 Amazon DynamoDB 等数据库。有关 Amazon Connect Streams API 的更多信息,请访问 GitHub存储库,网址为 https://github.com/aws/ amazon-connect-streams

座席问题报告处置示例

以下示例中的处置项按症状、场景和严重性列出。

症状
  • S - 软电话错误

  • M - 错过的呼叫

  • L - 延迟导致质量差

  • P - 开始时正常,一段时间后逐渐变差

  • D - 断开的呼叫

  • W - 单向音频;例如,座席可听见客户说话,但客户听不到座席说话

  • V - 音量太低或太高

  • C - 断断续续/间歇中断

场景
  • O - 出站呼叫

  • I - 入站呼叫

  • T - 三方通话

严重性
  • 1 - 影响不明显,但可以有效地使用 CCP

  • 2 - 中等影响,难以交流,但仍然可以进行通话

  • 3 - 严重影响,不能使用 CCP 进行通话

示例
  • 5:45PM agentName LT2(三方通话中存在延迟,中等影响)。

  • 6:05PM agentName DO3(因严重影响导致出站呼叫断开连接)。

  • 6:34PM agentName MI3(因严重影响错过入站呼叫)。

分析数据

下列准则可帮助您分析数据以确保您的环境中存在的问题。

  • 使用联系记录 / 联系人搜索报告,来识别发生呼叫质量问题期间的联系人的联系人 ID。联系记录包括一个指向关联通话录音的链接,还提供其他详细信息,供您用于确认症状以提供给您的 AWS 支持代表。

  • 使用座席名称和联系记录中的时间戳,根据座席、症状、场景和一段时间后的严重程度确定您遇到的问题的类型和比例。由此可以了解问题是在相同时间发生、因特定事件发生还是仅与特定座席或座席操作相关。另外,如果您需要向支持人员求助,您可以轻松地找出并访问相关通话录音和关联的联系人 ID。

  • 将数据源,例如客户端工作站上的操作系统中的本地网络日志、CPU/磁盘/内存利用率和进程监控日志关联起来。由此可以按座席将一段时间的事件相关联,以排除本地资源争用的原因或因素。

  • 根据每分钟或每小时报告的症状或场景分析数据,按类型和严重性为一段时间内一位座席的问题创建热图。这样做对于排除环境故障特别有用,因为您会发现因安排备份或大型文件传输等活动而导致的综合影响。

  • 如果您找不到任何本地资源争用的证据或得出任何值得注意的相关性,可以使用收集到的联系人 ID 打开一个支持案例。如果遇到的问题是间歇性的,则它们很可能与座席的工作站和/或网络连接的问题有关。

验证测试

语音质量问题可能是多个原因造成的。务必运行受控测试,并监控与报告问题的环境或工作站相同的环境或工作站,从而再现相同的使用案例。请考虑以下一般性测试建议,测量并收集数据以调查语音质量问题。

PSTN 和座席连接延迟

要排除交叉干扰的故障,您需要区分并测量座席和原始 PSTN 延迟的影响,因为它们需要不同的补救措施。

  • [overall_latency] 是呼叫方和座席之间经历的总延迟。可如下所示计算此延迟:[overall_latency] = [agent_latency] + [pstn_latency]。

  • [pstn_latency] 是 Amazon Connect 端点与呼叫方之间的延迟。可如下所示计算此延迟:[pstn_latency] = [overall_latency] - [agent_connection_latency]。可以通过使用不同的 Amazon Connect 区域位置或避免与地理位置较远的端点位置进行外部转接和循环转接来缩短该延迟。

  • [agent_latency] 是 Amazon Connect 端点与座席之间的延迟。可如下所示计算此延迟:[agent_latency] = [overall_latency] - [recording_latency]。可以通过为本地座席使用 AWS Direct Connect、避免使用 VPN 连接、提高专有 WAN/LAN 性能/持久性或使用与您的座席更接近的 Amazon Connect 区域位置来缩短该延迟。根据您的使用案例,选择不同的区域也可能增加 [pstn_latency]。

    Amazon Connect 利用连接功能 CloudFront 。并非所有 CloudFront 范围都进行了AWS Direct Connect广告宣传。这意味着并非 Amazon Connect 生成的所有 URL 均可通过共有虚拟接口访问。

  • [redirect_latency] 是将音频重定向到外部设备导致的延迟。可以在进行重定向时测量一次 [overall_latency],再在不进行重定向时测量一次,获得两者的差以计算该延迟。

  • [forward_latency] 是将呼叫转发到 Amazon Connect 或从中转发呼叫导致的延迟。可以在进行转发时测量一次 [overall_latency],再在不进行转发时测量一次,获得两者的差以计算该延迟。

测量延迟

  • 再现您的使用案例。需要测量所有偏差并将它们考虑在内,因为它们会导致测试结果偏移。

  • 尽可能匹配工作控制和环境。使用相同的流程、电话号码和端点位置。

  • 记录呼叫方的地理位置、座席和外部转接目标(如果适用)。如果您要为多个国家/地区提供服务,应单独测试每个国家/地区,以提供您的座席在工作时遇到的相同测试范围。

  • 记录在测试过程中使用的移动线路和地下线路。移动网络会增加延迟,需要进行测量并为客户、座席和转接端点(如果适用)考虑在内。

  • 复制业务的使用案例。如果座席使用会议和转接,请务必测试这些场景。如果发生循环转接(不建议这样做),也请务必测试这些场景。

  • 包括位于同一网络分段的工作站环境并使用您的座席将使用的设备,来再现座席的环境。

测试延迟的要求

要有效地测试延迟,需要满足以下条件:

  • 启用通话录音以捕获 [agent_latency]。如果没有通话录音,只能计算 [overall_latency]。

  • 客户的电话来源。进行测试时,确认与客户的实际通话的通话质量。

  • 座席的电话,如果将音频重定向到外部设备。您必须能够录制此设备的输入和输出。

  • 第三方转接端点(如果适用)。最好对实际通话或在从第三方转接时进行测试。

  • 已安装录音或分析软件的座席工作站。

  • 可再现的使用案例。如果不能再现问题,故障排除可能非常困难。

  • NTP 或同步时间戳的其他方法有助于识别特定的联系人和出现问题的时间,尤其是在活动跨多个时区进行的情况下。

使用软件电话测试入站呼叫

此进程让您能够在大约 15 秒内完成延迟测试场景。每个录音大约需要 1-2 分钟来分析结果和标记时间戳。

  1. 在安静位置进行。

  2. 将座席工作站配置为通过外部扬声器播放音频,并确保打开扬声器。

  3. 使用座席工作站登录到 CCP。

  4. 开始使用座席工作站上的音频捕获工具进行录音。

  5. 从客户的电话来源使用扬声器电话拨打您的 Amazon Connect 实例的呼入号码。实际上,这可以是能够模拟客户呼叫的任意外部电话来源。

  6. 使用座席工作站上的软件电话应答入站呼叫。

  7. 确保客户电话未静音。

  8. 在客户端使用一个物体或用手用力敲桌面或台面,然后立即将客户电话静音。

  9. 等待 3 秒或更长时间。重复步骤 7-8 至少 3 次。

  10. 在座席工作站上停止录音。

  11. 在您的音频分析工具中打开录音。您应该能够同时听到您最初敲桌面发出的声音,以及另一端的座席线路中的敲击声音。获得 [overall_latency] 的三个增量和平均值。

  12. 也可以在您的音频分析工具中打开关联的 Amazon Connect 通话录音,来计算 [agent_latency]。您应该能够同时听到最初的敲击声音,以及到达另一端的座席的敲击声音。获得 [recording_latency] 的三个增量和平均值。[agent_latency] = [overall_latency] - [recording_latency]。根据需要重复上述步骤。

必要时修改测试计划,以适合您的使用案例。当步骤发生变化时,录音和分析音频的过程是相同的。如果您需要测试会议和转接,正常进行测量,然后在会议进行过程中,在第三方转接端点获得另一个测量值。

解释测试结果

增加 [overall_latency] 的影响在大约 300ms 时变得明显,并在 500ms 以后造成交叉干扰。被视为可接受的影响和延迟程度取决于您的使用案例。有关可缩短延迟的建议补救措施,请参见 PSTN 和座席连接延迟