Close

In che modo Atlassian gestisce i dati dei clienti


In che modo Atlassian implementa la resilienza

I prodotti Atlassian Cloud sono progettati per fornire prestazioni elevate e sono basati sulle migliori tecnologie per offrirti la certezza che i dati e i servizi saranno disponibili ogni volta che ne hai la necessità. In Atlassian la resilienza dei dati e dei servizi dei nostri clienti riveste un'enorme importanza, non ultimo perché noi stessi utilizziamo la stessa suite di prodotti.

A tal fine, ci adoperiamo per ridurre al minimo l'impatto dei clienti nell'eventualità di interruzioni. Utilizziamo più data center geograficamente distribuiti, disponiamo di un programma completo di backup e verifichiamo la qualità conducendo regolarmente dei test sui piani di ripristino di emergenza e di continuità aziendale.

Questa pagina fornisce una panoramica di come gestiamo il ciclo di vita complessivo della gestione dei dati dei clienti, inclusi i backup che utilizzano funzionalità native di Amazon Web Services (AWS) per garantire la disponibilità dei nostri servizi, il modo in cui testiamo regolarmente i nostri piani di ripristino di emergenza e l'approccio al miglioramento continuo dei nostri piani di ripristino di emergenza e continuità aziendale.

Come gestiamo i backup

Infrastruttura e database al primo posto

In generale, Atlassian è suddiviso in due principali insiemi di infrastruttura in cui vengono eseguiti i nostri prodotti: un ambiente PaaS (Platform as a Service) noto internamente come Micros e ambienti non Micros. I prodotti in esecuzione sulla piattaforma Micros includono Jira, Confluence, Statuspage e Atlassian Access, mentre i prodotti in esecuzione in ambienti non Micros includono Bitbucket, Opsgenie e Trello. Per esigenze di semplicità, in questo documento ci concentreremo prevalentemente sui nostri prodotti di maggiori dimensioni: Jira, Confluence e Bitbucket.

Jira e Confluence Cloud sono ospitati in più regioni AWS, utilizzando l'offerta IaaS (Infrastructure as a Service) di AWS (in particolare, le regioni Stati Uniti occidentali, Stati Uniti orientali, Irlanda, Francoforte, Singapore e Sydney, con piani di espansione in altre regioni, se necessario). Sia Jira che Confluence Cloud utilizzano database relazionali logicamente separati per ogni istanza di prodotto, mentre gli allegati archiviati in Jira o in Confluence Cloud sono archiviati nella nostra piattaforma di archiviazione di documenti ("Media Platform") che, a sua volta, è archiviata in Amazon S3.

I servizi e le funzioni di Bitbucket Cloud sono forniti da una serie di servizi in esecuzione nel data center NTT Communications (NTT) di Ashburn, in Virginia, con backup archiviati sia nel data center NTT di Santa Clara, in California, sia in AWS. I dati dei clienti di Bitbucket Cloud sono archiviati nei filer PostgreSQL e NetApp.

Backup

Atlassian è consapevole del fatto che qualsiasi attività aziendale comporta la creazione di dati e che senza dati non c'è business. In linea con il nostro valore "Rispetta il cliente", la protezione dei dati dei clienti da perdite e la disponibilità di un ampio programma di backup è una nostra priorità fondamentale.

Per Jira e Confluence Cloud, Atlassian utilizza la funzione snapshot di Amazon RDS (Relational Database Service) per creare backup giornalieri automatizzati di ogni istanza RDS. Le snapshot di Amazon RDS vengono conservate per 30 giorni con il supporto del ripristino point-in-time e vengono crittografate utilizzando la crittografia AES-256.

Per Bitbucket, i backup vengono archiviati sia nei data center NTT fisici che in AWS.

Atlassian verifica i backup per il ripristino su base trimestrale e gli eventuali problemi emersi dai test vengono aperti come ticket Jira per garantirne il monitoraggio fino alla risoluzione.

Per maggiori informazioni, consulta le nostre FAQ sull'archiviazione di dati

Come utilizziamo più data center e zone di disponibilità per la disponibilità elevata

Per quanto remoti, i rischi come uragani, terremoti e tsunami comportano la necessità di sottoporre i dati a backup (e replica) in località geografiche diverse affinché possano essere recuperati, indipendentemente dagli eventi.

A tale scopo Atlassian utilizza le strutture di data center ad alta disponibilità di AWS in più regioni in tutto il mondo. Ogni area AWS è una località geografica separata, che dispone di più posizioni isolate note come zone di disponibilità (AZS). Ad esempio, gli Stati Uniti occidentali (costa occidentale degli Stati Uniti) costituiscono una regione all'interno della quale sono presenti due regioni di disponibilità: us-west-1a (ubicata nella California settentrionale) e us-west-1b (ubicata nell'Oregon); entrambe si trovano nella stessa regione, ma sono geograficamente isolate.

Ogni zona di disponibilità è progettata per essere isolata dai guasti di altre zone di disponibilità e per fornire connettività di rete conveniente e a bassa latenza ad altre zone di disponibilità nella stessa regione. Questa disponibilità elevata multizona rappresenta la prima linea di difesa; questo significa che i servizi in esecuzione nelle distribuzioni in più zone di disponibilità devono essere in grado di fronteggiare i guasti nelle zone di disponibilità.

Jira e Confluence utilizzano la modalità di distribuzione in più zone di disponibilità per Amazon RDS. In una distribuzione in più zone di disponibilità, Amazon RDS esegue il provisioning e la manutenzione di una replica in standby sincrona in una zona di disponibilità diversa della stessa regione per fornire ridondanza e funzionalità di failover. Il failover delle zone di disponibilità è automatizzato e richiede in genere 60-120 secondi, in modo che le operazioni del database possano riprendere il più rapidamente possibile senza interventi amministrativi. I concetti di regione, zona di disponibilità e replica sono evidenziati nei diagrammi riportati sotto. Opsgenie, Statuspage, Trello e Jira Align utilizzano strategie di distribuzione analoghe, con piccole differenze nei tempi della replica e del failover.

Per Bitbucket, tutti i server di database primari risiedono nei data center NTT con nodi di replica e backup archiviati sia nei data center NTT che in AWS. I dati di produzione vengono costantemente replicati nei data center NTT sia di Ashburn, in Virginia, che di Santa Clara, in California, tramite la tecnologia di mirroring. I dati di produzione Bitbucket vengono replicati ogni 2 ore dal sito principale al sito secondario, con un ritardo di replica medio di 10-20 minuti e di massimo quattro ore.

Come determiniamo gli obiettivi di tempo di ripristino e di punti di ripristino

A un livello ideale, non dovrebbero mai verificarsi perdite di dati cruciali per il business; in pratica, un sistema con un rischio di perdita di dati pari a zero è irraggiungibile o ha costi proibitivi. Mentre sul piano culturale Atlassian ha definito l'aspettativa di puntare a questo scenario di azzeramento della perdita di dati e alla capacità di sopravvivere automaticamente a un guasto della zona di disponibilità, nella pianificazione della continuità aziendale è necessario impostare "obiettivi di tempo di ripristino" e "obiettivi del punto di ripristino" (rispettivamente, RTO e RPO) che cerchino di trovare il giusto equilibrio tra costi, benefici e rischi.

L'RTO è il periodo di tempo successivo a un imprevisto in cui il processo aziendale (o il sistema) deve essere ripristinato per essere di nuovo operativo. L'RPO è effettivamente la quantità di dati che l'organizzazione accetta di poter perdere in un'operazione di ripristino. Ricorrendo a un esempio semplice, se si eseguono backup giornalieri e, al termine della giornata, si verifica un imprevisto e si esegue il ripristino dal backup (effettuato il giorno prima), si perderà 1 giorno di dati. Questa perdita corrisponde all'RPO.

Le nostre valutazioni dei rischi e dell'impatto aziendale aiutano i nostri team a definire obiettivi RTO e RPO personalizzati in base ai requisiti degli utenti dei clienti e al potenziale impatto di un'interruzione.

Più specificamente, dividiamo i nostri servizi in bucket di facile comprensione che definiamo tier. Sono stati definiti tre tier per i prodotti e servizi rivolti ai clienti, i sistemi aziendali Atlassian e gli strumenti interni (tier 1, 2 e 3); a questi, si aggiunge un tier sottostante (tier 0), che fornisce uno standard di disponibilità ancora più elevato per i componenti critici su cui poggia tutta l'infrastruttura.

Per ogni tier abbiamo definito gli obiettivi obbligatori esaminando, a titolo di esempio, le valutazioni dell'impatto aziendale e gli scenari di utilizzo tipici dei nostri servizi. I tier di servizio contribuiscono a determinare la disponibilità, l'affidabilità e gli obiettivi RTO e RPO, come indicato nella tabella seguente.

Tier 0 Tier 1 Tier 2 Tier 3
Componenti critici dell'infrastruttura e dei servizi I nostri servizi tier 0 sono alla base di tutti gli altri servizi e sono fondamentali per la distribuzione dei nostri prodotti. Generalmente, i servizi tier 1 riguardano i nostri prodotti o sono direttamente correlati alla loro distribuzione. I servizi tier 2 sono servizi non critici o destinati a un utilizzo interno. I servizi tier 3 sono servizi non critici o destinati a un utilizzo interno.
Servizi di esempio:

Servizi di esempio

· Piattaforma AWS

· Server Micros

· Funzioni di base della rete

Servizi di esempio

· Jira e Confluence Cloud

· Bitbucket

Servizi di esempio

· Effetti di immagine

· CAC

Servizi di esempio

· Ricezione di dati di analisi e/o di BI

RPO* <1 ora <1 ora <8 ore <24 ore
RTO** <4 ore <6 ore <24 ore <72 ore

*Obiettivo del punto di ripristino (RPO): perdita di dati nell'eventualità di un guasto.

**Obiettivo del tempo di ripristino (RTO): ripristino dei servizi nell'eventualità di un guasto.

Atlassian designa la responsabilità dei responsabili dei servizi per garantire che il servizio pertinente soddisfi gli obiettivi RPO e RTO.

Come effettuiamo i test del ripristino di emergenza

Atlassian esegue regolarmente test di ripristino di emergenza e si impegna per apportare miglioramenti continui nell'ambito del proprio programma Disaster Recovery (DR), con l'obiettivo di garantire l'affidabilità e la resilienza dei dati e dei servizi dei clienti. Conduciamo sia test programmati sia ad hoc, che includono i seguenti elementi:

Documentazione: per i servizi critici/rivolti ai clienti (inclusi i tier 0 e tier 1) vengono effettuate revisioni trimestrali della documentazione di backup per verificare che sia precisa, completa e aggiornata. Gli eventuali problemi identificati sono documentati e generano un ticket Jira interno affinché siano monitorati fino alla risoluzione.

Processo: vengono inoltre completati test trimestrali dei processi tecnici di backup e ripristino effettivi per i servizi critici/rivolti ai clienti (inclusi i tier 0 e tier 1), per determinare se gli obiettivi RTO e RPO sono soddisfatti o meno (in base alla classificazione dei tier di servizio). Gli eventuali problemi identificati dai test vengono aperti come ticket Jira affinché siano monitorati fino alla risoluzione.

Resilienza e failover: vengono eseguiti test periodici e ad hoc per i livelli di resilienza tra zone di disponibilità per garantire che Atlassian possa gestire un guasto delle zone di disponibilità con un tempo di inattività minimo. Sebbene un guasto dell'intera regione sia altamente improbabile, conduciamo anche un test periodico del failover della regione e continuiamo a consolidare la nostra resilienza regionale.

Sistemi: i team di ingegneri responsabili dell'affidabilità del sito (SRE) e i team di progettazione del prodotto monitorano continuamente un'ampia gamma di metriche dei servizi per garantire agli utenti un'esperienza eccellente. Avvisi automatici vengono configurati per informare i membri dei team SRE del superamento di determinate soglie per le metriche del servizio, in modo che possano intraprendere azioni immediate nell'ambito dei nostri processi di risposta agli imprevisti.

Dashboard di ripristino di emergenza: una dashboard DR viene gestita internamente in modo che per i servizi critici/rivolti ai clienti (inclusi i tier 0 e tier 1), i ticket Jira relativi a supervisione, manutenzione e test possano essere monitorati centralmente per garantire che le revisioni della documentazione e dei processi di backup/ripristino siano completate nei tempi previsti.

Test e simulazioni DR: i test di DR sono effettuati su base annuale e ad hoc. Nell'ambito dei nostri test DR, eseguiamo esercizi teorici per aiutare i team DR a esaminare i vari scenari dei potenziali imprevisti. Gli esercizi teorici testano diversi scenari e identificano le lacune nei nostri processi di ripristino. Gli scenari per gli esercizi teorici includono terremoti, incendi, calamità naturali, esercitazioni per il ripristino e test. Dopo aver eseguito i test DR, i risultati vengono acquisiti, analizzati e discussi per determinare l'ambito delle fasi successive per il miglioramento continuo. Le attività di miglioramento vengono acquisite all'interno di un ticket Jira e monitorate fino alla risoluzione.

Atlassian è consapevole del fatto che, per quanto disponga di test e processi tecnicamente rigorosi, il suo vero punto di forza risiede nel talento e nelle competenze eccezionali del suo personale. Per questo motivo, include i seguenti ruoli nel proprio programma di ripristino d'emergenza:

Ingegneri responsabili dell'affidabilità del sito ("SRE"): gli SRE si impegnano a tenere riunioni periodiche sul ripristino d'emergenza e a rappresentare i loro servizi critici. Identificano le lacune del ripristino d'emergenza con il nostro team di rischio e conformità, concentrandosi sull'eventuale correzione necessaria.

Promotori del ripristino di emergenza: i promotori del ripristino di emergenza sono nominati all'interno di ciascun team di prodotto/servizio (inclusi i servizi sottostanti) per supervisionare e gestire l'implementazione del ripristino di emergenza all'interno di quel prodotto/servizio allo scopo di garantire che soddisfi i requisiti del tier di servizio.

Leadership: i dirigenti e senior manager sono sempre coinvolti nei nostri processi di ripristino di emergenza, ai quali partecipano in maniera continuativa. Considerato il coinvolgimento della leadership, Atlassian ha tenuto conto di fattori aziendali e tecnici nella propria strategia per la resilienza.

Altre misure e altri piani più ampi di continuità aziendale

Atlassian si impegna a mantenere solide capacità di continuità aziendale ("BC") e di ripristino di emergenza ("DR") per garantire che l'impatto sui clienti sia ridotto al minimo in caso di interruzioni delle proprie operazioni. I principi chiave che guidano il nostro programma BC e DR includono:

Miglioramento continuo: Atlassian si impegna per garantire miglioramenti della resilienza tramite efficienze operative, automazione, nuove tecnologie e pratiche comprovate.

Garanzia attraverso i test: Atlassian è consapevole del fatto che attraverso test regolarmente programmati e l'applicazione di miglioramenti continui, può ottenere una resilienza ottimale.

Risorse dedicate: Atlassian può contare su persone e team dedicati per garantire che i propri prodotti destinati ai clienti ricevano l'attenzione necessaria per rendere possibili la BC e il DR. Atlassian dispone del livello di risorse sul campo appropriato per supportare il proprio comitato direttivo, le valutazioni dei rischi, i test di analisi dell'impatto aziendale e, naturalmente, gli imprevisti reali.

In sintesi

Atlassian combina le migliori tecnologie della categoria con i test e la convalida eseguiti su base continuativa per garantire che i dati dei clienti siano altamente disponibili, affidabili e resilienti. Gestiamo più data center geograficamente distribuiti, disponiamo di un ampio programma di backup e verifichiamo la qualità tramite test condotti regolarmente sui piani di ripristino di emergenza e di continuità aziendale. Soprattutto, abbiamo persone eccezionali e risorse dedicate che riuniscono i nostri processi.