RTO i RPO w praktyce – jak ograniczyć skutki awarii infrastruktury IT?

RTO określa dopuszczalny czas niedostępności

Recovery Time Objective odpowiada na pytanie: jak szybko system musi zostać ponownie uruchomiony po awarii?

Czas ten powinien obejmować nie tylko odtworzenie serwera, ale również uruchomienie aplikacji, sprawdzenie poprawności danych, przywrócenie integracji i udostępnienie systemu użytkownikom.

Jeżeli firma ustali RTO na poziomie dwóch godzin, infrastruktura i procedury muszą umożliwiać powrót do normalnej pracy w tym czasie. Samo posiadanie kopii zapasowej nie wystarczy, jeśli jej odtworzenie zajmuje cały dzień.

Na wartość RTO wpływają przede wszystkim:

• znaczenie systemu dla działalności firmy,
• koszt każdej godziny przestoju,
• liczba użytkowników aplikacji,
• zależności od innych systemów,
• dostępność infrastruktury zapasowej,
• czas potrzebny na podjęcie decyzji i rozpoczęcie procedury.

Im krótsze RTO, tym bardziej rozbudowane rozwiązania mogą być potrzebne. Przy krytycznych systemach samo przechowywanie backupu może być niewystarczające. Konieczna może być replikacja środowiska i możliwość szybkiego uruchomienia go w drugiej lokalizacji.

RPO wskazuje możliwą utratę danych

Recovery Point Objective określa, do jakiego momentu muszą zostać odtworzone dane. Parametr jest związany z częstotliwością wykonywania kopii lub replikacji danych.

Jeżeli kopia zapasowa powstaje raz na dobę, awaria może spowodować utratę zmian wykonanych od czasu ostatniego backupu. W przypadku systemu, w którym każdego dnia zapisywanych jest tysiące transakcji, taka strata może być trudna do zaakceptowania.

Wartość RPO należy dopasować do charakteru danych:

• dla statycznej strony internetowej dopuszczalna strata może obejmować wiele godzin,
• dla systemu dokumentowego może wynosić godzinę,
• dla platformy sprzedażowej może wymagać znacznie częstszej replikacji,
• dla systemu transakcyjnego utrata nawet kilku minut danych może być poważnym problemem.

NIST opisuje RPO jako punkt w czasie, do którego dane powinny zostać odzyskane po zakłóceniu działania systemu.

RTO i RPO nie oznaczają tego samego

Parametry są ze sobą powiązane, ale odpowiadają na dwa różne rodzaje ryzyka.

RTO dotyczy czasu niedostępności. RPO dotyczy utraty danych.

System może zostać uruchomiony bardzo szybko, ale na podstawie kopii sprzed kilku godzin. W takim przypadku RTO będzie krótkie, lecz RPO pozostanie długie. Możliwa jest też sytuacja odwrotna: dane są replikowane niemal na bieżąco, ale uruchomienie całego środowiska zapasowego trwa wiele godzin.

Dlatego przy RTO i RPO należy jednocześnie ustalić:

1. ile czasu firma może działać bez systemu,
2. ile danych może utracić,
3. jakie będą skutki biznesowe obu zdarzeń,
4. jakie rozwiązania techniczne pozwolą osiągnąć założone wartości.

Nie należy wpisywać identycznych parametrów dla wszystkich aplikacji tylko dlatego, że upraszcza to dokumentację. Systemy krytyczne powinny mieć bardziej restrykcyjne wymagania, natomiast mniej istotne aplikacje mogą być odtwarzane później.

Jak wyznaczyć właściwe wartości?

Punktem wyjścia powinna być analiza wpływu awarii na działalność przedsiębiorstwa. W ustalaniu parametrów powinni uczestniczyć nie tylko administratorzy, ale również właściciele procesów biznesowych.

Dział IT może wiedzieć, ile czasu zajmuje odtworzenie maszyny wirtualnej. Dział sprzedaży powinien jednak określić, jakie będą skutki niedostępności systemu obsługującego zamówienia.

Dla każdego systemu warto ustalić:

• jakie procesy zależą od jego działania,
• ilu pracowników lub klientów z niego korzysta,
• czy można czasowo wykonywać pracę w inny sposób,
• ile kosztuje godzina przestoju,
• jakie dane powstają w ciągu godziny,
• czy utracone informacje można odtworzyć ręcznie,
• jakie są wymagania prawne i umowne,
• od jakich innych aplikacji zależy uruchomienie systemu.

Na tej podstawie można podzielić aplikacje na poziomy krytyczności. Systemy najważniejsze są uruchamiane w pierwszej kolejności, a mniej istotne dopiero po przywróceniu podstawowych procesów.

Backup nie zastępuje planu Disaster Recovery

Kopie zapasowe są niezbędnym elementem ochrony danych, ale nie stanowią całego planu odtwarzania działalności. Backup odpowiada przede wszystkim na potrzebę zachowania informacji. Disaster Recovery obejmuje również infrastrukturę, procedury, ludzi i kolejność przywracania poszczególnych usług.

Firma może posiadać poprawną kopię bazy danych, ale nadal nie mieć:

• serwera, na którym można ją odtworzyć,
• odpowiednich licencji,
• dostępu do konfiguracji aplikacji,
• zapasowej łączności,
• procedury przełączenia użytkowników,
• osoby uprawnionej do podjęcia decyzji.

Dlatego disaster recovery powinno obejmować gotowy scenariusz postępowania, środowisko zapasowe i regularne testy. NIST definiuje planowanie awaryjne jako skoordynowane połączenie procedur i środków technicznych umożliwiających odzyskanie systemów, procesów i danych po zakłóceniu.

Jak technicznie osiąga się krótkie RTO i RPO?

Dobór rozwiązania zależy od przyjętych parametrów. Im mniejsza tolerancja na przestój i utratę danych, tym częściej potrzebna jest automatyzacja oraz infrastruktura działająca w drugiej lokalizacji.

Stosowane mechanizmy mogą obejmować:

• regularne kopie zapasowe,
• replikację baz danych,
• replikację maszyn wirtualnych,
• zapasowe łącza internetowe,
• drugie centrum danych,
• automatyczne przełączanie usług,
• gotowe środowiska zapasowe,
• dodatkowe stanowiska pracy dla personelu.

Nie każda organizacja potrzebuje wszystkich tych elementów. Dla mniej istotnej aplikacji wystarczające może być odtworzenie systemu z kopii w ciągu kilkunastu godzin. Krytyczne środowisko produkcyjne może natomiast wymagać synchronizacji danych i możliwości szybkiego przełączenia do ośrodka zapasowego.

Polcom realizuje usługi Disaster Recovery w oparciu o własne centra danych w Skawinie i Alwerni. Rozwiązanie może obejmować zapasowe centrum danych, procedury bezpieczeństwa oraz możliwość przełączenia kluczowych systemów do drugiego ośrodka.

Testy są równie ważne jak dokumentacja

Plan, którego nigdy nie sprawdzono, może nie zadziałać w rzeczywistej sytuacji. Od ostatniego testu mogły zmienić się aplikacje, adresy sieciowe, osoby odpowiedzialne za procedurę albo zależności między systemami.

Test powinien zweryfikować:

• czas wykrycia awarii,
• sposób podjęcia decyzji o przełączeniu,
• dostępność kopii i replik,
• czas uruchomienia środowiska zapasowego,
• działanie aplikacji i integracji,
• dostęp użytkowników,
• zgodność wyniku z ustalonym RTO i RPO.

Po każdym teście należy opisać napotkane problemy i poprawić procedury. Dokumentacja powinna być aktualizowana również po większych zmianach infrastruktury, wdrożeniu nowych systemów lub zmianach organizacyjnych.

Ciągłość działania wymaga spojrzenia biznesowego

Dobre planowanie ciągłości działania IT nie polega na ustaleniu jak najkrótszego RTO i RPO dla każdego systemu. Takie podejście byłoby kosztowne i często nieuzasadnione.

Najpierw należy wskazać procesy, których zatrzymanie spowoduje największe straty. Następnie trzeba określić dopuszczalny czas przestoju i utraty danych oraz dobrać rozwiązania techniczne umożliwiające osiągnięcie tych parametrów.

RTO i RPO łączą oczekiwania biznesu z możliwościami infrastruktury IT. Pozwalają ustalić kolejność odtwarzania systemów, dobrać częstotliwość tworzenia kopii i ocenić, czy potrzebne jest zapasowe centrum danych.

Najważniejsze jest jednak to, aby wartości nie pozostawały wyłącznie zapisami w dokumentacji. Muszą być poparte działającą technologią, przypisanymi odpowiedzialnościami i regularnie testowanym planem.