Close

Zarządzanie danymi klienta w Atlassian


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.

Osiąganie odporności przez Atlassian

Nasze produkty działają w środowisku PaaS (Platform as a Service) podzielonym na dwa główne zbiory infrastruktury, które określamy jako Micros i inny niż Micros. Produkty Jira, Confluence, Statuspage, Access, Bitbucket i Trello działają na platformie Micros, a Jira Align i Opsgenie na innej niż Micros.

W związku z tym staramy się ograniczyć do minimum wpływ ewentualnych zakłóceń na klienta. Korzystamy z wielu centrów danych zlokalizowanych w różnych miejscach świata, dysponujemy kompleksowym programem tworzenia kopii zapasowych i gwarantujemy niezawodność poprzez regularne testowanie planów odzyskiwania awaryjnego i utrzymania ciągłości działalności biznesowej.

Niniejsza strona zawiera omówienie sposobu, w jaki zarządzamy całym cyklem procesu zarządzania danymi klienta, z uwzględnieniem tworzenia kopii zapasowych w oparciu o natywne możliwości, jakie oferuje Amazon Web Services (AWS), w celu zapewnienia dostępności naszych usług, regularnego testowania naszych planów odzyskiwania awaryjnego oraz naszego podejścia do ciągłego doskonalenia planów odzyskiwania awaryjnego i utrzymania ciągłości działalności biznesowej.

Przede wszystkim: infrastruktura i bazy danych

Ogólnie rzecz biorąc, infrastrukturę Atlassian używaną do obsługi naszych produktów można podzielić na dwa główne zbiory: środowisko platformy jako usługi (PaaS) nazywane wewnętrznie Micros oraz pozostałą infrastrukturę. Na platformie Micros działają takie produkty, jak Jira, Confluence, Statuspage, Bitbucket i Atlassian Access, natomiast w środowiskach innych niż Micros działają takie aplikacje, jak Opsgenie i Trello. Dla ułatwienia w tym artykule skoncentrujemy się przede wszystkim na naszych największych produktach: Jira, Confluence i Bitbucket.

Rozwiązania Jira i Confluence Cloud są hostowane w wielu regionach AWS dostępnych w ramach oferty infrastruktury jako usługi (IaaS) AWS (a konkretnie wschodnia i zachodnia część USA, Irlandia, Frankfurt, Singapur oraz Sydney, a w miarę potrzeb planujemy również rozszerzenie na inne regiony). Jira i Confluence Cloud wykorzystują logicznie odrębne relacyjne bazy danych dla każdej instancji produktu, natomiast załączniki zapisane w Jira lub Confluence Cloud są przechowywane na naszej platformie magazynu dokumentów („Platformie multimedialnej”) obsługiwanej przez usługę Amazon S3.

Kopie zapasowe

W Atlassian wiemy, że niezależnie od profilu działalności, wiąże się ona z generowaniem danych, a bez danych nie da się prowadzić działalności. W myśl naszej wartości, która brzmi „Nie wkurzamy klientów”, dbamy o ochronę danych użytkowników przed utratą i dysponujemy rozbudowanym programem tworzenia kopii zapasowych.

W przypadku Jira i Confluence Cloud Atlassian korzysta z funkcji migawki usługi relacyjnej bazy danych Amazon RDS (Relational Database Service) w celu codziennego tworzenia zautomatyzowanych kopii zapasowych każdej instancji RDS. Migawki Amazon RDS są przechowywane przez 30 dni z obsługą odzyskiwania do określonego momentu i są szyfrowane przy użyciu algorytmu AES-256.

Należy pamiętać, że w przypadku Jira Align migawki usługi Amazon RDS są przechowywane przez 35 dni.

W przypadku Bitbucket dane są replikowane do innego regionu AWS, a w każdym regionie codziennie wykonywane są niezależne kopie zapasowe.

Co kwartał Atlassian testuje funkcję odzyskiwania danych z kopii zapasowych, a wszelkie nieprawidłowości wykryte w trakcie tych testów są przekazywane w formie zgłoszeń w systemie Jira, aby umożliwić ich monitorowanie aż do momentu wyeliminowania.

Więcej informacji można znaleźć na stronie Przechowywanie danych — często zadawane pytania.

Kopie zapasowe

W Atlassian wiemy, że niezależnie od profilu działalności, wiąże się ona z generowaniem danych, a bez danych nie da się prowadzić działalności. W myśl naszej wartości, która brzmi „Nie wkurzamy klientów”, dbamy o ochronę danych użytkowników przed utratą i dysponujemy rozbudowanym programem tworzenia kopii zapasowych.

W przypadku Jira i Confluence Cloud Atlassian korzysta z funkcji migawki usługi relacyjnej bazy danych Amazon RDS (Relational Database Service) w celu codziennego tworzenia zautomatyzowanych kopii zapasowych każdej instancji RDS. Migawki Amazon RDS są przechowywane przez 30 dni z obsługą odzyskiwania do określonego momentu i są szyfrowane przy użyciu algorytmu AES-256.

Należy pamiętać, że w przypadku Jira Align migawki usługi Amazon RDS są przechowywane przez 35 dni.

W przypadku Bitbucket dane są replikowane do innego regionu AWS, a w każdym regionie codziennie wykonywane są niezależne kopie zapasowe.

Co kwartał Atlassian testuje funkcję odzyskiwania danych z kopii zapasowych, a wszelkie nieprawidłowości wykryte w trakcie tych testów są przekazywane w formie zgłoszeń w systemie Jira, aby umożliwić ich monitorowanie aż do momentu wyeliminowania.

Więcej informacji można znaleźć na stronie Przechowywanie danych — często zadawane pytania.

Kopie zapasowe

W Atlassian wiemy, że niezależnie od profilu działalności, wiąże się ona z generowaniem danych, a bez danych nie da się prowadzić działalności. W myśl naszej wartości, która brzmi „Nie wkurzamy klientów”, dbamy o ochronę danych użytkowników przed utratą i dysponujemy rozbudowanym programem tworzenia kopii zapasowych.

W przypadku Jira i Confluence Cloud Atlassian korzysta z funkcji migawki usługi relacyjnej bazy danych Amazon RDS (Relational Database Service) w celu codziennego tworzenia zautomatyzowanych kopii zapasowych każdej instancji RDS. Migawki Amazon RDS są przechowywane przez 30 dni z obsługą odzyskiwania do określonego momentu i są szyfrowane przy użyciu algorytmu AES-256.

Należy pamiętać, że w przypadku Jira Align migawki usługi Amazon RDS są przechowywane przez 35 dni.

W przypadku Bitbucket dane są replikowane do innego regionu AWS, a w każdym regionie codziennie wykonywane są niezależne kopie zapasowe.

Co kwartał Atlassian testuje funkcję odzyskiwania danych z kopii zapasowych, a wszelkie nieprawidłowości wykryte w trakcie tych testów są przekazywane w formie zgłoszeń w systemie Jira, aby umożliwić ich monitorowanie aż do momentu wyeliminowania.

Więcej informacji można znaleźć na stronie Przechowywanie danych — często zadawane pytania.

Wyznaczanie docelowego czasu i punktu odzyskiwania

W idealnym świecie nigdy nie tracilibyśmy żadnych danych istotnych dla prowadzonej działalności. Jednak w praktyce zbudowanie systemu o zerowym ryzyku utraty danych jest nieosiągalne lub na tyle kosztowne, że staje się nieopłacalne. Oczekiwania stawiane zgodnie z kulturą obowiązującą w Atlassian zakładają dążenie do scenariusza, w którym ryzyko utraty danych zostałoby wyeliminowane, oraz możliwości automatycznego przetrwania awarii w strefie dostępności. Przy planowaniu zapewniania ciągłości działalności biznesowej konieczne jest jednak wyznaczenie „docelowego czasu odzyskiwania” i „docelowego punktu odzyskiwania” (odpowiednio RTO i RPO) tak, aby osiągnąć właściwą równowagę między kosztem, korzyścią a ryzykiem.

RTO oznacza okres po wystąpieniu incydentu, w trakcie którego powinno nastąpić odzyskanie procesu (lub systemu) biznesowego i przywrócenie go do działania. Z kolei RPO oznacza ilość danych, której utratę w trakcie odzyskiwania dopuszcza organizacja. Posłużmy się prostym przykładem. Jeśli wykonujesz kopię zapasową codziennie, a na koniec dnia dojdzie do incydentu i odzyskania danych z kopii zapasowej (wykonanej wczoraj), wówczas stracisz 1 dzień danych. To właśnie RPO.

Nasze oceny wpływu na działalność i ryzyka pomagają naszym zespołom ustawiać własne cele dotyczące RTO i RPO w oparciu o wymagania użytkowników klienta oraz potencjalny wpływ zakłócenia.

Mówiąc dokładniej, dzielimy nasze usługi na łatwe do zrozumienia grupy, które nazywamy warstwami. Produkty oraz usługi skierowane do klientów, systemy biznesowe i narzędzia Atlassian składają się na trzy warstwy (Warstwa 1, 2 i 3). W przypadku składników krytycznych, na których wszystko się opiera, dostępna jest również warstwa podstawowa (Warstwa 0), zapewniająca jeszcze wyższy standard dostępności.

Dla każdej warstwy zdefiniowaliśmy obowiązkowe cele, opierając się między innymi na ocenach wpływu na działalność i typowych scenariuszach użycia tworzonych przez nas usług. Nasze warstwy usług pozwalają określić dostępność, niezawodność oraz cele dotyczące RTO i RPO, zgodnie z poniższą tabelą.

Warstwa 0 Warstwa 1 Warstwa 2 Warstwa 3
Infrastruktura i składniki usług o znaczeniu krytycznym Nasze usługi Warstwy 0 stanowią podstawę dla wszystkich innych usług. Mają one krytyczne znaczenie dla dostarczania naszych produktów. Nasze usługi Warstwy 1 to zasadniczo nasze produkty lub usługi związane bezpośrednio z dostarczaniem naszych produktów. Usługi Warstwy 2 to usługi niemające krytycznego znaczenia lub usługi wewnętrzne. Usługi Warstwy 3 to usługi niemające krytycznego znaczenia lub usługi wewnętrzne.
Przykładowe usługi

Przykładowe usługi:

· Platforma AWS

· Serwer Micros

· Podstawowe usługi sieci

Przykładowe usługi:

· Jira i Confluence Cloud

· Bitbucket

· Jira Align

· Trello

· Opsgenie

Przykładowe usługi:

· Efekty obrazów

· CAC

Przykładowe usługi:

· Odbiór danych analitycznych lub BI

RPO* <1 godzina <1 godzina <8 godzin <24 godziny
RTO** <4 godziny <6 godzin <24 godziny <72 godziny

*RPO — (Recovery Point Objective) docelowy punkt odzyskiwania — utrata danych w przypadku awarii

**RTO — (Recovery Time Objective) docelowy czas odzyskiwania — czas przywracania usług w przypadku awarii

W Atlassian zapewnienie zgodności z celami dotyczącymi RPO i RTO należy do obowiązków właścicieli usług.

Sposoby testowania odzyskiwania awaryjnego

Atlassian regularnie przeprowadza testy odzyskiwania awaryjnego i dąży do ciągłego doskonalenia tego procesu w ramach programu odzyskiwania awaryjnego (DR). Ma to na celu zapewnienie niezawodności i odporności danych oraz usług klientów. Przeprowadzamy zarówno testy planowane, jak i testy ad hoc, obejmujące następujące elementy:

Dokumentacja — w przypadku usług krytycznych lub skierowanych do klientów (w tym usług Warstwy 0 i 1) co trzy miesiące przeprowadzane są kontrole dokumentacji kopii zapasowych, aby sprawdzić, czy jest ona dokładna, kompletna i aktualna. Wszystkie wykryte problemy są dokumentowane i dla każdego z nich tworzone jest zgłoszenie Jira, które umożliwia monitorowanie problemu do czasu jego wyeliminowania.

Proces — w przypadku usług krytycznych lub skierowanych do klientów (w tym usług Warstwy 0 i 1) co trzy miesiące przeprowadzane są również testy samych technicznych procedur tworzenia kopii zapasowych i odzyskiwania awaryjnego, aby stwierdzić, czy osiągnięto cele dotyczące RTO i RPO (biorąc pod uwagę klasyfikację usług według warstw). Dla każdego problemu wykrytego w trakcie tych testów tworzone jest zgłoszenie Jira, które umożliwia monitorowanie problemu do czasu jego wyeliminowania.

Odporność i praca w trybie awaryjnym — okresowo i doraźnie przeprowadzane są testy poziomów odporności stref dostępności, aby zyskać pewność, że Atlassian jest w stanie poradzić sobie w przypadku awarii strefy dostępności przy minimalnym przestoju. Zdajemy sobie sprawę, że całkowita awaria regionu jest bardzo mało prawdopodobna, jednak okresowo testujemy również funkcję awaryjnego przełączania regionów, dbając o rozwój naszej odporności na poziomie regionalnym.

Systemy — zespoły inżynierów ds. niezawodności lokalizacji (SRE) oraz inżynierów produktów ustawicznie monitorują wiele różnych wskaźników dotyczących usług, aby pomóc w zapewnieniu najwyższej jakości odbioru tych usług przez użytkowników. Skonfigurowano automatyczne alerty, aby powiadamiać członków zespołu SRE o przekroczeniu określonych wartości progowych wskaźników zdefiniowanych dla usług, umożliwiając im niezwłoczne podjęcie działań w ramach naszych procesów reagowania na incydenty.

Pulpit odzyskiwania awaryjnego — jest to wewnętrznie obsługiwane narzędzie. W przypadku usług o znaczeniu krytycznym lub skierowanych do klientów (w tym usług Warstwy 0 i 1) umożliwia ono centralne monitorowanie zgłoszeń Jira dotyczących nadzoru, konserwacji i testowania w celu zapewnienia terminowej realizacji procesów sprawdzania dokumentacji oraz tworzenia kopii zapasowych i odzyskiwania danych.

Testy i symulacje odzyskiwania awaryjnego — testy odzyskiwania awaryjnego są przeprowadzane co roku oraz ad hoc. W ramach naszych testów odzyskiwania awaryjnego przeprowadzamy teoretyczne ćwiczenia symulacyjne, które pozwalają zespołom odpowiedzialnym za odzyskiwanie awaryjne przeanalizować różne scenariusze potencjalnych incydentów. Ćwiczenia symulacyjne pozwalają przetestować różne scenariusze i wykryć luki w naszych procesach odzyskiwania danych. W trakcie ćwiczeń symulacyjnym rozważane są takie scenariusze, jak trzęsienie ziemi, pożar, klęska żywiołowa czy praktyczne ćwiczenia i testy odzyskiwania. Wyniki uzyskane po przeprowadzeniu testów odzyskiwania awaryjnego są rejestrowane, analizowane i omawiane w celu wyznaczenia kolejnych kroków w ramach procesu ciągłego doskonalenia. Działania usprawniające są dokumentowane w postaci zgłoszeń Jira i monitorowane aż do momentu ich przeprowadzenia.

Atlassian zdaje sobie sprawę, że pomimo rygorystycznych wymagań technicznych, którym podlegają testy i procesy, to doskonały zespół ludzi pozwala połączyć to wszystko w całość. W związku z tym w naszym programie odzyskiwania awaryjnego uwzględniliśmy następujące czynniki ludzkie:

Inżynierowie ds. niezawodności lokalizacji (SRE) — inżynierowie SRE biorą udział w regularnie organizowanych spotkaniach dotyczących odzyskiwania awaryjnego, reprezentując krytyczne usługi, którymi się zajmują. We współpracy z naszym zespołem ds. ryzyka i zgodności wykrywają luki w procesach odzyskiwania awaryjnego oraz koncentrują się na koniecznych działaniach zaradczych.

Liderzy ds. odzyskiwania awaryjnego — liderów ds. odzyskiwania awaryjnego wyznacza się w każdym zespole ds. produktów/usług (w tym usług podstawowych). Osoby te nadzorują wdrażanie procesów odzyskiwania awaryjnego w odniesieniu do konkretnego produktu lub konkretnej usługi i pomagają nimi zarządzać w celu spełnienia wymagań przewidzianych dla warstwy, do której należy usługa.

Kierownictwo — dbamy o stałe zaangażowanie zarządu i kadry kierowniczej wyższego szczebla w procesy odzyskiwania awaryjnego. Dzięki temu w swojej strategii zapewniania odporności Atlassian uwzględnia zarówno czynniki biznesowe, jak i techniczne.

Inne szeroko zakrojone plany i środki utrzymania ciągłości działalności biznesowej

Atlassian dąży do utrzymania wysokiego poziomu ciągłości działalności biznesowej (BC) oraz możliwości odzyskiwania awaryjnego, aby, w razie wystąpienia zakłóceń w naszej pracy, móc ograniczyć do minimum ich wpływ na naszych klientów. Najważniejsze zasady programu zapewniania ciągłości działalności biznesowej i odzyskiwania awaryjnego:

Ciągłe doskonalenie — Atlassian dąży do poprawy odporności poprzez zwiększanie wydajności operacyjnej, automatyzację oraz wdrażanie nowych technologii i sprawdzonych praktyk.

Zapewnianie odporności poprzez testy — Atlassian ma świadomość, że regularne przeprowadzanie zaplanowanych testów oraz wdrażanie ciągłych ulepszeń pozwoli nam osiągnąć optymalną odporność.

Dedykowane zasoby — w Atlassian wyznaczono specjalne osoby i zespoły, aby zapewnić produktom skierowanym do klientów uwagę potrzebną do zapewnienia ciągłości działalności biznesowej i sprawnego odzyskiwania awaryjnego. Atlassian ma do dyspozycji odpowiednią ilość zasobów, aby umożliwić funkcjonowanie komitetu sterującego, przeprowadzanie ocen ryzyka, testowanie analiz wpływu na działalność, a przede wszystkim obsługę rzeczywistych incydentów.

Podsumowanie

Atlassian łączy najlepsze w swojej klasie rozwiązania technologiczne oraz przeprowadzane na bieżąco testy i walidacje, aby zapewniać wysoką dostępność, niezawodność i odporność danych naszych klientów. Obsługujemy wiele centrów danych zlokalizowanych w różnych miejscach świata, dysponujemy rozbudowanym programem tworzenia kopii zapasowych i gwarantujemy niezawodność poprzez regularne testowanie planów odzyskiwania awaryjnego i utrzymania ciągłości działalności biznesowej. Przede wszystkim jednak mamy wyjątkowych pracowników i dedykowane zasoby, dzięki którym możemy realizować nasze procesy.