()

Wstęp

Jakiś czas temu budowaliśmy odporność biznesową za pomocą BCP. Teraz będziemy zwiększać tę odporność jeszcze bardziej: zajmiemy się tworzeniem DRP (Disaster Recovery Plan), czyli planem odzyskiwania po awarii stanu poprzedniego. DRP jest bardzo związane z BCP. Po odpaleniu BCP wykonywane są aktywności takie, jak analiza wpływu zdarzenia, krytyczności tego zdarzenia oraz wyznaczanie, co musi zostać przywrócone. Są to kluczowe tematy, które muszą być określone i być punktem wyjścia dla DRP.

Analiza wpływu i krytyczności zdarzenia pozwala ustalić priorytety, dzięki czemu możemy ustalić, co jest najważniejsze do przywrócenia. Określa się, które systemy czy aktywności muszą zostać przywrócone do działania w pierwszej kolejności. To pozwala zespołowi od DRP przygotować architekturę IT w odpowiedni sposób – tak, by jak najpełniej wesprzeć odzyskiwanie aktywów w odpowiedniej kolejności.

Zespół i role w DRP

Podobnie jak w przypadku BCP, tak i przy DRP musimy wybrać odpowiednie osoby na dane stanowiska, by obowiązki dotyczące DRP były prawidłowo wykonane w razie wystąpienia krytycznego zdarzenia. Jeśli czytałeś moje artykuły odnośnie tworzenia BCP, to stanowiska związane z DRP wydadzą Ci się podobne. A to dlatego, ponieważ, tak jak wspomniałem u góry, oba te dokumenty idą „ręka w rękę”.

Poniżej lista zespołów, które powinny obsługiwać DRP:

  1. Grupa zarządcza — grupa, która koordynuje zadania wszystkich pozostałych zespołów
  2. Pierwsi odpowiadający na incydent — są to osoby najczęściej spoza firmy, np. policja, strażacy czy ratownicy
  3. Komunikujący — jest to zespół typu Major Incident Team, który komunikuje się między zespołami. Tak, wiem, co przychodzi Ci do głowy: że są to dodatkowe osoby, które mogą pomylić, pomieszać czy zaciemniać komunikaty. Ale jeśli mamy taki zespół, to pomaga on odciążyć osoby zajmujące się danymi zagadnieniami i rozwiązywaniem problemu. Nie muszą się one skupiać na szukaniu, komu i co trzeba przekazać, tylko dzwonią do grupy komunikującej i to ta grupa ma za zadanie znaleźć osoby, które należy powiadomić o problemie. Jest to gigantyczne odciążenie podczas zdarzenia.
  4. Obsługujący zniszczenia — zespół, który będzie analizował straty, jakimi dotknięte zostały zasoby firmy wskutek wystąpienia zdarzenia krytycznego. Co zostało zniszczone, w jaki sposób, które z zasobów można jeszcze wykorzystać do wsparcia rozwiązania zdarzenia.
  5. Sieciowy — zespół specjalistów od sieci, którzy sprawdzą okablowanie w biurze, sieć i jej zależności – czy wszystko działa tak, jak trzeba.
  6. Admini — administratorzy systemów, którzy zapewnią normalne funkcjonowanie systemów bądź będą je przywracać do normalności.
  7. Admini baz danych — jak powyżej, tylko administratorzy baz danych.
  8. Admini/Support Aplikacji — tak samo, jak w wypadku administratorów systemów, administratorzy aplikacji muszą przywrócić normalne funkcjonowanie aplikacji.
  9. Deweloperzy Aplikacji — musimy mieć dostęp do deweloperów, by można było wprowadzić zmiany w aplikacjach, jeśli będzie to konieczne do przywrócenia działania.
  10. Zespół od transportu — jeśli mamy hot i cold site, potrzebny też jest zespół lub osoba, która pomoże zorganizować i zajmie się transportem z jednego miejsca na drugie.
  11. Bezpieczniki zespół ten odpowiada za bezpieczeństwo fizyczne jak i logiczne pracowników, zasobów oraz informacji.
  12. Zespół od finansów — zespół ten musi być decyzyjny w sprawie finansów, aby móc przeznaczyć odpowiednie środki na naprawy, gdy wystąpi zdarzenie krytyczne.

Wiem, że w wielu wypadkach będzie tak, że jedna osoba będzie znajdować się w kilku powyższych zespołach, ponieważ organizacji nie będzie stać, by aż tak wydzielać koszty. Zgoda – tylko trzeba pamiętać, że taka osoba nie może mieć zbyt dużo obowiązków, ponieważ mija się to z celem. Każda z osób powinna mieć ograniczoną ilość obowiązków, by być w stanie sprawnie pomóc w wypadku zdarzenia. A nie mieć masę na głowie i biegać z jednego miejsca do drugiego, bo za dużo ma do załatwienia. To też może powodować popełnianie masy błędów, co mija się z celem DRP.

Docelowy czas odzyskiwania

Docelowy czas odzyskiwania to RTO, czyli Recovery time objective. RTO określa czas od początku przestoju do czasu wznowienia działania danej usługi. RTO liczy się w godzinach bądź w dniach. Podczas tworzenia BIA należy określić RTO dla każdego procesu i systemu. RTO nie zawsze musi oznaczać powrót do 100% funkcjonalności – można zrobić dwa RTO, na przykład pierwszy przywracający do 50%, a drugi do 100% usługi.

Usługa może bowiem działać w 50% procentach i dalsze naprawianie jej będzie niezbędne, ale już od 50% może ona funkcjonować w taki sposób, który pozwoli np. robić zakupy za pomocą aplikacji. Często większe aplikacje mają funkcjonalności, które są dodatkowe, a nie niezbędne do jej działania. Wiec odpowiednie określenie RTO może pozwolić określić koszty poniesione do czasu przywrócenia aplikacji. A źle określone RTO może pokazać większe koszty, niż rzeczywiście należy ponieść, by przywrócić aplikację do funkcjonowania tak, aby była ona znowu zdolna do obsługi klientów.

Cel punktu odzyskiwania

Cel punktu odzyskiwania — RPO (Recovery point objective) jest to okres, od którego dane zostaną nieodwracalnie utracone w wypadku katastrofy. Tak samo jak w wypadku RTO, RPO zazwyczaj liczone jest w godzinach bądź w dniach, ale w przypadku bardzo krytycznych systemów może być liczone nawet w minutach.

RPO określa najgorszy możliwy scenariusz. Na przykład jeśli możemy coś przywrócić do sprawności w 6 godzin bądź szybciej, przy RPO będziemy zakładali 6 godzin. Jak to mówią, w bezpieczeństwie lepiej rozczarować się pozytywnie niż negatywnie 😉 Dla przykładu kopia zapasowa serwera wykonywana jest raz dziennie, a przywrócenie serwera do normalności zajmie cztery dni. Tutaj więc RPO będziemy mieć ustalone na jeden dzień, a RTO to będą cztery dni.

Określanie RTO i RPO

Załóżmy, że mamy aplikację, której kopia zapasowa jest wykonywana co godzinę. I gdy w trakcie zdarzenia ucierpi tylko ta aplikacja, będziemy mieć RTO rzędu jednej godziny. Ale gdy podczas zdarzenia ucierpi nie tylko aplikacja, ale i serwer, na którym ta aplikacja się znajduje, wówczas nie będzie już to godzina. Załóżmy, że serwer taki będziemy podnosić do działania przez 3 godziny. Gdy mamy te trzy godziny, a później jeszcze godzinę na przywrócenie kopii, to RTO zmienia swoją wartość z jednej do czterech godzin.

OK, a teraz inne założenie. W serwerze padło CPU i jego wymiana zajmie trzy godziny. Przy czym żadne dane nie zostaną utracone. W takim wypadku RTO będzie wychodziło trzy godziny, a RPO będzie zero, ponieważ żadne dane nie zostaną utracone.

Myślę, że powyższe przykłady ładnie obrazują, na czym polega określanie RTO i RPO. Teraz troszkę o finansach. Najprościej jest powiedzieć, że im chcemy mieć niższe RTO i RPO, tym będzie to nas drożej kosztować. Ponieważ technologie, które pozwolą to osiągnąć tak niski poziom RTO i RPO, zazwyczaj dużo więcej kosztują. Na przykład przywrócenia serwera z taśm będzie kosztowało mniej i załóżmy, że będzie trwało 2 tygodnie. A posiadanie taśm i zapasowego serwera na miejscu będzie kosztowało już trochę więcej. Dodanie load balancera znowu zwiększy koszty i tak dalej, i tak dalej.

Zespół od BCP musi zrozumieć związek między czasem wymaganym do podniesienia aplikacji a kosztami, jakie poniosą za dane rozwiązania, które pomogą zarządzać tym czasem. Muszą też oni zdać sobie sprawę, że im czas przywracania krótszy, tym większe koszty poniosą. Bardzo ważne jest również, by wiedzieli, że wzrost kosztów nie jest liniowy. Wręcz prawie zawsze jest on wykładniczy, bo im lepsze rozwiązania, tym różnica jest „razy x”, a nie „dodać x”.

Dlatego podczas określania RTO i RPO należy zaangażować zarząd, który pomoże określić, która aplikacja bądź który proces jest krytyczny i jakie są akceptowalne RTO i RPO dla tego procesu. Należy następnie podać rozwiązania i ich koszty, które pozwolą osiągnąć dane wartości. I zapytać, czy takie koszty są akceptowalne. Jeśli nie, to należy podać inne rozwiązania, „gorsze” oraz ich koszty i jaki RTO i RPO dla zarządu będzie akceptowalny.

I tak przepychamy się aż do uzyskania w obu przypadkach odpowiedniego poziomu. Czasem okazuje się, że wybór skreślony w pierwszej kolejności zostaje jednak po wieku burzliwych dyskusjach przyjęty. Nie denerwuj się taką sytuacją: często ludziom trzeba pokazać klika możliwości, by zrozumieli, że tańsze rozwiązanie nie zawsze jest korzystne bądź możliwe do zastosowania.

Przygotowanie strategii przywracania

Po określeniu przez zarząd RTO i RPO zespół BCP może zająć się opracowaniem strategii technologicznej i logistycznej, by RTO i RPO zostały zapewnione. Tak, jak napisałem powyżej, jeśli koszta są za wysokie, cofamy się o dwa kroki i robimy to jeszcze raz. Poniżej opisałem kroki, by zobrazować Ci, jak taki proces wygląda w rzeczywistości.

Lista kroków:

  1. BIA
  2. Określenie RTO i RPO dla procesu / aplikacji
  3. Określenie architektury technicznej i procesu przywracania
  4. Czy rozwiązanie jest zbyt drogie: TAK/NIE. Jeśli TAK, to wracamy do pkt. 2.
  5. Jeśli pkt. 4 – NIE, to implementujemy rozwiązanie z pkt. 3.

Opcje przywracania firmy

Czasem może zdarzyć się tak, że trzeba będzie przywracać cały odział danej firmy. By to zrobić i nie stresować się w trakcie zdarzenia, korzystamy z Hot/cold/warm site. Opisałem to już ładnie w innym artykule, więc nie będę tu powtarzał: zajrzyj tu, czym są hot/cold/warm site. Trzeba było wspomnieć o tym temacie i tutaj, ponieważ jest on ważny dla tego artykułu, więc jeśli nie wiesz, co to – znajdziesz wszelkie informacje pod powyższym linkiem. Coraz częściej odchodzi się od tego rozwiązania w organizacjach, gdzie to tylko możliwe, ponieważ jest to bardzo kosztowne rozwiązanie niezależnie w którym wariancie. A dzięki możliwości pracy zdalnej, której jestem zwolennikiem (mimo niedoskonałości i zagrożeń, jakie powoduje – temat zagrożeń przy pracy w domu poruszę innym razem) rezygnacja z hot/cold/warm site stała się w wielu przypadkach możliwa do spełnienia.

Technologie przywracania

Gdy już mamy określone zasoby, które muszą zostać przywrócone, kolejnym krokiem jest określenie, jakie technologie pozwolą zapewnić RTO i RPO. Poniżej wymienię Ci listę tematów, które trzeba wziąć pod uwagę, kiedy rozważamy wdrożenie danego rozwiązania.

  • Czy technologia pomaga osiągnąć RTO i RPO ?
  • Czy koszty mieszczą się w budżecie, czy też go przekraczają ?
  • Czy ta technologia pomoże obniżyć koszty przy innych systemach ?
  • Czy technologia wpasowuje się w aktualne operacje IT w organizacji? Czy też potrzeba dokonać jakichś zmian ?
  • Czy pracownicy będą potrzebować dodatkowego przeszkolenia, by wykorzystać wprowadzoną technologię?
  • Czy technologia niepotrzebnie komplikuje architekturę IT w firmie ?

Przygotowanie planu przywracania

Dopiero teraz, gdy już określiliśmy już BIA, przeanalizowaliśmy krytyczność procesów i aplikacji oraz określiliśmy wszelkie czasy przywracania, możemy się zająć DRP, ponieważ to są podstawowe fazy, które musimy mieć przerobione dla dobrze zrobionego DRP. Dzięki tym informacjom zespół DRP może określić i rozrysować mapę, jakiego dodatkowego sprzętu będzie potrzeba, by zapewnić spełnienie wymagań. Bardzo ważnym aspektem planu przywracania jest stworzenie dokumentacji, która opisze procesy i procedury niezbędne przy przywracaniu systemów, aplikacji itp. do normalności.

Te procesy i procedury mają za zadanie pouczyć odpowiednie osoby, jak mają one postępować w wypadku zdarzenia. Nic nie pomoże, jeśli będziemy mieli wdrożone odpowiednie rozwiązania, a personel odpowiedzialny za ich przywracanie nie będzie wiedział, jak postępować.

Poniżej opiszę Ci, co powinno zawierać takie DRP:

  1. Procedura deklaracji katastrof — procedura taka musi zawierać dokładne informacje, jak określana jest katastrofa i kto ma uprawnienia, by zadeklarować katastrofę, co pociągnie za sobą kolejne akcje.
  2. Role i odpowiedzialności — DRP musi określać, jakie aktywności i przez jakie osoby bądź zespoły powinny być wykonane. Ponieważ te zespoły czy osoby są przeszkolone i mają odpowiedni sprzęt, by je wykonać.
  3. Lista kontaktów w nagłych wypadkach — trzeba zapewnić listę kontaktów do zastosowania w nagłych wypadkach, najlepiej w paru ścieżkach – zależnie od rodzaju zdarzenia. Moim zdaniem najlepiej sprawdza się drzewko kontaktów, jest to najwygodniejszy sposób.
  4. Procedury działania systemu — są to procedury, które krok po kroku określają, jak przywrócić systemy do pracy. Procedury będą zawierały wiele szczegółów, jak są skonfigurowane systemy czy urządzenia sieciowe. Będą musiały zawierać informacje, jak sprawdzić, czy aplikacja działa na serwerze po jego przywróceniu itd.
  5. Procedury przywracania systemu — są to procedury, które krok po kroku z detalami opisują, jak działać na krytycznych systemach podczas przywracania. Bowiem podczas przywracania systemy IT mogą zachowywać się inaczej niż wtedy, gdy są w pełni sprawne. Dodatkowo może się zdarzyć, że przywracać będzie osoba, która nie miała jeszcze po temu okazji i będzie robiła to pierwszy raz. Musi więc to być opisane łopatologiczne i kroczek po kroczku 😉
  6. Procedura odbudowania systemu — są to kroki, jakie trzeba podjąć, by przywrócić do normalnego działania operacje IT.

Kopia danych i przywracanie

Bardzo ważnym aspektem w DRP jest wykonywanie kopii zapasowych. W przypadku firm, które jeszcze mają swoją infrastrukturę IT i nie jest ona w pełni w chmurze, takie firmy dalej muszą dbać o swoje kopie zapasowe same. Często są do tego wykorzystywane taśmy, dzięki którym kopie zapasowe mogą być przechowywane w innej lokalizacji. A to jest zdecydowanie pomocne w wypadku katastrofy. W wypadku rozwiązań chmurowych dane są zazwyczaj rozproszone na różnych serwerach w różnych lokalizacjach — bądź też są w jednej lokalizacji, lecz ta lokalizacja jest zewnętrzna i inna niż lokalizacja firmy.

Jakiś czas temu opisałem schematy robienia kopii zapasowych typu Full/ Incremental /Differential. Warto, byś się z nimi zapoznał, jeśli ich nie znasz, zanim przejdziesz dalej.

Organizacje chcą jak najdłużej przechowywać swoje kopie zapasowe po to, aby mieć możliwość powrócenia do kopii z różnych okresów. Musisz zwrócić uwagę na to, że nie zawsze od razu da się zobaczyć błąd i często mija już jakiś czas, od kiedy została naniesiona zmiana, która jest błędna. A kopie są wykonywane często w wyznaczonych odstępach czasu, ponieważ jest to wymagane przez prawo czy została obrana taka polityka.

Musisz wziąć pod uwagę, że utrzymanie dużej biblioteki kopii zapasowych jest kosztowne i zajmuje wiele miejsca. Dlatego zostały wymyślone schematy, by ograniczyć te koszty. Poniżej opiszę Ci 3 z nich:

  • FIFO (First In, First Out) – w wypadku tego schematu nie jest określone, jak długo ma być przechowywana kopia. Tutaj ostatnia z dostępnych taśm z kopią jest następną do użycia. Co to znaczy? Dla przykładu mamy trzy taśmy. Korzystamy najpierw z pierwszej, później z drugiej. I dochodzimy do trzeciej, a gdy musimy zapisać następną, czyli czwartą, korzystamy z taśmy numer jeden. Dużym plusem tego rozwiązania jest prostota. Lecz ma ono też swoje niedociągnięcia. Jeśli problem z danymi nie zostanie wykryty w szybkim czasie, kopia zostanie zastąpiona i nie będzie możliwości powrotu do danych. Dlatego tego typu schemat należy wykorzystywać tylko do mało wrażliwych danych.
  • Grandfather-Father-Son – jeden z popularniejszych schematów, który jest optymalny kosztowo przy większej retencji danych. W najczęściej spotykanym wprowadzeniu tego rozwiązania mamy full backup raz w tygodniu, a poza tym codziennie mamy incremental lub differential.
  • Towers of Hanoi — Najłatwiej to przedstawić w formie grafu jak poniżej.

Tower of Hanoi backup scheme | Acronis Backup & Recovery

Pamiętaj, że z punktu widzenia bezpieczeństwa musisz też zapisywać, kiedy zostały wykonane takie kopie zapasowe i przez kogo. Jak wspomniałem, często prawa lub regulacje wymagają, by dane przechowywania danych kopii zapasowych były zapisywane. Jak więc sam widzisz, wykonywanie kopii zapasowych odpowiednio nie jest tak proste, jak by się wydawało.

Testowanie

Tak samo, jak w wypadku BCP, DRP należy testować, testować i jeszcze raz testować, by poprawiać jego jakość i sprawdzać jego działanie w praktyce.

Poniżej wymienię Ci tylko rodzaje testów, ich dokładny opis znajdziesz pod poniższym linkiem.

  • Przegląd dokumentacji
  • Omówienie
  • Symulacja
  • Test równoległy
  • Test przecięcia

Dokładne opisy tych testów znajdziesz w artykule z BCP pod tym linkiem

Podsumowanie

Jak mogłeś sam zauważyć, nie jest łatwo stworzyć dokumenty typu DRP i BCP. Moim zdaniem są to najbardziej skomplikowane dokumenty w organizacji, ale zarazem najbardziej pomocne. Posiadanie tego typu dokumentów może być jedyną ochroną przed bankructwem w organizacji.

Tak jak już to wspominałem, gdy pisałem o BCP i DRP dla juniora — gdyby firmy spożywcze miały takie dokumenty, przygotowałyby się na pandemię i odcięcie ich od dostawców, i choćby w teorii wiedziałyby, co robić i jak się na to przygotować. A nie dopiero w czasie pandemii zastanawiać się nad rozwiązaniami.

Mam nadzieję, że te trzy artykuły pomogły Ci zrozumieć, przed jak dużym zadaniem stoisz przy tworzeniu BCP i DRP. I że im lepiej się do nich przyłożysz, tym mniej będziesz musiał się martwić podczas katastrofy. I będziesz przygotowany jeśli nie na wszystko, to na wiele 🙂

Pozdrawiam – Pusz 🙂

The form you have selected does not exist.

Jak przydatny był ten Artykuł

Kliknij gwiazdke by zagłosować

Średni / 5. Liczba głosów

Doceń naszą prace

Przepraszam że ten post nie był dla Ciebie przydatny

Popraw ten post!

Napisz mi co mogę poprawić