Close

Wie Atlassian Kundendaten verwaltet


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.

Ausfallsicherheit bei Atlassian

Unsere Produkte laufen in einer PaaS-Umgebung (Platform as a Service), die in zwei Hauptinfrastrukturgruppen aufgeteilt ist, die wir als Micros und Nicht-Micros bezeichnen. Jira, Confluence, Statuspage, Access, Bitbucket und Trello laufen auf der Micros-Plattform, während Jira Align und Opsgenie auf der Nicht-Micros-Plattform ausgeführt werden.

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.

Das Wichtigste zuerst: Infrastruktur und Datenbanken

Atlassian ist grob gesagt in zwei Hauptinfrastrukturen unterteilt, in denen unsere Produkte ausgeführt werden: eine PaaS-Umgebung (Platform as a Service), die intern Micros genannt wird, und Nicht-Micros-Umgebungen. Auf Micros werden unter anderem Jira, Confluence, Statuspage, Bitbucket und Atlassian Access ausgeführt. Auf den Nicht-Micros-Umgebungen laufen zum Beispiel 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.

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.

Hinweis zu Jira Align: Amazon RDS-Snapshots werden 35 Tage lang aufbewahrt.

Für Bitbucket werden Daten in eine andere AWS-Region repliziert. In jeder Region werden täglich unabhängige Backups erstellt.

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.

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.

Hinweis zu Jira Align: Amazon RDS-Snapshots werden 35 Tage lang aufbewahrt.

Für Bitbucket werden Daten in eine andere AWS-Region repliziert. In jeder Region werden täglich unabhängige Backups erstellt.

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.

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.

Hinweis zu Jira Align: Amazon RDS-Snapshots werden 35 Tage lang aufbewahrt.

Für Bitbucket werden Daten in eine andere AWS-Region repliziert. In jeder Region werden täglich unabhängige Backups erstellt.

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.

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 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 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

· Jira Align

· Trello

· Opsgenie

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.