Close

Hoe Atlassian klantgegevens beheert


Hoe Atlassian voor veerkracht zorgt

De cloudproducten van Atlassian zijn ontworpen voor hoge prestaties en gebouwd op de beste technologieën, zodat je er zeker van kunt zijn dat jouw gegevens en services beschikbaar zijn wanneer je ze nodig hebt. We geven veel om de veerkracht van onze klantgegevens en services bij Atlassian, niet in de laatste plaats omdat we zelf afhankelijk zijn van hetzelfde assortiment aan producten.

We werken er daarom aan om de invloed van eventuele storingen op klanten te minimaliseren. We maken gebruik van meerdere geografisch verspreide datacenters, een uitgebreid back-upprogramma en krijgen zekerheid door onze rampenherstel- en bedrijfscontinuïteitsplannen regelmatig te testen.

Deze pagina biedt een overzicht van hoe we de algemene cyclus van klantgegevensbeheer beheren, inclusief back-ups die gebruik maken van native functionaliteit van Amazon Web Services (AWS) om de beschikbaarheid van onze services te garanderen, hoe regelmatig we onze disaster recoveryprogramma's testen en hoe we de doorlopende verbetering van onze disaster recovery- en bedrijfscontinuïteitsprogramma's aanpakken.

Hoe we back-ups beheren

Beginnen bij het begin: infrastructuur en databases

Algemeen gezien is Atlassian opgesplitst in twee belangrijke sets van infrastructuur waarop onze producten draaien: een platform-as-a-service-omgeving (PaaS) die intern bekend staat als Micros, en niet-Micros. Producten die op ons Micros-platform draaien zijn bijvoorbeeld Jira, Confluence, Statuspage en Atlassian Access. Producten die in niet-Micros-omgevingen draaien zijn bijvoorbeeld Bitbucket, Opsgenie en Trello. Om het simpel te houden zullen we ons in deze paper voornamelijk richten op onze grootste producten: Jira, Confluence en Bitbucket.

Jira en Confluence Cloud worden gehost in meerdere AWS-regio's, waarbij de AWS-infrastructure-as-a-service (IaaS) gebruikt wordt (voornamelijk VS-Oost, VS-West, Ierland, Frankfurt, Singapore en Sydney, met plannen om indien nodig uit te breiden naar andere regio's). Jira en Confluence Cloud maken beide gebruik van logisch gescheiden relationele databases voor elke productinstallatie, terwijl bijlagen die zijn opgeslagen in Jira of Confluence Cloud opgeslagen worden op ons platform voor documentopslag ('Media Platform'), wat op zijn beurt is opgeslagen in Amazon S3.

De services en functies van Bitbucket Cloud worden geleverd door een reeks services die draaien in het NTT Communications (NTT) datacenter in Ashburn, Virginia. Back-ups worden opgeslagen in het NTT datacenter in Santa Clara, Californië en AWS. De klantgegevens van Bitbucket Cloud worden opgeslagen in PostgreSQL en NetApp-filers.

Back-ups

Atlassian beseft dat wat je bedrijf ook doet, er gegevens gecreëerd worden, en dat je zonder gegevens geen bedrijf hebt. In overeenkomst met onze waarde 'houd de klant niet voor de gek' geven we veel om het beschermen van jouw gegevens en hebben we een uitgebreid back-upprogramma.

Atlassian gebruikt voor Jira en Confluence Cloud de snapshotfunctie van Amazon RDS (Amazon Relational Database Service) om automatische dagelijkse back-ups te maken van iedere RDS-installatie. Amazon RDS-snapshots worden 30 dagen lang bewaard met ondersteuning voor point-in-time-herstel en worden versleuteld met AES-256-versleuteling.

Back-ups voor Bitbucket worden zowel opgeslagen in fysieke NTT-datacenters als in AWS.

Atlassian test back-ups ieder kwartaal op herstel en alle problemen die uit deze tests naar voren komen worden ingediend als Jira-tickets, zodat we er zeker van zijn dat alle problemen worden gevolgd tot ze zijn opgelost.

Zie onze Veelgestelde vragen over gegevensopslag voor meer informatie.

Hoe we meerdere datacenters en beschikbaarheidszones gebruiken voor hoge beschikbaarheid

Omdat orkanen, aardbevingen en tsunami's weliswaar ver weg maar toch bestaande risico's zijn, is het van belang dat gegevens opgeslagen (en gekopieerd) worden op verschillende geografische locaties, zodat gegevens altijd kunnen worden hersteld, ongeacht wat er gebeurt.

Atlassian doet dit door gebruik te maken van de vele beschikbare datacenter-faciliteiten van AWS in meerdere regio's over de hele wereld. Elke AWS-regio is een aparte geografische locatie, met meerdere geïsoleerde locaties die Availability Zones (AZ's) worden genoemd. Bijvoorbeeld: VS-West (de westelijke kust van de Verenigde Staten) is een regio, waarbinnen er twee AZ's zijn: us-west-1a (in het noorden van Californië) en us-west-1b (in Oregon). Deze bevinden zich beide in dezelfde regio, maar zijn geografisch gescheiden.

Elke AZ is ontworpen om geïsoleerd te zijn van storingen in andere AZ's en om goedkope netwerkconnectiviteit met weinig latentie te bieden met andere AZ's in dezelfde regio. Deze hoge beschikbaarheid in meerdere zone's is de eerste verdedigingslinie en betekent dat services die draaien in implementaties met meerdere AZ's bestand zijn tegen storingen in een AZ.

Jira en Confluence maken gebruik van de implementatiemodus met meerdere AZ's voor Amazon RDS. Amazon RDS levert en onderhoudt in een implementatie met meerdere AZ's een synchrone replica die in een andere AZ in dezelfde zone op stand-by staat om redundantie en failover-mogelijkheden te bieden. De AZ-failover is geautomatiseerd en duurt over het algemeen 60-120 seconden, dus databasebewerkingen kunnen zo snel mogelijk worden voortgezet zonder administratieve tussenkomst. Deze concepten van regio, AZ en replicatie worden in de onderstaande diagrammen gemarkeerd. Opsgenie, Statuspage, Trello en Jira Align maken gebruik van vergelijkbare implementatiestrategieën, met kleine variaties in de timing van replica's en failover.

Alle primaire databaseservers voor Bitbucket bevinden zich in NTT-datacenters, waarbij replicatienodes en back-ups worden opgeslagen in zowel NTT-datacenters als AWS. De productiegegevens worden constant gekopieerd in de NTT-datacenters in Ashburn, VA en Santa Clara, CA via mirroring-technologie. Bitbucket-productiegegevens worden elke twee uur gekopieerd van de primaire site naar de secundaire site. De kopieervertraging is daarbij gemiddeld 10-20 minuten en maximaal vier uur.

Hoe we doelen voor hersteltijd en herstelpunten bepalen

In een ideale wereld zouden we nooit vitale bedrijfsgegevens verliezen. In werkelijkheid is een systeem zonder risico op gegevensverlies echter onbereikbaar of onbetaalbaar. Hoewel we binnen de cultuur van Atlassian streven naar dit doel van geen gegevensverlies en de mogelijkheid om een storing in een Availability Zone automatisch te overleven, is het in de planning van bedrijfscontinuïteit toch nodig om 'Recovery time objectives' en 'Recovery point objectives' in te stellen (ofwel RTO's en RPO's) om de juiste balans te zoeken tussen kosten, voordelen en risico.

De RTO is de tijdsperiode na een incident, waarbinnen het bedrijfsproces (of -systeem) weer hersteld moet zijn en weer moet werken. De RPO is in feite de hoeveelheid gegevens waarvan het bedrijf accepteert dat het verloren kan gaan in een hersteloperatie. Een eenvoudig voorbeeld: als je dagelijks back-ups maakt en er gebeurt een incident aan het einde van een dag, kun je dit herstellen met de back-up (die gisteren is gemaakt). Je verliest dan één dag aan gegevens. Dat is de RPO.

Onze beoordelingen van bedrijfsimpact en risico helpen onze teams om aangepaste RTO- en RPO-doelen te stellen op basis van de gebruikersvereisten van onze klanten en de potentiële gevolgen van een storing.

Specifieker gezegd: we verdelen onze services in gemakkelijk te begrijpen categorieën die we niveaus noemen. We hebben drie niveaus voor producten en services die onze klanten zien, bedrijfssystemen van Atlassian en interne tools (niveau 1, 2 en 3) en een onderliggend niveau (niveau 0) dat aan een nog hogere norm onderhevig is voor de kritische onderdelen waar alles van afhangt.

We hebben voor elk niveau verplichte doelen opgesteld door bijvoorbeeld bedrijfsimpactbeoordelingen en typische gebruiksscenario's te beoordelen voor de services die we bouwen. Onze serviceniveaus helpen ons doelen voor beschikbaarheid, betrouwbaarheid, RTO en RPO op te stellen, zoals in de onderstaande tabel.

Niveau 0 Niveau 1 Niveau 2 Niveau 3
Kritische infrastructuur en serviceonderdelen Onze services op niveau 0 zijn de services die de basis vormen van al onze andere services en die kritiek zijn om onze producten te leveren. De services van niveau 1 zijn onze producten of zijn rechtstreeks gekoppeld aan het leveren van onze producten. Services van niveau 2 zijn of niet-kritisch of intern gericht. Services van niveau 3 zijn of niet-kritisch of intern gericht.
Voorbeeld van services:

Voorbeeld van services

· AWS-platform

· Micros-server

· Netwerkkern

Voorbeeld van services

· Jira en Confluence Cloud

· Bitbucket

Voorbeeld van services

· Image Effects

· CAC

Voorbeeld van services

· Analyses en/of BI-gegevens ontvangen

RPO* < 1 uur < 1 uur < 8 uur < 24 uur
RTO** < 4 uur < 6 uur < 24 uur < 72 uur

* RPO, Recovery Point Objective; gegevensverlies in geval van een ramp

** RTO, Recovery Time Objective; serviceherstel in geval van een ramp

Bij Atlassian stellen we service-eigenaren verantwoordelijk om ervoor te zorgen dat de service in kwestie de RPO- en RTO-doelen haalt.

Hoe we disaster recovery testen

Atlassian voert regelmatig tests voor disaster recovery uit en streeft naar doorlopende verbetering als onderdeel van ons rampenherstelprogramma (DR, disaster recovery). Dit is bedoeld om te kunnen garanderen dat de gegevens en services van klanten betrouwbaar en veerkrachtig zijn. We voeren zowel geplande als ad hoc-tests uit. Hieronder vallen de volgende aspecten:

Documentatie: de back-updocumentatie voor kritische/klantgerichte services (niveau 0 en niveau 1) wordt elk kwartaal beoordeeld op nauwkeurigheid en volledigheid/actualiteit. Alle gevonden problemen worden gedocumenteerd en leveren een intern Jira-ticket op, zodat het probleem wordt gevolgd tot het is opgelost.

Proces: er worden bovendien elk kwartaal tests uitgevoerd voor actuele technische back-up-/herstelprocessen voor kritische/klantgerichte services (niveau 0 en niveau 1) om te bepalen of aan de RTO- en RPO-doelen voldaan wordt (op basis van niveauclassificatie van de service). Alle problemen die in deze tests worden gevonden worden ingediend als Jira-ticket, zodat het probleem wordt gevolgd tot het is opgelost.

Weerbaarheid en failover: weerbaarheid van AZ's worden periodiek en ad hoc getest om er zeker van te zijn dat Atlassian een AZ-storing aankan met minimale downtime. We begrijpen dat een storing in een hele regio erg onwaarschijnlijk is, maar we testen toch periodiek de regiofailover zodat we onze regionale weerbaarheid kunnen blijven ontwikkelen.

Systemen: de Site Reliability Engineering (SRE)-teams en productengineeringteams houden voortdurend een breed scala aan statistieken van verschillende services in de gaten om te zorgen dat gebruikers een uitstekende ervaring hebben. Geautomatiseerde waarschuwingen zijn geconfigureerd om leden van het SRE-team op de hoogte te brengen wanneer bepaalde grenswaarden voor servicestatistieken overschreden worden, zodat ze meteen actie kunnen ondernemen binnen onze incidentresponsprocessen.

Dashboard Disaster Recovery: we houden intern een DR-dashboard bij, zodat kritische/klantgerichte services (niveau 0 en niveau 1), Jira-tickets met betrekking tot toezicht, onderhoud en tests centraal gevolgd kunnen worden om er zeker van te zijn dat beoordelingen van documentatie en back-up/herstelprocessen op tijd worden voltooid.

DR-tests en -simulaties: DR-tests worden jaarlijks en ad hoc uitgevoerd. We voeren simulaties uit als onderdeel van onze DR-tests, om de DR-teams te helpen verschillende scenario's van potentiële incidenten te doorlopen. Simulaties testen verschillende scenario's en brengen hiaten in onze herstelprocessen in kaart. Simulatie-scenario's zijn onder andere aardbevingen, brand, natuurrampen, hersteloefeningen en tests. Nadat de DR-tests uitgevoerd zijn, worden de resultaten van de tests vastgelegd, geanalyseerd en besproken om de scope van de volgende stappen voor continu herstel te bepalen. De verbeteringswerkzaamheden worden vastgelegd in een Jira-ticket en bijgehouden tot ze zijn opgelost.

Atlassian erkent dat onze tests en processen technisch streng zijn, maar dat we nog altijd de norm stellen dankzij uitzonderlijke mensen die het allemaal uit laten komen. Atlassian neemt daarom ook de volgende menselijke aspecten op in ons DR-programma:

Site Reliability Engineers (SRE's): SRE's zetten zich in voor doorlopende periodieke DR-vergaderingen en vertegenwoordigen hun kritische services. Ze stellen DR-hiaten vast met ons risico- en complianceteam en richten zich waar nodig op herstel.

Disaster Recovery Champions: DR-champions worden in ieder product- of serviceteam aangewezen (inclusief voor onderliggende services) om toezicht te houden op en te helpen bij het beheren van de implementatie van DR binnen dat product/die service om er zeker van te zijn dat het aan de vereisten voor het serviceniveau voldoet.

Leiderschap: we behouden de betrokkenheid en doorlopende inzet van executive en senior management in onze DR-processen. Omdat leidinggevenden betrokken zijn, worden zowel zakelijke als technische drijfveren meegenomen in Atlassian's weerbaarheidsstrategie.

Andere bredere maatregelen en plannen voor bedrijfscontinuïteit

Atlassian streeft ernaar om sterke capaciteiten voor bedrijfscontinuïteit ('BC') en DR te behouden en er zeker van te zijn dat het effect op onze klanten geminimaliseerd wordt voor het geval onze bedrijfsvoering verstoord wordt. De belangrijkste leidende principes voor onze BC- en DR-programma's zijn:

Continue verbetering: het doel van Atlassian is om te garanderen dat weerbaarheid steeds verbetert via operationele efficiëntie, automation, nieuwe technologieën en bewezen werkwijzen.

Zekerheid door tests: Atlassian begrijpt we optimale weerbaarheid kunnen bereiken via regelmatig geplande tests en door continue verbeteringen toe te passen.

Speciale resources: Atlassian heeft speciale mensen en teams om er zeker van te zijn dat onze klantgerichte producten de nodige aandacht krijgen om BC en DR mogelijk te maken. Atlassian heeft de juiste hoeveelheid resources ter plaatse ter ondersteuning van onze stuurgroep, risicobeoordelingen, analyserende tests van bedrijfsimpact en natuurlijk levensechte incidenten.

Samenvatting

Atlassian combineert vooraanstaande technologieën en doorlopende tests en controles om er zeker van te zijn dat onze klantgegevens beschikbaar, betrouwbaar en veerkrachtig zijn. We hebben meerdere geografisch verspreide datacenters, een uitgebreid back-upprogramma en verkrijgen zekerheid door disaster recovery- en bedrijfscontinuïteitsplannen regelmatig te testen. Bovendien hebben we uitzonderlijke mensen en specifieke resources die al onze processen samenbrengen.