20 věcí, které je třeba naplánovat pro obnovu po havárii IT

Implementace řešení obnovy po havárii závisí na třech faktorech — 1) čase 2) zdrojích 3) částce v dolarech.

Většina organizací na DR ani nepomyslí, když IT infrastruktura a aplikace běží bez problémů. Většina z nich přemýšlí o DR pouze tehdy, když se něco pokazí, což mělo zásadní negativní dopad na podnikání.

Pokud jste systémový správce nebo někdo, kdo je zodpovědný za udržování chodu IT, měli byste neustále pracovat o zotavení po havárii. Ať už vaše společnost přidělila čas a rozpočet nebo ne, stále můžete pracovat na některých aspektech DR.

Následuje seznam různých položek, které byste mohli chtít zvážit při plánování DR. Tento seznam není v žádném případě úplný, ale měl by vám poskytnout dostatek nápadů, abyste mohli začít s DR.

Odolné primární datové centrum. Před plánováním sekundárního vzdáleného datového centra byste se měli ujistit, že všechny komponenty v primárním datovém centru jsou vysoce nadbytečné. Vaším cílem by mělo být navrhnout vaše primární datové centrum co nejodolnější, abyste se rychle odrazili od většiny katastrof (s výjimkou přírodních katastrof), aniž byste museli kdy používat sekundární vzdálené datové centrum. Například pro vaši produkční databázi mějte fyzickou pohotovostní databázi spuštěnou ve stejném datovém centru, nakonfigurujte dvě síťové karty a karty HBA na všech prod serverech, nakonfigurujte více webových serverů pomocí nástroje pro vyrovnávání zátěže, připojte server ke dvěma napájecím obvodům pomocí redundantního napájení na serverech atd.
Vzdálené sekundární datové centrum. Pokud implementujete odolné primární datové centrum, váš cíl pro použití redundantního vzdáleného datového centra je primárně pro přírodní katastrofy, jako jsou zemětřesení, požáry, povodně atd. I když to může být velmi zřejmé, stojí za to uvést, protože jsem viděl několik společností když to uděláte, mají primární i sekundární datové centrum ve stejném městě, což maří účel DR. Pokud je vaše primární datové centrum v Kalifornii, nastavte sekundární datové centrum někde na východním pobřeží.
Replikujte produkční komponenty v datovém centru DR. Nemusíte replikovat veškerý hardware a aplikace z primárního do sekundárního datového centra. Systémový administrátor nebo jakákoli technická osoba může rychle identifikovat veškerý kritický hardware a software, který je třeba replikovat na místě DR, ale možná budete potřebovat pomoc od jiných oddělení, abyste identifikovali aplikace, které jsou pro podnik kritické. Musíte namapovat kritické obchodní funkce na komponenty IT infrastruktury a zajistit, aby všechny tyto komponenty infrastruktury spolu s aplikacemi a daty byly replikovány do lokality DR.
Plán úložiště. Pokud máte nějaký druh úložiště SAN (nebo úložiště NAS), které podporuje kritickou aplikaci v primárním DR, musíte mít podobné úložiště SAN (nebo úložiště NAS) také na svém webu DR. Z důvodů výkonu by prod servery v lokalitě DR měly mít stejnou specifikaci jako prod servery v primární lokalitě. Pokud však máte na primárním webu špičkové úložiště SAN od velkého dodavatele, zvažte implementaci podobného úložiště SAN vyšší třídy od malého dodavatele, které vás může stát mnohem méně peněz za stejnou konfiguraci a podobný výkon. .
Průběžně replikujte data na web DR. Synchronizace dat mezi primárním a datovým centrem katastrofy je kritickým aspektem úspěšné implementace DR. Jakmile vypíšete všechny aplikace, které je třeba replikovat na web DR, musíte zjistit, jak synchronizovat data mezi těmito dvěma weby pro všechny tyto aplikace. Můžete například replikovat databázi Oracle na úrovni bloku pomocí replikačních technologií poskytovaných dodavateli úložiště, nebo můžete použít datagurad k replikaci dat na úrovni Oracle. Obojí má své pro a proti. Musíte je pečlivě analyzovat a vybrat ten, který odpovídá vašemu rozpočtu a rozsahu DR.
Replikujte počáteční data pomocí ruční metody. Když nastavujete web DR poprvé, musíte se rozhodnout, jak provedete počáteční synchronizaci dat. Pokud například replikujete databázi datového skladu o velké velikosti, nemůžete zkopírovat počáteční zálohu databáze přes síť na vzdálené místo, protože by to mohlo zabrat šířku pásma. Místo toho můžete provést zálohu na pásku v primárním datovém centru a použít ji v sekundárním datovém centru k nastavení počáteční databáze. Po dokončení počátečního nastavení můžete implementovat nějakou formu automatické přírůstkové synchronizace mezi weby.
RTO je zkratka pro Recovery Time Objective. Ve spolupráci s manažerským týmem určíte přijatelnou RTO pro podnik. Vaše organizace se například může rozhodnout, že přijatelná RTO je 8 hodin. tj. Po katastrofě by měly být všechny kritické aplikace plně funkční v místě DR maximálně do 8 hodin. RTO má přímý dopad na to, kolik dolarových částek je vynaloženo na implementaci řešení DR. Například RTO v délce 1 hodiny může vyžadovat velmi sofistikované řešení DR, které je příliš drahé než to, co vyžaduje 24hodinové RTO.
RPO je zkratka pro Recovery Point Objective. Stejně jako RTO byste měli spolupracovat s vedením, abyste rozhodli o přijatelné RPO pro podnikání. Vaše organizace se například může rozhodnout, že přijatelná RPO je 2 hodiny. tj. Po katastrofě, kdy službu přepnete na sekundární DR, jsou pro firmu přijatelné 2 hodiny ztráty dat. Pokud například ke katastrofě dojde v 15:00, po obnovení systému v lokalitě DR bude systém obsahovat data z výroby pouze od 13:00. Takže jste ztratili data od 13:00 do 15:00. Jednoduše řečeno, pokud je vaše RPO 2 hodiny, vaše firma by měla být ochotna ztratit během katastrofy data v hodnotě 2 hodin.
Automatické nebo ruční převzetí služeb při selhání? Musíte se rozhodnout, zda chcete po havárii automaticky nebo ručně převzít převzetí služeb při selhání. Ve většině případů je přijatelný ruční zásah, protože nechcete automaticky přecházet na stránky DR na základě nějakého falešného signálu. Mějte na paměti, že po převzetí služeb při selhání je návrat do primárního datového centra spojen s velkým množstvím práce.
Převzetí služeb při selhání sítě. Viděl jsem plány DR, které se hodně zaměřují na replikaci dat, ale méně se zaměřují na síťové aspekty DR. Ve spolupráci se svým síťovým týmem musíte identifikovat všechny síťové infrastruktury, které je třeba replikovat. Například DNA převzetí služeb při selhání, abyste se ujistili, že vaše produkční adresa URL po převzetí služeb při selhání ukazuje na web DR. Pokud jste pro své zákazníky vytvořili připojení VPN, zjistěte, jak převzít připojení VPN při selhání. Když vytváříte/upravujete pravidla brány firewall (nebo cokoli souvisejícího se zabezpečením) v primárním datovém centru, musíte zjistit, jak lze tyto zásady zabezpečení průběžně replikovat na web DR.
Nastavení vzdálené ruky. Musíte mít vhodný plán pro přístup ke vzdálenému datovému centru pro ladění jakýchkoli problémů. KVM můžete nastavit na webu DR, abyste měli z kanceláře přístup ke konzole hardwaru umístěného na webu DR. Nebo potřebujete naplánovat nějakou formu manuálních služeb dálkové ruky, kdy někdo může fyzicky přijít na místo DR a provést vaše pokyny.
Roční testování DR. Několik organizací tráví spoustu času a peněz zakládáním webu DR, jen aby zjistily, že ve skutečné situaci DR ve skutečnosti nefunguje podle očekávání. Jednou ročně byste měli ověřit své aktuální konfigurace DR, abyste se ujistili, že stránka DR funguje správně a splňuje původní cíl. Pokud je vše správně nakonfigurováno, měli byste být schopni ručně převzít vaše kritické aplikace při selhání z primární lokality do lokality DR a nechat ji tam několik dní běžet. To vám také pomůže zjistit, jak web DR zvládá zatížení v reálném čase.
Stránka DR jako platforma kontroly kvality. Místo toho, abyste stránky DR používali pouze pro případ katastrofy, můžete je použít jako platformu QA pro testování výkonu a zátěže vašich aplikací. To může být užitečné, protože nemusíte investovat do další testovací infrastruktury v primárním datovém centru. Když použijete tento přístup, budete synchronizovat data z primárního webu s webem DR průběžně. Kdykoli však provádíte zátěžové testování, musíte implementovat nějaké další řešení, kde provedete kontrolní bod aktuálního stavu webu DR, provedete testování kvality a poté se okamžitě vrátíte k předchozímu kontrolnímu bodu a budete pokračovat v synchronizaci dat primárního webu. odtud.
Plán odezvy DR. Jakmile implementujete web DR, musíte mít jasný plán DR, jak vy a váš tým zareagujete, když dojde ke skutečné katastrofě. Spolupracujte s různými odděleními ve vaší organizaci a identifikujte klíčové zdroje, které budou součástí týmu pro reakci na DR, a určete jejich konkrétní roli v plánu reakce na DR. Plán odezvy DR je jednoduchý návod krok za krokem, co je třeba udělat, když dojde k DR, kdo bude tyto úkoly provádět a v jakém pořadí budou tyto úkoly provedeny.
Nemáte web DR? Mnoho organizací nemá stránky DR. Pokud pracujete pro jednoho z nich a jste odpovědní za kritické aplikace a IT infrastrukturu, je vaší odpovědností vymyslet plán DR a vzdělávat své vrcholové vedení o důležitosti trávit čas a peníze na DR a získat jejich schválení. Vymyslete tři různé plány DR – jeden, který stojí $ $ $, jeden, který stojí $ $, jeden, který stojí $. Jak jsme vysvětlili dříve, plán DR se může lišit v závislosti na různých faktorech a náklady jsou jedním z nich. Pokud svůj podrobný plán DR předložíte svému vedení, pokud jej stále neschválí, budete mít alespoň dobrý pocit, že jste při vymýšlení dobrého plánu DR udělali maximum.
Kdy vyhlásit katastrofu? Musíte to předem jasně identifikovat. Musíte mít velmi jasná písemná kritéria, kdy přejdete na web DR. tj. Jaká kritéria spouštějí kritéria převzetí služeb při selhání DR? Kdy zahájíte DR? V jakém okamžiku prohlásíte, že je to DR, přidejte začněte pracovat na selhání na webu DR? Odpověď na tyto otázky by měla být jasně definována a přezkoumána každým oddělením vaší organizace a nakonec by tato kritéria měla být schválena nejvyšším vedením. U některých, když produkce nefunguje, protože někdo omylem smazal něco ve výrobě, nemusí spustit DR. Pro některé organizace je pravděpodobně lepší obnovit data ze zálohy na samotném primárním webu. Jiné organizace nemohou čekat, až se obnoví ze zálohy, a musí přejít na web DR.
Zálohování, zálohování a zálohování. Zálohy jsou velmi důležitým faktorem v plánu DR. Jak jsme již zmínili dříve, vaším cílem by mělo být nikdy nepoužívat stránky DR, pokud nedojde ke skutečné přírodní katastrofě. Silná strategie zálohování na vašem primárním webu je tedy velmi důležitá. Měli byste zálohovat všechny kritické aplikace. Při zálohování databáze uložte zálohu na čtyři místa. Zálohy jsou v podstatě k ničemu, pokud je neobnovíte na testovacím serveru, abyste si ověřili, že fungují na průběžné bázi.
Použití oprav. Když aplikujete záplatu operačního systému, upgradujete firmware nebo provádíte jakýkoli druh správy konfigurace na hardware v primární lokalitě, musíte mít strategii, jak to na webu DR provádět průběžně. Nechcete se ocitnout v situaci, kdy je konfigurace operačního systému na vašem primárním webu jiná než na webu DR.
Úspěšné DR závisí na mnoha faktorech. Požehnání top managementu, adekvátní alokace rozpočtu, zapojení všech obchodních divizí, silný plán DR, silné technické zdroje, plně otestovaná implementace DR. A co je nejdůležitější, dobře definovaný rozsah DR, který je v souladu s obchodním cílem, je velmi důležitý pro úspěšné DR.
Dokumentace DR. Správné plánování DR vyžaduje zavedení mnoha procesů. Všechny tyto procesy by měly být řádně zdokumentovány. Například dokument, který vysvětluje proces eskalace, když DR udeří. Technická dokumentace, která vysvětluje, co je třeba udělat, aby se provedlo převzetí služeb při selhání na místo DR. Komunikační dokument, který uvádí všechny členy týmu zapojené do DR a za co jsou zodpovědní a jak je lze během DR kontaktovat. Dokument pro tým zákaznické podpory, který ví, co je třeba zákazníkovi sdělit a jak oslovit zákazníky během katastrofy. Dokument o testování DR, který uvádí vše, co tým kontroly kvality potřebuje otestovat poté, co bude web DR aktivní atd.

Pouze jsme poškrábali povrch obnovy po katastrofě. Je toho mnohem víc než výše uvedené položky. Pokud jste správce systému nebo někdo, kdo je zodpovědný za vaše IT aplikace a infrastrukturu, a pokud nemáte plán DR, berte to jako připomenutí, abyste začali něco se svou strategií DR.