Comment Atlassian gère les données des clients


Comment Atlassian approche la résilience

Les produits Atlassian Cloud sont conçus pour des performances élevées et s'appuient sur les meilleures technologies de leur catégorie afin que vous puissiez être sûr que vos données et services seront disponibles quand vous en aurez besoin. Chez Atlassian, nous nous soucions profondément de la résilience des données et services de nos clients, notamment parce que nous dépendons nous aussi de cette gamme de produits.

C'est pourquoi nous nous efforçons de minimiser l'impact sur les clients en cas de perturbations. Nous tirons parti de plusieurs data centers géographiquement répartis, nous disposons d'un programme de sauvegarde complet et nous nous assurons de la fiabilité en testant régulièrement nos plans de reprise d'activité et de continuité des opérations.

Cette page fournit un aperçu de la façon dont nous gérons le cycle de vie global de la gestion des données des clients, y compris les sauvegardes utilisant les capacités natives d'Amazon Web Services (AWS) pour assurer la disponibilité de nos services, ainsi que de la façon dont nous testons régulièrement nos plans de reprise d'activité, et notre approche pour améliorer en permanence nos plans de reprise d'activité et de continuité des opérations.

Comment nous gérons les sauvegardes

Commençons par le commencement : l'infrastructure et les bases de données

Globalement, Atlassian se divise en deux grands ensembles d'infrastructures où nos produits s'exécutent : un environnement de plateforme en tant que service (PaaS) connu en interne sous le nom de Micros, et un environnement non Micros. Les produits s'exécutant sur notre plateforme Micros comprennent Jira, Confluence, Statuspage et Atlassian Access, et les produits s'exécutant sur des environnements non Micros comprennent Bitbucket, Opsgenie et Trello. Pour simplifier les choses, ce document se concentrera en grande partie sur nos principaux produits : Jira, Confluence et Bitbucket.

Jira et Confluence Cloud sont hébergés dans plusieurs régions AWS, via l'offre d'infrastructure AWS en tant que service (IaaS), en particulier dans l'Est et l'Ouest des États-Unis, en Irlande, à Francfort, à Singapour et à Sydney, avec des projets d'extension à d'autres régions si nécessaire. Jira et Confluence Cloud utilisent des bases de données relationnelles logiquement séparées pour chaque instance de produit, tandis que les pièces jointes dans Jira ou Confluence Cloud sont stockées sur notre plateforme de stockage de documents (« Plateforme multimédia »), elle-même hébergée dans Amazon S3.

Les services et fonctionnalités de Bitbucket Cloud sont fournis par un ensemble de services fonctionnant dans le data center NTT Communications (NTT) d'Ashburn, en Virginie, avec des sauvegardes stockées à la fois dans le data center NTT de Santa Clara, en Californie, et AWS. Les données client de Bitbucket Cloud sont stockées dans les dépôts PostgreSQL et NetApp.

Sauvegardes

Atlassian sait que quelle que soit votre activité, elle crée des données, et que sans vos données, vous n'avez pas d'activité. Dans la lignée de notre valeur « Ne pas baratiner le client », la protection contre la perte de vos données est un enjeu majeur pour nous, pour lequel nous avons mis en place un programme de sauvegarde étendu.

Pour Jira et Confluence Cloud, Atlassian utilise la fonction d'instantané Amazon RDS (Amazon Relational Database Service) pour créer des sauvegardes quotidiennes automatisées de chaque instance RDS. Les instantanés Amazon RDS sont conservés pendant 30 jours avec prise en charge de la reprise à un instant de référence et sont chiffrés avec le chiffrement AES-256.

Pour Bitbucket, les sauvegardes sont stockées dans les deux data centers physiques NTT et AWS.

Atlassian teste les sauvegardes pour la restauration sur une base trimestrielle, et tous les problèmes identifiés lors de ces tests font l'objet de tickets Jira afin de s'assurer de leur suivi jusqu'à leur résolution.

Pour en savoir plus, consultez notre FAQ sur le stockage des données.

Comment nous utilisons plusieurs data centers et zones de disponibilité pour une haute disponibilité

Avec les ouragans, les tremblements de terre et les tsunamis (des risques faibles, mais non nuls), il est impératif que les données soient sauvegardées (et répliquées) dans des emplacements géographiques différents afin qu'elles puissent être récupérées, quoi qu'il arrive.

Atlassian y parvient en utilisant des installations de data centers AWS hautement disponibles dans plusieurs régions du monde. Chaque région AWS est une région géographique distincte, qui comprend plusieurs endroits isolés connus sous le nom de zones de disponibilité (ZD). Par exemple, USA Ouest (la côte ouest des États-Unis) est une région dans laquelle il y a deux ZD, us-west-1a (situé au nord de la Californie) et us-west-1b (situé dans l'Oregon), qui se trouvent dans la même région globale, mais sont géographiquement isolés.

Chaque ZD est conçue pour être isolée des pannes dans d'autres ZD et pour fournir une connectivité réseau peu coûteuse et à faible latence avec d'autres ZD de la même région. Cette haute disponibilité multizones constitue la première ligne de défense et signifie que les services fonctionnant dans des déploiements multi-ZD doivent être capables de résister aux pannes de ZD.

Jira et Confluence utilisent le mode de déploiement multi-ZD pour Amazon RDS. Dans un déploiement multi-ZD, Amazon RDS fournit et maintient une réplication synchrone de secours dans une autre ZD de la même région pour fournir une redondance et une capacité de basculement. Le basculement de ZD est automatisé et prend généralement de 60 à 120 secondes, de sorte que les opérations de la base de données peuvent reprendre aussi rapidement que possible sans intervention administrative. Ces concepts de région, de ZD et de réplication sont mis en évidence dans les diagrammes ci-dessous. Opsgenie, Statuspage, Trello et Jira Align utilisent des stratégies de déploiement similaires, avec de petites variations dans la synchronisation des réplications et des basculements.

Pour Bitbucket, tous les serveurs de base de données primaires résident dans des data centers NTT avec des nœuds de réplication et des sauvegardes stockés dans les deux data centers NTT et AWS. Les données de production sont constamment répliquées dans les data centers NTT d'Ashburn (Virginie) et de Santa Clara (Californie) via la technologie de mise en miroir. Les données de production Bitbucket sont répliquées toutes les 2 heures de son site principal à son site secondaire, avec un délai de réplication de 10 à 20 minutes en moyenne et de 4 heures au maximum.

Comment nous déterminons les objectifs de délai de récupération et de point de récupération

Dans un monde idéal, nous ne perdrions jamais de données métier vitales. Dans la pratique cependant, un système sans risque de perte de données est soit inaccessible, soit d'un coût prohibitif. Bien qu'Atlassian vise, par sa culture, à atteindre la perte nulle de données et la capacité à surmonter automatiquement une panne de la zone de disponibilité, dans la planification de la continuité des opérations, il est nécessaire de fixer des « objectifs de délai de récupération » et des « objectifs de point de récupération » (RTO et RPO, respectivement) qui visent à trouver le bon équilibre entre le coût, les avantages et les risques.

Le RTO est la période de temps après un incident, au cours de laquelle le processus opérationnel (ou le système) doit être récupéré et remis en service. Le RPO est en fait la quantité de données pour laquelle l'organisation accepte un risque de perte lors d'une opération de récupération. À titre d'exemple simple, si vous effectuez des sauvegardes quotidiennes, que vous rencontrez un incident en fin de journée et que vous récupérez à partir de la dernière sauvegarde (qui a été effectuée hier), vous allez perdre une journée de données. C'est le RPO.

Nos évaluations de l'impact métier et des risques aident nos équipes à établir des objectifs RTO et RPO personnalisés en fonction des besoins des utilisateurs client et de l'impact potentiel d'une perturbation.

Plus précisément, nous divisons nos services en lots facilement compréhensibles que nous appelons tiers. Trois tiers sont définis pour les produits et les services aux clients, les systèmes métier et les outils internes Atlassian (tiers 1, 2 et 3), et un tier sous-jacent (tier 0) fournit une norme de disponibilité encore plus élevée pour les composants stratégiques dont tout dépend.

Pour chaque tier, nous avons défini des objectifs obligatoires en examinant, entre autres, les évaluations de l'impact sur les activités et les scénarios d'utilisation typiques des services que nous élaborons. Nos tiers de service aident à déterminer la disponibilité, la fiabilité, les objectifs RTO et RPO comme indiqué dans le tableau ci-dessous.

         
  Tier 0 Tier 1 Tier 2 Tier 3
Composants stratégiques de l'infrastructure et des services Nos services de tier 0 sont ceux qui forment la base de tous les autres services et sont essentiels à la livraison de nos produits. Nos services de tier 1 sont généralement nos produits ou sont directement liés à la livraison de nos produits. Les services de tier 2 sont soit des services non stratégiques, soit des services internes. Les services de tier 3 sont soit des services non stratégiques, soit des services internes.
Exemples de services :

Exemples de services

Plateforme AWS

Serveur Micros

Réseau cœur

Exemples de services

Jira et Confluence Cloud

Bitbucket

Exemples de services

Effets d'image

CAC

Exemples de services

Réception de données analytiques et/ou de BI

RPO* <1 heure <1 heure <8 heures   <24 heures  
RTO** <4 heures <6 heures <24 heures <72 heures

*RPO (objectif de point de récupération) : restauration de services en cas de sinistre

**RTO (objectif de délai de récupération) : reprise des services en cas de sinistre

Chez Atlassian, nous confions aux Service Owners la responsabilité de veiller à ce que le service concerné atteigne ses objectifs RPO et RTO.    

 

Comment nous effectuons des tests de reprise d'activité

Atlassian effectue régulièrement des tests de reprise d'activité et s'efforce de s'améliorer continuellement dans le cadre de son programme de reprise d'activité (DR). Il s'agit d'assurer la fiabilité et la résilience des données et des services des clients. Nous effectuons des tests planifiés et ponctuels, y compris les éléments suivants :

Documentation : en ce qui concerne les services stratégiques et les services internes des clients (y compris les services de tier 0 et de tier 1), des revues trimestrielles des documents relatifs à la sauvegarde sont effectuées pour en vérifier l'exactitude, l'intégralité et l'actualité. Tous les problèmes identifiés sont documentés et font l'objet d'un ticket Jira interne, de sorte que le problème soit suivi jusqu'à sa résolution.

Processus : des tests trimestriels des processus de sauvegarde/récupération techniques réels sont également effectués pour les services stratégiques/des clients (y compris les tiers 0 et 1), afin de déterminer si les objectifs RTO et RPO sont atteints (selon la classification des niveaux de service). Tous les problèmes identifiés à la suite de ces tests font l'objet d'un ticket Jira, de sorte que le problème soit suivi jusqu'à sa résolution.

Résilience et basculement : des tests périodiques et ad hoc des niveaux de résilience de ZD sont effectués pour s'assurer qu'Atlassian peut gérer une panne de ZD avec un temps d'arrêt minimal. Bien que nous sachions qu'une panne complète de la région est hautement improbable, nous testons aussi périodiquement le basculement de la région et nous continuons à développer notre résilience régionale.

Systèmes : les équipes d'ingénierie de fiabilité du site (SRE) et d'ingénierie produit surveillent en permanence un large éventail de paramètres dans l'ensemble des services pour garantir aux utilisateurs d'excellentes expériences. Des alertes automatisées sont configurées pour avertir les membres de l'équipe SRE lorsque certains seuils d'indicateur de service sont franchis, afin que des mesures immédiates puissent être prises dans le cadre de nos processus de réponse aux incidents.

Tableau de bord de reprise d'activité : un tableau de bord de reprise d'activité est tenu à jour en interne, de sorte que les tickets Jira relatifs à la surveillance, à la maintenance et aux tests puissent être suivis de façon centralisée afin de s'assurer que les revues de la documentation et des processus de sauvegarde/reprise sont effectuées à temps pour les services stratégiques/des clients (notamment les tiers 0 et 1).

Tests et simulations de reprise d'activité : des tests de reprise d'activité sont effectués sur une base annuelle et ponctuelle. Dans le cadre de nos tests de reprise d'activité, nous effectuons des exercices sur table pour aider les équipes de reprise d'activité à passer en revue divers scénarios d'incidents potentiels. Ces exercices testent différents scénarios et identifient les lacunes dans nos processus de reprise d'activité. Les scénarios comprennent des tremblements de terre, des incendies, des catastrophes naturelles, des exercices de reprise et des tests. Après les tests de reprise d'activité, les résultats sont capturés, analysés et discutés afin de déterminer le périmètre des prochaines étapes de l'amélioration continue. Les efforts d'amélioration sont consignés dans un ticket Jira et suivis jusqu'à leur aboutissement.

Nous comprenons que bien que nos tests et nos processus sont techniquement rigoureux, nous nous efforçons de maintenir une norme qui consiste à disposer d'un personnel exceptionnel pour veiller à cette rigueur. Par conséquent, nous incluons les éléments suivants en matière de ressources humaines dans notre programme de reprise d'activité :

Ingénieurs chargés de la fiabilité du site (« SRE ») : les SRE s'engagent à tenir régulièrement des réunions de reprise d'activité et représentent leurs services stratégiques. Ils identifient les lacunes en matière de reprise d'activité au sein de notre équipe de gestion des risques et de conformité, en mettant l'accent sur la remédiation, au besoin.

Champions de la reprise d'activité : des champions de la reprise d'activité sont nommés au sein de chaque équipe de produits/services (y compris les services sous-jacents) pour superviser et aider à gérer l'implémentation de la reprise d'activité dans ce produit/service afin de s'assurer qu'il répond aux exigences du tier de service.

Leadership : nous maintenons la participation et l'engagement continu de la haute direction dans nos processus de reprise d'activité. Grâce à son leadership, Atlassian a tenu compte des facteurs métier et techniques dans sa stratégie de résilience.

Autres mesures et plans plus généraux de continuité des opérations

Nous nous efforçons de maintenir de solides capacités de continuité des opérations et de reprise d'activité pour nous assurer que l'impact sur nos clients est réduit au minimum en cas d'interruption de nos activités. Les principes clés qui guident notre programme de continuité des opérations et de reprise d'activité sont les suivants :

Amélioration continue : Atlassian s'efforce d'assurer l'amélioration de la résilience par l'efficacité opérationnelle, l'automatisation, les nouvelles technologies et les pratiques éprouvées.

Assurance par les tests : Atlassian comprend que grâce à des tests réguliers et à l'application d'améliorations continues, nous sommes en mesure d'atteindre une résilience optimale.

Ressources dédiées : nous disposons de personnes et d'équipes dédiées pour nous assurer que les produits de nos clients reçoivent l'attention dont ils ont besoin afin de rendre la continuité des opérations et la reprise d'activité possibles. Nous disposons du niveau de ressources adéquat sur le terrain pour soutenir notre comité de direction et prendre en charge les évaluations des risques, les tests d'analyse d'impact commercial et, bien sûr, les incidents réels.

En résumé

Atlassian combine les meilleures technologies de sa catégorie avec des tests et des validations continus pour s'assurer que les données de ses clients sont hautement disponibles, fiables et résilientes. Nous exploitons plusieurs data centers géographiquement diversifiés, nous avons un programme de sauvegarde étendu dont nous nous assurons de la fiabilité en testant régulièrement nos plans de reprise d'activité et de continuité des opérations. Pour couronner le tout, nous disposons de collaborateurs exceptionnels et de ressources dévouées qui gèrent nos processus.