Discussion :

[Stéphane le calme]

Atlassian accuse un script de maintenance d'avoir accidentellement désactivé plusieurs de ses services cloud pendant une semaine
et estime qu'il faudra deux semaines supplémentaires pour une restauration totale

Le développeur d'outils de développement de logiciels et de collaboration Atlassian accuse un récent script de maintenance d'avoir accidentellement désactivé plusieurs de ses services cloud, qui sont en panne depuis un peu plus d'une semaine :

« Lors de l'exécution d'un script de maintenance, un petit nombre de sites ont été désactivés involontairement. Nous sommes désolés pour la frustration causée par cet incident et nous continuons à passer par les différentes étapes de restauration. C'est notre priorité absolue et nous avons mobilisé des centaines d'ingénieurs dans toute l'organisation pour travailler 24 heures sur 24 afin de remédier à l'incident. Pendant que nous nous efforçons de restaurer l'accès, vous pouvez compter sur nous pour continuer à fournir des mises à jour sur : http://status.atlassian.com. Vous pouvez continuer à nous contacter sur https://support.atlassian.com/contact pour toute question, préoccupation ou mise à jour. Si vous rencontrez des problèmes pour ouvrir un ticket d'assistance technique, veuillez ouvrir un ticket de question sur la facturation et nous le transférerons aux équipes d'assistance. Nous nous attendons à ce que la plupart des récupérations de sites se produisent avec une perte de données minimale ou nulle ».

Atlassian a d'abord reconnu la panne sur sa page d'état le 5 avril à 9h03 UTC.

Les services qui continuent d'être impactés incluent Jira Software, Jira Work Management, Jira Service Management, Confluence, Opsgenie Cloud (acquis en 2018), Statuspage et Atlassian Access. Confluence est un wiki d'entreprise basé sur le Web et Jira concerne davantage le suivi des problèmes. Jira Work Management est destiné à la gestion de projet générique tandis que Jira Service Management est apparu l'année dernière dans le cadre d'une vision visant à appliquer les principes agiles et DevOps au service desk informatique. L'ironie de l'effondrement de ce dernier en raison d'un problème avec un script de maintenance n'aura pas été perdue pour les utilisateurs concernés.

Concernant la liste des services Atlassian indisponibles, le service de surveillance des incidents informatiques, OpsGenie (acquis en 2018) et le service de communication des incidents Statuspage d'Atlassian n'auront pas manqué de faire tourner le compteur d'ironie sur les réseaux sociaux.

Atlassian a initialement estimé que ses efforts de restauration ne prendraient pas plus de quelques jours et a confirmé que l'incident n'était pas le résultat d'une cyberattaque qui aurait conduit à un accès non autorisé aux données.

Cependant, dans les e-mails envoyés aux clients concernés, la société a révélé que la restauration des services aux personnes concernées prendra probablement jusqu'à deux semaines supplémentaires : « Nous n'avons pas été en mesure de confirmer un ETA plus ferme jusqu'à présent en raison de la complexité du processus de reconstruction de votre site. Alors que nous commençons à ramener certains clients en ligne, nous estimons que l'effort de reconstruction durera jusqu'à 2 semaines supplémentaires », a rapporté Kjartan Rekdal Müller, Team Lead chez NEP Mediaservices. Il indique que la structure pour laquelle il travaille a reçu ce message de la part d'Atlassian.

« Je sais que ce n'est pas la nouvelle que vous espériez. Nous nous excusons pour la durée et la gravité de cet incident et avons pris des mesures pour éviter qu'il ne se reproduise à l'avenir », a déclaré Atlassian à un autre client concerné.

Bien que l'impact sur les entreprises utilisant ses produits soit indéniable, Atlassian a déclaré vendredi qu'environ 400 de ses plus de 200 000 clients sont concernés.

La société affirme avoir été en mesure de restaurer les fonctionnalités de plus de 35 % de tous les utilisateurs directement touchés par cette panne en cours sans, apparemment, aucune perte de données :

« Un petit nombre de clients Atlassian continuent de subir des interruptions de service et ne peuvent pas accéder à leurs sites. Nos équipes mondiales d'ingénieurs travaillent 24h/24 et 7j/7 pour progresser sur la résolution de cet incident. À l'heure actuelle, nous avons reconstruit les fonctionnalités de plus de 35 % des utilisateurs touchés par la panne de service, sans aucune perte de données signalée. L'étape de reconstruction est particulièrement complexe en raison de plusieurs étapes nécessaires pour valider les sites et vérifier les données. Ces étapes nécessitent plus de temps, mais sont essentielles pour assurer l'intégrité des sites reconstruits. Nous nous excusons pour la durée et la gravité de cet incident et avons pris des mesures pour éviter qu'il ne se reproduise à l'avenir ».

Cette interruption des services cloud survient après que le cofondateur et co-PDG d'Atlassian, Scott Farquhar, a annoncé en octobre 2020 que la société ne vendrait plus de licences pour les produits sur site à partir de février 2021 et interromprait le support trois ans plus tard, le 2 février 2024.

« Le 2 février 2021, heure du Pacifique (PT), les modifications suivantes entreront en vigueur :

• fin des ventes de nouvelles licences de serveur : vous ne pouvez plus acheter ou demander un devis pour un nouveau produit de serveur ;
• mises à jour des prix des serveurs : nous mettrons en place de nouveaux prix pour les renouvellements et les mises à niveau des serveurs.

Le 2 février 2024 PT, le changement suivant entrera en vigueur :

• fin du support pour tous les produits serveur : cela signifie que le support et les corrections de bogues ne seront plus disponibles pour vos produits serveur.

« Pour faciliter une transition en douceur, nous offrirons trois ans de support et de maintenance pour vos produits de serveur et fournirons des remises de fidélité aux clients éligibles pour passer à nos produits cloud ou Data Center à un prix inférieur. Pour ceux qui sont prêts à explorer le cloud, nous avons créé le programme de migration Atlassian (AMP) qui vous fournit des guides étape par étape, des outils de migration gratuits, une équipe d'assistance dédiée à la migration et un essai gratuit de migration vers le cloud pour la durée de votre maintenance restante du serveur jusqu'à 12 mois(...).

« Même avec trois ans pour se préparer à ces changements, nous comprenons que tous les clients ne seront pas prêts à passer de nos produits serveur à nos produits cloud. Et certains d'entre vous ont des exigences commerciales qui pourraient vous empêcher d'opérer dans le cloud.

« Pour ces clients, nous continuerons à proposer notre édition d'entreprise robuste et autogérée, Atlassian Data Center. Cela comprendra de nouvelles fonctionnalités et intégrations qui faciliteront l'utilisation conjointe de nos produits cloud et de centre de données, comme l'unification de l'expérience d'administration pour des domaines tels que la gestion des utilisateurs.

« Nous renforçons également Atlassian Data Center en rendant certaines de nos applications les plus puissantes disponibles en mode natif et en proposant une assistance prioritaire avec des abonnements Data Center pour la plupart des niveaux d'utilisateurs. Pour soutenir cette innovation continue, nous mettrons à jour le prix des abonnements au centre de données le 2 février 2021 PT ».

Sources : Atlassian (1, 2, 3, 4)

Et vous ?

Êtes-vous concernés par cette panne ?
Un incident qui pourrait être utilisé comme argument par ceux qui hésitent à passer au cloud ?

Voir aussi :

Incendie OVH : absence de système d'extinction incendie automatique et de dispositif de coupure électrique général, le rapport des pompiers souligne des défaillances

[Stéphane le calme]

Panne géante des services Cloud d'Atlassian : comment des centaines de sociétés ont perdu leur accès à JIRA, Confluence et OpsGenie.
Atlassian est restée silencieuse pendant des jours. L'impact sur les clients a été important, dans l'ensemble

Le lundi 4 avril, environ 400 sur plus de 200 000 clients Atlassian Cloud ont connu une panne complète de leurs produits Atlassian. Ce dernier affirme être en train de restaurer les sites et annonce avoir rétabli le service pour environ 45 % des utilisateurs concernés : « Nous prévoyons un rétablissement complet pour le reste de nos clients dans les deux prochaines semaines ». Mais quel est l'impact sur les activités des entreprises clientes ? Ces dernières se sont plaintes du manque de communication d'Atlassian à ce sujet. Durant la panne, Atlassian est restée silencieuse pendant des jours et ce n'est qu'après neuf jours qu'un dirigeant a pris la parole.

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.

Le développeur d'outils de développement de logiciels et de collaboration Atlassian accuse un récent script de maintenance d'avoir accidentellement désactivé plusieurs de ses services cloud, qui sont en panne depuis un peu plus d'une semaine :

« Lors de l'exécution d'un script de maintenance, un petit nombre de sites ont été désactivés involontairement. Nous sommes désolés pour la frustration causée par cet incident et nous continuons à passer par les différentes étapes de restauration. C'est notre priorité absolue et nous avons mobilisé des centaines d'ingénieurs dans toute l'organisation pour travailler 24 heures sur 24 afin de remédier à l'incident. Pendant que nous nous efforçons de restaurer l'accès, vous pouvez compter sur nous pour continuer à fournir des mises à jour sur : http://status.atlassian.com. Vous pouvez continuer à nous contacter sur https://support.atlassian.com/contact pour toute question, préoccupation ou mise à jour. Si vous rencontrez des problèmes pour ouvrir un ticket d'assistance technique, veuillez ouvrir un ticket de question sur la facturation et nous le transférerons aux équipes d'assistance. Nous nous attendons à ce que la plupart des récupérations de sites se produisent avec une perte de données minimale ou nulle ».

Atlassian a d'abord reconnu la panne sur sa page d'état le 5 avril à 9h03 UTC.

Les services qui continuent d'être impactés incluent Jira Software, Jira Work Management, Jira Service Management, Confluence, Opsgenie Cloud (acquis en 2018), Statuspage et Atlassian Access. Confluence est un wiki d'entreprise basé sur le Web et Jira concerne davantage le suivi des problèmes. Jira Work Management est destiné à la gestion de projet générique tandis que Jira Service Management est apparu l'année dernière dans le cadre d'une vision visant à appliquer les principes agiles et DevOps au service desk informatique. L'ironie de l'effondrement de ce dernier en raison d'un problème avec un script de maintenance n'aura pas été perdue pour les utilisateurs concernés.

Ce qui s'est passé

« L'une de nos applications autonomes pour Jira Service Management et Jira Software, appelée "Insight - Asset Management", a été entièrement intégrée à nos produits en tant que fonctionnalité native. Pour cette raison, nous devions désactiver l'ancienne application autonome sur les sites des clients qui l'avaient installée. Nos équipes d'ingénieurs ont prévu d'utiliser un script existant pour désactiver les instances de cette application autonome. Cependant, deux problèmes critiques se sont posés :

• manque de communication : Tout d'abord, il y avait un manque de communication entre l'équipe qui a demandé la désactivation et l'équipe qui a exécuté la désactivation. Au lieu de fournir les identifiants de l'application destinée à être marquée pour la désactivation, l'équipe a fourni les identifiants de l'ensemble du site cloud où les applications devaient être désactivées ;
• scénario défectueux : Deuxièmement, le script que nous avons utilisé fournissait à la fois la capacité "marquer pour suppression" utilisée dans les opérations quotidiennes normales (où la capacité à être récupéré est souhaitable) et la capacité "supprimer définitivement" qui est nécessaire pour supprimer définitivement les données lorsque cela est nécessaire pour des raisons de conformité. Le script a été exécuté avec le mauvais mode d'exécution et la mauvaise liste d'ID. Le résultat a été que les sites d'environ 400 clients ont été supprimés de manière inappropriée.

Pour se remettre de cet incident, notre équipe d'ingénierie mondiale a mis en place un processus méthodique pour restaurer nos clients touchés ».

Ce que fait Atlassian pour tout remettre en marche

« Atlassian Data Management décrit en détail nos processus de gestion des données.

« Pour garantir une haute disponibilité, nous provisionnons et maintenons une réplique de secours synchrone dans plusieurs zones de disponibilité AWS (AZ). Le basculement AZ est automatisé et prend généralement 60 à 120 secondes, et nous gérons régulièrement les pannes du centre de données et d'autres perturbations courantes sans impact sur le client.

« Nous maintenons également des sauvegardes immuables conçues pour résister aux événements de corruption de données, ce qui permet une restauration à un point antérieur dans le temps. Les sauvegardes sont conservées pendant 30 jours, et Atlassian teste et audite en permanence les sauvegardes de stockage pour la restauration.

« À l'aide de ces sauvegardes, nous annulons régulièrement des clients individuels ou un petit groupe de clients qui suppriment accidentellement leurs propres données. Et, si nécessaire, nous pouvons restaurer tous les clients en même temps dans un nouvel environnement.

« Ce que nous n'avons pas (encore) automatisé, c'est la restauration d'un grand sous-ensemble de clients dans notre environnement existant (et actuellement utilisé) sans affecter aucun de nos autres clients.

« Dans notre environnement cloud, chaque magasin de données contient des données provenant de plusieurs clients. Étant donné que les données supprimées lors de cet incident ne représentaient qu'une partie des magasins de données qui continuent d'être utilisés par d'autres clients, nous devons extraire et restaurer manuellement des éléments individuels de nos sauvegardes. Chaque restauration de site client est un processus long et complexe, nécessitant une validation interne et une vérification finale par le client lors de la restauration du site ».

Dans les coulisses de la plus longue panne qu'ait jamais connue Atlassian, la perspective externe d'un ingénieur

Dans un billet, 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 ».

Voici sa perspective sur ce qui s'est passé.

Jour 1 - lundi 4 avril

JIRA, Confluence, OpsGenie et d'autres sites Atlassian cessent de fonctionner dans certaines entreprises.

Jour 2 - mardi 5 avril

Atlassian remarque l'incident et commence à le suivre sur sa page d'état. Ils publient plusieurs mises à jour ce jour, confirmant qu'ils travaillent sur un correctif. Ils clôturent la journée en disant « Nous fournirons plus de détails au fur et à mesure que nous avancerons dans la résolution ».

Pendant ce temps, le personnel et les clients d'Atlassian se sont tournés vers l'événement annuel phare d'Atlassian, Team 22, organisé à Las Vegas. De nombreux employés de l'entreprise, une grande partie de l'équipe de direction et de nombreux partenaires Atlassian se sont déplacés pour assister à l'événement en personne. La plupart des années, les annonces de produits lors de cet événement auraient dominé toute la semaine pour les actualités d'Atlassian.

Pendant qu'Atlassian se concentrait sur Team 22, les clients étaient frustrés. Beaucoup d'entre eux ont essayé de contacter Atlassian, mais la plupart d'entre eux n'ont pas eu de retour. Certains clients font part de leur frustration à Twitter. Ce fil de discussion d'un client impacté a rapidement suscité des réponses d'autres clients impactés :

Jour 3 - mercredi 6 avril

Atlassian publie les mêmes mises à jour toutes les quelques heures, sans partager aucune information pertinente. Sur la mise à jour, nous pouvons lire :

« Nous poursuivons le travail dans la phase de vérification sur un sous-ensemble d'instances. Une fois réactivé, le support mettra à jour les comptes via les tickets d'incident ouverts. La restauration des sites clients reste notre première priorité et nous nous coordonnons avec les équipes du monde entier pour garantir que le travail se poursuive 24h/24 et 7j/7 jusqu'à ce que toutes les instances soient restaurées ».

Les clients ne reçoivent aucune communication directe. Certains s'en vont sur les réseaux sociaux pour se plaindre.

Jour 4 - jeudi 7 avril

Le compte Twitter d'Atlassian reconnaît le problème et offre quelques détails légers. Ces tweets seront la dernière communication de ce compte officiel avant qu'il ne devienne silencieux pendant 5 jours consécutifs.

La page d'état d'Atlassian publie exactement la même mise à jour toutes les quelques heures.

Jours 5-7 - vendredi 8 avril - dimanche 10 avril

Pas de vraies mises à jour. Atlassian publie le même message sur sa page d'état encore et encore et encore… :

« L'équipe poursuit le processus de restauration tout au long du week-end et travaille à la récupération. Nous améliorons continuellement le processus en nous basant sur les commentaires des clients et en appliquant ces apprentissages à mesure que nous amenons plus de clients en ligne. »

Le dimanche 10 avril, publication d'un article sur la panne sur Twitter. L'incident devient viral sur les réseaux sociaux et un ancien employé d'Atlassian déclare : « Cela ne me surprend pas du tout. (...) chez Atlassian, leur processus et leur suivi des incidents sont une blague. Plus de la moitié des incidents sont détectés par les clients. La plupart des pratiques d'ingénierie chez Atlassian se concentrent uniquement sur la bonne voie, presque personne ne considère ce qui peut mal tourner. Chaque système est tellement interconnecté, et il y a plus de SPOF que d'employés ». Dans un système informatique, le single point of failure (Spof, ou « point unique de défaillance » en français) désigne un point dont dépend le reste du système.

Jour 9 - mardi 12 avril

Atlassian envoie une communication de masse aux clients. Plusieurs clients impactés reçoivent le même message :

« Nous n'avons pas été en mesure de confirmer un ETA plus ferme jusqu'à présent en raison de la complexité du processus de reconstruction de votre site. Bien que nous commencions à ramener certains clients en ligne, nous estimons que l'effort de reconstruction durera jusqu'à 2 semaines supplémentaires ».

Atlassian met également à jour sa page de statut, affirmant que 35 % des clients ont été restaurés.

Pour la première fois depuis le début de l'incident, Atlassian publie une déclaration. Ils affirment que des centaines d'ingénieurs travaillent sur la question. Dans leur déclaration, ils affirment également :

« Nous communiquons directement avec chaque client ».

Néanmoins, un client a envoyé un message à Orosz dans lequel il affirme que cette dernière affirmation d'Atlassian n'est pas vraie, car son entreprise ne reçoit que des réponses standardisées, et aucun détail, malgré les questions. Orosz répond donc à l'entreprise, soulignant le rapport des clients selon lequel ils n'ont aucune communication directe, bien qu'ils soient des clients payants :

En réponse, c'est la première fois qu'un dirigeant reconnaît les problèmes d'Atlassian. Sri Viswanath, CTO Atlassian, a partagé une déclaration que la société publie à ce moment-là, et dont la déclaration commence par des excuses que les clients concernés attendaient :

« Permettez-moi de commencer par dire que cet incident et notre temps de réponse ne sont pas à la hauteur de nos normes, et je m'excuse au nom d'Atlassian ».

Le responsable de l'ingénierie, Stephen Deasy, publie un Q&A sur l'incident actif dans la communauté Atlassian.

Ce que disent les clients Atlassian

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 leurs communications, ils l'ont définitivement bâclé », 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.

L'impact sur les clients a été important, dans l'ensemble. De nombreuses entreprises ne disposaient pas de sauvegardes de documents critiques sur Confluence. Aucun de ceux avec qui Orosz a parlé n'avait de sauvegardes JIRA. 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.

Quittera, quittera pas ?

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.

Les clients qui ont confirmé leur migration sont ceux qui intègrent PagerDuty. Ils considèrent PagerDuty comme une offre plus fiable et ont tous été alarmés par le fait qu'Atlassian n'a pas donné la priorité à la restauration d'OpsGenie avant les autres services.

L'impact de la panne sur l'activité d'Atlassian

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 ? »

Les enseignements de cette panne

Orosz estime qu'il y a beaucoup d'apprentissages sur cette panne que toute équipe d'ingénierie peut tirer. N'attendez pas qu'une panne comme celle-ci frappe vos équipes : préparez-vous plutôt à l'avance.

Voici ce qu'il propose pour le traitement des incidents :

• ayez un runbook pour la reprise après sinistre et les événements de cygne noir. Attendez-vous à l'inattendu et planifiez la façon dont vous réagirez, évaluerez et communiquerez ;
• suivez votre propre runbook de reprise après sinistre. Atlassian a publié son runbook de reprise après sinistre pour Confluence, et pourtant, n'a pas suivi ce runbook. Leur runbook indique que tout runbook a des directives de communication et d'escalade. Soit l'entreprise n'avait pas de directives de communication, soit elle ne les a pas suivies ;
• communiquez directement et de manière transparente. Atlassian n'a rien fait de tout cela jusqu'à 9 jours. Ce manque de communication a érodé une énorme quantité de confiance non seulement entre les clients concernés, mais aussi avec toute personne au courant de la panne. Alors qu'Atlassian aurait pu supposer qu'il est prudent de ne rien dire : c'est le pire choix à faire. Notez à quel point GitLab ou Cloudflare communiquent en toute transparence pendant les pannes - deux sociétés cotées en bourse, tout comme Atlassian ;
• parlez la langue de votre client. Les mises à jour de statut Atlassian étaient vagues et manquaient de tous les détails techniques. Cependant, leurs clients n'étaient pas des hommes d'affaires. Ce sont les responsables informatiques et les directeurs techniques qui ont fait le choix d'acheter des produits Atlassian… et ne pouvaient désormais pas répondre au problème du système. En simplifiant la messagerie, Atlassian a mis ses plus grands sponsors : les techniciens ! - dans une situation impossible à tenir. Si l'entreprise voit le taux de désabonnement des clients, Orosz l'attribue grandement à cette erreur ;
• un exécutif prenant la responsabilité publique de la panne. Il a fallu attendre le jour 9 pour qu'un niveau C reconnaisse cette panne. Encore une fois, dans les entreprises auxquelles les développeurs font confiance, cela se produit presque immédiatement. Les dirigeants qui ne publient pas de déclaration signalent que le problème est trop petit pour qu'ils s'en soucient ;
• contactez directement les clients et parlez-leur. Les clients ne se sont pas sentis entendus pendant cette panne et n'ont eu aucun contact humain avec eux. Ils se sont retrouvés avec des messages automatisés. Lors d'un événement de ce type, mobilisez les gens pour parler directement aux clients - vous pouvez le faire sans affecter l'effort d'atténuation ;
• évitez les mises à jour de statut qui ne disent rien. La majorité des mises à jour de statut sur la page de l'incident consistaient à copier-coller la même mise à jour. Atlassian a clairement fait cela pour fournir des mises à jour toutes les quelques heures… mais ce n'étaient pas des mises à jour. Ils ont ajouté au sentiment que l'entreprise n'avait pas maîtrisé la panne ;
• évitez le silence radio. Jusqu'au jour 9, Atlassian était en silence radio. Évitez cette approche à tout prix.

Sources : billet Gergely Orosz, Atlassian

Et vous ?

Que pensez-vous de l'analyse d'Orosz ?
Quels sont les points qui vous semblent les plus pertinents ?
Partagez-vous le sentiment des entreprises qui estiment qu'Atlassian a raté sa gestion de la communication sur la panne ?

[Invité]

Bonsoir,

Panne géante des services Cloud d'Atlassian : comment des centaines de sociétés ont perdu leur accès à JIRA, Confluence et OpsGenie. Atlassian est restée silencieuse pendant des jours. L'impact sur les clients a été important, dans l'ensemble

Que pensez-vous de l'analyse d'Orosz ?

J'ai bien entendu qu'il y a eu des perturbations au niveau de Jira . Dans ma boite on utilise Jira . Cependant de la à y voir une panne , non , on y a vu que du feu sur le cou

Quels sont les points qui vous semblent les plus pertinents ?

Déjà corriger la panne

Partagez-vous le sentiment des entreprises qui estiment qu'Atlassian a raté sa gestion de la communication sur la panne ?

Oui plutôt , on dirait un biss répétita d'ovh et de son incendie ... Toujours communiquer sur ce qu'on fait (nous dit on dans l'IT) .

[TotoParis]

Un bel accident industriel, un cas d'école même. Mais il n'est donc pas possible d'utiliser JIRA & cie sur un serveur dédié géré par le client ? Comme maintenant pour la messagerie Outlook ?

[smarties]

Ca me conforte dans l'idée de continuer à privilégier des solutions "self hosted" car en cas de pépin, on prend un nouveau serveur et on restaure la dernière sauvegarde (et on a perdu 24h de travail au pire)

[floyer]

Un bel accident industriel, un cas d'école même. Mais il n'est donc pas possible d'utiliser JIRA & cie sur un serveur dédié géré par le client ? Comme maintenant pour la messagerie Outlook ?

Atlassian avait une offre Jira Server et Jira DataCenter… mais en voulant pousser l’offre Cloud, il ne reste que la deuxième option en On-Premise, plus chère….

[Stéphane le calme]

Atlassian publie un rapport sur la panne qui a coupé des centaines d'entreprises de leur accès à JIRA, Confluence et OpsGenie
et promet de mieux communiquer à l'avenir

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 ?