Droga do planu awaryjnego w siedmiu krokach
11 lipca 2008 14:18
Patryk Królikowski
Nieprzewidywalność jest bezsprzecznym elementem życia codziennego. Nie ma znaczenia, czy mamy do czynienia z atakiem terrorystycznym, załamaniem pogody czy awarią źródła zasilania - firma nigdy nie wie, kiedy płynność jej działania może zostać zakłócona. Ale uniknięcie negatywnych konsekwencji takich zdarzeń nie musi mieć nic wspólnego ze szczęściem ani zgadywanką. Przedstawiamy siedem kroków, które mogą być pomocne i posłużyć jako wskazówki w budowaniu dobrego planu BCDR (Business Continuity/Disaster Recovery).
Krok 1 - Pogodzenie się z możliwością nastąpienia katastrofy
Podczas wizyt na kozetce u psychologa przede wszystkim należy przyznać się, że istnieje problem. Analogicznie jest w świecie BCDR - trzeba otwarcie przyznać, że organizacja narażona jest na realne zagrożenia, które mogą poważnie zakłócić jej funkcjonowanie, a nawet spowodować upadek. Bez wykonania tego pierwszego kroku na odpowiednio wysokim szczeblu w organizacji nie ma mowy o przejściu do następnych.
Krok 2 - Sporządzenie listy zagrożeń oraz przypisanie ich do określonych kategorii
Charakter prowadzonej działalności oraz właściwości jej otoczenia (tak fizycznego, jak i społecznego) będą miały olbrzymi wpływ na rodzaj zagrożeń, na które narażona jest organizacja. Po sporządzeniu ich listy należy dalej podzielić je na kategorie według rzeczywistego wpływu na różne systemy. Koszty reakcji na zagrożenie powinny być dostosowane do akceptowalnego przez organizacje czasu przestoju - im mniejsza tolerancja, tym wyższe koszty reakcji. Niektóre systemy muszą wrócić do pełnej sprawności w ciągu kilku minut po awarii, a inne mogą "leżeć" kilka godzin, a nawet dni bez większej szkody dla organizacji.
Krok 3 - Opisanie infrastruktury technologicznej organizacji w zakresie BCDR
Kluczowymi elementami infrastruktury technicznej z punktu widzenia BCDR są:
1) główne centrum danych,
2) centrum zapasowe będące lustrzanym odbiciem centrum głównego
3) wysokowydajne łącza
Idealnym podejściem jest oczywiście pełna redundancja każdego elementu. Jeżeli któryś z elementów w lokalizacji podstawowej zawiedzie, nastąpi automatyczne przełączenie do lokalizacji zapasowej.
Centrum danych byłoby bezużyteczne bez odpowiedniego zasilania. Przerwa w dostawie energii to według raportów analityków jedna z najczęstszych przyczyn przestojów - przestojów, których można uniknąć. A co z łączami? Nie ma znaczenia, jak "gruba rura" łączy poszczególne lokalizacje czy centra danych. Wystarczy odrobina niedbalstwa np. uszkodzenie światłowodu przez monterów - i mam problem. Dlatego też nadmiarowość łączy jest równie istotna, co nadmiarowość samych centrów danych. Oprócz tego, każde z łączy powinno być dostarczane przez innego dostawcę oraz biegnąć różnymi ścieżkami.
Krok 4 - Inwentaryzacja zasobów IT w organizacji
Po naszkicowaniu topologii infrastruktury BCDR, następnym krokiem jest dokonanie inwentaryzacji zasobów informatycznych. Ten krok pozwala organizacji na zrozumienie zasobów i procesów biznesowych, które muszą zostać objęte ochroną. Zadanie to może być zrealizowane przy użyciu różnych dostępnych na rynku rozwiązań typu "inventory management". Dostawcy tych rozwiązań oferują moduły oparte na agentach oraz bezagentowe, które przeczesując infrastrukturę dokumentują wszystko, co napotkają na swojej drodze (pozwalają na przechowywanie nie tylko informacji o samym sprzęcie, ale także np. w przypadku serwerów o zainstalowanym oprogramowaniu). Dane inwentaryzacyjne składowane są w bazach CMDB (Configuration Management Databases).
Krok 5 - Określenie oczekiwań wobec poziomu usług oraz zdefiniowanie polityk działania na wypadek awarii
Bazy CMDB przechowują nie tylko informacje o tzw. assetach (aktywach), ale także o SLA (Service Level Agreement), które określają czas nieprzerwanej pracy (uptime) oraz zasady przywrócenia funkcjonalności tego aktywu. Powróćmy na chwilę do kroku 2. Niezwykle istotne jest działanie ze strony kadry zarządzającej, która powinna świadomie podjąć decyzję o krytyczności usług. Wpływa ona bezpośrednio na związane z BCDR wydatki, które później ten sam zarząd będzie musiał ponieść.
Opierając się na samej znajomości wszystkich aktywów, konfiguracji oraz SLA organizacja może przystąpić do definiowania polityk planu awaryjnego. Także i za tymi politykami musi iść wsparcie ze strony menedżerów. Muszą więc ściśle wiązać płynność działania i bezawaryjność elementów infrastruktury IT z wymogami biznesowymi. Aby ustanowić takie powiązanie organizacja będzie musiała przeprowadzić analizę wpływu poszczególnych komponentów na działalność biznesową i wyłowić krytyczne procesy oraz zależności pomiędzy elementami infrastruktury. Kadra zarządzająca musi zrozumieć konsekwencje awarii, aby wesprzeć (a de facto także sfinansować) polityki określające działanie na wypadek awarii.
Krok 6 - Opracowanie planu awaryjnego BCDR
Plan awaryjny BCDR wypływa bezpośrednio z polityk, o których wspomnieliśmy przed chwilą. Opisuje on role oraz zakres odpowiedzialności poszczególnych działów i osób w utrzymywaniu systemów informatycznych, a także procedury przywracania sprawności systemów IT w sytuacjach kryzysowych. Do kluczowych elementów planu awaryjnego należy również określenie niezbędnych zasobów, szkoleń, częstotliwości przeprowadzania ćwiczeń (pozorowanych awarii), grafika prac utrzymaniowych oraz grafika wykonywania kopii zapasowych.
Do faz planu awaryjnego możemy zaliczyć powiadomienie/uruchomienie procedur w przypadku wystąpienia sytuacji awaryjnej, sformowanie grup szybkiego reagowania i przywrócenie funkcjonalności systemów oraz wznowienie normalnej działalności organizacji (albo podjęcie decyzji o dalszej pracy na systemach zapasowych w przypadku, kiedy systemy główne muszą zostać wymienione lub przebudowane, co wymaga dodatkowego czasu).
Krok 7 - Przetestowanie planu awaryjnego BCDR
Eksperci od "sytuacji awaryjnych" mówią, że jednym z najistotniejszych - jakże często niedocenianym- elementem całego procesu planowania jest to, co powinno nastąpić po przygotowaniu wszystkich polityk oraz procedur: testy. Testy muszą zweryfikować (pozytywnie lub negatywnie) skuteczność planu. Możliwe jest wówczas wprowadzenie odpowiednich poprawek i usprawnień. Wraz z upływem czasu technologie ulegają zmianom, model biznesowy również nie jest z kamienia. Testy należy zatem powtarzać i dostosowywać polityki i plan do panujących warunków.
Dodatkowo warto stworzyć środowisko testowe, które będzie odzwierciedlało warunki jak najbardziej zbliżone do rzeczywistych. W ten sposób awarie pozorowane będą przypominały te, które mogą wydarzyć się w "realu".
Świat bywa zbyt skomplikowany, żeby organizacja mogła ochronić się przed wszystkimi możliwymi zagrożeniami. Ale posiadając odpowiednie technologie, jasne oczekiwania co do jakości i ciągłości usług, praktyczne polityki, kompletny plan awaryjne oraz rygorystyczny reżim prowadzenia testów - jesteśmy w stanie ograniczyć negatywny wpływ niespodziewanych wydarzeń na ciągłość biznesową.
Tekst opracowany na podstawie materiałów IDG.
wydrukuj
wyślij do znajomego