Dwa pytania, od których trzeba zacząć
Rozmowa o zabezpieczeniu firmy przed awarią prawie zawsze zaczyna się od narzędzi. Ktoś pyta o oprogramowanie do kopii, ktoś inny o macierz albo o chmurę. To zła kolejność. Bez dwóch decyzji biznesowych nie da się ocenić, czy jakiekolwiek narzędzie jest właściwe, ani ile powinno kosztować.
Warto od razu rozdzielić trzy rzeczy, które w rozmowach zwykle zlewają się w jedno. Backup to kopia danych i ratuje po skasowanym pliku albo po awarii dysku. Disaster recovery to powrót do pracy po utracie całego środowiska, na przykład po pożarze, zalaniu albo zaszyfrowaniu serwerów przez atak. Plan ciągłości działania jest jeszcze szerszy, bo mówi także o tym, jak firma pracuje w czasie, gdy systemy nie wróciły.
Te decyzje to odpowiedzi na dwa pytania. Ile godzin firma wytrzyma bez konkretnego systemu i ile ostatniej pracy może stracić. Pierwsza liczba nazywa się RTO, druga RPO. Skróty brzmią technicznie, ale odpowiedzi nie zna administrator. Zna je osoba, która wie, co się dzieje w firmie, kiedy zamówienia przestają wchodzić.
Dopiero z tych dwóch liczb wynika reszta: jak często robić kopie, gdzie je trzymać, czy potrzebne jest środowisko zapasowe i jaki budżet ma tu sens. Odwrotna kolejność kończy się drogim rozwiązaniem, które i tak nie spełnia oczekiwań, albo tanim, o którym wszyscy zakładają, że wystarczy.
RTO, czyli ile godzin firma wytrzyma bez systemu
RTO to skrót od Recovery Time Objective. Amerykański NIST w swoim przewodniku planowania awaryjnego opisuje je jako czas, w którym system może pozostawać w fazie odtwarzania, zanim zacznie to szkodzić działaniu organizacji. Mówiąc prościej, chodzi o to, ile godzin dany system może nie działać, żeby firma jeszcze to zniosła.
Najczęstszy błąd polega na szukaniu jednej liczby dla całej firmy. RTO ustala się osobno dla każdego systemu. Sklep bez systemu sprzedaży nie pracuje w ogóle. Archiwum dokumentów z poprzednich lat może być niedostępne przez dwa dni i nikt tego nie zauważy. Te dwa przypadki nie mogą mieć tego samego zabezpieczenia, bo przy jednym z nich byłoby to wyrzucanie pieniędzy.
Druga pułapka to liczenie samego odtwarzania. RTO nie zaczyna się w chwili, gdy ktoś klika przywracanie danych. Zaczyna się w momencie awarii i obejmuje wszystko, co jest po drodze: zauważenie problemu, decyzję o uruchomieniu planu, dostęp do sprzętu, odtworzenie, sprawdzenie poprawności danych i wpuszczenie ludzi z powrotem do pracy. Jeżeli nikt nie pełni dyżuru w weekend, do RTO trzeba doliczyć także czas do poniedziałku.
Trzeba też pamiętać, że system nie pracuje sam. Aplikacja potrzebuje bazy danych, uwierzytelniania, sieci, a często również wymiany danych z księgowością albo z magazynem. RTO obejmuje całą tę drogę, więc realną liczbą jest czas powrotu najsłabszego ogniwa, a nie czas odtworzenia samej aplikacji.
RPO, czyli ile pracy wolno stracić
RPO to Recovery Point Objective. NIST definiuje je jako punkt w czasie, do którego dane muszą zostać odtworzone po awarii. W praktyce to odpowiedź na jedno pytanie. Jak daleko w przeszłość firma cofnie się po awarii.
Widać to najlepiej na zegarku. Jeżeli kopia powstaje raz na dobę o drugiej w nocy, a serwer przestaje działać o szesnastej, to znika czternaście godzin pracy. Nie chodzi o abstrakcyjne dane. Chodzi o zamówienia przyjęte tego dnia, wystawione faktury, notatki z rozmów z klientami i zmiany w plikach, nad którymi pracował cały zespół.
Część tej pracy da się odtworzyć z pamięci i z papieru. Część nie wróci nigdy, bo nikt nie pamięta, co dokładnie powiedział klient przez telefon. Dlatego RPO warto ustalać razem z osobami, które wprowadzają dane, a nie tylko z zarządem. To one wiedzą, ile trwa ponowne wpisanie jednego dnia pracy.
RPO, podobnie jak RTO, jest różne dla różnych systemów. Baza z zamówieniami i folder ze zdjęciami z firmowego pikniku nie potrzebują tej samej częstotliwości kopii.
Prosty przykład, na którym widać koszt
Weźmy firmę, która przyjmuje zamówienia przez własny system. Pracuje w nim dwadzieścia osób, a po każdym zamówieniu idzie wysyłka i faktura. Zarząd ustala, że RPO wynosi godzinę, a RTO cztery godziny. Zobaczmy, co z tego wynika.
Z RPO wynika częstotliwość kopii i sposób ich robienia. Kopia raz na dobę tego nie spełni, bo dopuszcza utratę całego dnia. Kopia co godzinę oznacza inny sposób pracy z bazą danych, więcej miejsca na dyskach i większe obciążenie łącza, jeżeli dane wychodzą poza firmę. Zejście do kilku minut zwykle wymaga już replikacji, czyli drugiej kopii systemu utrzymywanej na bieżąco. Każdy z tych trzech wariantów kosztuje inaczej i każdy wymaga innej pracy przy utrzymaniu.
Z RTO wynika, na czym te dane zostaną uruchomione. Cztery godziny to za mało, żeby czekać na dostawę serwera i instalować system od zera. Trzeba więc mieć gdzie wystartować, czyli wolne zasoby na istniejącym wirtualizatorze, maszynę zapasową albo przygotowane wcześniej środowisko w chmurze. To jest ta część rachunku, o której zwykle nikt nie myśli, bo kojarzy się z backupem, a jest zwykłym kosztem sprzętu i miejsca.
Zmiana jednej z tych liczb zmienia rozwiązanie i cenę. RTO na poziomie doby daje spokojne odtworzenie na nowym sprzęcie. RTO na poziomie godziny prawie zawsze oznacza drugie środowisko gotowe do przejęcia pracy. Uczciwe pytanie nie brzmi więc, które rozwiązanie jest najlepsze, tylko której liczby firma naprawdę potrzebuje.
Najczęstszy błąd, czyli RTO ustalone bez rachunku
Prawie każdy zapytany, jak szybko system ma wrócić, odpowiada, że natychmiast. To zrozumiałe i zupełnie bezużyteczne, bo natychmiast jest najdroższą odpowiedzią, jaka istnieje. Zamiast tego warto policzyć jedną rzecz. Ile firma traci na godzinie przestoju.
Do rachunku wchodzi kilka pozycji:
- liczba osób, które w tym czasie nie pracują, i koszt ich godziny
- to, czego nie da się w tym czasie sprzedać, wydać z magazynu ani zafakturować
- praca, którą trzeba będzie nadgonić później, razem z nadgodzinami
- terminy i kary umowne, które w tym czasie przepadają
- koszt rozmów z klientami, którzy usłyszeli, że system nie działa
Wynik nie musi być dokładny. Wystarczy rzetelne przybliżenie, żeby zestawić je z kosztem rozwiązania. To jest sens analizy wpływu na biznes, którą NIST opisuje jako badanie funkcji operacyjnych i skutków, jakie miałaby dla nich przerwa w działaniu.
Efekt takiego rachunku często zaskakuje w drugą stronę. Przy części systemów wychodzi, że dwa dni przestoju firma zniesie bez większej szkody. To bardzo dobra wiadomość, bo uwalnia pieniądze na ten jeden system, który musi wrócić w godzinę.
Backup to jeszcze nie plan ciągłości działania
Backup jest kopią danych. Plan ciągłości działania to zdolność do pracy po awarii. Różnica między jednym a drugim to kilka rzeczy, których samo oprogramowanie do kopii nie dostarczy.
Do kopii trzeba dołożyć co najmniej to:
- środowisko, na którym te dane w ogóle da się uruchomić, czyli wolne zasoby, sprzęt zapasowy albo przygotowane miejsce w chmurze
- kolejność przywracania usług, bo aplikacja odtworzona przed bazą danych i przed uwierzytelnianiem po prostu nie wstanie
- ludzi i procedurę, czyli kto stwierdza awarię, kto podejmuje decyzję i kto do kogo dzwoni
- łączność i zdalny dostęp, jeżeli ludzie mają pracować z innego miejsca niż zwykle
- test, czyli próbne odtworzenie z pomiarem czasu, a nie sam raport, że kopia się wykonała
Ta lista nie jest wymysłem. Przewodnik planowania awaryjnego NIST układa plan dokładnie z takich elementów, od analizy wpływu na biznes, przez wybór lokalizacji zapasowej i podział odpowiedzialności, aż po testy i szkolenie osób, które mają ten plan wykonać.
Ostatni punkt jest najważniejszy i najczęściej pomijany. Kopia, której nigdy nie odtworzono, jest tylko założeniem. Próbne odtworzenie jako jedyne pokazuje, ile to naprawdę trwa. Najłatwiej wychodzą przy nim braki, których nie widzi żaden raport z wykonanej kopii, na przykład zależność od innego systemu albo hasło, którego nikt już nie pamięta.
Jak sprawdzić, czy plan istnieje naprawdę
Jest kilka pytań, które szybko pokazują stan rzeczy. Można je zadać własnemu działowi IT albo firmie, która obsługuje infrastrukturę:
- kiedy ostatnio odtworzono dane z kopii i ile to zajęło
- na czym zostały odtworzone, bo przywrócenie pliku na ten sam serwer niczego nie sprawdza
- jakie RTO i RPO ma każdy system, bez którego firma nie pracuje
- czy istnieje kopia, do której nie ma dostępu z firmowej sieci
- kto podejmuje decyzję o uruchomieniu planu w niedzielę o piątej rano
Jeżeli odpowiedzi brzmią, że kopie się wykonują i że jest na to monitoring, to firma ma backup. Nie ma jeszcze planu. To nie zarzut wobec nikogo, tylko informacja, ile pracy zostało do zrobienia.
W C4PL testy odtworzenia danych prowadzimy realnie, nie kończymy na wdrożeniu i utrzymaniu kopii. Zakres wsparcia, w tym dyżur całodobowy, ustalamy w umowie, bo od niego zależy, ile realnie może wynosić RTO w nocy i w weekend.
Od czego zacząć
Nie od narzędzi. Najpierw powstaje lista systemów, bez których firma nie pracuje. Zwykle jest krótsza, niż się wydaje. Przy każdym z nich wpisuje się dwie liczby i jedno zdanie o tym, co się dzieje, kiedy ten system stoi.
Do wypełnienia takiej tabeli nie potrzeba audytu. Wystarczy jedno spotkanie z osobami odpowiedzialnymi za sprzedaż, produkcję, magazyn i księgowość. Techniczna część zaczyna się dopiero potem i jest wtedy znacznie prostsza, bo wiadomo, co ma być spełnione.
Kiedy obie liczby są ustalone, warto je zapisać. Dopóki RTO i RPO żyją tylko w rozmowie, są życzeniem. Wpisane do umowy z firmą, która utrzymuje infrastrukturę, stają się zobowiązaniem i dopiero wtedy da się do nich dobrać czas reakcji oraz zakres dyżuru.
Jeżeli chcesz przejść przez to z kimś, kto testy odtworzenia robi w praktyce, zadzwoń pod +48 662 036 615 albo napisz na [email protected]. Rozmowa o dwóch liczbach zajmuje kwadrans i zwykle od razu pokazuje, gdzie jest największa dziura.