Close

Comment Atlassian gère les données des clients


Keeping your cloud products and the underlying systems and services they use available and able to withstand the impact of negative or unplanned events is as crucial to us as it is to you. To make sure that your products are there when you need them, we’ve implemented technology, people, and programs to provide business resiliency.

Comment Atlassian approche la résilience

Nos produits fonctionnent sur un environnement PaaS (Platform as a Service) divisé en deux ensembles principaux d'infrastructures que nous appelons « Micros » et « non Micros ». Jira, Confluence, Statuspage, Access, Bitbucket et Trello s'exécutent sur la plateforme Micros, tandis que Jira Align et Opsgenie s'exécutent sur la plateforme non Micros.

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é d'activité.

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é d'activité.

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, Bitbucket et Atlassian Access, et les produits s'exécutant sur des environnements non Micros comprennent Opsgenie and 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.

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.

Remarque : pour Jira Align, les instantanés Amazon RDS sont conservés pendant 35 jours.

Pour Bitbucket, les données sont répliquées vers une autre région AWS, et des sauvegardes indépendantes sont effectuées quotidiennement dans chaque région.

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.

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.

Remarque : pour Jira Align, les instantanés Amazon RDS sont conservés pendant 35 jours.

Pour Bitbucket, les données sont répliquées vers une autre région AWS, et des sauvegardes indépendantes sont effectuées quotidiennement dans chaque région.

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.

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.

Remarque : pour Jira Align, les instantanés Amazon RDS sont conservés pendant 35 jours.

Pour Bitbucket, les données sont répliquées vers une autre région AWS, et des sauvegardes indépendantes sont effectuées quotidiennement dans chaque région.

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 déterminons la durée maximale d’interruption admissible (RTO) et les objectifs de point de reprise (RTO)

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é de l'activité, il est nécessaire de fixer une « durée maximale d’interruption admissible» et des « objectifs de point de reprise » (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

· Jira Align

· Trello

· Opsgenie

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 reprise) : restauration de services en cas de sinistre

**RTO (durée maximale d’interruption admissible) : 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é de l'activité

Nous nous efforçons de maintenir de solides capacités de continuité de l'activité 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é de l'activité 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é d'activité. Pour couronner le tout, nous disposons de collaborateurs exceptionnels et de ressources dévouées qui gèrent nos processus.