Business Continuity i Disaster Recovery. To nie jest to samo!
Ochrona danych, szczególnie tych krytycznych dla działania i funkcjonowania naszego biznesu jest tematem tak powszechnym i oczywistym, że długo się zastanawiałem nad tym czy warto poświęcać temu zagadnieniu czas i energię. Fakt, że zdecydowałeś się sięgnąć po ten artykuł oznacza jednak, że moje obawy nie były słuszne. I już teraz dziękuję Ci za to!
W końcu, gdyby temat ten był tak oczywisty i tak prosty do zaadresowania, to czy nadal słyszelibyśmy w środowisku IT (a czasami również w mediach) o problemach z dostępnością do danych, albo brakiem dostępności usług i całych aplikacji.
Właściwe zabezpieczenie danych i zapewnienie ciągłości biznesowej ważne jest niezależnie od tego, czy używasz swoich własnych centrów przetwarzania danych, czy uruchamiasz aplikacje i przechowujesz dane w chmurze publicznej. Dlatego postanowiłem zebrać trochę swojej wiedzy na ten temat, przyprawić ją kilkoma rysunkami i zapisać poniżej w postaci skondensowanego i zwięzłego materiału. A Ty oceń sam, czy mi się to udało.
„No bo przecież katastrofy i ataki cybernetyczne przytrafiają się wszystkim dookoła, ale nie mnie.” Nawet jeżeli rzeczywiście tak było do tej pory, to mimo wszystko warto być przygotowanym. Tym bardziej, że dzisiaj od tego zależeć może dalsze funkcjonowanie i istnienie Twojego biznesu.
Co w takim razie, w tym konkretnym przypadku, oznacza „bycie przygotowanym”?
Wyobraź sobie, że ogień w Twojej firmie niszczy połowę budynku, w tym zarówno Twoje biura, jak i Twój sprzęt IT. Bycie przygotowanym na tak paskudny scenariusz oznacza, że posiadasz drugą alternatywną lokalizację, która może być wykorzystana jako tymczasowe biuro. Dodatkowo musisz wiedzieć jaki sprzęt jest najbardziej potrzebny do poprawnego funkcjonowania Twojego biznesu oraz musisz być w stanie go „zorganizować” w jak najkrótszym terminie. Powinieneś wyszkolić pracowników na wypadek zaistnienia takiej sytuacji. W przypadku, gdy Twoje serwery i macierze dyskowe przestają działać (bo zostały spalone), nie działają również Twoje aplikacje, które są odpowiedzialne za prowadzenie księgowości, realizowanie zamówień, dostawy Twoich produktów, czy np. działanie produkcji. Jeżeli nie możesz realizować zamówień Twoich klientów, to jesteś bezpośrednio narażony na straty finansowe. A co gorsza, na pewno ucierpi na tym reputacja Twojej firmy. I całe zdarzenie może mieć również negatywny wpływ nie tylko na realizację bieżących zamówień, ale również obniżenie przyszłego strumienia przychodów.
No ładnie się zaczyna. Ale spokojnie. Z pomocą przychodzi cała dziedzina zarządzania ciągłością biznesową (Business Continuity, BC).
Właściwe zarządzanie ciągłością biznesową pomoże Ci zidentyfikować wszystkie krytyczne procesy oraz zdefiniować reguły i procedury postępowania, które mają zapobiec potencjalnym przerwom w działaniu biznesu. Zarządzanie to pozwala również obniżyć ryzyko wystąpienia takich sytuacji, jak np. ta opisana powyżej oraz zredukować negatywne skutki, które mogą być następstwem tego typu katastrof i ataków. Implementacja procedur i zasad zarządzania ciągłością biznesową jest często wymagana przez różne regulacje oraz standardy i jest uregulowana w kodeksach branżowych oraz kontrolowana przez instytucje nadzorujące. Niezależnie jednak od regulacji i kodeksów, w czasach, kiedy dane są jednym z najbardziej wartościowych assetów w przedsiębiorstwie, trudno sobie wyobrazić, abyśmy nie chcieli się zabezpieczać na wypadek ich utraty lub braku dostępności.
Spróbujemy w takim razie wykorzystać tę dziedzinę i stworzyć wspólnie plan ciągłości biznesowej dla naszego Hipotetycznego Przedsiębiorstwa (zbieżność skrótu – przypadkowa). To znaczy, ja będę podawał swoje propozycje poniżej, a Ty wpisz swoje w komentarzach pod artykułem.
Planowanie ciągłości biznesowej…
nie może być realizowane w oderwaniu od organizacji, dla której plan ten powstaje. Będzie on bowiem wyglądał inaczej dla giełdy papierów wartościowych, a inaczej dla przedsiębiorstwa, które zarządza siecią supermarketów spożywczych. Dlaczego? Ponieważ, większość procesów biznesowych w obydwu tych przypadkach jest zupełnie inna.
Aby jednak przygotować plan funkcjonalny ciągłości biznesowej, obydwie te organizacje muszą poddać się określonym procedurom, głównie w oparciu o analizę ich wewnętrznego i zewnętrznego otoczenia. Rezultatem tej analizy jest z kolei kilka podstawowych dokumentów, z których wszystkie są częścią planu ciągłości biznesowej.
A są to:
- Analiza Wpływu na Biznes,
- Diagnoza Ryzyka,
- Definicja Polityk i Ról,
- Opis Zasobów Zapasowych,
- Plan Odtworzenia Działania Biznesu,
- Plan Odtworzenia Infrastruktury IT (Disaster Recovery),
- Plan Szkoleń oraz Testów i Harmonogram Utrzymania.
Nie zamierzam szczegółowo opisywać każdego z tych dokumentów, natomiast warto moim zdaniem na chwilę zatrzymać się przy każdym z nich. I za chwilę tak właśnie zrobimy. Najpierw jednak musimy zbudować nasz zespół BC (Business Continuity). W jego skład wejdą właściciele określonych (krytycznych) procesów biznesowych oraz kadra kierownicza wyższego szczebla. Nowo powstały zespół przetłumaczy wymagania biznesowe naszego przedsiębiorstwa na kompletny plan ciągłości biznesowej. Znajdą się w nim informacje o technologii, ludziach oraz procesach, których celem będzie przywrócenie działania naszego biznesu. Członkowie zespołu BC będą musieli przedyskutować między innymi podstawowe wymagania związane z odzyskiwaniem danych oraz zdecydować:
- o wartości parametru RTO (Recovery Time Objective) – czasu potrzebnego na przywrócenie poprawnego działania,
- o wartości parametru RPO (Recovery Point Obcjetive) - punktu w czasie w przeszłości, poniżej którego nie akceptujemy utraty danych i braku możliwości ich odzyskania.
Na podstawie tych wymagań będziemy mogli później określić i wybrać właściwe techniki i metody zabezpieczania danych.
Analiza Wpływu na Biznes.
Jest diagnozą krytycznych procesów biznesowych w danej organizacji. Jest to ta część planowania, w której zidentyfikujemy procesy biznesowe, użytkowników i aplikacje, które są niezbędne do przetrwania naszego biznesu. Analiza pomoże nam również ocenić koszt niedostępności usług. A na tej podstawie będziemy mogli zdecydować o wyborze rodzaju rozwiązania oraz określić strategię ciągłości biznesowej (BC).
Procesy biznesowe podzielimy sobie na grupy:
- operacyjne (produkcja, sprzedaż, wsparcie klienta, dystrybucja, fakturowanie),
- wsparcia (IT, kadry),
- strategiczne (zarządzenie, planowanie).
Jeżeli priorytet danego procesu zmienia się wraz z upływem czasu (np. księgowość na koniec roku finansowego), wtedy będziemy go analizować z uwzględnieniem tego „gorącego” okresu. Uwzględnimy tutaj również wszelkie wzajemne zależności i relacje pomiędzy procesami. Efektem naszej analizy wpływu na biznes będzie określenie wartości dla parametrów:
- Recovery Time Objective (RTO),
- Recovery Point Objective (RPO),
- Maximum Tolerable Period of Disruption (MTPD) - maksymalny tolerowany czas niedostępności.
Wartości te zdefiniujemy sobie dla każdego procesu. O RPO i RTO już pisałem wcześniej i w moim przekonaniu są to parametry dość oczywiste. Zerknijmy w takim razie jeszcze na chwilę na MTPD. Wpływ na jego wartość będą bowiem miały również osoby, które zajmują się zarządzaniem ryzykiem. MTPD pokazuje jak długi czas niedostępności procesu biznesowego możemy zaakceptować. Po upływie tego czasu wydolność procesu albo rentowność całej organizacji zostanie zagrożona. Inaczej mówiąc, wtedy, gdy czas oznaczony wartością parametru MTPD zostanie przekroczony, jest praktycznie niemożliwe odzyskanie procesu, ponieważ szkody wyrządzone przez niedostępność są zbyt poważne.
MTPD jest określane w oparciu o wielkość straty finansowej poniesionej w wyniku przerwy w działaniu biznesu oraz takiego poziomu akceptacji ryzyka, który oznacza stratę finansową możliwą do „udźwignięcia” przez przedsiębiorstwo.
Aby zapobiec osiągnięciu granicy MTPD przedsiębiorstwo musi wdrożyć „jakieś” środki zapobiegawcze. Najlepszą opcją byłoby poczynienie takich zabezpieczeń, przy których ryzyko finansowe jest praktycznie pomijalne. Niestety, wysoka dostępność oraz odporność na awarie kosztuje. Dlatego tak ważne jest określenie poziomu akceptacji ryzyka. Do tej granicy strata finansowa może być znaczna, ale nie zagraża funkcjonowaniu biznesu. A akceptowalna możliwa strata finansowa jest nadal znacznie niższa niż koszt implementacji środków zapobiegawczych.
Jak pokazuje powyższy rysunek, RPO ma (przeważnie) niższą wartość niż RTO. Podobnie RTO jest zawsze mniejsze niż MTPD. A wznowienie przerwanego procesu biznesowego jest realizowane w kolejnych krokach odzyskiwania zdolności operacyjnej. Na początku odbudowujemy infrastrukturę (zasilanie, serwery, macierze, infrastruktura sieciowa). Następnie odzyskujemy dane oraz aplikacje. Restartujemy usługi i procesy. Aż do odzyskania pełnej operacyjności.
Dzisiejsza technologia pozwala na zagwarantowanie parametrów RPO na poziomie zero oraz RTO mierzonego w sekundach lub minutach (a w niektórych przypadkach również na poziomie zera). Jest to osiągane przez zduplikowanie infrastruktury, zainstalowanej w zapasowym ośrodku danych, który jest gotowy, aby przejąć pracę podstawowej lokalizacji w przypadku wystąpienia awarii. Rozwiązania takie budowane są w oparciu o klastry geograficznie rozproszone. Ponieważ rozwiązania te nie należą do najtańszych, dlatego w przypadku mniej krytycznych procesów wartości RPO i RTO oscylują w minutach i godzinach. Najtańsze rozwiązania budowane są w oparciu o mechanizmy kopii zapasowych, a wartości RPO i RTO wyrażane są dla nich w godzinach i dniach.
Diagnoza Ryzyka.
Wybierzemy tutaj właściwe środki do zaprojektowania środowiska, które ma być odporne na awarie. Dalej określimy prawdopodobieństwo wystąpienia zagrożeń, które mogą prowadzić do przerwy w dostępie do usług oraz zdefiniujemy skutek tych zagrożeń.
Różnica pomiędzy Analizą Wpływu na Biznes, a Diagnozą Ryzyka jest taka, że ta pierwsza określa jaki wpływ na operacyjność organizacji będzie miało przerwanie procesów biznesowych, podczas gdy ta druga mierzy prawdopodobieństwo wystąpienia zagrożeń i ich wpływ na procesy biznesowe. Zagrożenia, które weźmiemy pod uwagę w naszej diagnozie, to przede wszystkim: błędy ludzkie, katastrofy naturalne, błędy technologiczne, sytuacja ekonomiczna oraz brak stabilności politycznej.
Definicja Polityk i Ról.
Posłużymy się tutaj wynikami Diagnozy Ryzyka i zdefiniujemy role oraz odpowiedzialności członków naszego zespołu BC.
Opis Zasobów Zapasowych.
Jak wskazuje nazwa – opiszemy zasoby zapasowe naszego przedsiębiorstwa. Mogą to być zasoby, które są w posiadaniu firmy i które są rozmieszczone w dodatkowej lub wielu dodatkowych lokalizacjach. Mogą to być również zasoby zewnętrzne dostarczane przez poddostawców lub kontraktorów (np. zasoby w chmurze publicznej).
Plan Odtworzenia Dziania Biznesu.
Stworzymy skrypt (plan) przedstawiający krok po kroku, jakie procedury muszą zostać podjęte, w przypadku wystąpienia określonej sytuacji. Skupimy się na procesach biznesowych i opiszemy rozwiązania, które należy podjąć w sytuacjach, gdy np. biuro nie jest dostępne dla pracowników, pracownicy nie mogą dostać się do pracy, lub innych, podobnych.
Plan Odtworzenia Infrastruktury IT (Disaster Revovery).
Opiszemy czynności jakie należy podjąć, aby krytyczne aplikacje zadziałały ponownie po wystąpieniu incydentu.
Czym różni się Disaster Recovery od Business Continuity?
Plan ciągłości biznesowej (Business Continuity) skupia się na wszystkich tych procesach biznesowych, które są istotne dla danej organizacji. Zawiera opis akcji, które należy podjąć w przypadku wystąpienia konkretnego zagrożenia dla ciągłości działania biznesu. Wyobraź sobie, że nasze Hipotetyczne Przedsiębiorstwo jest lotniskiem. Mamy zimę i temperatury powietrza spadły mocno poniżej zera. A nasz dostawca nie dostarczył płynu, który jest wykorzystywany do odmrażania samolotu. Jak widzisz sytuacja ta ma niewiele wspólnego z IT, a jednak zagraża utrzymaniu ciągłości biznesowej.
Planowanie ciągłości biznesowej jest procesem bardzo szerokim i należy w nim zbadać wszystkie aspekty związane z działaniem operacyjnym organizacji.
Plan odtworzenia infrastruktury IT (Disaster Recovery) nie jest tym samym co plan ciągłości biznesowej (Business Continuity). Terminy te są niestety często błędnie mylone. A nie należy ich używać zamiennie. Disaster Recovery jest częścią Business Continuity i skupia się tylko na infrastrukturze IT oraz procesach, których działanie zależy od tej infrastruktury. W planie ciągłości biznesowej oprócz planu odtworzenia infrastruktury IT znajdują się również zagrożenia związane z brakiem dostępności poddostawców (i dostarczanych przez nich usług i towarów) oraz brakiem dostępności pracowników.
Pamiętaj: Business Continuity ma szersze znaczenie niż Disaster Recovery i zawsze stoi ponad nim.
Wróćmy jeszcze na chwilę do naszego planu odtworzenia infrastruktury IT, aby opisać w nim:
- podstawowe informacje: cel, zakres aplikacji, wymagania, modyfikacje planu, informacje na temat członków zespołu DR oraz ich role i odpowiedzialności,
- fazę aktywacji i powiadomienia: procedury powiadomienia, drzewo wywołań (call tree), oszacowanie zniszczeń, kryteria aktywacji, plan aktywacji,
- procedury odzyskiwania: kolejność procedur odzyskiwania (zgodnie z ich poziomem ważności), logowanie zdarzeń, eskalacje,
- informacje o podjęciu standardowej pracy operacyjnej: weryfikacja sprawności systemów, zakończenie planu DR,
- korekty: książka zgłoszeń, SLA producenta, RTO procesów.
Plan szkoleń oraz testowania i harmonogram utrzymania.
Tutaj określimy metodologię oraz kalendarz testów planu ciągłości biznesowej. Zapiszemy również nazwisko osoby odpowiedzialnej za aktualizacje tego planu.
No dobrze. Stworzyliśmy w naszym Hipotetycznym Przedsiębiorstwie zespoły Business Continuity i Disaster Recovery. Napisaliśmy wszystkie potrzebne plany. Czas przyjrzeć się rozwiązaniom, które pomagają w odtwarzaniu infrastruktury IT.
Backup i replikacja.
Są to dwa ważne słowa, używane w planowaniu Disaster Recovery.
Backup.
Tworzysz kopię bezpieczeństwa (backup), czyli duplikat danych w formie plików lub surowych bloków. Gdy chcesz mieć dostęp do tych danych, musisz je odtworzyć (restore). A to niestety trwa. Czas odtwarzania będzie zależał od tego na czym przechowujesz dane (dyski, taśma) oraz jaka jest Twoja strategia backupowa. Odtwarzanie może trwać godziny, a nawet dni.
Do wykonania kopii zapasowej użyjesz wyspecjalizowanego oprogramowania backupowego. To samo oprogramowanie musisz wykorzystać również podczas odtwarzania danych, aby udostępnić je aplikacjom, które ich potrzebują (działającym na Twoich serwerach produkcyjnych).
Replikacja.
Nie wymaga żadnego odtwarzania. Dane, które zostały zreplikowane mogą zostać użyte natychmiast lub prawie natychmiast i są dostępne bezpośrednio przez Twoje aplikacje produkcyjne. Nie musisz używać dodatkowego oprogramowania do odtwarzania danych (tak jak to ma miejsce w przypadku backupu).
Po co zatem używać backupu, skoro replikacja wydaje się być o wiele lepsza?
Z ekonomicznego punktu widzenia.
Ponieważ jest tańszy. W przypadku backupu dane mogą być zabezpieczane na tańszej przestrzeni dyskowej lub na taśmach. Replikacja zazwyczaj jest realizowana pomiędzy dwoma takimi samymi (równorzędnymi) macierzami dyskowymi.
Z technicznego punktu widzenia.
W przypadku backupu, w sytuacji wystąpienia błędu logicznego, możesz odzyskać taką paczkę danych, których kopia została wykonana jeszcze przed wystąpieniem tego błędu (RPO > niż czas wystąpienia błędu).
Zarówno backup jak i replikacja odgrywają ważną rolę w procesach zabezpieczania danych. Wykorzystanie jednej lub drugiej techniki będzie zależało od cyklu życia danych oraz krytyczności procesów biznesowych, które używają określonych zbiorów danych. Istnieje bardzo wiele różnych rozwiązań, które pozwalają na osiągnięcie wysokiej dostępności danych oraz zapewnienie ciągłości biznesowej i właściwego odtwarzania infrastruktury IT. Ich efektywność i zapewnienie lepszych (krótszych) wartości RPO i RTO idą zazwyczaj w parze z wyższymi kosztami rozwiązania.
Techniki backupu zapewniają dużą skalowalność, ale w ich przypadku musisz wziąć pod uwagę czas odtwarzania danych. Krytyczne aplikacje powinny być dostępne przez 24 godziny na dobę, 7 dni w tygodniu. Dlatego dla celów Disaster Recovery będziesz w ich przypadku wykorzystywał zdalną replikację. Backup charakteryzuje się zbyt długimi czasami RPO i RTO i dla tych najważniejszych aplikacji będzie niewystarczającym rozwiązaniem. Co oczywiście nie oznacza, że nie będziesz z niego w ogóle korzystał. Kopia bezpieczeństwa (backup) zabezpieczy bowiem Twoje aplikacje przed takim błędem logicznym, który łatwo może być skopiowany do ośrodka zapasowego mechanizmami replikacyjnymi.
A to oznacza, że backup i replikacja niekoniecznie muszą się wzajemnie wykluczać. Są one często wykorzystywane równolegle, do zabezpieczania tych samych danych na wypadek wystąpienia różnych scenariuszy awarii. Zdalna replikacja do drugiego ośrodka z bardzo krótkimi czasami RPO i RTO dla celów DR i szybkiego odtwarzania danych po awarii ośrodka lub urządzenia. Lokalny backup z dłuższymi czasami RPO i RTO dla celów zabezpieczenia aplikacji i danych przed błędem logicznym.
O backupie można byłoby spokojne napisać zupełnie oddzielny artykuł (i to zapewne niejeden). Ja chciałbym jednak na koniec zostawić dla Ciebie jeszcze kilka dodatkowych informacji na temat replikacji.
Kilka dodatkowych informacji na temat replikacji.
Replikacja może być realizowana za pomocą mechanizmów wbudowanych w samej aplikacji lub dostępnych w bazie danych. Replikować możemy również za pomocą dedykowanego oprogramowania, zainstalowanego na serwerach rozmieszczonych np. w różnych lokalizacjach. I w końcu, chyba najpopularniejsza metoda (chociaż to zależy od rodzaju środowiska / aplikacji) – replikacja bezpośrednio pomiędzy macierzami dyskowymi (blokowymi, plikowymi, obiektowymi) za pomocą ich natywnych mechanizmów, wbudowanych w kontrolery macierzy.
Pamiętaj, że osiągnięcie jak najniższych wartości RPO i RTO jest tutaj kluczowe. Jeżeli replikacja macierzowa jest połączona razem z klastrem serwerów, zainstalowanych w rożnych ośrodkach możliwe jest osiągnięcie RPO = 0 (zero) oraz RTO liczonego w sekundach. Replika zawiera dokładnie te same bloki danych co źródło, a to pozwala na natychmiastowe użycie tych danych przez aplikację bez konieczności uruchamiania procedur odzyskiwania danych. Replikację użyjesz również na potrzeby migracji danych lub do testowania aplikacji. Połączysz wtedy ze sobą techniki zdalnej i lokalnej replikacji (klony i snaphoty).
A idąc jeszcze krok dalej, możesz wykorzystać warstwę wirtualizacji, która zostanie rozproszona pomiędzy ośrodkami. Zbudujesz w ten sposób klaster active-active pomiędzy macierzami, zainstalowanymi w różnych lokalizacjach. Wolumeny obydwu macierzy będą miały atrybuty zarówno do odczytu jak i do zapisu. Do wolumenów tych podłączysz klaster serwerów, który również będzie „rozciągnięty” pomiędzy Twoimi ośrodkami (metro-cluster, geo-cluster). Warstwa wirtualizacyjna macierzy „przykryje” obydwa urządzenia, a serwery będą „myślały”, że komunikują się tylko z jedną macierzą. W przypadku ewentualnej awarii np. całego ośrodka, aplikacje i usługi będą obsługiwane w sposób automatyczny i przeźroczysty z drugiej macierzy w ośrodku zapasowym. Bez restartu aplikacji i bez konieczności jej przełączania (failover). I w ten sposób osiągniesz wartości RPO i RTO na poziomie zera.
A idealnie, jeżeli taki klaster macierzowy zbudujesz w oparciu o mechanizmy wewnętrzne macierzy dyskowych. Nie musisz wtedy instalować dodatkowych urządzeń i nie komplikujesz architektury środowiska DR. Dodatkowo być może posiadasz trzeci ośrodek przetwarzania danych i chciałbyś zbudować taką topologię replikacji, aby:
- lokalnie, pomiędzy ośrodkami, które znajdują się w obrębie tej samej metropolii, replikować dane synchronicznie i zbudować klaster active-active pomiędzy macierzami oraz metro klaster pomiędzy serwerami (RPO = 0 i RTO = 0)
- i jednocześnie trzecią kopię danych wysyłać asynchronicznie do trzeciego ośrodka, który znajduje się na drugim końcu kraju, w innym państwie lub na innych kontynencie (RPO > 0 i RTO > 0).
Materiał ten pozwolę sobie podsumować prostym porównaniem parametrów RPO i RTO (ich relatywnych wartości) w zależności od wybranych technik i strategii zabezpieczania danych.
One Response
marko
bardzo fajnie obrazowo opisales procesy BD i DR.