;

Desatero pro disaster recovery

1. 2. 2011
Doba čtení: 4 minuty

Sdílet

Opomenout některých z kritických kroků může znamenat rozdíl mezi úspěšným podnikáním a smutným bankrotem

Na základě zkušeností ze spolupráce s tisíci zákazníky jsme vypracovali následující kontrolní seznam o deseti bodech. Projděte si jej a ujistěte se, že jste neopomněli nějaký kritický krok, který by mohl znamenat rozdíl mezi úspěšným podnikáním a smutným bankrotem!

 

1. Odhalte všechny hrozby

Kromě očividných hrozeb – virů, trojských koňů, červů atd. – je třeba identifikovat také nebezpečí specifické pro váš region. Žijete v místě častých zemětřesení nebo v povodňové zóně? Trpíte díky častým bouřím výpadky elektřiny? Ujistěte se, že při tvorbě plánu pro obnovu po havárii či volbě místa pro nové zařízení DR zvažujete všechny faktory.

2. Zajistěte lidské zdroje

Pro společnosti není ojedinělé mít plán DR závisející na jediném člověku. Ale co když bude daná osoba v okamžiku havárie z nějakého důvodu právě nedostupná? Proto je třeba určit a vyškolit více zaměstnanců schopných v tomto případě reagovat. Je rovněž vhodné, aby tito zaměstnanci působili na geograficky odlišných lokacích pro případ velké přírodní katastrofy, která bude mít dopad na všechny místní pracovní síly.

3. Automatizujte procesy

Pokud ve vašem zařízení nastane výpadek proudu a není tam zrovna nikdo, kdo by to ohlásil, dozví se o tom vaši pracovníci DR? Musíte vytvořit automatizovaný systém (vlastní či zajištěný externím dodavatelem), který upozorní váš IT personál na jakoukoli havárii či výpadek služby.

4. Dimenzujte zálohu

Pokud je vaše zařízení ovlivněno dalekosáhlým environmentálním výpadkem, můžete se ocitnout bez elektrické energie po delší dobu. Proto si pořiďte co nejodolnější záložní zdroj s největší možnou výdrží. Nezapomeňte na dodatečné baterie.

5. Stanovte priority obnovy

Ke kterým z vašich IT aplikací je třeba přistupovat nejdříve? Provozujete nějaké, jejichž znovuzprovoznění může počkat den či dva, aniž tím utrpí podnikání? Je třeba být selektivní ohledně pořadí, ve kterém budou po havárii znovu uváděny do provozu a spouštěny on-line aplikace a služby. Například se rozhodnete, že nejdříve zprovozníte firemní e-mailovou aplikaci, než to samé učiníte se souborovými servery jednotlivých oddělení.

6. Vytvořte dokumentaci

Po vytvoření plánu je třeba krok za krokem sepsat detailní instrukce provedení tohoto plánu. Ujistěte se, že každý proces je dobře popsán. Popište umístění všech systémových zdrojů potřebných k dokončení obnovy. Dokumentaci skladujte na několika místech a ověřte si, že k manuálům má snadný přístup veškerý klíčový personál.

7. Pamatujte na aktuálnost

Nezáleží na kvalitě vašeho plánu DR, pokud máte data, která jsou zastaralá, která se nacházejí v místě ovlivněném havárií nebo jsou poškozená. Provádějte zálohování v přísně vynucených pravidelných intervalech, abyste ochránili integritu informací. Nebo využívejte technologii, jako je virtualizace, pro zprovoznění vzdáleného pracoviště s replikovanými virtuálními stroji pro urychlení obnovy.

8. Trénujte a cvičte

Musíte se ujistit, že váš plán DR bude v případě nouze opravdu účinný! Ačkoli to vypadá zřejmě, mnohé společnosti zapomínají adekvátně ozkoušet své plány. Technologie jako virtualizace VMware a možnost okamžitého (v řádu minut) provisioningu libovolného serveru s potřebnými virtuálními stroji činí testování plánu obnovy rychlým a efektivním.

9. Chraňte hesla

Ačkoli je ochrana pomocí hesel klíčová pro zabezpečení dat, měli byste svá sy­stémová hesla ukládat alespoň na dvou geograficky odlišných a zabezpečených místech. Přístup ke všem heslům a kódům by také neměl zůstat v rukou jediného člověka. Nezapomeňte hesla měnit hned, pokud klíčový personál opustí společnost.

10. Aktualizujte DR plán

Nikdy nezapomeňte aktualizovat svůj plán DR. Po jeho vytvoření jej pravidelně revidujte alespoň čtvrtletně. Sepište si seznam bodů, které by mohly znamenat změnu plánu. Zejména nedávné změny.

 

Autor působí ve společnosti VMware coby regional presales manager Eastern Europe

ICTS24

 

Vyšlo v CIO Business World 12/2010