Close

Zarządzanie danymi klienta w Atlassian


Osiąganie odporności przez Atlassian

Produkty chmurowe Atlassian zostały zaprojektowane z myślą o zapewnieniu wysokiej wydajności i bazują na najlepszych w swojej klasie technologiach, aby nasi użytkownicy mogli mieć pewność, że ich dane oraz usługi będą dostępne w każdej chwili. W Atlassian dokładamy wszelkich starań, aby zapewnić odporność danych i usług naszych klientów, zwłaszcza że sami korzystamy z tego samego pakietu produktów.

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.

Zarządzanie kopiami zapasowymi

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ętrzne Micros oraz pozostałą infrastrukturę. Na platformie Micros działają takie produkty, jak Jira, Confluence, Statuspage i Atlassian Access, natomiast w środowiskach innych niż Micros działają takie aplikacje, jak Bitbucket, 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.

Usługi i funkcje Bitbucket Cloud są obsługiwane przez zbiór usług działających w centrum danych NTT Communications (NTT) w Ashburn w Wirginii, natomiast kopie zapasowe są przechowywane zarówno w centrum danych NTT w Santa Clara w Kalifornii, jak i w AWS. Dane klientów Bitbucket Cloud są przechowywane w systemach archiwizujących PostgreSQL i NetApp.

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.

W przypadku Bitbucket kopie zapasowe są przechowywane zarówno w fizycznych centrach danych NTT, jak i w AWS.

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.

Zapewnianie wysokiej dostępności dzięki licznym centrom danych i strefom dostępności

Mając na uwadze możliwość wystąpienia huraganów, trzęsień ziemi czy uderzeń tsunami — czyli odległych, ale niemożliwych do całkowitego wyeliminowania zagrożeń — konieczne jest tworzenie kopii zapasowych (i replikowanie) danych w różnych lokalizacjach geograficznych, aby niezależnie od zaistniałych sytuacji można je było odzyskać.

W Atlassian wykorzystujemy w tym celu wysoce dostępne centra danych AWS w wielu regionach na całym świecie. Każdy region AWS jest odrębną lokalizacją geograficzną podzieloną na wiele odizolowanych od siebie obszarów zwanych strefami dostępności (Availability Zone, AZ). Przykładowo w regionie US-West (Zachodnie Wybrzeże Stanów Zjednoczonych) znajdują się dwie strefy AZ: us-west-1a (zlokalizowana w Północnej Kalifornii) oraz us-west-1b (zlokalizowana w Oregonie). Obydwie te strefy należą do jednego regionu ogólnego, ale pod względem geograficznym są odrębne.

Każda strefa AZ jest zaprojektowana tak, aby była odizolowana od awarii w innych strefach AZ, a jednocześnie zapewniała niedrogą łączność sieciową o małych opóźnieniach z innymi strefami AZ należącymi do tego samego regionu. Wysoka dostępność wynikająca z zastosowania wielu stref stanowi pierwszą linię obrony i oznacza, że usługi działające w oparciu o wdrożenia w wielu strefach AZ powinny być odporne na awarię w pojedynczej strefie AZ.

Produkty Jira i Confluence wykorzystują tryb wdrażania w wielu strefach AZ usługi Amazon RDS. W takim trybie wdrożenia usługa Amazon RDS inicjuje i utrzymuje synchroniczną replikę rezerwową w różnych strefach AZ tego samego regionu, zapewniając w ten sposób nadmiarowość i możliwość pracy w trybie awaryjnym. Przełączanie awaryjne między strefami AZ odbywa się automatycznie i trwa 60–120 sekund, umożliwiając możliwie jak najszybsze przywrócenie działania baz danych bez konieczności interwencji administracyjnej. Omówione koncepcje regionu, strefy AZ i replikacji przedstawiono na poniższych schematach. Produkty Opsgenie, Statuspage, Trello i Jira Align wykorzystują podobne strategie wdrażania. Niewielkie różnice dotyczą jedynie czasu tworzenia replik i przełączania awaryjnego.

W przypadku produktu Bitbucket wszystkie podstawowe serwery baz danych znajdują się w centrach danych NTT, przy czym węzły replikacji i kopie zapasowe przechowywane są zarówno w centrach danych NTT, jak i w AWS. Dane produkcyjne są stale replikowane w centrach danych NTT w Ashburn (Wirginia) oraz w Santa Clara (Kalifornia) poprzez zastosowanie technologii kopii lustrzanych. Dane produkcyjne Bitbucket są replikowane co 2 godziny z lokalizacji głównej do dodatkowej, przy czym opóźnienie replikacji wynosi średnio 10–20 minut, ale nie więcej niż cztery godziny.

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

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.