Nadmiarowość, czy odtwarzanie po awarii?

Nadmiarowość, czy odtwarzanie po awarii?

Czym jest uptime i jak się to ma do czasu przestoju?  Ile dziewiątek po przecinku gwarantuje względny spokój, gdy mowa jest o wysokiej dostępności infrastruktury informatycznej? I na koniec, na co postawić: na nadmiarowość czy może na błyskawiczne odtwarzanie po awarii?

Czy wiesz jaki poziom dostępności mają Twoje systemy?  Najlepsze centra danych w Polsce (np.: Atman, Beyond, Exea, Polcom, T-mobile), mogą pochwalić się niezawodnością na poziomie 99,99%. Oznacza to, że ich przestój w skali roku nie przekroczy godziny. Zwracam jednak uwagę, że procenty dotyczą określonych usług. Już tłumaczę. Powiedzmy, że zdecydujemy się na usługę kolokacji, czyli wynajmujemy miejsce w szafach teletechnicznych w centrum danych. Usługodawca deklaruje cztery dziewiątki. Czy w związku z tym nasze środowisko także będzie miało dostępność na poziomie 99,99%? Najprawdopodobniej nie. Wysoka dostępność dotyczy systemów zbudowanych w centrum danych, w tym zasilania, łączności, klimatyzacji, itp. Wystarczy, że architektura naszego rozwiązania została zaprojektowana bez nadmiarowości. Czyli do szaf wynajętych w centrum danych włożymy pojedyncze urządzenia. Wówczas niestety, poziom dostępności naszego środowiska IT będzie równy poziomowi dostępności najsłabszego elementu.

Czas nieprzerwanej pracy systemów określany jako uptime, dotyczy każdego elementu infrastruktury IT. Projektując wysokodostępne środowisko IT należy eliminować pojedyncze punkty awarii. Robimy to dublując urządzenia z najniższym przeciętnym uptime. Właściwie, to robimy to dublując wszystko co się da 🙂 Jedyne odstępstwa dotyczą usług, których niedostępność nie zatrzymuje procesów krytycznych dla działalności operacyjnej. W ten sposób istotnie zmniejszamy ryzyko wystąpienia przestojów. Naturalnie, poszczególne systemy nie muszą mieć jednakowego poziomu dostępności. Ustalanie precyzyjnych wskaźników dla każdej usługi wpływa wprost na poziom nakładów na środowisko IT i na rodzaj i koszt Disaster recovery.

Wysoka dostępność (HA) jest pochodną nadmiarowości. Odtwarzanie awaryjne uznać powinniśmy za uzupełnienie HA, bo odpowiada na problemy, których nie rozwiąże nawet rozproszony geograficznie klaster wysokiej dostępności. Disaster recovery (np. DRaaS) to ostatnia deska ratunku, gdy nasze systemy padną ofiarą cyberataku lub co bardziej prawdopodobne, staną się niedostępne przez jakiegoś wirusa szyfrującego. Moje doświadczenia pokazują, że nadmiarowość i odtwarzanie po awarii, które według najlepszych praktyk ITIL powinny być komplementarne, bardzo często rozdziela tytułowe „czy”.

Darmowa konsultacja - anty.expert

IT Disaster Recovery Plan w wersji mini

IT Disaster Recovery Plan w wersji mini

Krótko i konkretnie o tym, co powinno się znaleźć w Planie Odtwarzania po awarii dla obszaru IT. Kto zmierzył się z tym tematem ten wie, że są atrakcyjniejsze formy spędzania czasu. Mimo wszystko, gdy się już go popełni, satysfakcja gwarantowana 😉 Jeśli zabieracie się za samodzielne opracowanie planu, być może ten artykuł pomoże Wam uporządkować myśli.

Dla porządku, IT Disaster Recovery Plan jest częścią Zarządzania Ciągłością Działania (Business Continuity Management – BCM), a dokładnie jest jednym z dokumentów Planu Ciągłości Działania. Celem BCM jest zapewnienie dostępności krytycznych procesów i zasobów nawet w sytuacji kryzysowej, a więc na przykład w trakcie awarii. BCM obejmuje wszelkie procesy i zasoby występujące w organizacji. Tymczasem Plan Odtwarzania po awarii skupia się na obszarze teleinformatycznym.

Jak każdy plan, wymaga formy pisemnej. Warto go mieć pod ręką. Co powinien zawierać IT Disaster Recovery Plan, wymieniam w kolejności:

  1. Analiza Ryzyk, czyli przed czym mamy się chronić. Podczas analizy proponuję skupić się na procesach krytycznych. Biznes musi wiedzieć też o pozostałych operacjach, które nie zostaną obsłużone w razie awarii. Pamiętajmy, że to zarząd ostatecznie zdecyduje, które procesy mamy podtrzymać.
  2. Analiza Wpływu na Biznes (BIA) skoro mamy już opisane zagrożenia, to teraz przypisujemy im oddziaływanie. Przyczyna – skutek – konsekwencje. Polecam tutaj proste tabelki i matrycę, która „wyostrza optykę”. Bardzo ważne to wyliczenia, np. koszty przestoju, utraconych korzyści, itd.
  3. Katalog usług i map zależności – to zadanie może być przykre, bo pisanie katalogu usług dla klienta wewnętrznego, gdy służyć ma tylko jednemu celowi, słabo się broni. Jak dla mnie, wystarczy przyłożyć każdy proces krytyczny do odpowiedniego systemu czy aplikacji i tak powstanie nam lista zasobów, które musimy podtrzymać podczas awarii.
  4. Parametryzacja RTO & RPO, czyli określamy dla każdego procesu oczekiwany czas odtworzenia oraz akceptowalny przez organizację poziom utraty danych. Namawiam, by „odczarować” akronimy.

Koniecznie trzeba zrobić przymiarkę, ile będzie kosztował przyjęty zakres ochrony. Jeśli poza podstawowymi procesami mamy chronić także coś więcej, koniecznie sprawdźmy czy to ekonomicznie uzasadnione. Znowu, niech zdecyduje biznes.

Według mnie to najważniejsze punkty IT Disaster Recovery Planu. Mniej znaczy więcej. Zawsze można coś dopisać 🙂

Darmowa konsultacja - anty.expert