DR – referatów cykl dalszy.

Jako że cykl referatu dotyczącego spraw związanych z Wysoką-Dostępnością się już zakończył to nadszedł czas na wpięcie się na wyższy poziom wtajemniczenia, czyli Disaster Recovery. Zapraszam.

Wstęp, czyli o czym tym razem będziemy dywagować …

Disaster Recovery to zbiór procedur oraz strategii związanych z reagowaniem firmy na nieoczekiwane zdarzenia – katastrofy, mające ogromny wpływ na funkcjonowanie tej firmy. Zastanowimy się jakie są możliwości zabezpieczenia się przed skutkami takich katastrof.

Wyższy poziom wtajemniczenia, czyli Disaster Recovery …

W poprzednim odcinku sagi rozważaliśmy metody zabezpieczenia naszego środowiska informatycznego przed niespodziankami w postaci awarii poszczególnych elementów naszej infrastruktury. Zabezpieczeniami obejmowaliśmy pamięć masową, serwery, czy wręcz ich zasilanie. Wszystkie te działania miały jeden cel – aby zaistniałe awarie w minimalnym jak to możliwe stopniu wpłynęły na dostępność naszych usług czy aplikacji, które to w sposób pośredni lub bezpośredni przyczyniają się do ilości pieniędzy jakie zarabia lub traci nasza firma. Wszystkie te zabezpieczenia sprawdzają się rewelacyjnie w przypadku standardowych i możliwych do przewidzenia problemów obejmujących pojedyncze elementy naszej infrastruktury. Awarie pojedynczych dysków, serwerów czy kart PCI od tej pory staną się chlebem powszednim naszych administratorów, ale nie naszego biznesu. Taka sielanka może, ale nie musi trwać zbyt długo, przerwać ją może zdarzenie zwane katastrofą – Disaster.

BCP, czyli co zrobić aby firma przetrwała …

Katastrofa, czyli zdarzenie niespodziewane o ogromnym, negatywnym wpływie na działalność firmy może się przytrafić każdemu. Z definicji katastrofie nie możemy zapobiec, co nie oznacza, że nie powinniśmy minimalizować prawdopodobieństwa wystąpienia niektórych rodzajów katastrof poprzez odpowiedni dobór lokalizacji, projektu, materiałów czy zabezpieczeń naszego centrum przetwarzania danych. Oczywiście nie każda katastrofa będzie tak samo problematyczna dla firmy więc powinniśmy zajmować się wyłącznie tymi, których wystąpienie może potencjalnie doprowadzić do upadku firmy i zamknięcia biznesu z powodu wygenerowania strat, których firma nie będzie mogła zaakceptować (a może raczej jej właściciele czy wierzyciele). Dlatego też na początku zajmiemy się BCP (ang. Business Continuity Plan), czyli Plan Zapewniania/Kontynuacji Biznesu. Czym jest BCP? To strategia przetrwania firmy w wypadku dotknięcia jej dowolnym rodzajem katastrofy zagrażającej dalszemu funkcjonowaniu firmy. Na strategię tą składa się zbiór planów, procedur, w tym schematów komunikacji i podejmowania decyzji, dotyczących różnych obszarów działalności firmy, podziałów funkcjonalnych czy geograficznych. BCP zawiera także dogłębną analizę kluczowych usług firmy, które muszą być przez firmę utrzymywane lub świadczone bez względu na okoliczności (np. wymogi prawne). Brak utrzymywania lub świadczenia tych usług oznacza w krótkim czasie upadek firmy. Dotychczasowa metodologia i praktyka podpowiadała, aby przygotowywać oddzielne BCP na wypadek zaistnienia różnych rodzajów, różnych w skutkach czy zasięgu katastrof. Tak więc powstawały bardzo szczegółowe plany na wypadek: powodzi, trzęsienia ziemi, pożaru, tornado, katastrofy budowlanej, zamieszek itp., itd. Oczywiście większość z nich była mocno do siebie podobna, w końcu co za różnica czy budynek się zawali czy spłonie. Na szczęście ostatnio odchodzi się od nic nie wnoszącej różnorodności i drobiazgowości takich planów BCP na rzecz jednego ogólnego planu obejmującego scenariusz katastrofy nieprzewidywalnej o dowolnie małym prawdopodobieństwie zaistnienia. Dzięki takiemu podejściu upraszcza się bardzo wiele rzeczy, a wszelkie wysiłki skupiają się na zabezpieczeniu usług krytycznych a nie przeciwdziałaniu poszczególnym rodzajom katastrof.
Tak więc pierwszym etapem tworzenia BCP jest określenie usług krytycznych dla funkcjonowania firmy – na tym etapie specjaliści z działów IT praktycznie nie mają nic do roboty (chyba że firma to prawie 100% IT). Wtedy także okazuje się, że dotychczasowe pojmowanie przez działy IT krytyczności usług w firmie zazwyczaj różni się od tego co faktycznie jest krytyczne. Dla każdej z usług krytycznych strona biznesowa zmuszona jest określić dwa najważniejsze (także dla IT) parametry funkcjonalne: RTO (ang. Recovery Time Objective) oraz RPO (ang. Recovery Point Objective). Parametr RTO określa maksymalny akceptowalny czas od wystąpienia katastrofy po którym usługa musi zostać uruchomiona. W przypadku parametru RPO określamy możliwe do zaakceptowania straty danych spowodowane katastrofą. Tak więc już na wstępie mamy trzy źródła strat spowodowanych przez katastrofę: zniszczenia mienia, zniszczenia danych oraz przerwa w świadczeniu usług. Jeśli mamy już listę usług krytycznych wraz z ich parametrami, to w następnym kroku powinniśmy zastanowić się jakie są możliwe sposoby realizacji usługi krytycznej? Zapasowy sprzęt?, a może tylko zmiana procedur czy przejście na obsługę ręczną? W końcu nie wszystkie plany muszą od razu zakładać ponowne zbudowanie działu IT.

DR, czyli jak to się robi w informatyce …

Jeśli jednak w naszej firmie istnieją usługi krytyczne które muszą być realizowane przez dział IT, to nie pozostaje nam nic innego jak dokładniej przeanalizować informacje jakie zostały zebrane w BCP i na ich podstawie dostosować wymagania projektu DR. Ale czym się właściwie różni BCP od DR? DR jest zwyczajnie elementem BCP obejmującym procedury i mechanizmy związane z realizacją BCP i bezpośrednio z niego wynikające. DR to realizacja strategii BCP, to materiał roboczy w trakcie katastrofy. Aby dokładniej zrozumieć co powinno składać się na poprawnie zaprojektowane środowisko DR przeanalizujmy poszczególne etapy przykładowej katastrofy. DR rozpoczyna się od decyzji Sztabu Kryzysowego o uruchomieniu poszczególnych procedur. Następnie w czasie RTO poszczególne usługi krytyczne zostają uruchomione w lokalizacji zapasowej (o której będzie za chwilę) – jest to pierwszy etap realizacji procedur DR. W momencie zakończenia uruchamiania ostatniej usługi krytycznej środowisko IT przechodzi w awaryjny tryb pracy w lokalizacji zapasowej – jest to drugi etap DR. Taki stan utrzymywany jest do czasu odtworzenia głównego centrum przetwarzania danych (wybudowanie, czy zakup sprzętu), po którym następuje przełączenie usług do lokalizacji podstawowej – trzeci i równie ważny etap DR. Na zakończenie lokalizacja zapasowa jest ponownie przygotowywana do stanu wyjściowego i gotowości na przejęcie pracy – czwarty i ostatni etap. Tak więc procedury DR nie kończą się na samym przełączeniu usług. Procedury te muszą zapewnić także możliwość normalnej pracy operacyjnej w lokalizacji zapasowej czy, co jest równie ważne, powrót z przetwarzaniem do lokalizacji głównej. W procedurach DR musimy pamiętać także o schemacie komunikacji, decyzyjności (w szczególności w punktach związanych z wyzwalaczami działań) czy wymaganych zasobach krytycznych.

C.D.N.