Close

Wie Atlassian Kundendaten verwaltet


Ausfallsicherheit bei Atlassian

Die Cloud-Produkte von Atlassian sind auf hohe Leistung ausgelegt und basieren auf erstklassigen Technologien, sodass du sicher sein kannst, dass du jederzeit auf deine Daten und Services zugreifen kannst. Wir bei Atlassian legen großen Wert auf die Ausfallsicherheit von Kundendaten und -services, nicht zuletzt, weil wir selbst die gleichen Produkte nutzen.

Deshalb verwenden wir viel Zeit und Energie darauf, die Auswirkungen etwaiger Störungen auf Kunden gering zu halten. Dafür nutzen wir mehrere geografisch verteilte Rechenzentren, haben ein umfangreiches Backupprogramm implementiert und sorgen durch regelmäßige Tests unserer Disaster-Recovery- und Business-Continuity-Pläne für ein allgemein hohes Sicherheitsniveau.

Auf dieser Seite erfährst du, wie wir die Daten unserer Kunden verwalten und schützen. Wir legen Backups an und greifen unter anderem auf die nativen Funktionen in Amazon Web Services (AWS) zurück, um die Verfügbarkeit unserer Services sicherzustellen. Wir erläutern, wie wir unsere Disaster-Recovery-Pläne regelmäßig testen und die Ergebnisse nutzen, um in Sachen Disaster-Recovery und Business-Continuity noch besser zu werden.

Datensicherung bei Atlassian

Das Wichtigste zuerst: Infrastruktur und Datenbanken

Atlassian ist grob gesagt in zwei Hauptinfrastrukturen unterteilt, in denen unsere Produkte ausgeführt werden: eine Platform-as-a-Service (PaaS)-Umgebung, die intern Micros genannt wird, und Nicht-Micros-Umgebungen. Auf Micros werden unter anderem Jira, Confluence, Statuspage und Atlassian Access ausgeführt. Auf den Nicht-Micros-Umgebungen laufen zum Beispiel Bitbucket, Opsgenie und Trello. Der Einfachheit halber beschränken wir uns im Folgenden auf die wichtigsten Produkte: Jira, Confluence und Bitbucket.

Jira und Confluence Cloud werden im Rahmen des AWS Infrastructure-as-a-Service (IaaS)-Angebots in mehreren AWS-Regionen gehostet (insbesondere sind dies USA-Ost, USA-West, Irland, Frankfurt, Singapur und Sydney, wobei bei Bedarf die Expansion in weitere Regionen geplant ist). Jira und Confluence Cloud verwenden logisch getrennte relationale Datenbanken für jede Produktinstanz, während die in Jira oder Confluence Cloud gespeicherten Anhänge in unserer Dokumentenspeicherplattform ("Media Platform") abgelegt werden, die letztendlich in Amazon S3 gespeichert wird.

Die Services und Funktionen von Bitbucket Cloud werden über das Rechenzentrum von NTT Communications (NTT) in Ashburn, Virginia, bereitgestellt, wobei Backups sowohl im NTT-Rechenzentrum in Santa Clara, Kalifornien, als auch in AWS gespeichert werden. Die Kundendaten von Bitbucket Cloud werden in PostgreSQL- und NetApp-Filern gespeichert.

Backups

Daten sind die Lebensader deines Unternehmens. Keine Daten = kein Business. Atlassian weiß das und wir haben sogar eine Regel im Unternehmen, die lautet: "Versuche nicht, den Kunden hinters Licht zu führen". Deshalb unternehmen wir alles, um deine Daten vor Verlust zu schützen, und haben ein umfangreiches Backupprogramm implementiert.

Für Jira und Confluence Cloud nutzt Atlassian die Snapshot-Funktion von Amazon RDS (Amazon Relational Database Service), um automatische tägliche Backups jeder RDS-Instanz anzulegen. Amazon RDS-Snapshots werden 30 Tage lang aufbewahrt. Sie unterstützen die zeitpunktspezifische Wiederherstellung (Point-in-Time Recovery) und sind AES-256-verschlüsselt.

Bitbucket-Backups werden sowohl in NTT-Rechenzentren als auch in AWS gespeichert.

Die Backups werden von Atlassian vierteljährlich getestet, um ihre Wiederherstellbarkeit zu überprüfen. Etwaige Probleme, die sich bei den Tests ergeben, werden als Jira-Tickets geloggt, um sicherzustellen, dass sie bearbeitet und gelöst werden.

Weitere Informationen findest du in unseren FAQs zur Datenspeicherung.

Hohe Verfügbarkeit durch mehrere Rechenzentren und Availability Zones

Hurrikane, Erdbeben und Tsunamis mögen unwahrscheinlich sein, unmöglich sind sie nicht. Deswegen werden unsere Backups geografisch verteilt an verschiedenen Orten gespeichert (und repliziert), damit die Daten auf jeden Fall wiederhergestellt werden können.

Atlassian nutzt dafür die hochverfügbaren AWS-Rechenzentren, die in verschiedenen Weltregionen angesiedelt sind. AWS-Regionen sind geografisch getrennt und bestehen selbst aus mehreren isolierten Standorten, den sogenannten Availability Zones (AZs). Die Region USA-West (die Westküste der Vereinigten Staaten) besteht zum Beispiel aus den beiden AZs "us-west-1a" (in Nordkalifornien) und "us-west-1b" (in Oregon). Beide liegen innerhalb derselben Region, sind geografisch aber getrennt.

AZs in derselben Region sind über ein kostengünstiges, latenzarmes Netzwerk miteinander verbunden, gleichzeitig aber gegenseitig fehlertolerant. Die Verteilung auf mehrere Zonen ermöglicht Hochverfügbarkeit und sorgt dafür, dass ein in einem Multi-AZ-Deployment ausgeführter Service den Ausfall einer AZ problemlos übersteht.

Jira und Confluence nutzen den Multi-AZ-Deployment-Modus für Amazon RDS. In einem Multi-AZ-Deployment stellt Amazon RDS eine synchrone Standby-Replikat in einer anderen AZ der gleichen Region bereit, um Redundanz und Failover-Funktionalität zu gewährleisten. Das AZ-Failover ist automatisiert und dauert in der Regel 60 bis 120 Sekunden, sodass Datenbankoperationen so schnell wie möglich ohne Administratoreingriff wieder aufgenommen werden können. Die Konzepte "Region", "AZ" und "Replikation" sind in den folgenden Diagrammen dargestellt. Opsgenie, Statuspage, Trello und Jira Align verwenden ähnliche Deployment-Strategien, mit geringen Abweichungen beim Replikat- und Failover-Timing.

Bei Bitbucket befinden sich alle primären Datenbankserver in NTT-Rechenzentren, wobei Replikationsknoten und Backups sowohl in NTT-Rechenzentren als auch in AWS gespeichert werden. Die Produktionsdaten werden sowohl in den Rechenzentren von NTT Ashburn, Virginia, als auch in Santa Clara, Kalifornien, mittels Mirroring-Technologie laufend repliziert. Bitbucket-Produktionsdaten werden alle 2 Stunden von ihrem Hauptstandort zu ihrem Nebenstandort repliziert, mit einer durchschnittlichen Verzögerung von 10 bis 20 Minuten und maximal vier Stunden.

Wie wir Recovery Time Objectives und Recovery Point Objectives festlegen

In einer perfekten Welt würden wir wichtige Geschäftsdaten nie verlieren. In der Praxis ist ein System ohne Datenverlustrisiko jedoch entweder unerreichbar oder unerschwinglich teuer. Auch wenn die Unternehmenskultur von Atlassian ein Null-Datenverlustszenario und die Fähigkeit, den Ausfall einer Availability Zone automatisch zu überleben, erstrebenswert macht, schreibt die Business-Continuity-Planung vor, "Recovery Time Objectives" und "Recovery Point Objectives" (RTOs bzw. RPOs) festzulegen, die Kosten, Nutzen und Risiko optimal abwägen.

Das RTO gibt an, wie schnell nach einem Vorfall ein Geschäftsprozess (oder System) wiederhergestellt und wieder in Betrieb sein soll. Das RPO steht für die Datenmenge, deren Verlust für das Unternehmen nach erfolgter Wiederherstellung akzeptabel ist. Angenommen, du erstellst jeden Tag ein Backup und tags darauf kommt es zu einem Datenverlust, dann kannst du nur das gestrige Backup wiederherstellen. Du verlierst die Daten eines (1) Tages. Das ist das RPO.

Zur Festlegung von kundenspezifischen RTO- und RPO-Zielen führen unsere Teams ein Business-Impact-and-Risk-Assessment durch, das die geschäftlichen Auswirkungen und Risiken für Kunden anhand der jeweiligen Benutzeranforderungen bewertet.

Unsere Services haben wir ganz unkompliziert in Segmente aufgeteilt, die wir Stufen nennen. Es gibt drei Stufen für Produkte und kundenorientierte Services, Atlassian Business Systems und interne Tools (die Stufen 1, 2 und 3) sowie eine darunterliegende Stufe (0), die noch höhere Verfügbarkeit für die kritischen Komponenten bereitstellt, auf die sich alles andere stützt.

Für jede Stufe haben wir verbindliche Ziele definiert, indem wir unter anderem Business-Impact-Assessments durchführen und die von uns entwickelten Services in typischen Nutzungsszenarien testen. Unsere Servicestufen lassen eine klare Aussage über Verfügbarkeit, Zuverlässigkeit sowie RTO- und RPO-Ziele zu, wie in der folgenden Tabelle zu sehen ist.

         
  Stufe 0 Stufe 1 Stufe 2 Stufe 3
Kritische Infrastruktur- und Servicekomponenten Services der Stufe 0 sind die Grundlage für alle anderen Services und daher für die Bereitstellung unserer Produkte entscheidend. Services der Stufe 1 sind unsere Produkte oder direkt an der Bereitstellung unserer Produkte beteiligt. Services der Stufe 2 sind entweder nicht kritisch oder werden intern genutzt. Services der Stufe 3 sind entweder nicht kritisch oder werden intern genutzt.
Beispiel-Services:

Beispiel-Services

· AWS-Plattform

· Micros-Server

· Netzwerkkern

Beispiel-Services

· Jira und Confluence Cloud

· Bitbucket

Beispiel-Services

· Bildeffekte

· CAC

Beispiel-Services

· Empfang von Analyse- und/oder BI-Daten

RPO* <1 Stunde <1 Stunde <8 Stunden   <24 Stunden  
RTO** <4 Stunden <6 Stunden <24 Stunden <72 Stunden

*RPO – Recovery Point Objective – Datenverlust bei Ausfall

**RTO – Recovery Time Objective – Servicewiederherstellung bei Ausfall

Bei Atlassian sind Service Owner (Servicebesitzer) dafür verantwortlich, dass die RPO- und RTO-Vorgaben ihres Services eingehalten werden.    

 

Wie wir Disaster-Recovery-Tests durchführen

Atlassian führt regelmäßig Disaster-Recovery-Tests durch und hat sich in seinem Disaster-Recovery (DR)-Programm zu kontinuierlicher Verbesserung verpflichtet. So soll sichergestellt werden, dass die Daten und Services unserer Kunden jederzeit verfügbar und ausfallsicher sind. Tests finden sowohl geplant als auch ad-hoc statt und umfassen unter anderem folgende Elemente:

Dokumentation: Für kritische Kundenservices (einschließlich Stufe 0 und Stufe 1) wird die Backupdokumentation vierteljährlich auf Genauigkeit, Vollständigkeit und Aktualität überprüft. Probleme werden dokumentiert und in internen Jira-Tickets geloggt, damit das Problem verfolgt wird, bis es behoben ist.

Prozesse: Die technische Grundlage unserer Backup- und Wiederherstellungsprozesse für kritische/kundenorientierte Services (einschließlich Stufe 0 und Stufe 1) wird im vierteljährlichen Turnus überprüft. Dabei soll festgestellt werden, ob RTO- und RPO-Ziele (der jeweiligen Servicestufe) zuverlässig erreicht werden. Probleme, die sich aus diesen Tests ergeben, werden in Jira-Tickets geloggt, sodass das Problem verfolgt wird, bis es behoben ist.

Ausfallsicherheit und Failover: Die Ausfallsicherheit der AZs wird regelmäßig und ad hoc getestet, um sicherzugehen, dass Atlassian einen AZ-Ausfall mit minimaler Unterbrechung überstehen kann. Der Ausfall einer ganzen Region ist zwar unwahrscheinlich, dennoch testen wir auch regionale Failover und arbeiten daran, unsere Ausfallsicherheit dahingehend zu verbessern.

Systeme: Die Site-Reliability-Engineering (SRE)-Teams und Product-Engineering-Teams überwachen laufend eine Vielzahl von Kennzahlen, um sicherzustellen, dass alle unsere Services wie gewünscht funktionieren. Werden bestimmte Schwellenwerte für Servicemetriken überschritten, wird das SRE-Team automatisch benachrichtigt und kann im Rahmen unserer Incident-Response-Prozesse sofort Gegenmaßnahmen ergreifen.

Disaster-Recovery-Dashboard: Wichtige Informationen zu kritischen und kundenorientierten Services (einschließlich Stufe 0 und Stufe 1) fließen in unserem internen DR-Dashboard zusammen. Jira-Tickets in Bezug auf Überwachung, Wartung und Tests lassen sich zentral verfolgen, damit Überprüfungen der Dokumentation und Backup-/Wiederherstellungsprozesse fristgerecht abgeschlossen werden können.

DR-Tests und -Simulationen: DR-Tests finden jährlich und ad hoc statt. Dabei spielen wir mit den DR-Teams in Table-Top-Übungen diverse Vorfälle durch. Table-Top-Übungen testen verschiedene Szenarien und ermöglichen es uns, Lücken in unseren Wiederherstellungsprozessen zu identifizieren. Beispiele für Table-Top-Übungen: Erdbeben, Feuer, Naturkatastrophen, Wiederherstellungsübungen und -tests. Im Anschluss an die DR-Tests werden die Ergebnisse erfasst, ausgewertet und diskutiert, um Verbesserungsmaßnahmen zu bestimmen. Diese werden in einem Jira-Ticket geloggt und bis zur Behebung verfolgt.

Unsere Tests und Prozesse sind technisch sehr anspruchsvoll, aber wir haben das Glück, mit außergewöhnlichen Menschen zusammenzuarbeiten, die all dies möglich machen. Am DR-Programm von Atlassian sind unter anderem die folgenden Funktionen beteiligt:

Site Reliability Engineers ("SREs"): SREs nehmen regelmäßig an DR-Meetings teil und repräsentieren jeweils einen kritischen Service. Sie arbeiten mit unserem Risiko- und Compliance-Team zusammen, um DR-Lücken zu identifizieren, und kümmern sich bei Bedarf verstärkt um die Problembehebung.

Disaster Recovery Champions: DR Champions werden innerhalb der Produkt-/Serviceteams (einschließlich der zugrunde liegenden Services) ernannt, um die DR-Implementierung innerhalb dieses Produkts/Services zu überwachen und zu unterstützen. Sie sorgen dafür, dass die Anforderungen an die Servicestufe erfüllt werden.

Führungsebene: Die Geschäftsleitung und das obere Management sind in alle unsere DR-Prozesse involviert. Durch Einbeziehung der Führungsebene kann Atlassian seine Ausfallsicherheitsstrategie aus einem technischen und einem geschäftlichen Blickwinkel betrachten.

Andere Business-Continuity-Maßnahmen und -Pläne

Atlassian möchte, dass unsere Kunden von Störungen unserer Infrastruktur möglichst wenig betroffen sind und hat dafür starke Business-Continuity (BC)- und DR-Funktionen aufgebaut. Bei der Umsetzung unseres BC- und DR-Programms lassen wir uns unter anderem von den folgenden Prinzipien leiten:

Kontinuierliche Verbesserung: Atlassian verbessert die Ausfallsicherheit durch Effizienzsteigerung, Automatisierung, neue Technologien und die Nutzung bewährter Verfahren.

Sicherheit durch Tests: Atlassian führt regelmäßige, geplante Tests durch und setzt auf kontinuierliche Verbesserung, um optimale Ausfallsicherheit zu erreichen.

Spezialisierte Ressourcen: Bei Atlassian sind eigens Mitarbeiter und Teams abgestellt, die für die BC- und DR-Funktionen unserer kundenorientierten Produkte zuständig sind. Atlassian stellt in großem Umfang Ressourcen bereit, zum Beispiel für unseren Lenkungsausschuss, Risikobewertungen, Tests zur Business-Impact-Analyse und natürlich zur Bearbeitung tatsächlicher Vorfälle.

Zusammenfassung

Atlassian sorgt für die Hochverfügbarkeit, den Schutz und die Ausfallsicherheit von Kundendaten. Dies erreichen wir durch erstklassige Technologien, kontinuierliche Tests und Validierungen. Wir betreiben mehrere geografisch verteilte Rechenzentren, verfügen über ein umfangreiches Backupprogramm und testen unsere Disaster-Recovery- und Business-Continuity-Pläne regelmäßig auf Eignung und Wirksamkeit. Das Fundament jedoch, auf das sich all diese Maßnahmen stützen, sind unsere engagierten Mitarbeiter und Ressourcen, die alle unsere Prozesse zusammenführen.