OPS10-BP05 Definir un plan de comunicación con los clientes en caso de interrupciones del servicio - AWS Well-Architected Framework

OPS10-BP05 Definir un plan de comunicación con los clientes en caso de interrupciones del servicio

Defina y pruebe un plan de comunicación para interrupciones del sistema en el que pueda confiar, a fin de mantener informados a sus clientes y partes interesadas durante las interrupciones del servicio. Comuníquese directamente con sus usuarios tanto cuando los servicios que utilizan se vean afectados como cuando vuelvan a la normalidad.

Resultado deseado:

  • Dispone de un plan de comunicación para situaciones que van desde el mantenimiento programado hasta grandes errores inesperados, incluida la invocación de planes de recuperación de desastres.

  • En sus comunicaciones, proporciona información clara y transparente sobre los problemas de los sistemas para ayudar a los clientes a no dudar del rendimiento de sus sistemas.

  • Utiliza mensajes de error y páginas de estado personalizados para reducir el pico de solicitudes al servicio de asistencia y mantener informados a los usuarios.

  • El plan de comunicación se pone a prueba periódicamente para garantizar que funcione según lo previsto cuando se produzca una interrupción real.

Antipatrones usuales:

  • Se produce una interrupción de la carga de trabajo, pero no dispone de un plan de comunicación. Los usuarios saturan el sistema de tickets de problemas con solicitudes porque no tienen información sobre la interrupción del servicio.

  • Envía una notificación por correo electrónico a los usuarios durante una interrupción del servicio. No incluye un plazo para el restablecimiento del servicio, por lo que los usuarios no pueden hacer planes para la interrupción.

  • Existe un plan de comunicación para las interrupciones del servicio, pero no se ha probado nunca. Se produce una interrupción y el plan de comunicación no funciona porque se ha omitido un paso crucial que podría haberse detectado en las pruebas.

  • Durante una interrupción, envía una notificación a los usuarios que contiene demasiados detalles técnicos e información según su acuerdo de confidencialidad de AWS.

Beneficios de establecer esta práctica recomendada:

  • Mantener la comunicación durante las interrupciones del servicio garantiza que los clientes estén al tanto de la evolución de los problemas y el tiempo estimado para su resolución.

  • El desarrollo de un plan de comunicaciones bien definido asegura que sus clientes y usuarios finales estén bien informados para que puedan tomar las medidas adicionales necesarias para mitigar la repercusión de las interrupciones del servicio.

  • Con una comunicación adecuada y un mejor conocimiento de las interrupciones planificadas y no planificadas, puede mejorar la satisfacción del cliente, limitar las reacciones imprevistas y favorecer la retención de clientes.

  • Una comunicación oportuna y transparente sobre las interrupciones del sistema estimula la confianza necesaria para mantener las relaciones entre usted y sus clientes.

  • Una estrategia de comunicación sólida durante una interrupción o crisis del servicio reduce las conjeturas y habladurías que podrían obstaculizar su capacidad de recuperación.

Nivel de riesgo expuesto si no se establece esta práctica recomendada: medio

Guía para la implementación

Los planes de comunicación que mantienen informados a los clientes durante las interrupciones del servicio son holísticos y abarcan numerosas interfaces, como páginas de error orientadas al cliente, mensajes de error de API personalizados, banners de estado del sistema y páginas de comprobación de estado. Si su sistema tiene usuarios registrados, puede comunicarse a través de canales de mensajería como correo electrónico, SMS o notificaciones push para enviar mensajes con contenido personalizado a los clientes.

Herramientas de comunicación con el cliente

Como primera línea de defensa, las aplicaciones web y móviles deben proporcionar mensajes de error amables e informativos durante una interrupción del servicio, así como tener la capacidad de redirigir el tráfico a una página de estado. Amazon CloudFront es una red de entrega de contenido (CDN) totalmente administrada que incluye capacidades para definir y presentar contenido de error personalizado. Las páginas de error personalizadas de CloudFront son una buena primera capa de mensajería para clientes en caso de interrupciones de servicio en el nivel de componente. CloudFront también contribuye a simplificar la administración y activación de una página de estado para interceptar todas las solicitudes durante interrupciones planificadas o no planificadas.

Los mensajes de error de API personalizados pueden ayudar a detectar y reducir el efecto cuando las interrupciones se limitan a servicios discretos. Amazon API Gateway le permite configurar respuestas personalizadas para sus API de REST. Esto le permite proporcionar mensajes claros y significativos a los consumidores de la API cuando API Gateway no es capaz de llegar a los servicios de backend. Los mensajes personalizados también sirven para apoyar el contenido de banners de interrupción y notificaciones cuando una característica concreta del sistema se degrada debido a interrupciones en el nivel de servicio.

La mensajería directa es el tipo más personalizado de mensajería para clientes. Amazon Pinpoint es un servicio administrado para comunicaciones multicanal escalables. Amazon Pinpoint le permite crear campañas que pueden transmitir mensajes ampliamente a toda su base de clientes afectada mediante SMS, correo electrónico, voz, notificaciones push o canales personalizados que usted defina. Cuando administra la mensajería con Amazon Pinpoint, las campañas de mensajes están bien definidas, se pueden probar y se pueden aplicar de forma inteligente a segmentos de clientes específicos. Una vez establecidas, las campañas se pueden programar o activar por eventos y se pueden probar con toda facilidad.

Ejemplo de cliente

Cuando la carga de trabajo se ve afectada, AnyCompany Retail envía una notificación por correo electrónico a sus usuarios. En el correo electrónico se describe qué funcionalidad empresarial se ha visto afectada y se proporciona una estimación realista de cuándo se restablecerá el servicio. Además, dispone de una página de estado que muestra información en tiempo real sobre el estado de su carga de trabajo. El plan de comunicación se prueba en un entorno de desarrollo dos veces al año para comprobar que sea eficaz.

Pasos para la implementación

  1. Determine los canales de comunicación de su estrategia de mensajería. Considere los aspectos arquitectónicos de su aplicación y determine la mejor estrategia para hacer llegar los comentarios a los clientes. Esto podría incluir una o más de las estrategias de orientación descritas, como páginas de error y estado, respuestas de error de API personalizadas o mensajería directa.

  2. Diseñe páginas de estado para su aplicación. Si ha determinado que las páginas de estado o de error personalizadas son adecuadas para sus clientes, tendrá que diseñar el contenido y los mensajes para esas páginas. Las páginas de error explican a los usuarios por qué no está disponible una aplicación, cuándo podría volver a estar disponible y qué pueden hacer mientras tanto. Si su aplicación utiliza Amazon CloudFront puede presentar respuestas de error personalizadas o utilizar Lambda at Edge para traducir errores y reescribir el contenido de la página. CloudFront también permite intercambiar destinos del contenido de su aplicación a un origen de contenido estático de Amazon S3 que contenga su página de mantenimiento o estado de interrupción del servicio.

  3. Diseñe el conjunto correcto de estados de error de la API para su servicio. Los mensajes de error producidos por API Gateway cuando no es posible llegar a los servicios de backend, así como las excepciones de nivel de servicio, podrían no contener mensajes amables adecuados para mostrar a los usuarios finales. Sin tener que realizar cambios de código en sus servicios de backend, puede configurar respuestas de error personalizadas de API Gateway para asignar códigos de respuesta HTTP a mensajes de error de API seleccionados.

  4. Diseñe la mensajería desde una perspectiva empresarial de modo que sea relevante para los usuarios finales de su sistema y no contenga detalles técnicos. Tenga en cuenta su audiencia y adapte los mensajes. Por ejemplo, dirija a los usuarios internos hacia una solución o un proceso manual que aproveche sistemas alternativos. En cuanto a los usuarios externos, puede pedirles que esperen hasta que se restablezca el sistema o que se suscriban a las actualizaciones para recibir una notificación una vez que se restablezca el sistema. Defina la mensajería aprobada para numerosas situaciones, como interrupciones inesperadas del servicio, mantenimiento planificado y errores parciales del sistema en los que una característica concreta podría degradarse o no estar disponible.

  5. Cree plantillas y automatice la mensajería para clientes. Una vez que haya establecido el contenido del mensaje, puede utilizar Amazon Pinpoint u otras herramientas para automatizar la campaña de mensajería. Con Amazon Pinpoint puede crear segmentos de clientes objetivo para usuarios específicos afectados y transformar los mensajes en plantillas. Revise el tutorial de Amazon Pinpoint para entender cómo configurar una campaña de mensajería.

  6. Evite vincular estrechamente las capacidades de mensajería a su sistema de orientación al cliente. Su estrategia de mensajería no debe depender de servicios ni almacenes de datos del sistema para verificar que puede enviar mensajes correctamente cuando se produzcan interrupciones del servicio. Plantéese la posibilidad de crear la capacidad de enviar mensajes desde más de una región o zona de disponibilidad para asegurar la disponibilidad de la mensajería. Si utiliza servicios de AWS para enviar mensajes, aproveche las operaciones del plano de datos en lugar de las operaciones del plano de control para invocar la mensajería.

Nivel de esfuerzo para el plan de implementación: alto. El desarrollo de un plan de comunicación —y los mecanismos para enviarlo— puede demandar un esfuerzo considerable.

Recursos

Prácticas recomendadas relacionadas:

Documentos relacionados:

Ejemplos relacionados:

Servicios relacionados: