Zawodna organizacja

Sprzęt, oprogramowanie i wynagrodzenie ludzi obsługujących centrum zapasowe i czuwających nad prawidłowym wykonywaniem kopii to nie wszystko. Koszty zabezpieczenia firmy na wypadek awarii nie kończą się na infrastrukturze - sięgają daleko w głąb organizacji. Nieodłącznym elementem umowy na świadczenie usług disaster recovery powinny być symulacje sytuacji awaryjnych i "ćwiczeniowe" odtwarzanie środowiska informatycznego. Przeprowadzenie pierwszej próby pozwala zweryfikować poprawność scenariusza postępowania w razie awarii. Kolejne próby służą sprawdzeniu prawidłowości wprowadzania zmian w systemie zapasowym, odzwierciedlających ewolucję systemu podstawowego.

Przygotowanie symulacji wymaga wymyślenia scenariusza awarii (np. zalanie serwerowni, w wyniku którego ulega całkowitemu zniszczeniu pięć serwerów obsługujących m.in. system transakcyjny banku, system gospodarki własnej i pocztę elektroniczną) i porcji danych pozwalających sprawdzić poprawność odtworzenia w centrum zapasowym i poprawność powrotu do centrum podstawowego. Wymaga też zaangażowania w dniu wolnym od pracy "zespołu katastrofalnego", czyli wszystkich pracowników, którzy zgodnie z procedurami odpowiedzialni są za odtworzenie systemów.

Biorąc pod uwagę wszystkie koszty, firmy zazwyczaj niechętnie przeprowadzają takie symulacje, bo jest to kłopotliwe i zawsze niesie ze sobą ryzyko, że "kontrolowana katastrofa" wymknie się spod kontroli, a firma znajdzie się w prawdziwych tarapatach, nie mogąc poradzić sobie np. z powrotem do systemu podstawowego. Jednak im rzadziej firma ma do czynienia z kontrolowanymi katastrofami, tym większe jest ryzyko, że nie poradzi sobie z prawdziwą. Innymi słowy, brak "manewrów" raz na jakiś czas podważa sensowność tworzenia całego - kosztownego - centrum zapasowego.

Przy pierwszej próbie odtworzenia prawie zawsze okazuje się, że procedury awaryjne zostały źle zaprojektowane. Brak uwag po pierwszej symulacji katastrofy i odtworzenia oznacza zazwyczaj złe przygotowanie symulacji. W czasie testów ujawniają się często ukryte zależności pomiędzy poszczególnymi działaniami podejmowanymi po awarii. Rozpoczęcie sekwencji działań na jednym serwerze może wymagać zakończenia innej sekwencji na drugim. Tym samym niemożliwe okazuje się założone wcześniej równoległe odtwarzanie systemów na dwóch serwerach, a faktyczny czas odtworzenia (RTO - patrz ramka) okazuje się znacznie dłuższy od zaplanowanego. Może się też okazać, że zaplanowano odtworzenie systemu A, ale nie zaplanowano odtworzenia systemu B, z którego napływają dane zasilające system A. Brak systemu B czyni system A bezużytecznym. Od strony technicznej wszystko - po wcześniejszej serii testów cząstkowych - zwykle działa poprawnie. Zazwyczaj zawodzi koncepcja i organizacja.

Kolejne symulacje pokażą wyraźnie, w jaki sposób firma zarządza zmianami. Jeśli firma ma uporządkowane procesy biznesowe i stosuje dobre praktyki, utrzymanie systemu disaster recovery będzie dla niej mniej finansowo i organizacyjnie odczuwalne niż dla firmy, która nie ma uporządkowanych procedur np. zarządzania zmianami i kontroli konfiguracji. Jeśli natomiast zarządzanie zmianami jest w powijakach, aktualizacja zasad archiwizacji i procedur odtwarzania może poważnie zaciążyć na firmowym budżecie.

Jak z tego wybrnąć?

Można próbować na samym początku, odpowiadając sobie na wiele pytań na etapie analizy ryzyka. Czy system disaster recovery ma chronić tylko przed awarią serwera, czy również przed pożarem, zalaniem czy eksplozją budynku, w którym ów serwer się znajduje? Czy chodzi tylko o ochronę danych, czy o stworzenie użytkownikom końcowym możliwości normalnej pracy na systemie alternatywnym? Jeśli nawet normalna praca w centrum zapasowym ma być możliwa, czy można zaakceptować spadek wydajności? Jaka utrata danych jest akceptowalna (a prawie zawsze większa lub mniejsza ilość danych jest tracona)? Czy faktycznie nasze przedsiębiorstwo jest lub musi być przedsiębiorstwem 24/7?

Jako najnowszy hit w dziedzinie obniżania kosztów, również centrum zapasowego, reklamowana jest wirtualizacja. Idea polega na tym, by infrastrukturę i aplikacje z centrum podstawowego można było odtworzyć na mniejszej liczbie fizycznych serwerów, przełączników itd. w centrum zapasowym. Wirtualizacja ogranicza wydajność, ale może zmniejszyć koszty, zwłaszcza że firma nigdy może się nie dowiedzieć, jak bardzo były one uzasadnione.