Każda decyzja biznesowa związana z wydatkami powoduje weryfikację bieżącego planu budżetowego zespołu, działu lub firmy. Kalkulacja oparta na planach finansowych powinna mieć odzwierciedlenie w ryzyku, które podejmuje organizacja. Jeśli biznes nie może pozwolić sobie na przestoje, przedsiębiorstwo stoi w obliczu decyzji, jakie środki przeznaczyć na ochronę biznesu przez ewentualnymi zagrożeniami z zewnątrz (ataki hakerskie) czy nawet z wnętrza organizacji (nielojalni pracownicy). W ostatnich kilkunastu latach infrastruktura IT zmienia się ze środowisk utrzymywanych lokalnie (on-premise) na rzecz przekazania utrzymania do chmur publicznych (Microsoft Azure, Amazon Web Services, Google Cloud Platform) lub prywatnych (All for One Cloud lub innych dostawców). Decyzja przeniesienia odpowiedzialności na dostawcę wiąże się z ryzykiem, które należy odnotować:

  • Czy w celu zapewniania ciągłości działania będzie możliwość otworzenia systemów IT w skończonym czasie, akceptowalnym dla właściciela biznesowego?
  • Na jaką utratę danych w czasie możemy sobie pozwolić?
  • Jak zareagujemy, kiedy nasze środowisko podstawowe (on-premise, w chmurze publicznej lub prywatnej) nie będzie dostępne?

Dobrą odpowiedzią na wiele powyższych pytań jest utworzenie zapasowego środowiska wraz z powtarzalnymi testami odtworzeniowymi. Możliwe scenariusze dla Disaster and Recovery Center mogą być różne i wynikają z obecnej i planowanej strategii utrzymania systemów oraz uwarunkowań biznesowych.

Własne zasoby

W przypadku posiadania własnych zasobów warto utworzyć replikę danych w chmurze prywatnej lub publicznej. W zależności od możliwości technologicznych oraz potrzeb można rozważyć różne rozwiązania:

  • Dla najbardziej wymagających biznesowo systemów, w których istotny jest czas dostępności środowiska, można podzielić rozwiązanie na dwa etapy:
    • Utworzenie synchronicznej repliki wszystkich zasobów w drugim ośrodku lub chmurze prywatnej lokalnego dostawcy. Uzyskamy ochronę w postaci drugiej identycznej wersji danych;
    • Dodatkowo (dla klientów, gdzie dostęp do danych jest krytyczny) między ośrodkami danych można zachowywać różnicę w czasie synchronizacji danych, aby w zależności od problemu, jaki wystąpił, móc albo przełączyć się bez utraty danych, albo przełączyć się dla wybranych systemów z określoną utratą danych, np. jedna godzina, w czasie której nastąpiło uszkodzenie danych, zostanie wycofana.
  • Dla mniej wymagających klientów, dla których utrata danych na poziomie 15 minut nie stanowy ryzyka dla ciągłości działania, można zaproponować rozwiązania niesynchroniczne, czyli takie, w których dane replikowane są poprzez logi transakcyjne lub replikację na poziomie wirtualizacji.
  • Dla klientów, którzy mogą pozwolić sobie na większe postoje, można replikować tylko kopie zapasowe danych utworzonych w podstawowym środowisku, tworząc procedurę odtworzenia wraz z kolejnością, kiedy i jakie systemy należy odtworzyć. Wówczas czas dostępności usług możemy mierzyć w godzinach lub dniach.

Chmura prywatna

Dla systemów utrzymywanych w chmurze prywatnej możemy utworzyć replikę w drugiej chmurze prywatnej, publicznej lub utrzymywać we własnym rozwiązaniu on-premise środowisko do zapewnienia ciągłości działania. W zalewności od możliwości dostawcy można przygotować warianty podobne do opisanych powyżej (dla rozwiązań on-premise):

  • synchronicznej replikacji;
  • niesynchronicznej replikacji (w tym replikacji danych do chmury publicznej);
  • replikacji kopi zapasowej.

Chmura publiczna

Dla zasobów utrzymywanych w chmurze publicznej (Azure, AWS, GPC) możliwe są różne scenariusze zapasowego centrum przetwarzania danych, w zależności od dostępności usług w różnych regionach:

  • Replikacja całych maszyn wirtualnych do innego regionu;
  • Replikacja kopii zapasowych do innego regionu.

We wszystkich powyższych modelach utrzymania systemów wybór strategii dla zapasowego centrum danych będzie pochodną wymagań biznesowych, akceptowalnych czasów niedostępności systemów oraz oczywiście wysokości inwestycji, na jaką gotowa jest firma.

Testy odtworzeniowe

Zapasowe centrum przetwarzania danych to ważny element budowania bezpiecznego środowiska IT. Jego integralnym uzupełnieniem są plany ciągłości działania. Ich utworzenie i cykliczne testowanie (co najmniej raz do roku) jest niezbędne, by utrzymać wysoką gotowość zapasowego centrum do przejęcia produktywnego działania w zdefiniowanych parametrach na wypadek niedostępności podstawowych systemów. Istotne jest to, aby w testy zaangażować nie tylko dział IT, ale także właścicieli biznesowych systemów – czyli osoby dopowiedziane za poszczególne jednostki organizacyjne, które wykorzystują środowiska IT.

Disaster & Recovery Center jest stałym kosztem dla organizacji, jak jednak wycenić straty spowodowane wielodniową przerwą w pracy całości biznesu?

Posiadanie testowanych i odtwarzanych kopii zapasowych daje pewność, że możemy odtworzyć dane, z ewentualną akceptowalną stratą. Do rozstrzygnięcia pozostają dwie ważne kwestie:

  • Gdzie odtworzymy dane (skoro nasza serwerownia właśnie spłonęła lub w wyniku cyberataku macierz została bezpowrotnie zaszyfrowana)?
  • W jakim czasie po odtworzeniu danych będziemy mogli zacząć pracować w innej lokalizacji (np. czy łącza z naszymi kooperantami będą działać, jak rozwiążemy inne problemy wynikłe podczas testów DR)?

Testowanie planów ciągłości działania i planów odtwarzania utraconych zasobów to integralny element systemu bezpieczeństwa IT w firmie. Tylko podczas „próbnego alarmu” jesteśmy w stanie zweryfikować, czy przygotowane procedury zadziałają, ile rzeczywiście czasu zajmuje każdy opisany krok, czy nie pominęliśmy jakiegoś z pozoru mało istotnego elementu, który może zaważyć na sukcesie lub porażce uruchomienia systemu w zapasowej lokalizacji.

Na podstawie doświadczeń z testów możemy zapoznać się z rzeczywistą skalą problemów, jakie mogą wystąpić, dają czas na spokojnie doszlifowania szczegółów technicznych oraz uzyskanie odpowiedzi ważnych dla biznesu: ile danych rzeczywiście możemy utracić w czasie awarii i jak długo będzie trwało uruchomienie systemów produkcyjnie.