Najlepsze praktyki lub zasoby dotyczące tworzenia planu odzyskiwania po awarii [Zamknięte]

Miałem za zadanie prowadzić projekt dotyczący aktualizacji starego i nieco jednostronnego planu odzyskiwania po awarii. Na razie szukamy tylko rozwiązania IT po DR. Ostatnim razem, gdy to robili, ustalili zakres, tworząc pojedynczą katastrofę (centrum danych zalane) i planując ją z wyłączeniem wszystkich innych rodzajów katastrof. Chciałbym przyjąć bardziej zaokrąglone podejście. Wiem, że to rozwiązany problem, inne organizacje napisały plany DR.

Nasz plan polega na przyjęciu naszego planu DR IT i kontynuowaniu go i powiedzeniu: „Hej, tego właśnie chcemy w planie DR dotyczącym IT, czy łączy się on z tym, co robi reszta Uniwersytetu? Czy istnieją przywileje usługi przywrócone? chciałbym się zmienić? Mamy całkiem niezły pomysł na resztę planu i spodziewamy się, że wszystko pójdzie dobrze.

To, czego szukam, to wskazówki, jak opracować plan DR i jakie pytania powinienem przemyśleć. Czy masz ulubione zasoby, książki, szkolenia związane z opracowaniem planu DR?

Doskonałym źródłem informacji jest Disaster Recovery Journal ( o ).

Dostępne zasoby społeczności obejmują aktualny projekt dokumentu ogólnie przyjętych praktyk (GAP) , który zapewnia doskonały zarys procesu i rezultaty stanowiące solidny plan i proces ciągłości działania. Dostępnych jest również kilka oficjalnych dokumentów na różne tematy związane z DR / BC.

Proces wydaje się zniechęcający, ale jeśli podejdziesz do niego systematycznie z dobrym zarysem, w którym chcesz się skończyć (np. Dokument DRJ GAP), możesz zapewnić optymalizację zainwestowanego czasu i maksymalizację wartości produktu końcowego.

Uważam, że ich kwartalna publikacja jest również interesująca i pouczająca ( subskrybuj ).

Upewnij się, że masz listę kontaktów alarmowych. alias Recall Roster

Powinno to wyglądać jak drzewo i pokazywać, kto się z kim kontaktuje. Na końcu oddziału ostatnia osoba powinna zadzwonić do pierwszego i zgłosić każdego, z kim nie można się skontaktować.

(Może to być koordynowane przez dział HR i wykorzystywane w przypadku każdego rodzaju katastrofy)

Jeśli dodamy nasze pomysły, możemy stworzyć fajną wiki z tego postu, gdy wszyscy dodadzą własne pomysły. Rozumiem, że istnieje wiele do naśladowania, ale niektórzy z nas mają określone priorytety, jeśli chodzi o powrót do zdrowia. Na początek oto moje:

Upewnij się, że posiadasz dokumentację off-line / zdalną swojej sieci

W przypadku DR podstawowe rzeczy to RTO (cele czasu odzyskiwania) i RPO (cele punktu odzyskiwania), co z grubsza tłumaczy się jako „ile czasu można przeznaczyć na odzyskanie go i ile danych możemy sobie pozwolić na utratę”. W idealnym świecie odpowiedzi brzmiałyby „nic i nic”, ale scenariusz DR jest wyjątkową okolicznością. To naprawdę powinny być napędzane przez klientów, ale ponieważ zaczynasz od IT, możesz zgadywać, ale bądź przygotowany na dostosowanie w górę lub w dół, jeśli to konieczne. Celowanie tak blisko „nikt i nikt”, jak można rozsądnie uzyskać, jest dobre, ale musisz być w stanie rozpoznać, kiedy nadejdzie punkt malejących zysków.

Te dwa czynniki mogą być różne w różnych porach roku i różne w różnych systemach.

Lubię bardziej wszechstronne podejście; kuszące jest wyszczególnienie zdarzeń, które mogą prowadzić do scenariusza DR, ale tak naprawdę należą one bardziej do analizy ananlysis / łagodzenia ryzyka. W przypadku DR zdarzenie już się wydarzyło, a specyfika tego, co było, jest mniej istotna (może z wyjątkiem wpływu na dostępność urządzeń do DR). Jeśli stracisz serwer, musisz go odzyskać, niezależnie od tego, czy został uderzony piorunem, przypadkowo sformatowany, czy cokolwiek innego. Podejście skoncentrowane na skali i rozprzestrzenianiu się katastrofy ma większe szanse na uzyskanie rezultatów.

Jednym z podejść do stosowania u klientów, jeśli okaże się, że niechętnie się angażują, jest zadawanie im pytań DR z perspektywy niezwiązanej z IT. Przykładem może być pytanie, jakie są ich plany, czy wszystkie ich papierowe dokumenty staną w płomieniach. Może to pomóc w większym zaangażowaniu ich w szerszą kwestię DR i może dostarczyć użytecznych informacji do twoich własnych planów.

Wreszcie regularne testowanie twojego planu jest kluczowe dla sukcesu. Nie jest dobrze mieć piękny plan DR, który świetnie wygląda na papierze, ale który nie spełnia swoich celów.

Właściwie pierwszym krokiem jest model rozwoju „pojedynczego incydentu”. Jednym z powodów jest to, że ćwiczenie planowania jest bardziej realistyczne i skoncentrowane. Cały czas planuj powódź. Następnie przypuśćmy inny incydent (powiedzmy, długoterminowe przerwy w dostawie prądu), zastosuj do niego ten plan i napraw to, co się psuje. Po kilku iteracjach plan powinien być stosunkowo solidny.

Kilka myśli ... - pamiętaj, aby uwzględnić osoby niedostępne. W przypadku powodzi nie można zakładać, że cały odpowiedni personel jest dostępny. Ktoś może być na wakacjach, być ranny lub mieć do czynienia z rodziną.
- zaplanować problemy i słabości komunikacyjne. Posiadaj wiele liczb i wiele trybów.
- plan DR wymaga łańcucha dowodzenia. Wiedza o tym, kto podejmuje decyzje, ma kluczowe znaczenie.
- plan musi być szeroko rozpowszechniony, w tym poza siedzibą i poza siecią. Musi być dostępny podczas katastrofy!

Tam, gdzie pracuję, byłem zaangażowany w prowadzenie testu DR na dużą skalę w ciągu ostatnich dwóch lat. Odkryliśmy, że testowanie naszych usług, ludzi i procesów w „realistycznych” sytuacjach było przydatne. Kilka wyciągniętych wniosków (być może oczywistych) w nadziei, że okażą się przydatne:

• Nieprzetestowane usługi, pomimo tego, co napisały w dokumentacji DR, zwykle mają ukryte zależności powodujące katastrofy. Wytrząsanie ich za pomocą realistycznego testu lub dwóch jest użytecznym i mierzalnym rezultatem procesu przygotowania DR.
• Nieprzetestowani ludzie myślą, że ich systemy są w porządku i „będą wiedzieć, co robić” w przypadku katastrofy. Potrząsając je się z realistycznego testu lub dwa jest wielki.
• Nieprzetestowane procesy rozpadają się szybko w rzeczywistych sytuacjach awaryjnych. W szczególności złożone procesy eskalacji koncentrowały się głównie na efektownym informowaniu o przełożeniu wyższej kadry kierowniczej. Najskuteczniejsze są lekkie procesy skoncentrowane na potrzebach personelu operacyjnego i innych reagujących, centralne źródła informacji o rozwijającej się sytuacji awaryjnej, wyraźne przeniesienie odpowiedzialności i „codzienne” procedury reagowania w sytuacjach awaryjnych.

Chyba chodzi o to, że powinieneś starać się nie robić wszystkiego na temat procesu planowania DR. Poproś o pozwolenie, aby faktycznie zepsuć wszystko, a tym samym uzyskać twarde dane na temat gotowości organizacji. Będzie to oczywiście wymagało poważnego wsparcia ze strony kierownictwa, ale może być cudownie skoncentrować się na tym, aby firma spędziła kilka dni na próbach na najgorsze.

Cian

Istnieje kilka standardów z British Standards Institute (BSi), które koncentrują się na zarządzaniu ciągłością i odtwarzaniu po awarii.

• BS 25999-1: 2006 Zarządzanie ciągłością działania, część 1: Kodeks postępowania
• BS 25999-2: 2007 Zarządzanie ciągłością działania. Specyfikacja
• BS 25777: 2008 Zarządzanie ciągłością technologii informacyjnych i komunikacyjnych. Kodeks postępowania

Może się to wydawać oczywiste, ale zgodnie z powyższą dokumentacją zewnętrzną upewnij się, że masz kopie zapasowe poza siedzibą (najlepiej poza regionem). Może to być usługa pamięci online lub miejsce, w którym można zabrać taśmy.

Mówię najlepiej poza regionem, ponieważ pochodzę z obszaru, w którym co roku nie ma wielu klęsk żywiołowych, ale jeśli tak się dzieje, dzieje się to na skalę regionalną z masowymi zniszczeniami (trzęsienia ziemi, wulkany). Dobrze jest mieć kopię zapasową w sejfie w banku, dopóki bank nie znajdzie się pod płynną gorącą magmą (/ Dr. Evil Voice).

Coś, o czym czytałem, to agencje dzielące koszty utrzymania gorącej strony na wypadek, gdy duża trafi. Realizują plany przywrócenia krytycznej dla obu stron misji obu firm za pomocą wirtualizacji i tym podobne, a następnie dzielą personel na poziomie migania. Tylko myśl.

W przypadku książek znajduje się Planowanie odzyskiwania po awarii autorstwa Jona Williama Toigo, teraz w 3. edycji, z czwartym wydaniem (blog + książka) na horyzoncie.

Laura,

Oto link z SQLServerPedia, który podaje podstawy DR.

http://sqlserverpedia.com/blog/sql-server-backup-and-restore/disaster-recovery-basics-tutorial/

Przeczytaj także „Ciągłość biznesowa”