Plusieurs services atlasiens connaissent des problèmes
- investigating
Nous rencontrons des problèmes avec plusieurs produits Atlassiens. Nos équipes enquêtent et d'autres mises à jour, y compris seront partagées dans un délai d'une heure.
- identified
Nous avons constaté que la cause profonde de la question est liée à une panne d'infrastructure de notre fournisseur de cloud public. Nous travaillons en étroite collaboration avec eux pour atténuer cette question. Nous fournirons d'autres mises à jour lorsqu'elles seront disponibles.
- identified
Nos équipes continuent de travailler à atténuer la panne d'infrastructure de notre fournisseur de cloud public. Nous fournirons d'autres mises à jour lorsqu'elles seront disponibles.
- identified
Nous continuons de travailler avec notre fournisseur de services de cloud public pour atténuer ce problème. Nous commençons à voir une certaine reprise dans des régions en dehors de l'Est des États-Unis, cependant, les utilisateurs à l'échelle mondiale peuvent encore éprouver des problèmes avec certaines caractéristiques de produit. Ceux-ci sont énumérés au bas de chaque page de produit.
- monitoring
La question sous-jacente de l'infrastructure publique qui a affecté le traitement asynchrone des événements a été atténuée et tous les services touchés se rétablissent. Nous travaillons maintenant sur la compensation de l'arriéré des événements en attente, ce qui signifie que certaines actions (comme les notifications, les déclencheurs d'automatisation et les synchronisations de données) peuvent être dégradées. Nous continuerons de surveiller et de fournir des mises à jour à mesure que l'arriéré sera réglé.
- monitoring
Nous continuons de surveiller la situation à mesure que les services se rétablissent. Nous sommes actuellement en train de résorber l'arriéré des événements en attente. Nous fournirons une nouvelle mise à jour dans environ une heure.
- monitoring
Nos services sont maintenant pleinement opérationnels. Nous continuons à rejouer tous les événements qui ont été manqués pendant l'incident et nous faisons de bons progrès. Nous fournirons une nouvelle mise à jour une fois les replays terminés. Si vous rencontrez des problèmes permanents, veuillez contacter notre équipe de soutien. Nous nous excusons pour cette perturbation et vous remercions de votre patience.
- resolved
Le 8 mai 2026, certains clients utilisant des produits Atlassian ont connu des taux d'erreur élevés et des performances dégradées. Le problème a maintenant été résolu et le service fonctionne normalement pour tous les clients touchés.
- postmortem
Toutes les dates et heures ci-dessous sont en UTC sauf indication contraire. Résumé Le 8 mai, 2026 entre 00:22 et 06:08, l'un de nos fournisseurs d'hébergement a subi un incident important dans une zone de disponibilité spécifique en prod-est qui a conduit à des clients atlassiens subissant des performances dégradées et des retards d'opérations de fond et d'exécution d'automatisation. L'incident a commencé le 8 mai 2026 à 00h22 et a été détecté dans les 4 minutes par des systèmes de surveillance automatisés. Nos équipes ont travaillé à restaurer l'accès au noyau d'ici 06:08. Le nettoyage final des processus en retard et des questions mineures a progressé par étapes à partir de là a été achevé itérativement vers 19:15. ### ** IMPACT** L'infrastructure principale affectée par cet incident était le pipeline de traitement des événements dans la région prod-est, qui distribue les événements entre les services Atlassiens et sous-tend les opérations de fond telles que l'exécution automatique, l'indexation des recherches, les notifications, la synchronisation des autorisations. * Entre 00:22 et 06:08, un incident d'infrastructure dans notre fournisseur d'hébergement a déclenché une défaillance d'ingestion dans notre pipeline de traitement des événements. * À 02h50, l'ingestion de l'événement a échoué dans une zone de disponibilité non affectée, rétablissant progressivement les flux d'événements vivants. * A 06:08, la fiabilité pour une nouvelle ingestion dans le prod-east récupéré à 100%. Le reste du travail consistait à drainer l'arriéré de messages accumulé entre les régions, qui s'est terminé à 17 h. * En 18:48, Automation avait traité leur arriéré d'événements qui ont été créés pendant le traitement **Automation** Entre 00:22 et 02:50, les clients avec des règles d'automatisation déclenchées par des événements provenant de la région prod-est ont connu une réduction significative des exécutions de règles. Au cours de cette fenêtre, les règles d'automatisation déclenchées par des événements n'ont pas été lancées parce que les événements qui les ont déclenchés n'étaient pas livrés. La rédaction, l'enregistrement et les règles déclenchées manuellement, par des horaires ou par des webhooks n'ont pas été affectés. À 02h50, l'infrastructure de traitement des événements a échoué dans une zone de disponibilité non affectée, rétablissant la livraison des événements en direct à Automation et permettant à de nouvelles règles déclenchées par des événements de commencer à exécuter normalement. Cependant, les événements générés pendant la fenêtre d'impact devaient encore être rejoués avant que les automatisations retardées puissent être traitées. À partir de 08h28, les services en amont ont rejoué leurs événements en file d'attente dans une séquence coordonnée, et tous les événements rejoués ont été traités par 18h48. Au cours de la fenêtre de replay, les clients ont peut-être connu des règles d'automatisation exécutées plus tard que prévu, un petit nombre de règles atteignant des limites de traitement quotidiennes en raison de la replay compressée, et des règles sensibles au temps ne s'achevant pas comme prévu en cas de dépassement des seuils de délai interne. ** Gestion des services Jira et Jira** Entre 00:22 et 02:50, les clients avec des locataires hébergés dans la région de prod-est ont subi une perturbation des fonctionnalités de Jira et de Jira Service Management, comme l'automatisation, ainsi qu'une courte période d'erreurs élevées pendant la panne d'infrastructure. Les expériences de Core Jira, y compris la vue des enjeux, les planches et la navigation des projets, sont demeurées disponibles tout au long de l'incident. La livraison des événements de Jira a été affectée par l'impact principal, empêchant les services en aval de recevoir des événements liés au cycle de vie. Cela a affecté les règles d'automatisation déclenchées par les événements de Jira, l'orchestration d'agents d'IA en Jira, les notifications pour les mises à jour des numéros et les transitions, l'indexation des recherches pour les nouveaux problèmes créés ou modifiés, et les intégrations d'événements entre Jira et d'autres produits Atlassian. À 02h50, l'infrastructure de traitement des événements a échoué dans une zone de disponibilité non affectée, rétablissant la livraison de nouveaux événements. Tous les événements générés pendant la fenêtre d'impact ont été conservés dans une file d'attente de récupération et ont nécessité un rejouage. Cela a commencé à 8 h 28 et s'est terminé à 12 h. Pendant le replay, les clients peuvent avoir expérimenté des règles d'automatisation exécutant plus tard que prévu, des notifications retardées arrivant des heures après l'action de déclenchement, des lacunes temporaires dans les résultats de recherche pour le contenu créé ou modifié pendant la fenêtre d'impact, et des flux de travail d'agents d'IA qui ne se terminent pas comme prévu là où les seuils de délai interne ont été dépassés. **Confluence** Entre 00:22 et 02:50, les clients avec des locataires hébergés dans la région de prod-est ont connu des perturbations aux services d'événements à Confluence. Cela a entraîné des retards dans l'indexation des recherches, les notifications, l'exécution des règles d'automatisation et la synchronisation des autorisations. L'infrastructure de traitement des événements sous-jacente a échoué dans une zone de disponibilité non affectée, après quoi les opérations de Confluence ont repris normalement. Cependant, les événements générés pendant la fenêtre d'impact ont été en attente pour le replay, et certains services de fond sont restés retardés jusqu'à ce que le replay et les travaux de validation connexes soient terminés. Entre 10h14 et 17h00, un replay en bloc de toutes les tâches de replay des locataires en attente a été effectué pour restaurer la cohérence des données. Pendant et immédiatement après la fenêtre de replay, les clients peuvent avoir expérimenté des résultats de recherche ne reflétant pas le contenu créé ou modifié pendant la panne, des notifications retardées ou manquantes pour l'activité de page et de commentaire, des règles d'automatisation tirant plus tard que prévu, et de brefs retards dans la synchronisation de l'autorisation pour les locataires s'appuyant sur la synchronisation d'identité progressive. **Bitbucket et pipelines** Entre 00:22 et 06:08, les clients utilisant Bitbucket et Pipelines ont connu des défaillances et des fonctionnalités dégradées à travers les workflows animés par des événements. Les opérations du noyau Git, y compris la poussée, la traction et le clone, n'ont pas été affectées et ont continué à fonctionner normalement tout au long de l'incident. Les déclencheurs de pipelines automatiques déclenchés par des événements de demande de poussée ou de traction n'étaient pas disponibles pendant la fenêtre d'impact. Fusionner les files d'attente, les vérifications de fusion personnalisées, les déclencheurs basés sur Forge, les modifications des permissions d'espace de travail et certains flux de provisionnement d'espace de travail ont également été touchés. Les clients utilisant les files d'attente de fusion n'étaient pas en mesure de fusionner les requêtes de tirage, et certaines étapes du pipeline ont échoué parce que les travaux en file d'attente contribuaient à des limites de concordance élevées. Vers 03h57, Pipelines a été reconfiguré pour consommer des événements par un chemin alternatif, en rétablissant le déclenchement automatique du pipeline. Fusionner les files d'attente, les vérifications de fusion personnalisées, les déclencheurs Forge et d'autres workflows touchés ont été progressivement restaurés à mesure que l'infrastructure de traitement des événements sous-jacents a été récupérée. Tous les services de Bitbucket et de Pipelines ont été confirmés pleinement opérationnels à 06:08. Après la récupération, les événements en attente ont été examinés et rejoués là où ils étaient sûrs de rétablir l'uniformité des données pour la facturation, l'enregistrement des vérifications et d'autres processus de base. **Services d'identité** Entre 00:22 et 02:50, les clients avec des locataires hébergés dans la région prod-est ont connu des retards dans la propagation de l'identité et de l'adhésion de groupe aux produits atlasiens en aval. Les opérations d'identité de base, y compris les mesures d'authentification, de connexion et de gestion directe des groupes, n'ont pas été touchées et ont continué de fonctionner normalement tout au long de l'incident. L'impact s'est limité aux opérations asynchrones axées sur les événements qui dépendent du pipeline de traitement des événements. Cela incluait des retards dans la livraison de l'adhésion de groupe et des changements de profil d'utilisateur à des produits tels que Jira et Confluence, qui ont affecté la synchronisation des autorisations en aval et les flux de synchronisation de foule. Un petit nombre de processus de synchronisation d'identité basés sur SCIM et de fourniture de sites ont également connu des retards temporaires. Une fois l'infrastructure de traitement des événements récupérée, les événements liés à l'identité sauvegardée et au répertoire de groupe ont été rejoués au besoin, ce qui a permis de rétablir la cohérence en aval des produits touchés. Aucune donnée d'identité n'a été perdue. Les changements d'adhésion au groupe, les mises à jour du profil de l'utilisateur et les événements liés à la fourniture qui se sont produits pendant la fenêtre d'impact ont été conservés et traités après la récupération. ** PLAN D'ACTION ET PROCHAINES ÉTAPES** Nous savons que les pannes affectent votre productivité. Bien que nos processus de surveillance et de rétablissement nous aient aidés à réagir rapidement, cet incident a mis en évidence des occasions de renforcer encore la résilience des services axés sur les événements. Nous accordons la priorité aux améliorations qui : * **Couverture en cas de panne d'équipement** afin que le traitement des événements critiques puisse se rétablir plus facilement pendant les perturbations de l'infrastructure. * **Matériel de récupération renforcé** afin que les événements rejoués puissent être traités plus rapidement. Nous nous excusons auprès des clients dont les services ont été touchés pendant cet incident; nous prenons des mesures immédiates pour améliorer la performance et la disponibilité de la plateforme. Merci, Assistance client Atlassian.
Traduit automatiquement depuis la mise à jour officielle de l'incident.