Début avril, environ 400 sur plus de 200 000 clients Atlassian Cloud ont connu une panne complète de leurs produits Atlassian, selon des indications de l'éditeur. Atlassian, qui a accusé un script de maintenance, a rétabli les fonctionnalités pour tous ses clients un peu plus de deux semaines plus tard (le 18 avril). Si plusieurs clients ont souligné le manque de communication de l'entreprise, Atlassian a désormais fourni un rapport post-incident, en prenant la peine de présenter ses excuses aux clients impactés par le biais de ses cofondateurs. Début avril, 775 clients Atlassian ont perdu l'accès à leurs produits Atlassian. La panne a duré jusqu'à 14 jours pour un sous-ensemble de ces clients, le premier groupe de clients étant restauré le 8 avril et tous les sites clients étant progressivement restaurés le 18 avril.
Atlassian a assuré que ce n'était pas le résultat d'une cyberattaque et qu'il n'y a pas eu d'accès non autorisé aux données des clients. Atlassian indique qu'il dispose d'un programme complet de gestion des données avec des SLA publiés et un historique de dépassement de ces SLA.
L'impact sur les clients a été important, dans l'ensemble. De nombreuses entreprises ne disposaient pas de sauvegardes de documents critiques sur Confluence. Plusieurs entreprises utilisent l'outil de gestion des services pour leur service d'assistance : cela signifie que leur service d'assistance informatique est hors service pendant cette panne. Les plannings des entreprises ont été retardés, les projets ont dû être replanifiés ou retardés. L'impact de cette panne va bien au-delà de la simple ingénierie, car de nombreuses entreprises ont utilisé JIRA et Confluence pour collaborer avec d'autres fonctions commerciales.
Dans un billet, l'ingénieur Gergely Orosz a noté que « Pendant la majeure partie de cette panne, Atlassian est resté silencieux dans les communications sur ses principaux canaux tels que Twitter ou les forums communautaires. Il a fallu attendre le jour 9 pour que les dirigeants de l'entreprise reconnaissent la panne ». Et de préciser que « Atlassian n'a pas fait mieux pour communiquer avec les clients pendant cette période. Les entreprises concernées ont reçu des modèles d'e-mails et aucune réponse à leurs questions ».
La plus grande plainte de tous les clients a été la mauvaise communication d'Atlassian. Ces entreprises ont perdu tout accès aux systèmes clefs, étaient des clients payants, et pourtant, elles ne pouvaient pas parler à un humain. Jusqu'au jour 7, beaucoup d'entre elles n'ont reçu aucune communication, et même le jour 9, beaucoup n'ont encore reçu que les e-mails en masse sur les 2 semaines qu'il fallait pour une restauration totale, e-mails génériques qui étaient envoyés à chaque client impacté.
« Nous n'avons pas non plus été impressionnés par leur communication, ils l'ont définitivement bâclée », a déclaré le responsable ingénierie dans une entreprise de 2 000 personnes impactée.
« La communication Atlassian était mauvaise. Atlassian donnait les mêmes excuses boiteuses à notre équipe d'assistance interne que celles diffusées en ligne », a regretté un ingénieur logiciel dans une entreprise de 1 000 personnes impactée.
L'impact de la panne a été très important pour ceux qui comptent sur OpsGenie. OpsGenie est le système de gestion des incidents « PagerDuty for Atlassian ». Toutes les entreprises touchées par cette panne ont été exclues de cet outil.
Alors que plusieurs entreprises parvenaient à contourner le problème posé par l'état de JIRA et Confluence qui ne fonctionnaient pas, OpsGenie est un élément d'infrastructure essentiel pour tous les clients. Trois clients sur trois à qui Orosz a parlé ont intégré le concurrent PagerDuty, afin qu'ils puissent assurer le fonctionnement sécurisé de leurs systèmes.
Lettre des cofondateurs et co-PDG d'Atlassian
« Nous tenons à souligner la panne qui a interrompu le service pour les clients au début du mois. Nous comprenons que nos produits sont essentiels à la mission de votre entreprise et nous ne prenons pas cette responsabilité à la légère. La responsabilité nous incombe. Point final. Pour les clients concernés, nous nous efforçons de regagner votre confiance.
« Soyez assuré que la plateforme cloud d'Atlassian nous permet de répondre aux divers besoins de nos plus de 200 000 clients cloud de toutes tailles et de tous les secteurs. Avant cet incident, notre cloud offrait systématiquement une disponibilité de 99,9 % et dépassait les SLA de disponibilité. Nous avons réalisé des investissements à long terme dans notre plateforme et dans un certain nombre de capacités de plateforme centralisées, avec une infrastructure évolutive et une cadence constante d'améliorations de la sécurité.
« À nos clients et à nos partenaires, nous vous remercions pour votre confiance et votre partenariat continus. Nous espérons que les détails et les actions décrites dans ce document montrent qu'Atlassian continuera à fournir une plateforme cloud de classe mondiale et un puissant portefeuille de produits pour répondre aux besoins de chaque équipe.
« -Scott et Mike »
Que s'est-il passé ?
En 2021, Atlassian a finalisé l'acquisition et l'intégration d'une application Atlassian autonome pour Jira Service Management et Jira Software appelée « Insight - Asset Management ». La fonctionnalité de cette application autonome était alors native dans Jira Service Management et n'était plus disponible pour Jira Software. Pour cette raison, Atlassian devait supprimer l'ancienne application autonome sur les sites des clients qui l'avaient installée. Ses équipes d'ingénieurs ont utilisé un script et un processus existants pour supprimer les instances de cette application autonome, mais il y avait deux problèmes :
- manque de communication. Il y avait un écart de communication entre l'équipe qui a demandé la suppression et l'équipe qui a exécuté la suppression. Au lieu de fournir les identifiants de l'application destinée à être marquée pour suppression, l'équipe a fourni les identifiants de l'ensemble du site cloud où les applications devaient être supprimées ;
- avertissements système insuffisants. L'API utilisée pour effectuer la suppression acceptait les identifiants de site et d'application et supposait que l'entrée était correcte. Cela signifiait que si un identifiant de site était transmis, un site serait supprimé ; si un ID d'application était transmis, une application serait supprimée. Il n'y a eu aucun signal d'avertissement pour confirmer le type de suppression (site ou application) demandée.
« Le script qui a été exécuté a suivi notre processus standard d'examen par les pairs, qui s'est concentré sur quel point de terminaison était appelé et comment. Il n'a pas vérifié les ID de site cloud fournis pour valider s'ils faisaient référence à l'application ou à l'ensemble du site. Le script a été testé dans Staging conformément à nos processus standard de gestion des modifications, cependant, il n'aurait pas détecté que les ID entrés étaient incorrects, car les ID n'existaient pas dans l'environnement Staging.
« Lorsqu'il était exécuté en production, le script s'exécutait initialement sur 30 sites. La première exécution de production a réussi et a supprimé l'application Insight pour ces 30 sites sans autres effets secondaires. Cependant, les identifiants de ces 30 sites ont été obtenus avant l'événement de mauvaise communication et comprenaient les identifiants d'application Insight corrects.
« Le script de l'exécution de production suivante incluait des ID de site à la place des ID d'application Insight et s'exécutait sur un ensemble de 883 sites. Le script a commencé à s'exécuter le 5 avril à 07h38 UTC et s'est terminé à 08h01 UTC. Le script a supprimé les sites de manière séquentielle en fonction de la liste d'entrée, de sorte que le site du premier client a été supprimé peu de temps après le début de l'exécution du script à 07h38 UTC. Le résultat a été une suppression immédiate des 883 sites, sans signal d'avertissement pour nos équipes d'ingénierie.
« Les produits Atlassian suivants n'étaient pas disponibles pour les clients concernés : famille de produits Jira, Confluence, Atlassian Access, Opsgenie et Statuspage.
« Dès que nous avons appris l'incident, nos équipes se sont concentrées sur la restauration pour tous les clients impactés. À ce moment-là, nous avons estimé le nombre de sites impactés à environ 700 (883 sites au total ont été impactés, mais nous avons soustrait les sites appartenant à Atlassian). Sur les 700, une partie importante était constituée de comptes inactifs, gratuits ou de petits comptes avec un faible nombre d'utilisateurs actifs. Sur cette base, nous avons initialement estimé le nombre approximatif de clients concernés à environ 400.
« Nous avons maintenant une vue beaucoup plus précise, et pour une transparence totale basée sur la définition officielle des clients d'Atlassian, 775 clients ont été touchés par la panne. Cependant, la majorité des utilisateurs étaient représentés dans l'estimation initiale de 400 clients. La panne a duré jusqu'à 14 jours pour un sous-ensemble de ces clients, le premier groupe de clients étant rétabli le 8 avril et tous les clients étant rétablis le 18 avril ».
Que fait Atlassian pour prévenir de telles situations à l'avenir ?
Atlassian affirme avoir pris un certain nombre de mesures immédiates et s'engage à apporter des changements pour éviter cette situation à l'avenir. Voici quatre domaines spécifiques où l'entreprise a apporté ou apportera des changements importants :
- établissement des « suppressions logicielles » universelles sur tous les systèmes : Dans l'ensemble, une suppression de ce type devrait être interdite ou avoir plusieurs couches de protection pour éviter les erreurs, y compris un déploiement par étapes et un plan de restauration testé pour les « suppressions douces ». Nous empêcherons globalement la suppression des données client et des métadonnées qui n'ont pas été soumises à un processus de suppression réversible ;
- accélération dans notre programme de reprise après sinistre (DR) pour automatiser la restauration des événements de suppression multisites et multiproduits pour un plus grand nombre de clients : Nous tirerons parti de l'automatisation et des enseignements tirés de cet incident pour accélérer le programme DR afin d'atteindre l'objectif de temps de récupération (RTO) tel que défini dans notre politique pour cette ampleur d'incident. Nous effectuerons régulièrement des exercices de reprise après sinistre impliquant la restauration de tous les produits pour un grand nombre de sites ;
- révision du processus de gestion des incidents pour les incidents à grande échelle : nous améliorerons notre procédure d'exploitation standard pour les incidents à grande échelle et la pratiquerons avec des simulations de cette ampleur d'incident. Nous allons mettre à jour nos formations et nos outils pour gérer le grand nombre d'équipes travaillant en parallèle ;
- création d'un manuel de communication sur les incidents à grande échelle : nous accuserons réception des incidents tôt, via plusieurs canaux. Nous publierons des communications publiques sur les incidents en quelques heures. Pour mieux atteindre les clients concernés, nous améliorerons la sauvegarde des contacts clefs et moderniserons les outils d'assistance pour permettre aux clients sans URL ou ID Atlassian valides d'entrer en contact direct avec notre équipe d'assistance technique.
L'impact de la panne sur l'activité d'Atlassian
Orosz a demandé aux clients s'ils accepteraient de quitter Atlassian à la suite de la panne. La plupart d'entre eux ont déclaré qu'ils ne quitteraient pas la pile Atlassian, tant qu'ils ne perdraient pas de données. En effet, la migration est complexe et ils ne voient pas qu'une migration réduirait le risque de défaillance d'un fournisseur de cloud. Cependant, tous les clients ont déclaré qu'ils investiraient dans un plan de sauvegarde en cas de panne d'un SaaS sur lequel ils comptent.
Pour Orosz, l'impact le plus important de cette panne n'est pas la perte de revenus : il s'agit d'une atteinte à la réputation et pourrait nuire aux efforts de vente Cloud à plus long terme :
« Ce qui fait peur dans la façon dont la panne s'est déroulée, c'est que n'importe quelle entreprise aurait pu perdre tout accès à Atlassian Cloud pendant des semaines. Je suis sûr que l'entreprise prendra des mesures pour atténuer ce qui se passe. Cependant, la confiance est une confiance facile à perdre et difficile à gagner.
« Malheureusement pour l'entreprise, Atlassian a un historique d'incidents répétés de la pire espèce. En 2015, leur produit HipChat a subi une faille de sécurité, cette faille faisant fuir des clients comme Coinbase à l'époque. Seulement deux ans plus tard, en 2017, HipChat a subi une nouvelle faille de sécurité. Cette deuxième récidive a été la raison pour laquelle Uber a suspendu son utilisation de HipChat avec effet immédiat.
« L'ironie de la panne est la façon dont Atlassian poussait les clients vers son offre Cloud, mettant en avant la fiabilité comme argument de vente. Ils ont cessé de vendre des licences Server et cesseront de prendre en charge le produit en février 2024
« Cette violation et l'historique des infractions répétées avec un incident spécifique combinés soulèveront des questions pour les entreprises utilisant actuellement le produit Server sur la confiance qu'elles accorderont à Atlassian on the Cloud. Si elles sont obligées de faire la migration, choisiront-elles un autre fournisseur à la place ? »
Source : Atlassian
Et vous ?
Que pensez-vous des résolutions prises par Atlassian ? La bonne direction pour regagner la confiance des clients ? Que pensez-vous de l'analyse d'Orosz ?