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 ? 
Envoyé par TotoParis
