„Potrzebuję gotowości do Disaster Recovery!”

Data: 2014-09-15
Autor: Sebastian Konkol
„Potrzebuję gotowości do Disaster Recovery!”

Wiele firm twierdzi, że ich IT – zarówno technologia, jak i organizacja – są gotowe do stawienia czoła sytuacjom kryzysowym. W niektórych branżach wymaganie takiej gotowości jest wręcz prawnie usankcjonowana. Chciałbym, aby każda organizacja miała plan Disaster Recovery i nigdy z niego nie skorzystała. Tym niemniej, posiadanie takich procedur i odkrycie, że są one błędne w trakcie ich wykonywania w prawdziwie krytycznej sytuacji jest chyba najcięższym doświadczaniem, jakie może spotkać menedżera IT w jego życiu zawodowym.

Nie jestem ekspertem od tworzenia takich procedur, ale widziałem wiele takich dokumentów, opisujących kroki do odbudowania pełnego środowiska informatycznego firmy – począwszy od infrastruktury fizycznej, a skończywszy na gotowości systemów i zakresu wsparcia biznesowego – warstwa po warstwie. Uważam takie podejście za fundamentalnie błędne. Disaster Recovery nie polega na odbudowaniu całości środowiska informatycznego z prędkością światła – polega na uzasadnionej ekonomicznie zdolności odtworzenia krytycznej działalności biznesowej w trybie quick-and-dirty, bez poddawania bezpieczeństwa biznesu kompromisom.

Jeszcze dekadę temu w zasadzie jedyną opcją dla zapewnienia zdolności Disaster Recovery było posiadanie drugiego, geograficznie oddzielonego centrum przetwarzania danych, gromadzącą infrastrukturę (sprzęt, platformę operacyjną i aplikacyjną) i aplikacje (synchronizowane konfiguracje i replikowane dane), pozwalające na odtworzenie działania środowiska informatycznego w sytuacji klęski. Rozwiązanie relatywnie łatwe w utworzeniu (kopia wszystkiego), ale posiadające jedną wadę – wysokie koszty. Dzisiaj są inne opcje warte rozważenia, przy czym przez „warte rozważenia” rozumiem rzetelną odpowiedź na pytanie: „Co by było, gdyby była to jedyna opcja dostępna?”:

  • tradycyjny hosting i wynajmowanie infrastruktury – zamiast kupować infrastrukturę, firma mogłaby ją wynajmować formułując kontrakt tak, aby płacić wyłącznie za jej użytkowanie i gotowość do przełączenia;
  • Cloud Computing – zasoby (moc obliczeniowa, przestrzeń danych) mogą być wynajęte od wiarygodnych dostawców (np. Amazon, dostawcy sprzętu organizujący chmury prywatne), płacąc wyłącznie za użytkowanie zasobów;
  • współdzielenie cech i zdolności architektury (capabilities) z partnerami – odtworzenie po awarii może być w pewnych sytuacjach łatwiejsze dla partnerów biznesowych, niż dla firmy, co na określony przejściowy czas może być wystarczające dla utrzymania biznesu przy życiu (największą inspiracją są powszechnie znane doświadczenia odtwarzania produkcji Toyoty).

Te opcje są często pomijane z powodu jednego słowa kluczowego – bezpieczeństwo – potencjalnego „wycieku” wrażliwych danych biznesowych, danych klientów itd. To także jest błędny pogląd. Bez wątpienia, możliwość skorzystania z takich opcji wymaga większych przygotowań, ale potencjał oszczędności w pełni uzasadnia rzetelne ich rozważenie, zamiast odrzucać je bez uzasadnienia.

Na czym miałaby polegać taka analiza? Przede wszystkim, jej założeniem powinno być ustalenie, co musi, co może, a co nie powinno być odtwarzane w przypadku sytuacji klęski. Zdolność odtworzenia powinna być bowiem nie tyle możliwa do zrealizowania, co wbudowana w architekturę każdego z systemów, których odtworzenie – w całości lub części – jest krytyczne. Kroki analizy, jakie przeprowadzałem, przedstawiały się następująco:

  • Dekompozycja. Całość architektury środowiska informatycznego firmy opisywana jest w postaci capabilities, którym nadawane są unikalne priorytety określające sekwencję odtwarzania.
  • Definicja. Każde capability musi być określona w terminologii wszystkich „warstw” architektury (aplikacji, danych i technicznej), a w konsekwencji systemów i ich modułów, które są niezbędne dla zapewnienia danej capability.
  • Poziom. Choć w warunkach poprawnej pracy dane capability jest wymagane na określonym poziomie (np. wiemy, że przetwarzamy 10 000 transakcji na godzinę), w warunkach odtwarzania po klęsce wcale nie musi być tak samo (np. ograniczamy do 1000).
  • Zasoby. Każdy element zasobów wymaganych dla zapewnienia danej capability powinien być opisany w kategoriach standardów i interfejsów, aby uczynić je niezależnymi od bieżącej implementacji i gotowymi do uruchomienia na innej infrastrukturze, zgodnej ze standardami i definicjami interfejsów (dane, protokół komunikacyjny).

Najtrudniejszym krokiem jest zwykle priorytetyzacja – nie spotkałem się z organizacją, która byłaby w stanie dojść w tej sprawie do porozumienia. W takich okolicznościach stosuję podejście oparte o wartość biznesową danej capability (generowanie przychodu, oszczędność kosztów, minimalizacja ryzyka), nadając najwyższe priorytety dla capabilities o najwyższej wartości. Dyskusji podlegają wtedy jedynie dwa aspekty: najbardziej kontrowersyjne przypisania oraz konsekwencje zależności technicznych.

Prawdziwym wyzwaniem jest zapewnienie bezpieczeństwa odtworzenia po klęsce. Prawdziwym powodem istnienia takiego wyzwania nie jest jednak potencjał „wycieku” – jest nim brak uwzględnienia architektonicznej perspektywy zdolności do odtworzenia po awarii w czasie konstruowania i realizacji poszczególnych systemów. Jeśli coś nie zostało zaprojektowane, aby było bezpieczne, trudno oczekiwać, aby takim się stało w sytuacji klęski.

Pewnym zagadnieniem jest dyskusja o zapotrzebowaniu na zasoby – nie w kategoriach „ile wykorzystujemy”, lecz w kategoriach „ile musimy mieć, aby zapewnić dane capability”. Wymaga to zwykle bardziej wyrafinowanych metod pomiaru obciążenia generowanego przez poszczególne elementy środowiska informatycznego i umiejętności wyrażania ich w kategoriach biznesowych (np. „musimy odtworzyć zdolność przetworzenia 1000 transakcji” zamiast „musimy mieć 12 rdzeni procesora”).

Dobra wiadomość jest następująca: przy odpowiedniej dawce dobrej woli, wszystkie te zagadnienia daje się opracować i przeliczyć. W wyniku uzyskiwane są rzetelne i wiarygodne dane decyzyjne, ale przede wszystkim uzyskiwane jest zrozumienie krytyczności architektury – nie jako całości, ale dobrze określonych jej składowych. Architektura korporacyjna (EA, Enterprise Architecture) jest najlepszą filozofią, jaka pozwala łączyć w jeden spójny sposób różnorodne perspektywy, od całego lasu (capabilities), przez gałęzie (punkty widzenia), aż po liście (systemy, ich moduły i interfejsy). Spójność, darowana przez filozofię EA, zapewnia także, że – mimo złożoności i wielości perspektyw – żadna istotna informacja nie zostanie pominięta, a jej konsekwencje – niedostrzeżone.

Pozostaw komentarz