OPS10-BP05 定义中断时的客户沟通计划 - AWS Well-Architected Framework
实施指导资源

OPS10-BP05 定义中断时的客户沟通计划

定义和测试系统中断时的沟通计划，您可以依赖此计划在中断期间让客户和利益攸关方了解情况。当用户使用的服务受到影响和服务恢复正常时直接传达给用户。

期望结果：

  • 为从计划维护到重大意外故障的各种状况（包括调用灾难恢复计划）制定沟通计划。

  • 在沟通中，提供有关系统问题的清晰透明信息，帮助客户避免事后猜测其系统的性能。

  • 使用自定义错误消息和状态页面减少服务台请求的激增并让用户了解相关情况。

  • 定期测试沟通计划，以便确认在真正发生中断时计划会按预期执行。

常见反模式：

  • 发生工作负载中断，但您没有沟通计划。因为用户不知晓关于中断的信息，他们不断发出请求，使您的故障单系统不堪重负。

  • 您在中断期间向用户发送电子邮件通知。邮件中未包含恢复服务的时间表，因此用户无法针对中断制定计划。

  • 您有针对中断的沟通计划，但从未经过测试。发生中断，但因为漏掉了一个本来可以在测试中发现的关键步骤，沟通计划失败。

  • 在中断期间，您向用户发送通知，其中包含太多受 AWS 保密协议保护的技术细节和信息。

建立此最佳实践的好处：

  • 在中断期间保持沟通可以确保客户可以了解有关问题的进度和预估的解决时间。

  • 制定明确的沟通计划，确认您的客户和最终用户可以充分了解情况，以便他们可以采取必要的额外步骤来缓解中断的影响。

  • 通过适当的沟通并提高对计划内和计划外中断的认识，您可以提高客户满意度、限制非预期的反应和提高客户保留率。

  • 及时和透明的系统中断沟通可以树立信心和建立信任，从而维护您和客户之间的关系。

  • 在中断或危机期间，行之有效的沟通策略可以减少猜测和流言蜚语，以免阻碍您恢复运营。

在未建立这种最佳实践的情况下暴露的风险等级：中等

实施指导

在中断期间让您的客户了解情况的沟通计划是全面的，涵盖多个接口，包括面向客户的错误页面、自定义 API 错误消息、系统状态横幅和运行状况状态页面。如果您的系统包括注册用户，您可以通过各种消息传递渠道（例如，电子邮件、短信或推送消息）进行沟通，向客户发送个性化的消息内容。

客户沟通工具

作为第一道防线，Web 和移动应用程序应在中断期间提供友好且信息丰富的错误消息，并能够将流量重定向到状态页面。Amazon CloudFront 是完全托管式内容分发网络（CDN），包括定义和提供自定义错误内容的功能。CloudFront 中的自定义错误页面是很好的第一层客户信息传递，适合组件级中断。CloudFront 还可以简化状态页的管理与激活，以便在计划内或计划外中断期间拦截所有请求。

当中断隔离到不相关联的服务时，自定义 API 错误消息可以帮助检测和减少影响。您可以使用 Amazon API Gateway 为 REST API 配置自定义响应。当 API Gateway 无法访问后端服务时，您可以利用它向 API 使用者提供清晰而有意义的信息。客户消息还可以用于支持中断横幅内容，以及在特定系统功能因服务层中断而降级时发出通知。

直接消息传递是最个性化的客户消息传递类型。Amazon Pinpoint 是适合可扩展多渠道通信的托管服务。您可以利用 Amazon Pinpoint 来构建活动，通过短信、电子邮件、语音、推送通知或您定义的自定义渠道在受影响的客户群中广泛广播消息。当您使用 Amazon Pinpoint 管理消息传递时，消息活动定义明确、可测试，并且可以智能地应用于目标客户群体。建立活动之后，就可以对其作出安排，或通过事件来触发，然后就可以很容易地进行测试。

客户示例

当工作负载受影响时，AnyCompany Retail 向其用户发送电子邮件通知。电子邮件描述了哪些业务功能受到影响，并对何时恢复服务作出合理的预估。此外，他们有一个状态页，其中显示了有关其工作负载运行状况的实时信息。每年在开发环境中对沟通计划测试两次，以便确认计划有效。

实施步骤

  1. 确定消息传递策略的沟通渠道。考虑应用程序的架构方面，并确定向客户提供反馈的最佳策略。这包括概述的一个或多个指导策略，包括错误和状态页、自定义 API 错误响应或直接消息传递。

  2. 设计应用程序的状态页面。如果您已确定状态或自定义错误页面适合您的客户，则需要为这些页面设计内容和信息。错误页面向用户说明为什么应用程序不可用、什么时候可以再次使用以及在此期间他们可以做什么。如果应用程序使用 Amazon CloudFront，您可以提供自定义错误响应或使用 Lambda at Edge 来转变错误并重写页面内容。CloudFront 还可以将目的地从应用程序内容转换为包含维护或中断状态页面的静态 Amazon S3 内容来源。

  3. 为服务设计一组正确的 API 错误状态。当 API Gateway 无法访问后端服务时生成的错误消息以及服务层异常可能不包含适合向最终用户显示的友好消息。您无需对后端服务进行代码更改，而可以将 API Gateway 自定义错误响应配置为将 HTTP 响应代码映射到精选的 API 错误消息。

  4. 从业务角度设计信息，使其与系统的最终用户相关，并且不包含技术细节。考虑您的受众并调整信息。例如，您可以引导内部用户转向利用替代系统的解决方法或手动流程。外部用户可能需要等到系统恢复，或订阅更新，以便在系统恢复后收到通知。定义多个场景的已批准消息传递，包括意外中断、计划维护以及会导致特定功能可能降级或不可用的部分系统故障。

  5. 使您的客户消息传递模板化和自动化。确立消息内容之后，您可以使用 Amazon Pinpoint 或其他工具使消息传递活动实现自动化。借助 Amazon Pinpoint，您可以为特定的受影响用户创建客户目标细分，并将消息转换为模板。查看 Amazon Pinpoint 教程，了解如何设置消息传递活动。

  6. 避免将消息传递功能与面向客户的系统紧密耦合。消息传递策略不应该严格依赖于系统数据存储或服务，以便确认在遇到中断时您可以成功发送消息。考虑培养从多个可用区或区域发送消息以实现消息传递可用性的能力。如果您使用 AWS 服务来发送消息，请利用数据面板操作而不是控制面板操作来调用消息传递。

实施计划的工作量级别：高。制定沟通计划和用于发送计划的机制需要付出巨大的努力。

资源

相关最佳实践：

相关文档：

相关示例：

相关服务：