SOMMAIRE
Le 9 août 2024, de 15 h 46 UTC à 15 h 57 UTC, les clients Support utilisant le Pod 17 ont rencontré divers problèmes, notamment des codes d’erreur, des temps de chargement lents et l’impossibilité d’ouvrir des tickets ou de consulter les messages au sein de l’interface du produit.
Chronologie
09 août 2024 16h13 UTC | 9 août 2024 9h13 (heure du Pacifique)
Nous étudions des cas d’utilisateurs qui ne peuvent pas consulter les tickets Support dans le Pod 17, alors que leur problème est déjà résolu. Nous fournirons des mises à jour supplémentaires dans 30 minutes ou plus tôt, dès que nous aurons confirmé la stabilité totale.
09 août 2024 16h32 UTC | 9 août 2024 9h32 (heure du Pacifique)
De 15 h 46 UTC à 15 h 57 UTC, les clients Support du Pod 17 ont rencontré des problèmes pour charger les tickets. Les performances se sont stables et nous continuerons à les suivre. Prochaine mise à jour dans une heure ou quand nous aurons de nouvelles informations.
09 août 2024 16h51 UTC | 9 août 2024 9h51 (heure du Pacifique)
Les problèmes de performances Support qui ont eu lieu dans le Pod 17 de 15 h 46 UTC à 15 h 57 UTC sont désormais complètement résolus. Nous vous prions de nous excuser de ce désagrément et vous remercions de votre patience.
APRÈS LE TEMPS DE
Analyse de la cause
Cet incident est dû au redémarrage inattendu d’un système qui accélère la récupération des données en mettant des informations en cache dans la mémoire. En raison d’une réponse insuffisante à cet échec, la composante de graphique d’agent a attendu une réponse jusqu’à 60 secondes, ce qui provoque des erreurs de dépassement du délai d’inactivité et des erreurs de service 503. Les facteurs clés incluent que le système n'est pas passé à une autre source de données en temps opportun et que les surveillances en place n'ont pas déclenché d'alertes car le problème a été résolu avant d'atteindre les seuils définis.
Résolution
Pour résoudre ce problème, le système s’est automatiquement rétabli lorsque le système de mise en cache de la mémoire est reconnecté en ligne. Nous avons identifié que le redémarrage de ce système était à l’origine des retards et il a été confirmé que le problème se résolvait en self-service, ne nécessitant pas d’intervention manuelle immédiate pour rétablir le service.
Éléments de correction
- Réduction du nombre d’expirations pour la récupération du cache utilisateur.
- Envisagez d’effectuer des tests pour simuler de tels échecs dans un environnement contrôlé.
- Révisez et ajustez les seuils d’alerte pour une détection et un temps de réponse plus rapides.
- Contactez AWS pour enquêter sur le redémarrage inattendu du système de mise en cache de la mémoire cache afin d’éviter que de tels événements se reproduisent à l’avenir.
POUR EN SAVOIR PLUS
Pour des informations sur le statut actuel de votre Zendesk, consultez notre page de statut du système. Le résumé de notre enquête rétrospective est généralement affiché ici quelques jours après la fin de l’incident. Si vous avez d’autres questions au sujet de cet incident, contactez l’assistance client Zendesk.
Traduction - exonération : cet article a été traduit par un logiciel de traduction automatisée pour permettre une compréhension élémentaire de son contenu. Des efforts raisonnables ont été faits pour fournir une traduction correcte, mais Zendesk ne garantit pas l’exactitude de la traduction.
Si vous avez des questions quant à l’exactitude des informations contenues dans l’article traduit, consultez la version anglaise de l’article, qui représente la version officielle.
0 commentaire