Planowanie odtwarzania po awarii z wykorzystaniem istniejącego sprzętu platformy

Planowanie odtwarzania po awarii (Disaster Recovery) jest zawsze trudne — istnieje tak wiele czynników i scenariuszy “co jeśli”, które trzeba wziąć pod uwagę, a nadmierne inwestowanie w rozwiązanie recovery może samo w sobie stać się swego rodzaju katastrofą. Czynnikiem często pomijanym w planowaniu DR jest to, że w przypadku awarii jesteśmy zazwyczaj zdolni i bardzo skłonni do dokonywania kompromisów tam, gdzie to konieczne, ponieważ katastrofa już nastąpiła. Nadchodzi czas triażu, a nie normalnego funkcjonowania biznesu.

Wiele osób od razu zakłada, że jeśli do systemów produkcyjnych potrzebna jest wydajność i pojemność na poziomie X, to systemy disaster recovery również muszą spełniać wymagania na poziomie X. W rzeczywistości rzadko kiedy jest to prawdą. W przypadku awarii można — z rzadkimi wyjątkami — pracować przy niższej wydajności, ograniczając dostępność systemu tylko do bardziej krytycznych obszarów, a wiele operacji konserwacyjnych, w tym często archiwizacja, jest wstrzymywanych do czasu przywrócenia pełnej produkcji. Oznacza to, że system disaster recovery może być często znacznie mniejszy niż główne systemy produkcyjne.

Systemy disaster recovery nie są inwestycją w produktywność — są zabezpieczeniem przed awariami i należy je postrzegać właśnie w tym świetle. Z tego powodu powszechną i skuteczną strategią jest podejście do potrzeb systemu DR bardziej z perspektywy “wystarczalności” do utrzymania działalności biznesowej, niekoniecznie w sposób komfortowy czy przezroczysty dla użytkowników. Jeśli dojdzie do poważnej awarii i pracownicy będą musieli zmagać się z wolnym pobieraniem plików, wolniejszymi niż zwykle bazami danych lub będą musieli odłożyć intensywne analizy BI do czasu przywrócenia wydajnych systemów produkcyjnych, niewielu będzie narzekać. Większość pracowników, a z pewnością decydenci biznesowi, jest w stanie zrozumieć, że system jest w stanie awaryjnym i że być może będą musieli dać z siebie wszystko do czasu przywrócenia pełnej wydajności.

Mając to podejście na uwadze, skuteczną strategią może być ponowne wykorzystanie starszych platform jako systemów w miejscach Disaster Recovery, gdy nowe platformy są kupowane i wdrażane do głównego użytku produkcyjnego. Może to stworzyć niskokosztowy i łatwy do zaplanowania “potok DR”, w którym lokalizacja DR zawsze dysponuje pojemnością z “ostatniego odświeżenia”, co w większości scenariuszy DR jest więcej niż wystarczające. Może to być świetny sposób na wykorzystanie sprzętu, który w przeciwnym razie mógłby zostać po prostu zezłomowany lub kusicielsko wrócić do produkcji, wyzwalając emocjonalną reakcję na “utopiony koszt”, której generalnie chcemy unikać.

Błąd utopionych kosztów (sunk cost fallacy) jest trudny do uniknięcia. Posiadanie sprzętu sprawia, że bardzo łatwo jest poczuć, że ponowne jego wdrożenie — nawet gdy implementowany jest nowo zaprojektowany system — poza zakresem specyfikacji systemu jest użyteczne lub korzystne. Są przypadki, gdy może to być prawdą, ale najprawdopodobniej tak nie jest. Jednak tak jak nie chcemy nadmiernie przywiązywać się emocjonalnie do sprzętu tylko dlatego, że już za niego zapłaciliśmy, tak samo nie chcemy ignorować wartości istniejącego sprzętu, który już posiadamy. Właśnie tutaj zaplanowany potok do scenariusza Disaster Planning może w wielu przypadkach bardzo dobrze wykorzystać to, w co już zainwestowaliśmy. Musimy pamiętać, że to prawdopodobnie bardzo użyteczny sprzęt z dużą ilością wartości, którą jeszcze można z niego wyciągnąć, jeśli tylko wiemy, jak właściwie go użyć, aby spełniał nasze istniejące potrzeby.

Solidny proces planowania migracji platform z produkcji do disaster recovery może być świetnym sposobem na obniżenie wydatków budżetowych przy jednoczesnym osiąganiu doskonałych wyników w zakresie odtwarzania po awarii.