To błąd. Nie powinniśmy przenosić odpowiedzialności za funkcjonowanie całego lub części biznesu na dostawcę usług. Musimy założyć ewentualność, że pewnego dnia platforma, która stanowi filar naszej działalności, przestanie działać. I co wtedy? Czy razem z nią ma pogrążyć się całe przedsiębiorstwo?
Pamiętasz pewnie pożar w serwerowni OVH. Octave Klaba, founder i CEO firmy opublikował na Twitterze post, w którym informował o incydencie i rekomendował uruchomienie Disaster Recovery Plan wśród użytkowników.
Wiele osób zaczęło pytać, gdzie znajdzie ten Disaster Recovery Plan. Czy OVH prześle im na maila, czy mają szukać go gdzieś w panelu? Biznesy tych osób, które nie wiedziały, że o bezpieczeństwo, stabilność i plan Disaster Recovery należy zadbać samodzielnie, poszły z dymem.
Disaster Recovery Plan – element planu ciągłości działania biznesu
W języku polskim Disaster Recovery Plan (DRP) to plan odzyskiwania po awarii. To dokument będący częścią planu ciągłości działania przedsiębiorstwa – Business Continuity Plan (BCP).
Plan BCP przygotowuje organizację na sprawne reagowanie w takich sytuacjach jak:
- katastrofa naturalna (np. trzęsienie ziemi, powódź),
- awaria budynku (np. zalanie, pożar, katastrofa budownicza),
- wypadek komunikacyjny (zwłaszcza w przypadku firm spedycyjnych),
- kradzież czy zniszczenie fizycznych dokumentów,
- kradzież sprzętu firmowego,
- włamanie do systemu informatycznego.
Disaster Recovery Plan dotyczy obszaru IT, a konkretniej odzyskiwania danych informatycznych, systemów i aplikacji po awarii. To dokument zawierający spis procedur i kroków wraz z objaśnieniem, jaką akcję należy podjąć w przypadku incydentu – czy to we własnym centrum danych, po stronie dostawcy usług, czy w wyniku wystąpienia krytycznego błędu w oprogramowaniu.
Celem planu Disaster Recovery jest jak najszybsze ponowne uruchomienie systemu, z jak najaktualniejszymi danymi sprzed awarii, by zapobiec konsekwencjom przerwy w działaniu albo zminimalizować szkodę.
Co składa się na plan Disaster Recovery?
To, jakie obszary powinien obejmować Disaster Recovery Plan, jest kwestią indywidualną dla każdej organizacji i dla każdego systemu. Dla jednej firmy newralgicznym punktem będzie serwis e-commerce, dla innej platforma obsługi klienta, dla jeszcze innej system enterprise resource planning. Nie ma uniwersalnego przepisu na DRP – każdy powinien zostać przygotowany od zera, po analizie własnych zasobów.
Na Disaster Recovery składają się kroki:
- Spis wykorzystywanych urządzeń, programów i zasobów. Pierwszym krokiem jest przygotowanie listy wszystkich elementów infrastruktury IT, które są używane w przedsiębiorstwie. Będzie to fizyczny sprzęt mobilny i stacjonarny, używane aplikacje webowe, bazy danych, serwery czy usługi chmury i hostingu.
- Ocena poziomu krytyczności danych obszarów. W następnym kroku należy wskazać, jakie obszary ucierpią w wyniku awarii poszczególnych elementów infrastruktury oraz jaki wpływ będzie to miało na ciągłość działania organizacji.
- Ustalenie celów planu odzyskiwania po awarii. W Disaster Recovery funkcjonują dwa główne wskaźniki:
- Recovery Point Objective (RPO) – określa, do którego momentu sprzed awarii można przywrócić system. Najczęściej jest to moment wykonania ostatniej migracji, snapshota czy kopii zapasowej;
- Recovery Time Objective (RTO) – wskazuje, jaki jest maksymalny czas trwania przerwy w działaniu aplikacji, czyli przez ile sekund lub minut system może być niedostępny.
Mając listę krytycznych elementów, należy określić wartości RPO i RTO dla każdego z nich i podjąć działania, które mają wspomóc ich realizację – na przykład zwiększyć częstotliwość wykonywania kopii zapasowej czy zaplanować architekturę odzyskiwania w Disaster Recovery Center (w zapasowym centrum danych).
- Opracowanie procesów i harmonogramu działań. Dla każdego krytycznego obszaru trzeba opracować plan zawierający takie elementy jak: dane kontaktowe do osób, które należy powiadomić w razie awarii; harmonogram działań obejmujący m.in. opis incydentu, określenie strat, poinformowanie użytkowników o przerwie w dostawie usług, wskazanie niezbędnych kroków do przywrócenia funkcjonowania systemu; czy działania, jakie należy podjąć po uruchomieniu aplikacji, np. test obciążenia czy sprawdzenie jakości połączenia.
- Stworzenie kompleksowego dokumentu. Disaster Recovery Plan ma być instrukcją dla osoby, która zauważy incydent i ma pozwolić jej wykonać wszystkie niezbędne kroki, by przywrócić funkcjonowanie systemu.Wyżej wymienione informacje – spis elementów aplikacji, używanych narzędzi, wykorzystywanego sprzętu wraz z priorytetami oraz harmonogram działań – powinny zostać spisane w przejrzysty i zrozumiały sposób w jednym pliku.
- Umieszczenie DRP w bezpiecznym miejscu. Dokument powinien znajdować się w kilku lokalizacjach – a na pewno nie jedynie w miejscu, gdzie znajdują się kluczowe elementy aplikacji, które Disaster Recovery Plan ma odzyskać. Razem z brakiem dostępu do zasobów firmowych, zablokuje się też dostęp do informacji, jak te zasoby odzyskać. DRP dobrze jest przechowywać w oddalonym geograficznie centrum danych innego dostawcy, na fizycznym nośniku, a nawet na papierze.
- Testowanie planu i wprowadzanie ulepszeń. Istotna jest weryfikacja, czy plan działa. Lepiej, żeby znaleźć jego niedoskonałości podczas testów, niż w trakcie rzeczywistego incydentu. Próby pokażą też, w których obszarach należy położyć szczególny nacisk na edukację pracowników.
- Cykliczne szkolenia personelu i aktualizacja dokumentu. Ostatnim, ale nigdy niekończącym się krokiem, jest dbanie o aktualność informacji oraz wiedzę pracowników. Szkolenia z odzyskiwania po awarii dobrze jest prowadzić przynajmniej raz na kwartał, zwłaszcza jeśli wskaźniki RPO i RTO zostały ustawione na wysoką wartość.
Disaster Recovery Center – zapasowe centrum danych w chmurze
Jednym z najbezpieczniejszych miejsc na awaryjne uruchomienie aplikacji jest chmura publiczna, która udostępnia usługę Disaster Recovery as a Service. DRaaS często polega na bieżącym kopiowaniu i przesyłaniu do chmury całego systemu lub jego kluczowych elementów oraz wyzwalaniu awaryjnego uruchomienia w odpowiedzi na konkretne wydarzenie, na przykład po uzyskaniu informacji o wyłączeniu maszyny wirtualnej.
Jedną z chmur, która udostępnia środowisko dla Disaster Recovery, jest Google Cloud Platform. Chmura GCP posiada własną sieć światłowodową, łączącą ponad 70 centrów danych, oferując tym samym wysoką wydajność i dostępność (SLA na poziomie 99,95-99,99% dla wszystkich usług). Sama topologia chmury GCP wyklucza przerwę w działaniu w wyniku zniszczenia maszyn, pożaru całego centrum danych czy nawet wystąpienia katastrofy naturalnej. To dlatego, że jej punkty są rozproszone pomiędzy różnymi, geograficznie oddalonymi od siebie lokalizacjami, pomiędzy którymi nieprzerwanie jest prowadzona redundancja, czyli kopiowanie i przesyłanie zaszyfrowanych danych.
Tutaj znajdziesz więcej informacji o zapasowym centrum danych oraz zapoznasz się z przykładowymi scenariuszami odzyskiwania w chmurze Google: Disaster Recovery Plan, czyli jak zachować dostępność aplikacji w obliczu awarii.
Zadbaj o stabilność biznesu przy wsparciu lokalnego partnera Google Cloud
Obok wysokiej dostępności i wydajności, jaką zapewnia Google Cloud Platform, dużą zaletą jest wsparcie certyfikowanych specjalistów. Lokalnym partnerem Google Cloud na rynku polskim jest FOTC – firma posiadająca na pokładzie ponad 70 ekspertów, w tym inżynierów i architektów chmury oraz specjalistów ds. bezpieczeństwa i sieci, którzy wesprą Twoją firmę w opracowaniu Disaster Recovery Plan czy przygotowaniu stabilnego Disaster Recovery Center w chmurze Google.