W ramach najbardziej zaawansowanego (z serii kursów dotyczących systemów sieciowych NetWare) novellowego kursu 801 Service & Support w sekcji ''Optymalizacja i odtwarzanie systemu po katastrofie'' prezentuje się transparencję wymieniającą trzy najważniejsze elementy w odtwarzaniu systemu po katastrofie:

- dobra kopia zapasowa;

- dobra kopia zapasowa;

- dobra kopia zapasowa.

Taka transparencja ma swoje zalety - zazwyczaj wybuch śmiechu czytających powoduje przebudzenie pozostałych. Ma też, niestety, bardzo poważną wadę - utrwala błędne przekonanie o elementach niezbędnych przy odtwarzaniu danych, gdyż mówi tylko o jednym elemencie za to trzykrotnie wymienionym, co zwiększa jeszcze jego znaczenie. Nie chcę tu powiedzieć, że archiwizacja jest nieistotna. Na temat dobrego systemu archiwizacji pisałem w numerach 39/211 i 40/212 Computerworlda. Jednakże oprócz archiwizacji konieczne są jeszcze inne elementy. Konieczne, ale niewystarczające, jak w założeniach niektórych twierdzeń matematycznych. Najważniejszy warunek to ten, który nie jest spełniony. W takim razie jakie są te pozostałe warunki konieczne, ale niewystarczające? Czy coś jeszcze jest w ogóle potrzebne? Tak, sama archiwizacja to za mało.

Co się stanie, gdy uszkodzeniu ulegnie system, na którym było zainstalowane oprogramowanie do archiwizacji? Wystarczy wtedy po prostu najpierw odtworzyć system archiwizacji, a potem odtworzyć zarchiwizowane dane. Oczywiście, ale jeśli system zainstalowano kilka lat temu to czy wiemy, gdzie teraz znajdują się dyskietki instalacyjne? A gdzie jest dokumentacja do oprogramowania?

Nawet jeśli osoba, która zainstalowała to oprogramowanie, jest ciągle naszym współpracownikiem to może już nie pamiętać jak to kiedyś zrobiła - teraz zajmuje się już całkiem innymi sprawami.

Aktualna dokumentacja

Zatem na pewno potrzebna jest dokumentacja i to nie tylko dokumentacja oprogramowania do archiwizacji. Jeśli uszkodzeniu uległ streamer, to po zakupie nowego trzeba go skonfigurować tak samo jak stary. Wystarczy obejrzeć stary streamer i ustawić wszystkie parametry nowego identycznie? A jeśli paramtery ustawia się programowo? A co, w przypadku kradzieży starego streamera? Jak zobaczymy jego ustawienia? Przy innych parametrach program do archiwizacji (odtwarzania) może nie pracować lub ponowna jego konfiguracja zajmie bardzo dużo czasu.

Potrzebna jest zatem również dokumentacja sprzętu. Całego sprzętu a nie tylko streamera, gdyż uszkodzeniu może ulec każdy element naszego systemu. I nie chodzi tu tylko o sprzęt obsługujący urządzenia do archiwizacji, ale wszystkie urządzenia, które chcemy objąć ochroną. Jak odtworzymy dane na dysk, którego nie potrafimy prawidłowo skonfigurować? Jak prześlemy dane po sieci jeśli karta sieciowa na stacji nie współpracuje prawidłowo?

Taka dokumentacja sprzętowa będzie też przydatna w szybkim przywróceniu systemu do pracy, gdy awarii ulegnie element, który nie jest bezpośrednio związany z danymi, np. karta sieciowa, karta wideo, drukarka, CD-ROM itp. To że potrzebna jest dokumentacja konfiguracji oprogramowania nie ulega chyba wątpliwości. Pisząc "konfiguracja oprogramowania" mam na myśli również parametry systemu operacyjnego. Mając taką pełną dokumentację możemy szybko przywrócić system do działania nawet po katastrofie: pożarze, kradzieży (!), zalaniu wodą, trzęsieniu ziemi (to może nie u nas) itp.

Firma ubezpieczeniowa zwróci nam pieniądze za sprzęt, ale nie zapłaci za czas stracony na ponowną specyfikację zakupów, konfigurację sprzętową i programową. W takim przypadku oba typy dokumentacji są niezbędne, a ważniejszy okaże się ten, którego akurat brakuje.

Aktualność dokumentacji

Jeszcze jedna uwaga: dokumentacja musi być aktualna! Co z tego, że mamy dokumentację, jeśli w międzyczasie nastąpiło kilkanaście zmian w konfiguracji? Taka dokumentacja jest chyba gorsza od całkowitego jej braku. A więc co: biegać z dokumentacją przy wprowadzeniu każdej zmiany? Nie, byłoby to niewygodne i często bezsensowne. Zmiana którą wprowadziliśmy po kilku dniach może okazać się zmianą na gorsze i trzeba przywrócić stan poprzedni.

Trzeba zatem ustalić pewien harmonogram kontroli aktualności dokumentacji, np. sprawdzać dokumentację ze stanem faktycznym raz na miesiąc i notować wszystkie zmiany (podając przyczynę zmian) nie niszcząc zapisów o poprzedniej konfiguracji. To że nowa konfiguracja jest gorsza od starej może się okazać dopiero po dłuższym czasie.

Ktoś może powiedzieć, że takie wymagania są nierealne: administrator systemu ma sporo innych zajęć, a jeśli ma pod opieką kilkadziesiąt stanowisk to sama aktualizacja dokumentacji może mu wypełnić cały czas, nie wspominając o czasie koniecznym na jej sporządzenie. To prawda, że w dużych sieciach jest to czynność pracochłonna i niewdzięczna, gdyż często nie wymagająca wielkiej wiedzy. Ale nikt nie utrzymuje, że powinno się ją wykonywać "ręcznie". Istnieją systemy wspomagające, pozwalające częściowo ten proces zautomatyzować (przynajmniej jeśli chodzi o elementy sieciowe). Poza tym, administrator nie musi robić wszystkiego osobiście - może znaleźć i wykształcić współpracowników wykonujących część zadań. Osoby potrafiące (każda przynajmniej częściowo) zastąpić administratora są niezbędne w każdym środowisku na wypadek jego nieobecności (urlop, choroba, wypadek, nagłe odejście z pracy).

Czas potrzebny na sporządzenie dokumentacji może skrócić unifikacja systemu.

Jeśli wszystkie stacje robocze są identyczne, pracują z tym samym oprogramowaniem, w takiej samej konfiguracji, to dokumentacja kilkudziesięciu stanowisk zajmie niewiele więcej czasu niż dokumentacja jednego z nich. Łatwiej jest wtedy także utrzymać magazyn części zamiennych: wystarczy po jednym egzemplarzu każdego z elementów. Odtworzenie jednego stanowiska po awarii trwa wtedy wyjątkowo krótko.

Schemat podziału odpowiedzialności

Kolejnym elementem koniecznym dla uchronienia systemu przed totalną katastrofą jest więc podział zadań między różne osoby. Trzeba tu zaznaczyć, że w momencie przydzielania zadania do wykonania musi być jasno sformułowany zakres odpowiedzialności osoby przejmującej zadanie. Zwykle oznacza to również jej pełną kontrolę nad powierzonym zadaniem -administrator pełni tylko rolę konsultanta - w przeciwnym wypadku odpowiedzialność się rozmywa. Pamiętajmy, że taka osoba wypełniająca jedno z zadań (archiwizacja, dokumentacja sprzętowa, dokumentacja oprogramowania, magazyn części zamiennych itp.) powinna zadbać również o swoje zastępstwo na wypadek urlopu, choroby itp.

W ramach tej odpowiedzialności musi również wziąć pod uwagę konieczność zduplikowania niektórych elementów. Co z tego, że archiwizacja była starannie przeprowadzana, jeśli wszystkie taśmy spłonęły razem z budynkiem? To samo dotyczy dokumentacji, części zamiennych.

Wszystkie te elementy powinny być opisane: kto czym się zajmuje, kto go zastępuje, gdzie (w dwóch miejscach) przechowywane są wyniki jego pracy.

Czy to znowu nie są pobożne życzenia? Przecież nawet jeśli administrator znajdzie kogoś do pełnienia niektórych obowiązków, to już zastępca tej osoby będzie mniej kwalifikowany (dlatego właśnie jest tylko zastępcą). Kiedy znaleźć czas na kształcenie tych ludzi.

A jeśli tzw. ruchomość kadr jest duża? Cały czas administratora pochłoną kolejne szkolenia. To może już lepiej niech administrator sam wszystko robi. Ale to już przerabialiśmy: on sam nie da rady. Jakie wobec tego jest wyjście z tej sytuacji?

Opisane procedury

Najlepszym sposobem uniknięcia szkolenia kolejnych pokoleń zastępców administratora jest opisanie czynności niezbędnych do wykonania zadania. Tak przygotowany opis administrator wręcza wybranemu zastępcy i zostawia go samego. Po wykonaniu przez niego zadania sprawdza jakość wykonanej pracy (ten obowiązek będzie zawsze spoczywał na administratorze) i prosi o uwagi do opisu procedury. Jeśli jakieś elementy były niezrozumiałe - wprowadza poprawki do opisu. W ten sposób czas szkolenia ogranicza do minimum, a po kolejnych poprawkach opisu procedurę może wykonać dowolna inna osoba. Opisanie procedur będzie przydatne również, gdy wszystkie czynności administrator wykonuje osobiście. Okażą się bezcenne, gdy administrator zachoruje, będzie na urlopie, zechce zmienić pracę, ale przydadzą się także administratorowi - w przypadku rzadko wykonywanych procedur łatwo zapomnieć nawet o istotnych elementach.

Oprócz opisu różnych procedur konieczne jest sporządzenie harmonogramu ich wykonywania: jak często, z jakim stopniem szczegółowości powinny być one przeprowadzane. Wykonanie czynności przewidzianych opisem powinno być każdorazowo poświadczane datą i podpisem osoby wykonującej. W ten sposób mamy dokumentację działania naszego systemu ochrony i możemy oszacować jak bardzo jest on czasochłonny.

Po co nam takie szacunki? Po to żeby zachować umiar. Nie byłoby chyba rozsądnie, gdyby wszyscy pracownicy 8 godzin dziennie przez pięć dni w tygodniu zajmowali się działalnością związaną z ochroną systemu przed katastrofą. Czy warto wtedy taki system, na którym de facto nikt nie pracuje, chronić?

Dotykamy tutaj problemu podstawowego: co powinno być chronione i w jakim stopniu? Na to pytanie nie ma jednoznacznej odpowiedzi. Zależy to od środków (ile pieniędzy, ile osób, ile czasu firma może na to poświęcić?) oraz od potrzeb (jaki czas po awarii firma może przetrwać bez funcjonującego systemu?).

Pierwszy z tych elementów oszacować łatwo: wystarczy porozmawiać z szefem. Przy drugim sprawa jest znacznie trudniejsza: polecana metoda to oszacowanie strat jakie firma poniesie, gdy system komputerowy nie będzie działał przez określony czas. Często z tego szacunku wynika, że warto zmienić nieco pogląd na to jakie środki jesteśmy skłonni zaangażować w ochronę naszego systemu.

Pomijam tutaj oczywistą sprawę ustalenia różnych priorytetów dla elementów bardziej istotnych w naszym systemie (serwery, hosty, elementy archiwizujące) oraz mniej istotnych (stacje robocze, drukarki itp.).

Symulacja katastrof

Praktyka wskazuje, że nawet najlepsi administratorzy, pracujący zgodnie z podanym wyżej sposobem, nie są w stanie przewidzieć wszystkiego co jest niezbędne do odtworzenia systemu w zadanym czasie. Co wobec tego robić? Czy nie ma ratunku? Po co w takim razie robić cokolwiek skoro nie ma pewności, że zapewni to bezpieczeństwo? Rzeczywiście, pewności nie ma się nigdy, ale za to stwarza się większe prawdopodobieństwo, że w razie katastrofy sobie poradzimy. Stuprocentowej pewności nie będziemy mieli nigdy: podobno "nie ma na tym świecie nic pewnego, a nawet i to nie jest do końca pewne". Natomiast możemy dążyć do zwiększenia prawdopodobieństwa, że nasza zapobiegliwość doprowadzi do sukcesu. Jak? Trzeba co pewien czas symulować awarie, a jeszcze lepiej całe katastrofy. Wyobraźmy więc sobie, że ukradziono nam np. serwer ze streamerem. Co powinniśmy kupić, jak skonfigurować sprzętowo, a jak programowo, gdzie są taśmy? Czy nie ukradziono ich razem ze streamerem bo były w tym samym pomieszczeniu? I wszystkie te czynności wykonujemy (może bez zakupu nowego sprzętu) sprawdzając, czy mamy odpowiednią wiedzę (dokumentację!) oraz mierząc czas jaki nam to zajmuje. Najlepiej jak katastrofę symuluje jedna osoba, a odtwarza system inna - wtedy osoba symulująca awarię zmienia różne elementy systemu (zapisując, na wszelki wypadek, co zmieniła).

Ile takich symulacji trzeba przeprowadzić? Im więcej tym lepiej. "Repetitio mater studiorum est".