OPS10-BP05 Définissez un plan de communication avec les clients en cas d'interruption de service - AWS Well-Architected Framework
Directives d'implémentationRessources

OPS10-BP05 Définissez un plan de communication avec les clients en cas d'interruption de service

Définissez et testez un plan fiable de communication pour les pannes système pour tenir vos clients et vos parties prenantes informés pendant les pannes. Communiquez directement avec vos utilisateurs lorsque les services qu'ils utilisent sont touchés et lorsqu'ils reviennent à la normale.

Résultat souhaité :

  • Vous disposez d'un plan de communication pour les situations allant de la maintenance programmée aux grandes pannes imprévues, y compris l'appel de plans de reprise après sinistre.

  • Dans vos communications, vous fournissez des informations claires et transparentes sur les problèmes liés aux systèmes afin d'aider les clients à ne pas douter des performances de leurs systèmes.

  • Vous utilisez des messages d'erreur personnalisés et des pages d'état pour réduire le pic des demandes au service d'assistance et tenir les utilisateurs informés.

  • Le plan de communication est régulièrement testé pour vérifier qu'il fonctionnera comme prévu en cas de panne réelle.

Anti-modèles courants :

  • Une interruption de la charge de travail survient mais vous n'avez aucun plan de communication. Les utilisateurs inondent votre système de tickets (TT) de demandes parce qu'ils n'ont aucune information sur la panne.

  • Vous envoyez un e-mail de notification à vos utilisateurs pendant une panne. Il ne contient pas de calendrier de rétablissement du service, de sorte que les utilisateurs ne peuvent pas planifier en fonction de la panne.

  • Il existe un plan de communication pour les pannes, mais il n'a jamais été testé. Une panne survient et le plan de communication échoue parce qu'une étape critique a été omise, alors qu'elle aurait pu être détectée lors des tests.

  • Pendant une panne, vous envoyez une notification aux utilisateurs contenant trop de détails techniques et d'informations appartenant à votre accord de confidentialité AWS.

Avantages liés au respect de cette bonne pratique :

  • Le maintien de la communication pendant les pannes garantit que les clients sont informés de l'état d'avancement des problèmes et du temps estimé pour les résoudre.

  • L'élaboration d'un plan de communication bien défini permet de vérifier que vos clients et utilisateurs finaux sont bien informés afin qu'ils puissent prendre les mesures supplémentaires nécessaires pour atténuer l'impact des pannes.

  • Grâce à une communication adéquate et à une sensibilisation accrue aux interruptions planifiées et non planifiées, vous pouvez améliorer la satisfaction des clients, limiter les réactions involontaires et favoriser la fidélisation des clients.

  • Une communication opportune et transparente sur les pannes de système permet d'instaurer la confiance nécessaire au maintien des relations entre vous et vos clients.

  • Une stratégie de communication éprouvée lors d'une panne ou d'une crise réduit les spéculations et les commérages qui pourraient entraver votre capacité de récupération.

Niveau de risque exposé si cette bonne pratique n'est pas respectée : moyen

Directives d'implémentation

Les plans de communication qui permettent de tenir vos clients informés pendant les pannes sont complets et couvrent plusieurs interfaces, notamment les pages d'erreur destinées aux clients, les messages d'erreur API personnalisés, les bannières d'état du système et les pages d'état de santé. Si votre système comprend des utilisateurs enregistrés, vous pouvez communiquer via des canaux de messagerie tels que l'e-mail, les SMS ou les notifications push pour envoyer des messages personnalisés à vos clients.

Outils de communication avec les clients

En guise de première ligne de défense, les applications web et mobiles doivent fournir des messages d'erreur conviviaux et informatifs pendant une panne et avoir la possibilité de rediriger le trafic vers une page d'état.Amazon CloudFront est un réseau de diffusion de contenu (CDN) entièrement géré qui permet de définir et de diffuser un contenu d'erreur personnalisé. Les pages d'erreur personnalisées dans CloudFront constituent une bonne première couche de messagerie client pour les pannes au niveau des composants. CloudFront peut également simplifier la gestion et l'activation d'une page d'état pour intercepter toutes les demandes pendant les pannes planifiées ou non.

Les messages d'erreur d'API personnalisés peuvent aider à détecter et à réduire l'impact lorsque les pannes sont limitées à des services distincts. Amazon API Gateway vous permet de configurer des réponses personnalisées pour vos API REST. Cela vous permet de fournir des messages clairs et pertinents aux consommateurs d'API lorsque API Gateway n'est pas en mesure d'atteindre les services dorsaux. Les messages personnalisés peuvent également être utilisés pour prendre en charge le contenu des bannières d'interruption de service et les notifications lorsqu'une fonctionnalité particulière du système est dégradée en raison d'interruptions de service.

La messagerie directe est le type de messagerie client le plus personnalisé. Amazon Pinpoint est un service géré pour des communications multicanales évolutives. Amazon Pinpoint vous permet de créer des campagnes qui peuvent diffuser des messages à grande échelle dans votre base de clients affectés par SMS, e-mail, voix, notifications push, ou des canaux personnalisés que vous définissez. Lorsque vous gérez la messagerie avec Amazon Pinpoint, les campagnes de messages sont bien définies, testables et peuvent être appliquées intelligemment à des segments de clientèle ciblés. Une fois établies, les campagnes peuvent être programmées ou déclenchées par des événements et elles peuvent facilement être testées.

Exemple de client

Lorsque la charge de travail est réduite, AnyCompany Retail envoie un e-mail de notification à ses utilisateurs. L'e-mail décrit les fonctionnalités de l'entreprise qui ont été affectées et donne une estimation réaliste de la date à laquelle le service sera rétabli. En outre, la société dispose d'une page d'état qui affiche des informations en temps réel sur l'état de sa charge de travail. Le plan de communication est testé dans un environnement de développement deux fois par an pour valider son efficacité.

Étapes d'implémentation

  1. Déterminez les canaux de communication pour votre stratégie de messagerie. Tenez compte des aspects architecturaux de votre application et déterminez la meilleure stratégie pour fournir des commentaires à vos clients. Il peut s'agir d'une ou plusieurs des stratégies d'orientation décrites, notamment les pages d'erreur et d'état, les réponses personnalisées aux erreurs de l'API ou la messagerie directe.

  2. Concevez des pages d'état pour votre application. Si vous avez déterminé que les pages d'état ou les pages d'erreur personnalisées conviennent à vos clients, vous devrez concevoir votre contenu et votre message pour ces pages. Les pages d'erreur expliquent aux utilisateurs pourquoi une application n'est pas disponible, quand elle pourrait le redevenir et ce qu'ils peuvent faire entre-temps. Si votre application utilise Amazon CloudFront, vous pouvez envoyer des réponses d'erreur personnalisées ou utiliser Lambda en périphérie pour traduire les erreurs et réécrire le contenu des pages. CloudFront permet également d'échanger les destinations du contenu de votre application contre une origine de contenu Amazon S3 statique contenant votre page d'état de maintenance ou d'interruption.

  3. Concevez l'ensemble correct de statuts d'erreur API pour votre service. Les messages d'erreur produits par API Gateway lorsqu'il ne peut pas atteindre les services dorsaux, ainsi que les exceptions du niveau de service, peuvent ne pas contenir de messages conviviaux adaptés aux utilisateurs finaux. Sans avoir à modifier le code de vos services dorsaux, vous pouvez configurer des réponses d'erreur personnalisées API Gateway afin de faire correspondre les codes de réponse HTTP aux messages d'erreur de l'API.

  4. Concevez les messages dans une optique commerciale afin qu'ils soient pertinents pour les utilisateurs finaux de votre système et ne contiennent pas de détails techniques. Tenez compte de votre public et alignez vos messages. Par exemple, vous pouvez orienter les utilisateurs internes vers une solution de contournement ou un processus manuel qui s'appuie sur d'autres systèmes. Les utilisateurs externes peuvent être invités à attendre que le système soit rétabli ou à s'inscrire aux mises à jour pour recevoir une notification lorsque le système sera rétabli. Définissez les messages approuvés pour de multiples scénarios, y compris les pannes inattendues, la maintenance planifiée et les pannes partielles du système où une fonction particulière peut être dégradée ou indisponible.

  5. Modélisez et automatisez vos messages destinés aux clients. Une fois que vous avez préparé le contenu de votre message, vous pouvez utiliser Amazon Pinpoint ou d'autres outils pour automatiser votre campagne de messagerie. Avec Amazon Pinpoint, vous pouvez créer des segments cibles pour les utilisateurs concernés et transformer les messages en modèles. Consultez le tutoriel Amazon Pinpoint pour comprendre comment configurer une campagne de messagerie.

  6. Évitez de fortement coupler les capacités de messagerie à votre système de contact avec la clientèle. Votre stratégie de messagerie ne doit pas avoir de dépendance stricte vis-à-vis des magasins de données ou des services du système pour vérifier que vous pouvez envoyer des messages en cas de panne. Envisagez de créer la possibilité d'envoyer des messages à partir de plus d'une zone de disponibilité ou d'une région pour la disponibilité de la messagerie. Si vous utilisez des services AWS pour envoyer des messages, privilégiez les opérations du plan de données à celles du plan de contrôle pour appeler votre messagerie.

Niveau d'effort du plan d'implémentation : élevé. L'élaboration d'un plan de communication, et des mécanismes pour l'envoyer, peut demander un effort important.

Ressources

Bonnes pratiques associées :

Documents connexes :

Exemples connexes :

Services associés :