RTO, RPO i MTTR: definiowanie celów odtwarzania

Bez konkretnych, mierzalnych celów odtwarzania nie można zaprojektować odpowiednich strategii tworzenia kopii zapasowych, wybrać właściwego poziomu zapasowej lokalizacji DR ani ocenić, czy inwestycje w technologie odtwarzania są uzasadnione. RTO, RPO i MTTR przekładają wymagania biznesowe dotyczące dostępności na precyzyjne cele inżynieryjne. Miary te umożliwiają zespołom ds. bezpieczeństwa i IT prowadzenie z kadrą kierowniczą opartych na danych rozmów o kosztach przestoju w porównaniu z kosztami inwestycji w DR, dzięki czemu uzasadnienia biznesowe stają się konkretne, a nie abstrakcyjne.

Docelowy czas odtworzenia (RTO) to maksymalny akceptowalny czas od rozpoczęcia zakłócenia do przywrócenia normalnego działania usługi. Jeśli krytyczny system płatności ulegnie awarii o 10:00, a firma może tolerować najwyżej 2 godziny przestoju, zanim utrata przychodów stanie się nieakceptowalna lub dojdzie do naruszenia umów SLA, RTO wynosi 2 godziny — system musi zostać przywrócony najpóźniej do 12:00. RTO wpływa na wybór poziomu lokalizacji DR (hot site dla RTO wynoszącego 15 minut w porównaniu z cold site dla RTO wynoszącego 48 godzin), częstotliwość replikacji i automatyzację przełączania awaryjnego.

Docelowy punkt odtworzenia (RPO) to maksymalna akceptowalna utrata danych mierzona w czasie — określa, jaką utratę danych można tolerować w razie katastrofy. RPO wynoszące 1 godzinę oznacza, że po przywróceniu systemy muszą zawierać dane nie starsze niż 1 godzina względem momentu wystąpienia katastrofy. RPO wpływa na częstotliwość tworzenia kopii zapasowych: RPO wynoszące 1 godzinę wymaga co najmniej godzinnych kopii zapasowych (lub ciągłej replikacji). RPO wynoszące 4 godziny pozwala tolerować czterogodzinne odstępy między kopiami zapasowymi. RPO dotyczy odzyskiwania danych, a RTO — przywracania dostępności usługi.

RTO i RPO dotyczą różnych aspektów odtwarzania i należy je definiować niezależnie. System może mieć krótki RPO (1 godzina, czyli częsta replikacja danych), ale długi RTO (4 godziny, czyli czas potrzebny na uruchomienie środowiska DR, mimo że dane są aktualne). Z drugiej strony system może mieć długi RPO (24 godziny, ponieważ wystarczająca jest kopia tworzona co noc), ale krótki RTO (wymagane jest przełączenie w ciągu 1 godziny, więc środowisko DR musi być wcześniej przygotowane i gotowe do aktywacji). Obie miary wynikają z analizy wpływu na działalność.

Średni czas przywracania (MTTR) to średni rzeczywisty czas potrzebny na przywrócenie usługi po incydencie — operacyjna miara skuteczności odtwarzania. RTO to maksymalny tolerowany czas przestoju (cel lub wymaganie), natomiast MTTR to obserwowana średnia (rzeczywista wydajność). Organizacje mierzą MTTR dla incydentów w dłuższym okresie i porównują go z RTO, aby ocenić swoje możliwości odtwarzania. Stałe przekraczanie RTO przez MTTR oznacza, że możliwości DR są niewystarczające i konieczne są inwestycje w automatyzację, personel lub infrastrukturę.

Średni czas między awariami (MTBF) mierzy niezawodność systemu — średni czas działania systemu między awariami. Wyższy MTBF oznacza większą niezawodność. MTBF i MTTR razem określają procent dostępności systemu: Availability = MTBF / (MTBF + MTTR). System z MTBF wynoszącym 2000 godzin i MTTR wynoszącym 2 godziny ma dostępność 2000/2002 = 99,9%. Zrozumienie MTBF pomaga przewidywać prawdopodobieństwo awarii i odpowiednio planować okna konserwacyjne — sprzęt, którego MTBF spada, zbliża się do końca okresu eksploatacji i powinien zostać zawczasu wymieniony.

Maksymalny tolerowany czas przestoju (MTD) to absolutnie najdłuższy czas, przez jaki system może być niedostępny, zanim firma poniesie nieodwracalne szkody — utratę klientów, kary regulacyjne lub niemożność wywiązania się ze zobowiązań umownych. MTD jest zawsze większy lub równy RTO. Zależność jest następująca: MTD to granica biznesowa, a RTO to cel IT. Jeśli umowa dopuszcza czterogodzinne naruszenie SLA, po którym naliczane są kary, MTD może wynosić 4 godziny. Zespół IT projektuje system z RTO wynoszącym 1–2 godziny, aby zapewnić margines bezpieczeństwa przed osiągnięciem MTD.

Umowy o gwarantowanym poziomie świadczenia usług (SLA) określają zobowiązania umowne wobec klientów, które bezpośrednio wpływają na wymagania RTO i RPO. Umowa SLA dostawcy chmury gwarantująca dostępność na poziomie 99,95% pozwala na około 4,4 godziny przestoju rocznie. Naruszenie SLA uruchamia prawo do uzyskania rekompensaty w postaci kredytów na usługi lub do rozwiązania umowy. Wewnętrzne umowy SLA między działem IT a jednostkami biznesowymi działają podobnie. RTO i RPO należy zaprojektować tak, aby rzeczywisty czas przestoju mieścił się w zobowiązaniach SLA, a MTTR musi być mierzony i raportowany w celu wykazania zgodności.

Wybór technologii jest bezpośrednio uzależniony od wymagań RTO i RPO. RTO wynoszące 15 minut i zerowe RPO wymagają klastrowania active-active z synchroniczną replikacją — bez utraty danych i z automatycznym przełączaniem awaryjnym. RTO wynoszące 4 godziny i RPO wynoszące 1 godzinę pozwalają wykorzystać przesyłanie logów lub asynchroniczną replikację do warm standby. RTO wynoszące 24 godziny i RPO wynoszące 24 godziny pozwalają wykorzystać codzienne kopie zapasowe w pamięci masowej cold storage. Projektowanie większej odporności, niż jest wymagana, marnuje budżet, a projektowanie mniejszej odporności stwarza niedopuszczalne ryzyko biznesowe podczas incydentów.

Cele odtworzeniowe są ważne tylko wtedy, gdy są regularnie weryfikowane podczas testów. Organizacje powinny przeprowadzać testy odtwarzania, które mierzą rzeczywisty MTTR i weryfikują rzeczywisty punkt odzyskania danych (jak stare są dane w momencie przywrócenia?). Jeśli test wykaże, że MTTR wynosi stale 3 godziny przy RTO wynoszącym 1 godzinę, należy zlikwidować tę lukę — albo przez usprawnienie infrastruktury DR (automatyzację, wstępne przygotowanie zasobów), albo przez zmianę oczekiwań biznesowych na podstawie zaktualizowanej analizy BIA. Częstotliwość testów powinna odpowiadać krytyczności systemów: systemy krytyczne należy testować co kwartał, a pozostałe raz w roku.

Raporty dotyczące RTO, RPO i MTTR należy przekazywać interesariuszom biznesowym w zrozumiały dla nich sposób. Zamiast mówić: „Nasz MTTR dla systemów poziomu 1 wynosi 47 minut”, należy powiedzieć: „Gdy ulegają awarii nasze najważniejsze systemy, średnio przywracamy usługę w czasie krótszym niż godzina — mieści się to w dwugodzinnym oknie dopuszczonym przez nasze umowy”. Regularne raportowanie buduje zaufanie interesariuszy i pomaga wypracować wspólne rozumienie poziomu odporności organizacji. Raportowanie trendów MTTR na pulpitach na przestrzeni czasu pokazuje poprawę programu i uzasadnia budżet przeznaczany na inwestycje w DR.

Sprawdź swoją wiedzę na temat zagadnień CompTIA Security+ (SY0-701) omówionych w tej lekcji.

W tej lekcji dowiedzieli się Państwo, że: RTO to maksymalny czas, przez jaki usługa może być niedostępna, który wyznacza wymagania dotyczące szybkości przełączania awaryjnego; RPO to maksymalna dopuszczalna utrata danych, która określa częstotliwość tworzenia kopii zapasowych i replikacji; natomiast MTTR to zmierzony rzeczywisty średni czas odtwarzania, który porównuje się z RTO w celu oceny skuteczności programu DR. W następnej części omówimy strategie tworzenia kopii zapasowych — regułę 3-2-1 oraz niezmienne kopie zapasowe, których ransomware nie może zniszczyć.