Plan DR: krytyczne serwisy i punkty awarii

Tworzenie planu DR: identyfikacja kluczowych usług i punktów awarii

Plan odzyskiwania po awarii (Disaster Recovery, DR) zaczyna się od skupienia na usługach końcowych dostępnych dla użytkowników. Celem jest minimalizacja czasu przestoju procesów biznesowych, a nie pojedynczych komponentów infrastruktury. Użytkownicy zauważają awarie na poziomie usług: brak dostępu do poczty czy systemu ERP, a nie awarię dysku na serwerze.

Najpierw sporządź listę kluczowych usług IT. To te narzędzia, bez których biznes traci przychody lub efektywność:

• Poczta elektroniczna
• Firmowa telefonia
• Systemy zarządzania przedsiębiorstwem (ERP, 1C)
• Platformy do wspólnej pracy nad dokumentami
• Drukowanie sieciowe
• Dostęp do zasobów internetowych
• Firmowe CRM i bazy danych

Wyklucz niekrytyczne elementy, takie jak serwery gamingowe — nie wpływają one na działalność operacyjną.

Wyszukiwanie punktów awarii w infrastrukturze

Dla każdej usługi zidentyfikuj wszystkie potencjalne punkty awarii — komponenty infrastruktury, których awaria powoduje niedostępność usługi. Punkt awarii definiuje się jako jednostkę, gdzie diagnoza ogranicza się do statusu „nie działa”.

W urządzeniach modułowych (np. routerach) uwzględnij oddzielne moduły i szasze. Jeśli lokalizacja i wymiana są możliwe na poziomie podkomponentów, każdy z nich to osobny punkt awarii.

Przykład dla usługi „Poczta elektroniczna”:

• System operacyjny serwera (Linux/Windows Server)
• Oprogramowanie pocztowe (Postfix, Exchange)
• Przełącznik rdzenia sieci
• Systemy zasilania (UPS, PDU)
• Zewnętrzne serwery DNS
• Filtry czarnych list (RBL)
• Kontrola klimatu serwerowni
• Magazyn danych (SAN/NAS)

Nie ignoruj „niezawodnego” sprzętu: awaria macierzy dyskowej z RAID i replikacją nadal wymaga planu odzyskiwania.

Analiza zależności między punktami awarii

Punkty awarii tworzą graf zależności: awaria jednej wywołuje kaskadę w innych. Na przykład, awaria UPS zatrzymuje serwery, a przy restarcie hiperwizora maszyny wirtualne mogą nie wystartować poprawnie. Lokalny przełącznik klienta jest natomiast niezależny.

Dla „Poczty elektronicznej” zależności obejmują łańcuch: zasilanie → serwery → aplikacje → sieć → usługi zewnętrzne. Rozszerz model na wszystkie kluczowe usługi, budując diagram wpływu.

To zrozumienie jest kluczowe dla priorytetyzacji: określa kolejność lokalizacji, RTO/RPO i ryzyka. W kolejnych częściach omówimy procedury odzyskiwania i metryki.

Co jest ważne

• Skupienie na usługach użytkownika, a nie sprzęcie: biznes mierzy przestój w minutach braku kluczowych narzędzi.
• Pełna lista punktów awarii bez wyjątków dla „niezawodnego” sprzętu — prawo Murphy'ego w akcji.
• Graf zależności ujawnia awarie kaskadowe i ułatwia TTR (Time To Recovery).
• Plan DR przekształca reaktywne działania w proaktywne z budżetem i SLA.
• Integracja z CMDB lub ITSM dla automatyzacji wykrywania.

— Editorial Team