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

# Amazon Connect 工作负载的卓越运营
<a name="operational-excellence"></a>

卓越运营包括运行和监控系统以交付商业价值和持续改善支持流程和程序的能力。本部分包含设计原则、最佳实践以及围绕 Amazon Connect 工作负载卓越运营的问题。

## 准备
<a name="prepare"></a>

要为 Amazon Connect 工作负载做准备，请考虑以下几个方面。

### AWS 账户
<a name="awsaccount"></a>

使用 AWS Organizations，您可以为开发、暂存和质量保证环境的每个级别设置多个 AWS 帐户。这样，当您在 AWS上增长和扩展工作负载时，就可以集中管理您的环境。无论您是成长中的初创公司还是大型企业，Organizations 都能帮助您集中管理账单；控制访问权限、合规性和安全；并在您的 AWS 账户之间共享资源。这是消费 AWS 服务和云采用框架的起点。

### 区域选择
<a name="regionselection"></a>

Amazon Connect 区域选择取决于数据监管要求、使用案例、每个区域的可用服务、每个区域的电话成本，以及与您的座席、联系人和外部转接端点的地理位置相关的延迟。

### 通话
<a name="telephony-bp"></a>
+ **电话号码转网** 尽可能在待定上线日期之前提交携号转网请求。

  在为关键工作负载移植电话号码时，请在上线日期前几个月将所有要求和用例信息包含在您的 claim/port 号码中。这包括对实时割接支持的请求，割接之前、期间和之后的通信、监控全球，以及任何特定于您的使用案例的其他请求。

  有关转网号码的详细信息，请参阅[将当前的电话号码转网到 Amazon Connect](port-phone-number.md)。
+ **运营商多元化** 在美国，您应该使用 Amazon Connect 电话服务获得美国免费号码，这样您就能够以双活的方式在多个供应商之间路由免费流量，而没有额外费用。如果您要将入站流量转发到 Amazon Connect 电话号码，则应在多个电话提供商之间请求冗余的 DID 或免费电话号码。如果您要在美国境外申请或转网多个 DID 或免费电话号码，则应请求将这些号码申请或转网到各种电话提供商，以提高弹性。
+ **国际免费电话和高并发性 DIDs**如果您使用现有的免费全国电话服务将入站流量重定向到 DIDs，则应在多个电话提供商之间申请 DID 电话号码。此配置的常规建议是每个 DID 100 个会话，您的 AWS 解决方案架构师可以帮助进行容量计算和设置。
+ **测试** 彻底测试所有使用案例场景，最好使用与您的座席和客户相同或相似的环境。确保测试多个入站和出站场景的体验质量、呼叫方 ID 功能，并测量延迟，以确保延迟在您的使用案例可接受的范围内。与目标座席和客户环境的任何偏差都需要进行测量和考虑在内。有关更多信息（包括使用案例测试说明和标准），请参阅[排查联系人控制面板 (CCP) 问题](troubleshooting.md)。

### 座席工作站
<a name="agent-ws"></a>

Amazon Connect 呼叫控制面板 (CCP) 具有特定的网络和硬件要求，必须满足这些要求才能确保为您的座席和联系人提供最高质量的服务：
+ 针对 CCP 使用来设置您的网络，并确保您的座席硬件满足最低要求。
+ 确保您已在与座席相同的网络分段上使用了 Amazon Connect Check Amazon 连接工具，以验证是否已针对 CCP 使用正确配置了您的网络和环境。
+ 计算要求座席和联系人位于地理上偏远的位置的使用案例的 PSTN 延迟
+ 查看[排查联系人控制面板 (CCP) 问题](troubleshooting.md)部分以创建运行手册和行动手册，以供您的座席和主管在遇到问题时遵循。
+ 为您的座席工作站设置监控，并考虑采用合作伙伴解决方案来监控通话质量。您监控座席工作站的目标应该是，能够识别任何潜在网络和资源争用的根源。例如，考虑典型座席指向 Amazon Connect 的软电话网络连接路径：  
![\[座席工作站监控。\]](http://docs.aws.amazon.com/zh_cn/connect/latest/adminguide/images/architecture/agentworkstation-oe.png)

  如果不在本地 LAN/WAN、路径和座席工作站级别设置监控，就很难而且通常不可能确定语音质量问题是否源于您的代理的工作站、他们的专用 LAN/WAN AWS、ISP 或联系人本身。 AWS主动设置日志记录和警报机制对于确定根本原因和优化语音质量环境具有至关重要的意义。

### 配置您的现有目录
<a name="configure-directory"></a>

如果您已经在使用 Directory Service 目录来管理用户，则可以使用同一个目录来管理 Amazon Connect 中的用户账户。这必须在创建 Amazon Connect 实例时确定和配置。在创建实例后，您不能更改您选择的身份选项。例如，如果您决定更改所选目录以便为实例启用单点登录 (SSO)，则可以删除该实例并创建一个新实例。删除实例后，将失去该实例的所有配置设置和指标数据。

### 服务配额
<a name="service-quotas-bp"></a>

查看您的工作负载中涉及的每项服务的默认服务限额以及 Amazon Connect 的默认服务限额，并在适用时请求增加服务限额。当请求增加 Amazon Connect 的服务限额时，请务必使用预期值，而不针对波动使用额外的填充。当您提出请求时，系统会自动考虑波动。

### AWS 企业支持
<a name="enterprise-support-bp"></a>

AWS 建议将 Enterprise Support 用于上的业务 and/or 关键型工作负载。 AWS企业支持和 AWS 解决方案架构师的架构完善的审查都需要符合 Amazon Connect 服务等级协议的资格。

### AWS 精心设计的评论
<a name="well-architected-review-bp"></a>

在迁移或实施到 Amazon Connect 之前，请使用 Well-Architecte AWS d 框架 “卓越运营”，遵循我们的最佳实践。该框架为您提供了一种一致的方法来评估架构和实施设计，这些设计基于五大支柱（卓越运营、安全性、可靠性、性能效率和成本优化），将会随时间推移而扩展。我们还建议将 E AWS nterprise Support 用于中的业务和任务关键型工作负载。 AWS企业支持和解决方案架构师的 Well-Architected 审核都必须符合获得 Amazon Connect 服务等级协议的资格。 AWS 

## 运营
<a name="operate-bp"></a>

要运行 Amazon Connect 工作负载，请考虑以下几个方面。

### 日志记录和监控
<a name="logging-monitoring-bp"></a>

请参阅[使用监控您的 Amazon Connect 实例 CloudWatch](monitoring-cloudwatch.md)和[使用记录 Amazon Connect API 调用 AWS CloudTrail](logging-using-cloudtrail.md)。

### 联系属性
<a name="contactattributes-bp"></a>

Amazon Connect 允许您在流程中动态设置和引用联系人属性，为您的联系人创建动态和个性化的体验，创建强大的数据驱动型自助服务应用程序 IVRs，与其他 AWS 服务集成，简化电话号码管理，并允许自定义实时和历史报告和分析。以下是您可以遵循的最佳做法和注意事项，以降低复杂性、防止数据丢失并确保联系人获得一致的体验质量。

请注意以下注意事项：
+ 数据大小 – 为阻止截断，您可以在“设置联系属性”数据块中设置的联系属性的大小限制会因字符集、编码和使用的语言不同而异。虽然这些数据通常足以为联系人播放一个短篇故事，但也有可能超过这一限制，截断超过 32KB 的任何属性集。
+ 数据敏感度 – 请注意所设置、查询和引用的任何属性是否为敏感属性或属于任何监管准则的范围，并确保针对您的使用案例对数据进行适当处理。
+ 数据持久性 – 使用“设置联系属性”数据块设置的任何属性都将包含在联系人的联系记录中，并可用于使用 Streams API 向任何自定义座席桌面弹出屏幕。每当您的流程中引用该属性并启用流程日志记录时，该属性的名称和值都将记录到 Amazon CloudWatch。

**最佳实践**
+ 监控使用情况 – 在实施新功能、加入新业务部门和迭代现有流时，请在联系人搜索中查找当前的属性使用情况，将属性复制到文本编辑器，添加新属性，并确保不超过 32KB 的大小限制。请务必考虑可变长度字段，例如 firstName 和 lastName，并确保即使字段中使用了最大空间，也要仍低于 32KB 的限制。
+ 清理 – 如果不需要数据持久性，则可以设置具有相同名称和空值的属性，以防止数据存储到联系记录中或使用 [Amazon Connect Streams](https://github.com/aws/amazon-connect-streams) API 在屏幕弹出窗口中传递给座席，同时释放数据本应在联系记录中使用的字节。
+ 敏感数据 – 使用**存储客户输入**数据块从联系人那里收集敏感的 DTMF 输入，并使用信封加密来保护原始数据和用于加密这些数据的数据密钥。将敏感数据存储在需要持久性的单独数据库中，使用**设置日志记录行为**流数据块在每次引用敏感信息时禁用日志记录，并使用前面概述的**设置联系属性**数据块清理方法删除、清理或模糊处理敏感数据。有关更多信息，请参阅 [Amazon Connect 中的合规性验证](compliance-validation.md)。

### 通话
<a name="telephony-bp"></a>

在美国，请尽可能使用免费电话号码在多个运营商之间进行负载均衡，以获得额外的路线和运营商冗余。与必须由单个运营商管理的 DID 电话号码相比，这样也有助于缩短解决时间。在您使用的情况下 DIDs，尽可能在来自多个运营商的号码之间进行负载平衡，以提高可靠性。确保正确处理流中的所有错误路径，并实施[排查联系人控制面板 (CCP) 问题](troubleshooting.md)中提供的最佳实践、要求和建议。

如果您要将现有电话提供商的电话号码转发到 Amazon Connect，请确保您的运营团队定义并充分理解将转发目标更改为备用 DID/免费电话号码或以其他方式删除转发的流程。确保您拥有专门用于生产就绪性评估、电话号码转网和转发过程以及排查从现有电话提供商转接电话时可能出现的音频问题的运行手册和行动手册。您还需要一个可重复的流程，您的运营团队可以按照该流程来确定这些音频问题的根源是 Amazon Connect 还是您现有的电话提供商。

### Amazon Connect APIs
<a name="apis-bp"></a>

Amazon Connect 限制限额是按账户设置的，而不是按实例设置的。在使用 Amazon Connect 时，您应该考虑以下最佳实践 APIs：

#### 实施 caching/queuing 解决方案
<a name="queuingsolution"></a>

为了降低 API 数据查询开销并避免限制，您可以使用像 Amazon DynamoDB 这样的中间数据库来存储 API 调用结果，而不是从对 API 数据感兴趣的所有端点调用 API。例如，下图表示从需要使用此信息的多个源使用 Amazon Connect 指标 API：

![\[实施缓存和队列解决方案。\]](http://docs.aws.amazon.com/zh_cn/connect/latest/adminguide/images/architecture/amazonconnectapis-oe.png)


您可以让一个 AWS Lambda 函数将所有感兴趣的数据写入 Amazon DynamoDB，而不必使用单独的函数，每个 AWS Lambda 函数都有自己的轮询要求。它们不是让每个端点直接转到 API 来检索数据，而是指向 DynamoDB，如下图所示：

![\[此图显示了端点指向 DynamoDB 而不是从 API 检索数据。\]](http://docs.aws.amazon.com/zh_cn/connect/latest/adminguide/images/architecture/amazonconnectapis2-oe.png)


此架构允许您根据需要更改轮询间隔并添加端点，而不必担心超出服务限额，从而使您能够扩展到数据库解决方案支持的任意数量的并发连接。您可以使用这一相同的概念来查询来自 Amazon Connect 的任何实时数据源。对于需要执行 API 操作（例如出站 API 调用）的情况，您可以将相同的概念与 Amazon Simple Queue Service 结合使用，将 API 请求 AWS Lambda 与 SQS 结合使用来排队 API 请求。

#### 指数回退和重试策略
<a name="retrystrategies"></a>

您可能会遇到超出 API 节流限制的情况。当 API 调用失败，在没有实施缓存或队列解决方案的情况下，重复重试 API 调用或直接从多个并发端点进行 API 调用时，可能会发生这种情况。为避免超出服务配额并影响下游进程，应考虑在 AWS Lambda 函数中使用指数级退出和重试策略，同时使用缓存和队列。

### 变更管理
<a name="changemanagement"></a>

将工作负载迁移到 Amazon Connect 的两个主要驱动因素是灵活性和上市速度。为了在不牺牲敏捷性的前提下确保卓越运营，请遵循以下最佳实践：
+ **模块化流**：Amazon Connect 中的流与现代应用程序构建类似，在此情况下，与单体式替代方案相比，较小的专用组件具有更大的灵活性、控制性和易管理性。您可以通过**转移到流程块将模块化流程组合成一种 end-to-end体验，从而使您的流程**变得小巧且可重复使用。这种方法允许您在变更实施期间降低风险，允许您测试单个较小的更改，而不是对整个体验进行回归测试，并且可以更轻松地在测试期间识别和解决流中的问题。
+ **存储库**：在更改管理流程中，使用联系流导入/导出将所有流的所有版本备份到您所选择的存储库中。
+ **按百分比分配**：为了降低更改管理过程中遇到的风险，并为您的联系人尝试新的体验，您可以使用**按百分比分配**数据块将一部分流量路由到新的流，同时将其他流量留在原始体验上。
+ **衡量结果**：数据驱动型决策是成功推动业务实现有意义变革的关键。用一个关键指标来衡量您的更改是绝对必要的。对于您所做的所有更改，您需要计划如何衡量成功。例如，如果您正在对联系人实施自助服务功能，那么您希望自助服务的联系人中有多少百分比的联系人认为工作负载成功，或者您正在衡量哪些其他指标来确定成功？ 
+ **回滚**：确保有一个清晰、明确定义且易于理解的流程来将任何更改退回到先前的状态，具体取决于所执行的更改。例如，如果您发布新的流版本，请确保更改说明中包含有关如何回滚到流的早期版本的文档。

### 路由配置文件
<a name="routingprofiles"></a>

了解优先级、延迟和溢出路由在 Amazon Connect 中的工作原理，对于最大限度地提高座席的工作效率、减少联系人等待时间和确保联系人获得最佳体验质量具有至关重要的意义。

### 在 Amazon Connect 中路由
<a name="routing-bp"></a>

联系人在 Amazon Connect 中路由是通过一组队列和路由配置（称为路由配置文件）完成的。队列等同于座席为该队列的联系人提供服务所需掌握的技能或熟练程度。路由配置文件可以被视为一组技能，您可以将其与联系人的需求相匹配

在您的流中，您可以提示提供其他信息，如果这些信息需要到达座席，您可以使用流配置将它们放置在适当的队列中。在以下示例中，“储蓄”、“支票”和“贷款”是单独的队列或技能，三个路由配置文件是唯一的技能集或技能组：

![\[按队列组进行路由。\]](http://docs.aws.amazon.com/zh_cn/connect/latest/adminguide/images/architecture/routingprofile1.png)


每个座席根据其技能集仅分配到一个路由配置文件，并且具有相似技能集的许多座席可以共享相同的路由配置文件：

![\[按技能集进行路由。\]](http://docs.aws.amazon.com/zh_cn/connect/latest/adminguide/images/architecture/routingprofile2.png)


每个电话号码或聊天端点将与一个流相关联。该流会执行其逻辑，其中可能包括提示客户提供信息，以确定联系人的需求，并最终将联系人路由到适当的队列中。下图描述了路由配置文件、队列和流如何协同工作为联系人提供服务：

![\[路由图显示了路由配置文件、队列和流如何共同为联系人提供服务。\]](http://docs.aws.amazon.com/zh_cn/connect/latest/adminguide/images/architecture/routingprofile3.png)


为了说明如何可以确定各种队列、路由配置文件和路由配置文件的座席分配，请考虑下表：

![\[按队列组进行路由。\]](http://docs.aws.amazon.com/zh_cn/connect/latest/adminguide/images/architecture/routingprofile4.png)


在第一行，您已经确定了自己的技能或队列。在左列中，您有座席列表，在中间，您已经检查了每个座席支持的技能。您可以对矩阵进行排序，该矩阵按我们座席群体中的一组常见技能要求进行分组。这样有助于将路由配置文件识别为绿色框中标记的一个路由配置文件（由两个队列组成），您可以为其分配座席。通过该练习，您已经确定了四个路由配置文件，并相应地为它们分配了 13 个座席。

根据上表，来自需要储蓄技能的联系人的传入呼叫可以由三个路由配置文件 1、2 和 4 中的三组座席接听，如下图所示：

![\[按队列组进行路由。\]](http://docs.aws.amazon.com/zh_cn/connect/latest/adminguide/images/architecture/routingprofile5.png)


### 优先级和延迟
<a name="prioritydelay-bp"></a>

在不同的路由配置文件中结合使用优先级和延迟，您可以创建灵活的路由策略。

![\[此图显示了路由配置文件中用于创建路由策略的优先级和延迟。\]](http://docs.aws.amazon.com/zh_cn/connect/latest/adminguide/images/architecture/priorityandelay.png)


上述路由配置文件示例显示了一组队列，以及它们各自的优先级和延迟。数字越小，优先级越高。必须先处理所有优先级较高的呼叫，然后才能处理优先级较低的呼叫。这与最终会根据加权系数处理优先级较低的呼叫的系统有所不同。

您还可以为每个路由配置文件中的每个队列添加延迟。任何进入队列的呼叫都将在分配给指定队列的指定延迟期内处于接听状态。即使座席有空，呼叫也将在延迟期内处于接听状态。如果您有一组代理负责帮助您满足服务级别协议（SLAs），但被分配到其他任务或队列中，则可以使用此功能。如果呼叫在指定时间段内没有得到应答，则这些座席将有资格接听来自指定队列的呼叫。例如，考虑以下图表：

![\[此图显示了 Savings 队列将通话路由至可用座席。\]](http://docs.aws.amazon.com/zh_cn/connect/latest/adminguide/images/architecture/priorityandelay2.png)


此图显示了 30 秒的 SLA。储蓄队列中有呼叫拨打进来。由于队列的配置文件中配置了 0 延迟，因此储蓄队列会立即在“储蓄”路由配置文件中查找座席。由于高级座席配置了 15 秒延迟，因此他们在 15 秒内将没有资格接听储蓄联系人。15 秒后，高级座席可接听联系人，Amazon Connect 会在两个路由配置文件中查找空闲时间最长的座席。

### 提供服务的途径
<a name="pathtoservice-bp"></a>

当您在 Amazon Connect 中设计客户体验时，请进行计划以确保提供服务的途径。有许多计划内和计划外事件可能会影响客户在遍历 Amazon Connect 流时的体验。以下示例客户体验显示了一些建议的检查，以确保联系人获得一致的质量体验：

![\[此图显示了应对可能影响客户服务的意外事件的服务路径。\]](http://docs.aws.amazon.com/zh_cn/connect/latest/adminguide/images/architecture/pathtoservice.png)


此示例客户体验将计划内事件（如节假日和营业时间）以及计划外事件（如在工作时间内未配备座席）考虑在内。有了这个逻辑，您还可以考虑紧急情况，例如由于恶劣天气或服务中断而导致的联络中心关闭。请考虑下图所示的以下概念：
+ **自助服务**：在典型的 IVR 中，您可以预先包含任何问候语和免责声明消息，例如通话录音公告，然后可以选择自助服务选项。自助服务可优化您的联络中心的成本和绩效，使您的组织能够全天候为客户提供服务，无论节假日、工作时间或座席空闲时间如何均可。请始终包含服务途径，以防客户无法进行自助服务并需要人工帮助。例如，如果您使用 Amazon Lex 机器人进行自助服务，则可以利用回退意图升级对话以获得人工帮助。
+ **节假日**：许多企业客户都有一个用于存放公司假日的中央存储库。您可以使用 AWS Lambda 函数对该存储库进行数据提取并为客户提供假日待遇。此外，您还可以在 DynamoDB 中存储公司节假日以及每个假期的自定义消息。例如，如果您的企业将 12 月 25 日定为圣诞节，则可能会有节假日提示或文本到语音转换：“我们目前因圣诞节而关闭。请于 12 月 26 日回电，届时我们的正常工作时间将恢复。”  
![\[该图显示了 Amazon Connect 如何使用 AWS Lambda 和 DynamoDB 向客户播放消息。\]](http://docs.aws.amazon.com/zh_cn/connect/latest/adminguide/images/architecture/holidays.png)
+ **工作时间**：节假日通过验证后，您可以查看工作时间，如果在工作时间之外，则可以动态更改联系人的体验。如果联系发生在工作时间内，则可以识别客户的呼叫意图并映射到联络中心的某些队列，从而增加找到正确座席的可能性，并缩短联系人访问服务所需的时间。强烈建议您映射默认值，因为客户可能出于您尚未说明的原因致电，或者可能以您意想不到的方式回复。
+ **紧急消息**：确定客户的呼叫意图后，建议实施紧急检查处理。如果出现影响联络中心的紧急情况，您可以在 DynamoDB 等中间数据库中存储紧急 True/False 标志。要允许您的主管和管理员在不使用代码的情况下动态设置此标志，您可以构建一个单独的 IVR，该 IVR 根据 ANI 和 PIN 号码验证对您的 Amazon Connect 管理员进行身份验证，以仅供内部使用。在紧急情况下，您的主管可以通过电话呼叫该专线，在进行身份验证后，将紧急标志设置为 true，以应对因恶劣天气导致联络中心关闭或联络中心实际位置的 ISP 中断等情况。
+ **紧急消息 API**：您也可以考虑在后端构建一个 AWS API 网关，以便在数据库中 true/false 安全地设置紧急标志。 AWS Lambda 您的主管可以通过 Web 安全地访问该 API，以切换灾难模式或动态切换它以响应外部事件。在您的 Amazon Connect 实例中，通过流程进入的每个联系人都将使用 AWS Lambda 来检查紧急标志，在灾难模式下，您可以动态发布公告并为客户提供服务途径。这样将进一步确保业务连续性，并减轻此类情况对客户的影响。
+ **检查座席配置**：在转到流程中的队列之前，您可以检查座席配置，以确保座席已登录，可为联系人提供服务。例如，您的座席可能正在忙着为另一位可能在接下来的五分钟内有空的联系人提供服务，或者可能根本没有任何人员登录系统。在这些实例期间，您会更喜欢不同的客户体验，而不是让他们在队列中等待座席可用。
+ **服务路由**：当您将呼叫转接到队列时，您可以使用 Amazon Connect 路由配置文件提供排队回拨、队列溢出或分层路由，以便为满足您的服务等级要求的呼叫方提供一致、高质量的体验。

## 资源
<a name="operational-resources-bp"></a>

**文档**
+ [DevOps 和 AWS](https://aws.amazon.com/devops/)
+ [Amazon Connect Service API 文档](https://docs.aws.amazon.com/connect/latest/APIReference/welcome.html)

**博客**
+ [如何使用 Amazon Connect 处理意外联系高峰](https://aws.amazon.com/blogs/contact-center/how-to-handle-unexpected-contact-spikes-with-amazon-connect/)

**视频**
+ [DevOps 在亚马逊](https://www.youtube.com/watch?v=esEFaY0FDKc.pdf)