故障排除工具和信息 - Amazon Connect
使用流 API 收集有用信息分析数据验证测试

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

故障排除工具和信息

以下工具和信息有助于解决 Amazon Connect 的问题。

  • 实例 ARN —在联系AWS支持人员时提供您的实例 ARN（亚马逊资源名称），以便他们可以看到您的 Amazon Connect 实例中的活动。您可以从 Amazon Connect 控制台中选择实例的别名，在您访问的概览页面上找到该实例的 ARN。

  • 通话录音 —非常有用，不仅可以说明和确定举报的行为，还可以排除代理方面的音频问题。在音频通过代理连接之前，Amazon Connect 中的录制是在交互的实例端完成的。由此，您能够确定音频问题是仅在通话的客服端存在，还是在客服收到的音频中存在。您可以在联系人搜索报告中找到与联系人关联的通话录音。

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

  • 代理桌面性能/进程日志 — 可以帮助排除本地资源/网络争用情况。

  • 联系人控制面板 (CCP) 日志 — 用于跟踪代理操作和时间。要下载 CCP 日志，在 CCP 中选择设置齿轮，然后选择 Download logs (下载日志)。日志会保存到浏览器的默认下载目录中。

  • 网络利用率记录/监控 — 专门针对与代理位于同一网段上的延迟和丢弃的数据包。

  • 私有 WAN/LAN 网络图 — 概述边缘路由器到 AWS 的连接路径，以解释网络遍历。

  • 防火墙允许访问列表-验证 IP/端口范围是否已添加到允许列表（也称为白名单），如中所述设置网络。

  • 音频采集和分析工具 — 用于在代理工作站计算延迟。

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

使用流 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:45 PM agentName LT2（三方通话中存在延迟，中等影响）。

  • 下午 6:05 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_latent] 是 Amazon Connect 终端节点和代理之间的延迟。可如下所示计算此延迟：[agent_latency] = [overall_latency] - [recording_latency]。通过在本地使用代理、避免使用AWS Direct Connect VPN 连接、提高私有 WAN/LAN 性能/耐久性或使用离代理更近的 Amazon Connect 区域位置，可以改善这种延迟。根据您的使用案例，选择不同的区域也可能增加 [pstn_latency]。

    Amazon ConnecCloudFront t 利用连接功能。并非所有 CloudFront 范围均通过 AWS Direct Connect 公告。这意味着并非所有由 Amazon Connect 生成的网址都可以通过公共虚拟接口访问。

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

  • [forward_latency] 是指将呼叫转接到或来自 Amazon Connect 的延迟。可以在进行转发时测量一次 [overall_latency]，再在不进行转发时测量一次，获得两者的差以计算该延迟。

测量延迟

除以下步骤外，请参阅 Amazon Connect 中的 “测量延迟以进行验证、测试和故障排除”）。

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

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

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

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

  • 复制业务的使用案例。如果客服使用会议和转接，请务必测试这些场景。如果发生循环转接（不建议这样做），也请务必测试这些场景。

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

测试延迟的要求

要有效地测试延迟，需要满足以下条件：

  • 启用通话录音以捕获 [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 和客服连接延迟。