{"id":31323,"date":"2021-03-12T14:49:15","date_gmt":"2021-03-12T13:49:15","guid":{"rendered":"https:\/\/fotc.com\/?p=31323"},"modified":"2021-11-15T10:33:08","modified_gmt":"2021-11-15T09:33:08","slug":"disaster-recovery-plan","status":"publish","type":"post","link":"https:\/\/dev.fotc.com\/pl\/blog\/disaster-recovery-plan\/","title":{"rendered":"Disaster Recovery Plan, czyli jak zachowa\u0107 dost\u0119pno\u015b\u0107 aplikacji w obliczu awarii"},"content":{"rendered":"\n
Dzia\u0142alno\u015b\u0107 wielu biznes\u00f3w polega dzisiaj na dost\u0119pno\u015bci system\u00f3w informatycznych. Wiele firm, dotychczas funkcjonuj\u0105cych jedynie w sferze offline, przesz\u0142o przez ekspresowy proces cyfrowej transformacji w wyniku pandemii. Przej\u015bcie do online\u2019u z jednej strony przek\u0142ada si\u0119 na wi\u0119ksz\u0105 p\u0142ynno\u015b\u0107 i elastyczno\u015b\u0107, z drugiej \u2013 na niemal ca\u0142kowit\u0105 zale\u017cno\u015b\u0107 od technologii. <\/span><\/p>\n\n\n\n A awarie si\u0119 zdarzaj\u0105. Czy to w wyniku niedopatrzenia po stronie dostawcy us\u0142ug, b\u0142\u0119du pracownika, ataku hakerskiego, czy katastrofy naturalnej. Niezale\u017cnie od przyczyny, incydent mo\u017ce prze\u0142o\u017cy\u0107 si\u0119 na ogromne straty. Cz\u0119\u015b\u0107 przedsi\u0119biorstw jest skazana na zamkni\u0119cie dzia\u0142alno\u015bci, poniewa\u017c nie s\u0105 w stanie odtworzy\u0107 dotychczasowego trybu pracy, utraconej aplikacji czy danych lub koszt ich odzyskania jest zbyt du\u017cy<\/strong>.<\/span><\/p>\n\n\n\n Wed\u0142ug bada\u0144 u\u015bredniony koszt minutowej przerwy w funkcjonowaniu systemu du\u017cych przedsi\u0119biorstw waha si\u0119 od 5600 $ do 9000 $<\/strong> (Gartner, Ponemon Institute). W przypadku ma\u0142ych i \u015brednich przedsi\u0119biorstw jest to od 137 $ do 427 $<\/strong> (Carbonite). 13-minutowa przerwa w funkcjonowaniu serwisu Amazon.com w 2015 roku kosztowa\u0142a firm\u0119 ponad 2,5 miliona dolar\u00f3w. A s\u0105 to dane dotycz\u0105ce jedynie przerwy w dostawie us\u0142ug \u2013 nie utraty systemu czy informacji i koszt\u00f3w ich odtworzenia.<\/span><\/p>\n\n\n\n Ka\u017cda kolejna minuta niedost\u0119pno\u015bci systemu przek\u0142ada si\u0119 na coraz wi\u0119ksze straty. Dlatego istotne jest zadbanie o bezpiecze\u0144stwo danych i kluczowych element\u00f3w aplikacji, przygotowanie planu awaryjnego i przeszkolenie personelu, by w obliczu incydentu jak najszybciej przywr\u00f3ci\u0107 stabilne dzia\u0142anie serwisu.<\/span><\/p>\n\n\n\n Business Continuity Plan pozwala sprawnie zarz\u0105dza\u0107 sytuacjami kryzysowymi w kluczowych obszarach przedsi\u0119biorstwa oraz minimalizowa\u0107 skutki incydentu. DCP powinien przewidywa\u0107 takie sytuacje jak:<\/span><\/p>\n\n\n\n W planie ci\u0105g\u0142o\u015bci nale\u017cy wskaza\u0107 obszary kluczowe dla funkcjonowania przedsi\u0119biorstwa \u2013 przyk\u0142adowo, zachowanie fizycznych dokument\u00f3w, utrzymanie budynku, w kt\u00f3rym znajduje si\u0119 siedziba firmy czy archiwum, zapewnienie bezpiecze\u0144stwa pracownik\u00f3w w obliczu katastrofy. <\/span><\/p>\n\n\n\n Do ka\u017cdego z kluczowych obszar\u00f3w powinien by\u0107 rozpisany proces reakcji, obejmuj\u0105cy wytyczne komunikacyjne (np. kogo i w jakiej kolejno\u015bci poinformowa\u0107 o incydencie) oraz informacje o kolejnych krokach. Instrukcje powinny by\u0107 przedstawione w jak najbardziej zrozumia\u0142y spos\u00f3b, a personel przeszkolony na wypadek wyst\u0105pienia sytuacji kryzysowej. Dokument i jego kopie powinny by\u0107 zabezpieczone i znajdowa\u0107 si\u0119 w kilku lokalizacjach \u2013 by w obliczu awarii nie utraci\u0107 r\u00f3wnie\u017c instrukcji obs\u0142ugi takiego kryzysu<\/strong>.<\/span><\/p>\n\n\n\n W przypadku przedsi\u0119biorstw, kt\u00f3rych g\u0142\u00f3wnym filarem dzia\u0142alno\u015bci jest technologia, obowi\u0105zkow\u0105 pozycj\u0105 w Business Continuity Plan jest Disaster Recovery Plan, czyli plan odzyskiwania system\u00f3w i danych po awarii.<\/span><\/p>\n\n\n\n Disaster Recovery Plan to dokument zawieraj\u0105cy opis procedur, jakie nale\u017cy podj\u0105\u0107 w razie awarii w obszarze IT \u2013 incydentu we w\u0142asnym centrum danych, awarii po stronie dostawcy us\u0142ug, problem\u00f3w w funkcjonowaniu aplikacji, wyst\u0105pieniu krytycznego b\u0142\u0119du w systemie czy przerwy w dost\u0119pno\u015bci cyfrowych narz\u0119dzi pracy.<\/span><\/p>\n\n\n\n Celem planu odzyskiwania po awarii jest jak najszybsze uruchomienie stabilnej aplikacji (ca\u0142ej lub kluczowych jej obszar\u00f3w) oraz przywr\u00f3cenie dost\u0119pu do danych i mo\u017cliwo\u015bci dalszego ich przetwarzania<\/strong>. Szybka i zaplanowana reakcja ma skr\u00f3ci\u0107 czas niedost\u0119pno\u015bci systemu i ograniczy\u0107 jego skutki.<\/span><\/p>\n\n\n\n Dla przyk\u0142adu \u2013 za\u0142\u00f3\u017cmy, \u017ce posiadamy sie\u0107 sklep\u00f3w stacjonarnych oraz serwis e-commerce. Powinni\u015bmy zabezpieczy\u0107 si\u0119 na wypadek takich sytuacji jak:<\/span><\/p>\n\n\n\n Je\u015bli kt\u00f3re\u015b z tych sytuacji s\u0105 kluczowe dla dalszego funkcjonowania przedsi\u0119biorstwa, Disaster Recovery Plan powinien je uwzgl\u0119dnia\u0107.<\/span><\/p>\n\n\n\n W dokumencie Disaster Recovery Plan powinny znale\u017a\u0107 si\u0119 dwa wska\u017aniki \u2013 Recovery Point Objective i Recovery Time Objective. Obie warto\u015bci s\u0105 warto\u015bciami czasowymi i przedstawia si\u0119 je najcz\u0119\u015bciej w minutach lub godzinach.<\/span><\/p>\n\n\n\n Recovery Point Objective (RPO)<\/strong> to warto\u015b\u0107 pokazuj\u0105ca, jaki okres czasu obejmuje ostatnia przeprowadzona kopia zapasowa czy transfer danych do centrum Disaster Recovery. Je\u015bli w aplikacji co kilka minut wprowadzane s\u0105 istotne zmiany, RPO powinno wynosi\u0107 w\u0142a\u015bnie kilka minut. Je\u015bli aktualizacje nast\u0119puj\u0105 rzadziej lub maj\u0105 mniejsz\u0105 wag\u0119, warto\u015b\u0107 RPO mo\u017ce by\u0107 r\u00f3wna kilku godzinom.<\/span><\/p>\n\n\n\n Recovery Time Objective (RTO)<\/strong> to miara, kt\u00f3ra wskazuje, jaki jest maksymalny czas na przywr\u00f3cenie funkcjonowania po awarii \u2013 czyli ile maksymalnie czasu system mo\u017ce by\u0107 wy\u0142\u0105czony. RTO cz\u0119sto jest sk\u0142adow\u0105 Service Level Agreement (SLA), wi\u0119c okre\u015blenie warto\u015bci jest kluczowe m.in. do spe\u0142nienia warunk\u00f3w zawartej z klientem umowy.<\/span><\/p>\n\n\n\n Im ni\u017csz\u0105 warto\u015b\u0107 maj\u0105 Recovery Point Objective i Recovery Time Objective (im szybciej zale\u017cy nam na przywr\u00f3ceniu najnowszej wersji systemu), tym wysz\u0142y b\u0119dzie koszt odzyskania po awarii.<\/span><\/p>\n\n\n\n To, jakie obszary nale\u017cy pokry\u0107 i jakie dzia\u0142ania podj\u0105\u0107 w obliczu kryzysu, jest kwesti\u0105 indywidualn\u0105 ka\u017cdego przedsi\u0119biorstwa i ka\u017cdego systemu.<\/strong><\/p>\n\n\n\n Jest jednak kilka uniwersalnych krok\u00f3w, kt\u00f3re nale\u017cy wykona\u0107, przygotowuj\u0105c plan odzyskiwania po awarii. Oto one:<\/span><\/p>\n\n\n\n Pierwszym krokiem jest swego rodzaju \u201cinwentaryzacja IT\u201d \u2013 czyli przygotowanie listy wykorzystywanych elektronicznych i cyfrowych produkt\u00f3w, od kt\u00f3rych zale\u017cy funkcjonowanie przedsi\u0119biorstwa, a kt\u00f3re mog\u0105 zawie\u015b\u0107.<\/span><\/p>\n\n\n\n Na li\u015bcie powinny znale\u017a\u0107 si\u0119 m.in.:<\/span><\/p>\n\n\n\n Nast\u0119pnym krokiem jest ocena poziomu krytyczno\u015bci danych element\u00f3w. Nale\u017cy wskaza\u0107, kt\u00f3re obszary dzia\u0142alno\u015bci ucierpi\u0105 w sytuacji braku dost\u0119pu do danych informacji czy danych narz\u0119dzi i jaki wp\u0142yw b\u0119dzie to mia\u0142o na ci\u0105g\u0142o\u015b\u0107 funkcjonowania biznesu.<\/span><\/p>\n\n\n\n Nale\u017cy oceni\u0107, jakie s\u0105 potencjalne zagro\u017cenia dla danych obszar\u00f3w oraz jakie konsekwencje ze sob\u0105 nios\u0105. Pod uwag\u0119 nale\u017cy wzi\u0105\u0107 niewielkie incydenty (jak b\u0142\u0105d strony skutkuj\u0105cy kilkuminutowym przestojem), jak te\u017c najczarniejsze scenariusze (np. ca\u0142kowite zniszczenie centrum danych wraz z plikami aplikacji). <\/span><\/p>\n\n\n\n Dobrze jest oceni\u0107 finansow\u0105 warto\u015b\u0107 danych element\u00f3w, posi\u0142kuj\u0105c si\u0119 informacjami o przychodzie, jaki generuje dany obszar<\/strong>. W sieci dost\u0119pne s\u0105 propozycje wzor\u00f3w na obliczenie kosztu nawet minuty przestoju systemu.<\/span><\/p>\n\n\n\n Okre\u015blenie potencjalnych incydent\u00f3w i ich skutk\u00f3w pozwala wskaza\u0107 realne cele i wska\u017aniki w nast\u0119pnych krokach opracowania planu.<\/span><\/p>\n\n\n\n Maj\u0105c list\u0119 element\u00f3w o najwy\u017cszym priorytecie, nale\u017cy wskaza\u0107 RTO i RPO dla poszczeg\u00f3lnych obszar\u00f3w. Je\u015bli dany element jest krytyczny, czas przywr\u00f3cenia jego mo\u017cliwie najnowszej wersji powinien by\u0107 jak najkr\u00f3tszy. Pod cele nale\u017cy przygotowa\u0107 procesy i strategi\u0105 przywracania po awarii. Przyk\u0142adowo, je\u015bli firma \u015bwiadczy wysokie SLA, powinna zadba\u0107 o jak najszybsz\u0105 i nasprawniejsz\u0105 reakcj\u0119 z Disaster Recovery Center.<\/span><\/p>\n\n\n\n Wy\u017cej wymienione informacje \u2013 spis element\u00f3w aplikacji, u\u017cywanych narz\u0119dzi, wykorzystywanego sprz\u0119tu wraz z priorytetami \u2013 powinny zosta\u0107 spisane w przejrzysty i zrozumia\u0142y spos\u00f3b do jednego dokumentu. DRP powinien by\u0107 instrukcj\u0105 dla os\u00f3b, kt\u00f3re zauwa\u017caj\u0105 incydent i ma umo\u017cliwi\u0107 im szybk\u0105 i zorganizowan\u0105 reakcj\u0119.<\/span><\/p>\n\n\n\n Disaster Recovery Plan powinien zawiera\u0107 m.in.:<\/span><\/p>\n\n\n\n Dokument oraz jego kopie powinny znajdowa\u0107 si\u0119 kilku lokalizacjach, \u0142atwo dost\u0119pnych dla pracownik\u00f3w. Z pewno\u015bci\u0105 planu Disaster Recovery nie mo\u017cna zamie\u015bci\u0107 w tym samym miejscu co innych kluczowych plik\u00f3w i danych, poniewa\u017c w sytuacji incydentu, dost\u0119p do niego r\u00f3wnie\u017c zostanie utracony.<\/span><\/p>\n\n\n\n Przyk\u0142adowo, je\u015bli korzystasz z w\u0142asnego centrum danych, dokument DRP mo\u017cesz przechowywa\u0107 na innym, oddalonym geograficznie serwerze lub w chmurze.<\/span><\/p>\n\n\n\n Nast\u0119pnym krokiem jest przeprowadzenie testu planu i wszystkich procedur. Pozwoli to zweryfikowa\u0107 obrane wska\u017aniki, wskaza\u0107 obszary potencjalnego zagro\u017cenia i ulepszy\u0107 plan.<\/span><\/p>\n\n\n\n Ten krok jest niezwykle istotny \u2013 cz\u0119sto dopiero w praktyce okazuje si\u0119, \u017ce niekt\u00f3re punkty wymagaj\u0105 znacznej modyfikacji. Testy wska\u017c\u0105 te\u017c, w jakich obszarach nale\u017cy po\u0142o\u017cy\u0107 mocny nacisk na szkolenie personelu.<\/span><\/p>\n\n\n\n
<\/a><\/figure>\n\n\n\nBusiness Continuity Plan, czyli plan ci\u0105g\u0142o\u015bci dzia\u0142ania<\/span><\/h2>\n\n\n\n
Disaster Recovery Plan (DRP) \u2013 plan odzyskiwania po awarii<\/span><\/h2>\n\n\n\n
RPO i RTO \u2013 kluczowe warto\u015bci w planie awaryjnym<\/span><\/h3>\n\n\n\n
<\/figure>\n\n\n\n
<\/figure>\n\n\n\nCo powinien zawiera\u0107 Disaster Recovery Plan?<\/span><\/h3>\n\n\n\n
1. Spis wykorzystywanych urz\u0105dze\u0144 i program\u00f3w<\/span><\/h4>\n\n\n\n
2. Ocena krytyczno\u015bci danych obszar\u00f3w<\/span><\/h4>\n\n\n\n
3. Oszacowanie ryzyka i wp\u0142ywu na biznes<\/span><\/h4>\n\n\n\n
4. Ustalenie cel\u00f3w planu odtwarzania po awarii<\/span><\/h4>\n\n\n\n
5. Stworzenie kompleksowego dokumentu<\/span><\/h4>\n\n\n\n
6. Umieszczenie DRP w bezpiecznym miejscu<\/span><\/h4>\n\n\n\n
7. Testowanie planu i wprowadzanie ulepsze\u0144<\/span><\/h4>\n\n\n\n
8. Cykliczne szkolenia personelu i aktualizacje dokumentu<\/span><\/h4>\n\n\n\n