Recherches récentes


Pas de recherche récente

Attila Takacs's Avatar

Attila Takacs

Adhésion le 14 avr. 2021

·

Dernière activité le 05 févr. 2025

Suivis

0

Abonnés

2

Activité totale

72

vote

1

Abonnements

63

APERÇU DES ACTIVITÉS

Dernière activité effectuée par Attila Takacs

Attila Takacs a créé un article,

ArticleNotifications de service

SOMMAIRE

05 février 2025 11:48 UTC | 05 février 2025 03h48 (heure du Pacifique)
Nous avons le plaisir de vous informer que les problèmes de connexion avec notre service de guide ont été identifiés et résolus par notre équipe d’ingénierie. Vous devriez désormais pouvoir accéder au service sans problème. Nous vous remercions de votre patience et de votre compréhension pendant cet incident. Si vos problèmes persistent, contactez notre équipe d’assistance.

05 février 2025 11h29 UTC | 05 février 2025 03:29 Heures du Pacifique
Nous subissons une dégradation du service avec la connexion au service de guide à partir des navigateurs mobiles. Si vous rencontrez des erreurs lors de l’accès à votre compte, essayez de vous connecter à partir d’un ordinateur de bureau. Notre équipe travaille activement à la résolution de ce problème.

POST-MORTEM

À DÉTERMINER

POUR EN SAVOIR PLUS

Pour des informations sur le statut actuel du système pour Zendesk et son impact spécifique sur votre compte, consultez notre page de statut du système. Vous pouvez vous abonner à cet article pour être prévenu de la publication de notre rapport rétrospectif. 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.

Modification le 05 févr. 2025 · Attila Takacs

0

Abonnés

1

vote

0

Commentaire


Attila Takacs a créé un article,

ArticleNotifications de service

SOMMAIRE

Le 1er février 2025, de 00:13 UTC à 00:59 UTC, les clients du POD 26 ont rencontré des problèmes d’accès aux tickets archivés. Pendant ce temps, plusieurs nœuds de lecture de base de données n’ont pas pu ouvrir un tableau en raison d’un défaut du système de base de données. Ainsi, les requêtes pour les tickets archivés ont échoué.

CALENDRIER

01 février 2025 01:13 UTC | 31 janvier 2025 17h13 (heure du Pacifique)
Nous sommes heureux de vous informer que le problème à l’origine des erreurs affectant un groupe de nos clients Support sur le POD 26 a été résolu. Nous vous remercions de votre patience pendant notre enquête.

01 février 2025 12h57 UTC | 31 janvier 2025 16h57 (heure du Pacifique)
Nos ingénieurs pensent avoir identifié la cause de ces erreurs affectant un groupe de clients Support sur le POD 26 et travaillent à la résolution du problème.

01 février 2025 12h57 UTC | 31 janvier 2025 16h57 (heure du Pacifique)
Nous étudions les erreurs potentielles pour nos clients Support hébergés sur le POD 26.


APRÈS LE TEMPS DE

Analyse de la cause

Cet incident est dû à un défaut dans le système de base de données qui empêchait les nœuds de lecture de clusters d’accéder au tableau des tickets archivés. Le problème a été confirmé par l’assistance technique de notre fournisseur et était spécifique à la version de base de données installée à l’époque.


Résolution

Pour résoudre ce problème, nos ingénieurs ont interrompu un déploiement vers d’autres shards et laissé les modifications en cours se terminer sur les shards concernés. La table de la base de données était alors accessible. Nous projetons ensuite de mettre à niveau et de passer à une nouvelle version de notre système de base de données, qui inclut un correctif pour le problème identifié.


Éléments de correction

  1. Mettez à niveau et passez à la version corrigée ou supérieure avant de reprendre les modifications du schéma.
  2. Vous pouvez séparer les ajouts de colonnes et les baisses d’index pour minimiser les risques pendant les déploiements.
  3. Mettez à jour le Run-book pour que les migrations importantes n’atteignent qu’un cluster au départ avant de s’étendre à d’autres clusters.
  4. Mettez en œuvre un processus de vérification régulier (au moins une fois par an) des correctifs système de bases de données et établissez un rythme de mise à niveau.

POUR EN SAVOIR PLUS

Pour des informations sur le statut actuel du système pour Zendesk et son impact spécifique sur votre compte, consultez notre page de statut du système. Vous pouvez vous abonner à cet article pour être prévenu de la publication de notre rapport rétrospectif. 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.

Modification le 06 févr. 2025 · Attila Takacs

0

Abonnés

1

vote

0

Commentaire


Attila Takacs a créé un article,

ArticleNotifications de service

SOMMAIRE
Le 13 janvier 2025, de 11h07 UTC à 12h07 UTC, les clients du Pod 17 ont rencontré des problèmes et les déclencheurs de messagerie ne s’exécutaient pas.

CALENDRIER

13 janvier 2025 12h24 UTC | 13 janvier 2025 04h24 (heure du Pacifique)
Le récent problème de messagerie a été complètement résolu et nos services sont à nouveau opérationnels. Merci de votre patience pendant ce temps. Notre équipe continuera de surveiller de près nos systèmes pour s’assurer que tout fonctionne correctement. Nous vous remercions de votre soutien et sommes à votre disposition pour répondre à toutes vos questions ou suggestions.

13 janvier 2025 11h51 UTC | 13 janvier 2025 03h51 (heure du Pacifique)
Nous étudions les problèmes avec les déclencheurs de messagerie s’exécutant pour nos clients sur POD17.


APRÈS LE TEMPS DE

Analyse de la cause

Cet incident a été provoqué par des interruptions précoces du service d’événements du journal des tickets de messagerie, qui ont eu lieu alors que le service était encore en cours d’exécution. Par conséquent, les clients ne pouvaient pas traiter les événements entrants, ce qui a débouché sur un arrêt total de l’évaluation et de l’exécution des déclencheurs de messagerie sur le Pod 17.

Résolution

Pour résoudre ce problème, nous avons identifié l’erreur de configuration qui définissait le nombre maximal d’enregistrements à traiter en une seule fois sur 500 au lieu de 250 comme prévu. En corrigeant cette faute de frappe et en réduisant la valeur max. d’enregistrements, nous avons essayé de réduire les risques que les consommateurs soient interrompus pour des raisons de délai.

Éléments de correction

  1. Effectuez un contrôle de santé pour détecter les abandons précoces chez les consommateurs.
  2. Créez une surveillance pour suivre le nombre de consommateurs actifs.
  3. Établissez une surveillance pour surveiller les segmentations arrêtées par le consommateur d’événements du journal des tickets de messagerie.
  4. Ajoutez un widget de statut de délai consommateur au tableau de bord Service de déclencheur de messagerie.
  5. Créer une mesure pour mesurer le temps nécessaire au traitement d’un lot de messages à partir du sujet des événements du journal de tickets de messagerie.

Ces mesures correctives sont conçues pour améliorer la surveillance et empêcher des incidents similaires à l'avenir, afin de garantir la stabilité et la fiabilité du service de déclencheurs de messagerie.


POUR EN SAVOIR PLUS

Pour des informations sur le statut actuel du système pour Zendesk et son impact spécifique sur votre compte, consultez notre page de statut du système. Vous pouvez vous abonner à cet article pour être prévenu de la publication de notre rapport rétrospectif. 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.

Modification le 29 janv. 2025 · Attila Takacs

0

Abonnés

2

Votes

0

Commentaire


Attila Takacs a créé un article,

ArticleNotifications de service

RÉSUMÉ

Le 9 décembre 2024, de 8h08 UTC à 13h03 UTC, les clients utilisant la fonctionnalité Multimarque ont rencontré des erreurs lors de la création de tickets ou de la mise à jour des titres de tickets, mais les modifications ont été enregistrées.

Chronologie

09 décembre 2024 10:21 UTC | 14h21 (heure du Pacifique)

Nous avons le plaisir de vous informer que la modification récente a été annulée et que le problème de création de tickets multimarques est désormais résolu.
Si vous rencontrez encore des problèmes, essayez d’effectuer une actualisation en dur (Ctrl + F5) ou de vider le cache et les cookies de votre navigateur. Cela peut vous aider à résoudre les problèmes persistants.
N’hésitez pas à nous contacter si vous rencontrez des difficultés. Merci de votre patience.

09 décembre 2024 12h58 UTC | 04h58 (heure du Pacifique)
Nous rencontrons actuellement des problèmes avec la création des tickets multimarque. Notre équipe d’ingénierie a été informée de ce problème et s’efforce de le résoudre le plus rapidement possible.
Nous vous mettrons à jour dès que nous aurons plus d’informations. Merci de votre patience et de votre compréhension.

 

POST-MORTEM

Analyse de la cause

La cause de cet incident était une faille dans la logique d’initialisation du ticket. Quand l’ID du demandeur n’était pas défini, le système essayait de le récupérer en utilisant la clé du ticket, ce qui entraînait des erreurs chaque fois qu’un changement de champ se produisait dans l’interface de ticket. L’introduction d’une nouvelle logique pour lire l’ID utilisateur à partir de la page de profil utilisateur et le définir sur l’ID du demandeur a accidentellement défini l’objet du demandeur sur non défini, ce qui ne correspondait pas à la fonctionnalité attendue.


Résolution

Pour résoudre ce problème, la mise à jour posant problème a été annulée.


Éléments de correction

  1. Corrigez le code erroné : Assurez-vous que le système définit correctement les données du demandeur quand vous créez des tickets pour éviter les saisies vides.
  2. Ajoutez des tests automatiques : Créez un test pour vérifier que le processus d’enregistrement du ticket gère correctement les informations du demandeur.
  3. Confirmer les tests manuels : exigez des déployeurs qu’ils testent manuellement les modifications sur les POD « canar » et que tout fonctionne comme il faut avant le déploiement.
  4. Améliorez la surveillance : Configurez la surveillance pour avertir des erreurs de navigateur, comme « un problème est survenu », afin d’identifier rapidement les problèmes.

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, veuillez contacter 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.

Modification le 17 déc. 2024 · Attila Takacs

0

Abonnés

1

vote

0

Commentaire


Attila Takacs a créé un article,

ArticleNotifications de service

SOMMAIRE

Le 3 décembre 2024, de 21:09 UTC à 3:36 UTC le 7 décembre 2024, certains clients utilisant le Mobile SDK ont rencontré des erreurs 400 lors de la création de tickets. Suite à une modification, un délai d’expiration par défaut de 8 heures a été affecté aux tokens OAuth nouvellement créés. Cette modification a accidentellement endommagé les anciens Mobile SDK, qui n’avaient pas pu récupérer les nouveaux tokens si leurs tokens existants n’étaient plus valides, ce qui a débouché sur une expérience utilisateur frustrante. Le problème a été résolu en annulant la modification.


Chronologie

6 décembre 2024 18h20 UTC | 6 décembre 2024 10h20 (heure du Pacifique)

Nous avons le plaisir de signaler que le problème qui provoquait des erreurs 400 pour certains clients lors de la création de tickets via le SDK a été résolu. Nous vous prions de nous excuser de toute perturbation que cela a pu causer et vous remercions de votre patience pendant notre enquête.

6 décembre 2024 12h06 UTC | 6 décembre 2024 04:06 (heure du Pacifique)
Notre équipe continue de travailler à résoudre les comportements qui provoquent des erreurs 400 lors des envois de tickets via l’API via notre Mobile SDK. Pour l’instant, si les utilisateurs finaux rencontrent cette erreur, ils peuvent redémarrer l’application. Les tickets seront créés normalement.


6 décembre 2024 09:45 UTC | 6 décembre 2024 01h45 (heure du Pacifique)

Nous avons conscience que certains de nos clients peuvent rencontrer des erreurs 400 lors de la tentative de création de tickets via notre Mobile SDK. Si vous rencontrez cette erreur, redémarrez l’application pour résoudre le problème.


APRÈS LE TEMPS DE

Analyse de la cause

Cet incident est dû à une erreur lors de l’évaluation de l’utilisation des tokens d’authentification dans différents produits avant le déploiement d’une modification de leur délai d’expiration. Les anciens SDK ne peuvent pas obtenir de nouveaux tokens OAuth quand les tokens existants arrivent à expiration, mais cet aspect n’a pas été entièrement pris en compte au cours des étapes de planification et d’intégration. Une collaboration améliorée et une évaluation plus approfondie de l’utilisation des tokens auraient pu éviter cette perturbation.


Résolution

Pour résoudre ce problème, l’équipe d’authentification a commencé par désactiver le processus de remplissage qui ajoutait des délais d’expiration aux tokens existants. Par la suite, elle a déployé une demande d’extraction (pull) qui a rétabli les paramètres d’expiration pour les nouveaux tokens et a initié un backfill pour supprimer l’expiration des tokens existants. Cette action a rétabli des fonctionnalités pour la majorité des clients affectés.


Éléments de correction

  1. Mettez en place un protocole de communication clair entre les équipes pour vous assurer que les défauts connus sont correctement documentés et passés en revue avant toute mise en œuvre de modifications importantes.
  2. Améliorer les outils d’implémentation existants pour mieux gérer le flux d’authentification et réduire la Dette technique associée aux anciens SDK.
  3. Créez des alertes et des systèmes de surveillance supplémentaires pour détecter des problèmes similaires à l’avenir, en vous concentrant particulièrement sur les échecs des OAuth .
  4. Définissez des limites de connexion pour des applications spécifiques afin d’éviter une génération excessive de tokens et de limiter l’expansion de la base de données.

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, veuillez contacter 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.

Modification le 20 déc. 2024 · Attila Takacs

0

Abonnés

1

vote

0

Commentaire


Attila Takacs a créé un article,

ArticleNotifications de service

SOMMAIRE

Le 21 novembre 2024, de 21h02 UTC à 21h56 UTC, certains clients utilisant Sunshine Conversations hébergées sur le Pod 17 ont rencontré des problèmes de lenteur et de performances.

 

CALENDRIER

24 novembre 2024 10h23 UTC | 24 novembre 2024 14h23 (heure du Pacifique)
Nous avons le plaisir d’annoncer que les problèmes de latence affectant Sunshine Conversations pour certains de nos clients sur le POD 17 ont été résolus. Merci de votre patience.

24 novembre 2024 22h09 UTC | 24 novembre 2024 14h09 (heure du Pacifique)
Nous pensons avoir identifié la cause première des problèmes de performances affectant SunCo pour notre client sur Pod17. Nous constatons désormais des améliorations et continuerons de surveiller le comportement.

24 novembre 2024 21h53 UTC | 24 novembre 2024 13h53 (heure du Pacifique)
Nous continuons d’enquêter sur les problèmes de performances du Pod 17. Ils risquent de ralentir Sunshine Conversations. Nous reviendrons vers vous bientôt.

24 novembre 2024 21h36 UTC | 24 novembre 2024 13h36 (heure du Pacifique)
Nous étudions les problèmes de performances potentiels affectant certains de nos clients hébergés sur le Pod 17. Nous publierons bientôt une mise à jour contenant plus de détails.


APRÈS LE TEMPS DE

Analyse de la cause

Cet incident a été dû à une hausse inattendue du trafic sur Pod17, qui a plus que doublé la semaine précédente et presque triplé le jour de l’incident. Le SDK Unity utilisé par un client envoyait des demandes excessives à l'API SunCo pour récupérer les messages non lus, ce qui entraînait une charge accrue du système. L’évolutivité automatique des ressources était déjà à sa capacité maximale, ce qui empêchait l’ajout de ressources supplémentaires pour gérer l’augmentation du trafic. Par conséquent, cette surcharge a débouché sur des temps de réponse plus lents et a fini par déclencher des vérifications de l’état qui ont débouché sur des redémarrages, ce qui n’a fait qu’ajouter au problème.

Résolution

Pour résoudre ces problèmes de performances, nous avons augmenté le nombre maximum de réplications pour l’API SunCo sur Pod17. Cet ajustement a permis au système de mieux gérer l'augmentation du trafic et a rétabli des temps de réponse normaux pour tous les clients.

Éléments de correction

  1. Examinez le SDK Unity pour comprendre pourquoi il envoie un nombre excessif de demandes à SunCo et mettez en œuvre des optimisations.
  2. Documentez les schémas d’interactions du backend dans les Embeddables pour clarifier l’utilisation et identifier les inefficacités potentielles.
  3. Évaluez la mise en œuvre d’une stratégie de mise en cache pour les API SDK dans SunCo afin de réduire le nombre de demandes effectuées.
  4. Ajoutez la surveillance pour détecter une croissance anormale du trafic pendant des périodes spécifiques afin de gérer les surcharges potentielles de façon proactive.

 

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.

Modification le 04 déc. 2024 · Attila Takacs

0

Abonnés

1

vote

0

Commentaire


Attila Takacs a créé un article,

ArticleNotifications de service

SOMMAIRE

Entre 23 h 30 UTC le 12 novembre 2024 et 11 h 26 UTC le 15 novembre 2024, les clients Support qui utilisent les SLA dans les Pods 25 et 30 ont rencontré des retards dans les calculs SLA (Accord sur les niveaux de service) et les badges SLA (Accord sur les niveaux de service) sur leurs tickets ne s’affichaient pas comme prévu après application. des mises à jour des tickets Zendesk.

 

CALENDRIER

15 novembre 2024 13h00 UTC | 15 novembre 2024 5h00 (heure du Pacifique)
Nous avons le plaisir de vous annoncer que les problèmes affectant les performances des mesures SLA (Accord sur les niveaux de service) dans les Pods 25 et 30 ont été résolus. Merci de votre patience.

15 novembre 2024 12h16 UTC | 15 novembre 2024 04:16 (heure du Pacifique)
Nous constatons désormais des améliorations du problème affectant les performances du SLA (Accord sur les niveaux de service) des mesures dans les Pods 25 et 30. Nous continuons à surveiller et vous fournirons des mises à jour supplémentaires.

 

POST-MORTEM

Analyse de la cause

Cet incident est dû à un secret mal configuré pour le service des événements de mesure. Ainsi, quand Zendesk déployait une mise à jour avec une validation supplémentaire, le service n’était pas initialisé pour les déploiements en Asie Pacifique, ce qui provoque des retards de traitement.

Résolution

Pour résoudre ce problème, une valeur par défaut a été ajoutée pour le secret affecté le 15 novembre 2024. Cela a permis au service des événements de mesure de s’initialiser correctement et de reprendre des opérations normales. Zendesk a aussi identifié et configuré une valeur par défaut pour un secret du service de transcription Talk afin de minimiser tous les risques futurs.

Éléments de correction

  1. Effectuez un audit approfondi de tous les secrets pour vous assurer que les valeurs sont définies pour toutes les localités, en particulier pour les régions Asie-Pacifique.
  2. Améliorez les outils d’implémentation existants pour éviter des configurations erronées similaires à l’avenir.
  3. Créez des alertes supplémentaires pour prévenir les équipes concernées en cas d’échec ou de problème d’initialisation.
  4. Enquêtez sur le suivi des mesures d’échec pour vous assurer que de tels incidents déclenchent des alertes pour une résolution rapide.

En mettant ces mesures pour remédier à la situation, nous nous efforçons d’améliorer la résilience de nos services et d’empêcher des incidents similaires à 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.

Modification le 04 déc. 2024 · Attila Takacs

0

Abonnés

1

vote

0

Commentaire


Attila Takacs a créé un article,

ArticleNotifications de service

SOMMAIRE

Le 14 novembre 2024, de 14 h 15 UTC à 23 h 20 UTC, les clients utilisant Explore ont rencontré des erreurs de réseau lors de l’accès aux rapports et aux tableaux de bord. 

 

Chronologie

14 novembre 2024 18h11 UTC | 14 novembre 2024 10h11 (heure du Pacifique)
Nous avons le plaisir de vous signaler que le problème à l’origine des messages d’erreur réseau lors du chargement des tableaux de bord ou des rapports Explore a été résolu. Nous vous remercions de votre patience pendant notre enquête.

14 novembre 2024 15h18 UTC | 14 novembre 2024 07h18 (heure du Pacifique)
Il est possible que certains utilisateurs d’Explore voient un message d’erreur réseau lors du chargement des tableaux de bord ou des rapports. Si cela se produit, vous devez effacer les cookies et le cache de votre navigateur pour résoudre le problème. Veuillez nous excuser de ce désagrément.

POST-MORTEM

Analyse de la cause

Cet incident est dû à un changement de réseau qui a augmenté le nombre d’en-têtes envoyés au service Explore au-delà de sa limite configurée. En conséquence, le service échouait « en informations » et les tableaux de bord ne se chargent pas pour les clients.

Résolution

Pour résoudre ce problème, l’équipe réseau a été chargée d’enquêter sur les modifications. Une fois le problème identifié, ils ont annulé les modifications qui ajoutaient des en-têtes excessifs, ce qui a rétabli une fonctionnalité normale pour les tableaux de bord Explore.

Éléments de correction

  • Améliorez les outils d’implémentation existants : Passez en revue et améliorez les outils utilisés pour gérer les limites d’en-tête dans les demandes API afin d’empêcher des incidents similaires.
  • Créez des alertes supplémentaires : Configurez des alertes pour surveiller les en-têtes et autres mesures critiques afin de détecter les problèmes avant qu'ils n'aient d'impact sur les clients.
  • Ajoutez des limites de connexion pour des applications spécifiques : Implémentez des limites de connexion pour les API afin de vous assurer qu’elles ne dépassent pas les seuils opérationnels et ainsi de réduire le risque d’incidents futurs.


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.

Modification le 03 déc. 2024 · Attila Takacs

1

Abonné

1

vote

0

Commentaire