SOMMAIRE
En juin 2024, en particulier les 13 et 25 jours ainsi que quelques jours en juillet, un certain nombre de problèmes sont survenus au sein de l’espace de travail d’agent Support de Zendesk. Ces incidents perturbaient les workflows des agents et leur empêchaient d’accéder aux tickets. Les principaux problèmes rencontrés incluaient une erreur « Messages introuvables » et un code d’erreur « A_xxx » lors de la tentative de chargement des tickets. Ces problèmes se sont produits essentiellement dans plusieurs Pods pendant plusieurs jours. Chaque pic de perturbations durait généralement 2 minutes en moyenne. Les clients pouvaient essayer d’actualiser le système, mais ils risquaient de perdre des conversations en cours.
Chronologie
25 juin 2024 16h05 UTC | 25 juin 2024 9h05 (heure du Pacifique)
Nous avons été au courant d’un pic d’erreurs affectant les clients dans plusieurs pods entre 15 h 40 et 15 h 47 UTC le 25 juin 2024, pouvant entraîner des réponses « Messages introuvables » et des messages « code d’erreur A_xxx » lors des tentatives de chargement des tickets dans Support. Nous avons récupéré ces erreurs et le problème devrait être résolu en rechargeant votre navigateur et/ou en vidant votre cache et vos cookies.
APRÈS LE TEMPS DE
Analyse de la cause
La cause principale de ces incidents était une augmentation inattendue des demandes HTTP au serveur, souvent aux heures de pointe. Ce pic a provoqué un « résultats » qui a submergé les connexions du serveur Graph d’agent, ce qui a provoqué l’échec des vérifications de statut. Lotus, un composant essentiel du système, joue un rôle important. Le gestionnaire de données de tickets (TDM) était submergé de demandes à chaque reconnexion. Cette hausse du trafic est principalement attribuée aux abonnements au statut des conversations qui se reconnectent après des déconnexions en masse, semble-t-il dues à des déploiements de Zorg/Nginx et/ou de services d’abonnement.
Le TDM est principalement chargé de la gestion des données de ticket. Il organise et stocke les informations lorsqu'un ticket est généré, puis récupère et présente ces données lorsqu'un agent ou un client a besoin d'y accéder, et joue le rôle de contrôleur principal de toutes les données ayant trait aux tickets, ce qui assure des opérations fluides au sein du système.
Résolution
Des mesures préventives ont été mises en place pour remédier à ces problèmes. Ceux-ci incluent le limiteur de débit de connexion et de demande, chargé de la régulation du trafic entrant. En parallèle, des mesures ont été prises pour améliorer la résilience du graphique d’agent lors des échecs de mise en cache. Cette stratégie a permis d’éviter des interruptions dans l’ensemble du système, dues à des problèmes techniques inévitables, qui joueraient le rôle de générateurs de secours en cas de panne de courant. De nombreuses mesures d’atténuation ont été mises en place, mais la résolution de l’incident de service a été apportée dans Lotus. Cette modification a réduit le nombre de scénarios dans lesquels la récupération des données aurait lieu par la suite, ce qui met fin à l’effet de forage.
Modifié le 25 juillet: Après avoir effectué quelques ajustements le 10 juillet pour éviter une accumulation de demandes causant des problèmes, nous n’avons pas vu d’autres pics affectant l’interface de ticket. Nous avons continuer de surveiller de près les événements et avons été satisfaits de constater que les choses se passaient bien dans les jours suivants.
De plus, au cours du mois précédent, nous avions remarqué des baisses de performances dans certains Pods le vendredi, mais les choses s’amélioreraient le 12 juillet et nous donnions plus de confiance en nos changements. Par la suite, le 15 juillet, nous n’avons pas rencontré de problèmes ou de pics de performances, ce qui nous laisse penser que le problème a été résolu.
Éléments de correction
D’autres stratégies ont été conçues pour améliorer encore la stabilité du système et éviter des perturbations futures :
- Alerte pour les échecs de la vérification de la disponibilité : Mettez en œuvre un test de détection pour permettre à l’équipe technique de le signaler rapidement à tout problème potentiel et ainsi permettre une action rapide.
- Considération des schémas de récupération : Conseillez aux développeurs de logiciels de réfléchir avec soin au volume et à la fréquence de récupération des informations afin d’éviter les déséquilibres du système.
- Création d’une base de demandes : Déterminez la capacité du système à traiter les demandes d'informations sur les tickets simultanées afin d'éviter une panne du système.
- Espacez les récupérations : Introduisez une gigue pour atténuer les effets du Enterprise.
- Explorez une rétention des abonnements plus simple : Cherchez des moyens de maintenir les abonnements plus efficacement pendant les déploiements.
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.