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
- Mettez à niveau et passez à la version corrigée ou supérieure avant de reprendre les modifications du schéma.
- Vous pouvez séparer les ajouts de colonnes et les baisses d’index pour minimiser les risques pendant les déploiements.
- 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.
- 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.
0 commentaire