Disaster Recovery Center (DRC): tratwa ratunkowa dla Twojego biznesu e‑commerce

Sklep działa, klienci klikają, zamówienia się kompletują, przelewy spływają. Pewnego dnia następuje katastrofa. Właściciel firmy e‑commerce bezradnie przygląda się stratom generowanym przez awarię systemu. Chcesz uniknąć takiej sytuacji?

Poznaj bliżej Disaster Recovery Center! 

Czy Twój biznes e‑commerce ma plan B? 

Każda firma, bez względu na wielkość, powinna posiadać Disaster Recovery Plan (DRP). Ten plan to procedura opisująca, co należy robić, kiedy NIC nie działa, ponieważ zabrakło prądu, zawiodła klimatyzacja albo firma została odcięta od sieci.

W Twojej głowie zaświtała teraz pewnie myśl: „Zaraz, przecież mam serwery w chmurze. Cóż mnie to może obchodzić?”. Niestety, problem jest dużo bardziej złożony. Na szczęście istnieje rozsądne rozwiązanie dla Twojej firmy. Kryje się ono w skrócie DRC. 

Co to jest DRC?

DRC to skrót od Disaster Recovery Center, czyli zapasowe centrum przetwarzania danych. Jest to miejsce, w którym możesz przywrócić do działania swoje usługi IT. Rolę DRC mogą pełnić data center, chmura, a nawet przysłowiowy „komputer pod biurkiem prezesa”, choć tego rozwiązania akurat nie polecam. 

4 pytania przed rozpoczęciem prac nad DRC 

Temat Disaster Recovery Center w Twojej firmie wymaga odpowiedzi na kilka kluczowych kwestii: 

1) Czego Twoje usługi IT potrzebują do działania?
Serwerów dedykowanych, wirtualnych, klastrów Kubernetes, rozwiązań cloudowych czy może czegoś jeszcze innego? 

2) Ile z tych zasobów potrzeba, by Twoje usługi IT działały i były w stanie obsłużyć zwykły ruch?
Chodzi o standardową ilość użytkowników systemu. 

3) Jaka utrata danych jest akceptowalna dla Twojej firmy?
Zawsze trzeba się liczyć z jakąś utratą danych i zakładać jakiś margines błędu. Jest to jeden z ważnych mierników przy projektowaniu DRC – Recovery Point Objective (RPO). Przykład: przełączenie na DRC może spowodować utratę zamówień z ostatnich 5 minut. 

4) Po jakim czasie usługi powinny być dostępne w DRC?
To drugi podstawowy wskaźnik: Recovery Time Objective (RTO). Czas przełączenia jest zależny od implementacji samego DRC. W tym wypadku niezbędne będą konsultacje z zespołem IT. Niekiedy konieczny będzie zakup dodatkowego oprogramowania (np. do synchronizacji baz danych) lub wręcz wsparcie firmy zewnętrznej. 

Koszt infrastruktury DRC to nie wszystko 

Po przeanalizowaniu odpowiedzi na powyższe pytania, możesz orientacyjnie określić swoje wymagania dotyczące DRC i zacząć szacować bezpośredni koszt utworzenia tego rozwiązania. WAŻNE: Bezpośredni koszt infrastruktury DRC jest tak naprawdę niewielkim elementem całej układanki.  

Aby DRC działało i robiło to w miarę sensownie, trzeba zrobić coś więcej niż tylko zakupić serwery i wstawić je w lokalizacji zapasowej. Kluczem do sukcesu jest wybór odpowiedniego dostawcy infrastruktury.

Jak wybrać dostawcę infrastruktury DRC? 

Z mojego punktu widzenia, najistotniejszymi kryteriami wyboru dostawcy DRC są:

1) Niezależność geograficzna 

Dwie niezależne lokalizacje geograficzne (np. Polska i USA) brzmią rozsądnie, ale jeśli koncentrujesz się w 100% na użytkownikach z Polski, to bardziej sensowne będzie skupienie się na dwóch lokalizacjach w Polsce. Wniosek: wybierz rozwiązanie, które odpowiada przyjętemu przez Twoją firmę modelowi biznesowemu.

2) Niezależność biznesowa 

Dobrze jest, jeżeli właściciele obu naszych lokalizacji (podstawowej i zapasowej) są podmiotami niezależnymi biznesowo. Głównie chodzi o niezależność właścicielską i finansową.  

3) Elastyczność 

Tworząc DRC, można założyć, że jego zasoby przez 99% czasu będą niewykorzystywane. Dlatego kluczowa jest możliwość tworzenia tych zasobów i skalowania ich ad hoc. 

4) Dostępność 

W tym przypadku chodzi o zagwarantowanie, by w razie potrzeby użycia Disaster Recovery Center, jego zasoby były dostępne. 

5) Koszty 

Finanse nie powinny być najważniejszym kryterium, ale nie można też tego czynnika bagatelizować. Jest on w dużym stopniu związany ze wspomnianą elastycznością. DRC będzie stałym kosztem, a przy odrobinie szczęścia może nie być on wykorzystany w ogóle. 

Cel to podstawa! 

To ważne, ponieważ precyzyjne zdefiniowanie celu tworzenia DRC pomoże Ci odpowiednio go zaimplementować.  

Przykład: Jeżeli zakładasz stałą synchronizację danych (replikację), a jednocześnie chcesz w ten sposób bronić się przed efektami ataku hakerskiego lub błędu ludzkiego (np. przed skasowaniem danych), to musisz się liczyć z niepowodzeniem. Efekty ataku lub błędy zostaną bowiem zreplikowane na DRC.

3 uwagi na koniec do CTO/E‑commerce managera 

Po lekturze tego artykułu z pewnością masz więcej pytań niż odpowiedzi.

Na pierwsze 3 z nich odpisuję poniżej:

1) Kiedy DRC może poczekać? 

Dla mniejszych sklepów internetowych lub aplikacji typu B2B, gdzie wymagana jest np. dostępność w godzinach 8‑16, tworzenie DRC może wydawać się strzelaniem z armaty do wróbla. Wszystko zależy jednak oczywiście od Twoich założeń biznesowych.

2) Kiedy DRC nic mi nie da? 

DRC nie uchroni Cię w sytuacji, kiedy infrastruktura podstawowa działa niestabilnie. Najpierw trzeba bowiem rozwiązać bieżące problemy z aplikacją/infrastrukturą, a dopiero potem próbować tworzyć na jej podstawie DRC. 

3) Kto już dziś powinien pomyśleć o DRC? 

W przypadku portali typu B2C (sklepy internetowe), gdzie wymagana jest wysoka dostępność, a każda minuta przestoju to realna utrata pieniędzy. Rozwiązanie DRC jest tutaj bardziej wymogiem niż opcją. 

Prowadzisz duży biznes e‑commerce? Chcesz dowiedzieć się więcej o Disaster Recovery Center?