Wersjonowanie planu DR

Wersjonowanie planu DR pozwala śledzić zmiany procedury odzyskiwania wraz z rozwojem infrastruktury.

Po co wersjonować plan odtwarzania po awarii

Wersjonowanie planu DR (Disaster Recovery) polega na utrzymywaniu kolejnych, jednoznacznie oznaczonych wydań dokumentu opisującego odzyskiwanie usług, systemów i danych po awarii. Plan nie jest dokumentem statycznym, ponieważ zmieniają się serwery, aplikacje, zależności między usługami, lokalizacje kopii zapasowych, procedury dostępu oraz wymagania dotyczące czasu przywrócenia. Każda istotna zmiana infrastruktury powinna mieć odzwierciedlenie w nowej wersji planu, aby instrukcja używana podczas awarii odpowiadała rzeczywistemu środowisku.

Poprawnie prowadzona historia wersji pozwala ustalić, jakie procedury obowiązywały w określonym momencie, kto je zatwierdził i z jakiego powodu zostały zmienione. Jest to istotne podczas przeglądu po awarii, testu odtworzeniowego oraz analizy rozbieżności między dokumentacją a działaniem systemu. Wersjonowanie ogranicza także ryzyko korzystania z nieaktualnych instrukcji, na przykład zawierających dawny adres repozytorium kopii, nieużywane konto techniczne albo kolejność uruchamiania usług, która przestała odpowiadać ich zależnościom.

Elementy identyfikujące kolejne wydania

Każda wersja planu powinna mieć numer, datę utworzenia lub publikacji, opis zakresu zmian oraz status, na przykład roboczy, zatwierdzony albo wycofany. W historii zmian warto zapisać również autora modyfikacji, osobę zatwierdzającą i powiązane zdarzenie, takie jak wdrożenie nowej bazy danych, zmiana harmonogramu kopii lub wynik testu odtwarzania. Numeracja może być prosta, na przykład 1.0, 1.1 i 2.0, pod warunkiem że organizacja konsekwentnie definiuje znaczenie poszczególnych poziomów.

Zmiana treści opisującej drobną korektę, doprecyzowanie kroku lub aktualizację kontaktu może otrzymać numer wydania podrzędnego. Zmiana wpływająca na kolejność odzyskiwania, zakres systemów, wartości RTO albo RPO powinna skutkować wyraźnym podniesieniem wersji i ponownym zatwierdzeniem planu. RTO określa docelowy czas przywrócenia usługi, natomiast RPO określa maksymalny akceptowany okres danych, który może zostać utracony. Wersja dokumentu powinna wskazywać, dla jakich wartości i założeń została przygotowana.

Kontrola zmian i powiązanie z konfiguracją

Plan DR powinien być przechowywany w systemie umożliwiającym kontrolę dostępu, rejestrowanie zmian i odtworzenie poprzedniej wersji. W przypadku dokumentów tekstowych może to być repozytorium Git, a w przypadku innych formatów system zarządzania dokumentacją z historią rewizji. Sam plik nie wystarcza: obok procedury należy utrzymywać metadane opisujące wersję, właściciela dokumentu, zakres obowiązywania oraz datę następnego przeglądu. Wycofane wersje powinny pozostać dostępne do wglądu, lecz nie mogą być mylone z aktualnym wydaniem operacyjnym.

Podczas aktualizacji należy sprawdzić zgodność planu z rzeczywistą konfiguracją. Dotyczy to między innymi nazw usług, zależności uruchamiania, lokalizacji kopii, sposobu odtworzenia kluczy i certyfikatów, wymagań systemowych oraz procedur przełączania na środowisko zapasowe. Jeżeli plan odwołuje się do osobnych instrukcji, skryptów lub diagramów, trzeba wskazać ich wersje albo identyfikatory. Dzięki temu operator nie użyje nowego planu razem ze starym skryptem, który oczekuje innego układu katalogów, parametrów lub punktów końcowych.

Testowanie aktualnego wydania

Wersjonowanie ma wartość operacyjną dopiero wtedy, gdy każda istotna wersja jest sprawdzana w praktyce. Test może obejmować pełne odtworzenie usługi, odtworzenie wybranych komponentów albo przejście przez procedurę bez zmiany środowiska produkcyjnego. Wynik powinien zawierać używaną wersję planu, datę testu, zakres sprawdzenia, czas wykonania poszczególnych etapów, wykryte problemy i działania korygujące. Jeżeli test ujawni niezgodność, dokument należy poprawić, nadać mu nowy numer i ponownie poddać zatwierdzeniu.

Po zmianach infrastruktury, aktualizacji systemu, zmianie sposobu wykonywania kopii lub modyfikacji zależności aplikacji należy ocenić, czy poprzednia wersja nadal jest aktualna. Przegląd kalendarzowy również pomaga wykryć starzenie się procedur, ale nie zastępuje kontroli po zmianach technicznych. W nagłej sytuacji zespół powinien móc jednoznacznie wskazać obowiązujące wydanie, pobrać je z ustalonego miejsca i rozpocząć działania zgodnie z kolejnością kroków. Takie podejście zmniejsza ryzyko decyzji podejmowanych na podstawie nieaktualnej dokumentacji i ułatwia późniejsze odtworzenie przebiegu prac.