Hlavní navigace

Rychlé zotavení po katastrofě aneb Připravujeme se na nejhorší

1. 7. 2004

Sdílet

Utrácíte zbytečně moc peněz za systémy a opatření, jež vám mají umožnit bezproblémové obnovení provozu po katas...
Utrácíte zbytečně moc peněz za systémy a opatření, jež vám mají umožnit
bezproblémové obnovení provozu po katastrofě? Jistě, vypadá to jako směšná
otázka. Jak byste mohli? Novinové titulky varují před dalšími a dalšími
riziky... Tento článek je věnován speciálně obnovení provozu po katastrofě a je
plný návrhů, jak na to. Jejich realizace ovšem obvykle vyžaduje více peněz,
nikoliv méně. A jakmile zjistíte, že jste na tom v této oblasti celkem dobře,
pravděpodobně začnete mít obavy o své dodavatele a smluvní partnery.
"Abyste se vyhnuli nadměrným výdajům, měli byste pro obnovu v případě
katastrofy vytvořit tři úrovně opatření, a to na základně oprávněných požadavků
uživatelů," radí Tim DeLisle, ředitel konzultantské firmy Corigelan, jež se
danou problematikou zabývá. CIO by se podle jeho názoru nejprve měl podnikových
manažerů zeptat, jaké aplikace jsou skutečně natolik kritické, aby vyžadovaly
pro zachování chodu firmy obnovu do 24 hodin. Těch by mělo být jen málo.
Rozhodně podle něj není nutné zrcadlit všechno. "Druhá úroveň aplikací, které
vyžadují obnovu mezi 24 až 72 hodinami, může vyžadovat pouze levné zálohování
na pásky, zatímco poslední řada aplikací nemusí vyžadovat zálohování žádné,"
vysvětluje DeLisle.
Vše, co vedoucí podnikoví pracovníci a regulátoři vyžadují, je podniknutí
rozumných kroků pro kontinuitu operací firmy. Není nutné firmu zruinovat kvůli
neoprávněně vysokým nárokům. Následující tipy od skutečných uživatelů s dobře
propracovanými plány mohou sloužit k inspiraci, jak udržet podnik v chodu během
nejběžnějších katastrof. Jedním z klíčů, jak udržet firmu na nohách v případě,
že dojde k nejhoršímu, je přitom předvídání určitých kaskádových efektů, které
může katastrofa mít na fungování IT.
I když některé katastrofy hrozí pouze v určitých částech světa, problémy, které
způsobují, se mohou vyskytnout i v jiných souvislostech. To je i případ
hurikánu, který v roce 1992 zasáhl jižní Floridu. Tehdy došlo v datovém centru
radnice v Miami--Dade k výpadku napájení. Naftové generátory se přehřály, když
ve studni došla voda, což bylo důsledkem narušení hlavního vodovodního řadu
větrem a následným snížením úrovně hladiny. Později IT manažeři nechali
nainstalovat generátory chlazené vzduchem.
Experti tvrdí, že jedním z problémů obnovy provozu v případě katastrofy je
fakt, že ačkoliv většina firem má k dispozici plány pro podobné běžné případy
jako jsou havárie vody nebo masivní výpadky elektřiny zmíněné plány nejsou
pravidelně testovány a nejsou s nimi seznámeni koncoví uživatelé. Ve
skutečnosti nedávný průzkum, jehož se zúčastnilo 283 čtenářů Computerworldu,
ukázal, že 81 % respondentů ví o tom, že jejich firma má plány pro případ
katastrofy. Nicméně 71 % respondentů z firem, jež tyto plány mají, řeklo, že za
celý minulý rok neproběhl žádný jejich nácvik.
Abyste se vyhnuli přerušení provozu během katastrofy, musíte předvídat. Jak
odborníci, tak uživatelé se shodují v tom, že existují kroky, které mohou
zvýšit vaše šance na to, abyste při nejběžnějších typech katastrof vyvázli bez
úrazu.

Havárie způsobené počasím
"Podíváte-li se na to, proč zařízení během přírodních pohrom způsobených vodou
selhávají, jedná se vždy o velmi předvídatelné okolnosti. Někdo tomu říká vyšší
moc, já tomu zase říkám projev stupidity," tvrdí Ken Brill, výkonný ředitel The
Uptime Institute.
Již zmíněné datové centrum v Miami-Dade ohrožují každý rok od června do
listopadu hurikány, přesto IT manažeři stále bojují s tím, aby každý pochopil
důležitost plánování pro případ katastrofy. "Vždy je důležité ujistit se, že
všichni zaměstnanci jsou do těchto plánů plně zapojeni a účastní se jich,"
konstatuje Ruben Lopez, ředitel pro technologické služby centra.
Datové centrum v Miami-Dade každoročně věnuje 56 hodin testování plánu pro
obnovení provozu po katastrofě přepojením na alternativní datové centrum a
obnovením dat. Tento čas využívá k odhalování nedostatků a jejich pozdější
nápravě.
"Kontinuita operací a připravenost na katastrofu je v zásadě pouze o zjištění
nedostatků a stanovení kroků k jejich nápravě. Nejde o to, jak na papíře dostat
jedničku s hvězdičkou," upozorňuje Joe Torres, koordinátor datového centra pro
případ katastrof. Zdůrazňuje, že během testování plánu pro obnovu netestuje
lidi, ale samotný plán podle jeho slov totiž nelze být závislý na konkrétních
lidech. "Dáte jim brožuru s instrukcemi, a oni musejí být schopni tyto
instrukce dodržet," říká Torres.
Jedním z kroků, které byly v Miami-Dade v tomto směru podniknuty, bylo zvážení
přínosů softwaru, který by zaměstnancům pomohl v případě naléhavé události
telefonicky kontaktovat ty správné manažery.
Walter Hatten, manažer pro technické služby Hancock Bank, se zase zaměřil na
konsolidaci vlastní serverové farmy a vytvoření redundantní komunikační sítě v
té oblasti země, která je průměrně každých 3,5 roku zasažena hurikánem. Banka
se 100 pobočkami a ústředím v Mexickém zálivu konsoliduje 500 serverů na
linuxový mainframe tak, aby snížila dobu nutnou pro obnovu v případě katastrofy.

"Jenom samotný rozsah obnovení 500 serverů pro nás znamená riziko, že to nebude
schopni realizovat včas," říká Hatten. Linux zvolil kvůli otevřeným standardům
a škálovatelnosti. Tvrdí, že mainframe přinese větší rychlost obnovy dat, a
celý proces se tak podaří zkrátit z řádu dní na hodiny.

Když je zavřeno
Maria Herrerová je CTO právní kanceláře Patton Boggs, která má 400 advokátů
specializovaných na mezinárodní obchodní právo. Vzhledem k blízkosti sídla
firmy a amerického Kapitolu je podle jejích slov jednou z neustálých obav
uzavření budovy v důsledku teroristické hrozby.
Herrerová vytvořila duplicitní provozní prostředí v několika dalších pobočkách
a uzavřela smlouvy se dvěma firmami, které se zabývají obnovou provozu po
katastrofě: SunGard Data Systems se zabývá obnovou serverů a pracovních stanic,
AmeriVault má na starosti zálohování dat.
V lednu společnost AmeriVault nainstalovala na desktopech firmy rozhraní
CentralControl a na všech serverech právní kanceláře Patton Boggs agentský
software. Po dokončení počáteční zálohy veškerých dat nyní AmeriVault provádí
inkrementální zálohování změn ve svých centrech ve Walthamu a Filadelfii.
V případě havárie lze data obnovit na dálku, dokonce i z domova. Administrátoři
k tomu využívají point-and-click funkce webového portálu společnosti
AmeriVault. Data je možné také dodat na páskách pro případ rozsáhlého
obnovování. "Každý měsíc či dva stahujeme několik dokumentů od AmeriVault,
abychom systém otestovali," vysvětluje Herrerová. "Jsme schopni kompletně
obnovit data ve firmě za zhruba 10 hodin," dodává.
Herrerová také navrhuje, aby se zkoušek procesu obnovy po katastrofě účastnil
veškerý IT personál, jelikož v případě nouze podle jejích slov nikdy nevíte,
koho budete mít po ruce. Příslušným způsobem také zaškolila zaměstnance ve
všech čtyřech pobočkách po celé zemi. "Firma SunGard má několik středisek, kde
se IT specialisté a právníci mohou setkat a pracovat, pokud dojde k uzavření
sídla firmy," říká Herrerová.
Doug Lilly, starší provozní technik telekomunikací na ministerstvu pro
technologie a informace Delaware, říká, že jeho úřad má k dispozici trojici
datových center, jež mají na starosti podporu zhruba 20 tisíc státních
zaměstnanců. Ministerstvo využívá k replikaci dat mezi datovými centry
Symmetrix Remote Data Facility společnosti EMC. Pro zálohování využívá také
centrální nástroj pro správu od firmy CommVault Systems.
"Pokud by toto středisko vybombardovali, měli bychom k dispozici náhradní
servery, ale data bychom museli obnovit z pásek," vysvětluje Lilly. "Software
firmy CommVault je schopen přenášet data rychlostí 60-65 GB za hodinu. Trvalo
by několik hodin, než by lidé byli opět on-line."
Lilliho IT tým má k dispozici kopii procedur pro obnovu po katastrofě také
doma. "Vedoucí týmu všechny vyrozumí; nosíme s sebou mobilní telefony a
hanheldy BlackBerry, které se připojují k redundantním sítím," upřesňuje.
"Jedná se o značně unifikovanou messagingovou platformu, spojující schopnost
přenášet data, hlas, fax a video do jedné aplikace. Tak jsme k zastižení
kdykoliv a kdekoliv."

Výpadky elektřiny
Edward Koplin, inženýr strojírenské firmy Jack Dale Associates, říká, že
nedostatečné testování obnovy po katastrofě je hlavní příčinou výpadků datových
center v případě přerušení dodávky elektrického proudu. Doporučuje, aby firmy
často testovaly své naftové generátory při plném zatížení po takovou dobu, po
jakou se předpokládá jejich využití při výpadku.
Brill z The Uptime Institute k tomu dodává: "Na výpadek proudu byste měli být
vždy připraveni s nejméně dvěma rezervními generátory oproti potřebnému počtu,
a tyto generátory byste měli testovat doslova odpojením od sítě. Testoval bych
je po takovou dobu, po kterou předpokládám, že by měly pod zátěží fungovat. A
prováděl bych to přinejmenším každé dva až tři roky a nejlépe v létě."
Jim Rittas, bezpečnostní administrátor, který odpovídá ze sítě společnosti
Mizuho Markets, pobočky tokijské Mizuho Financial Group druhé největší firmy na
světě zabývající se finančními službami, říká, že jeho firma je teď schopna
provést kompletní obnovu dat po výpadky proudu nebo jiné havárii během jediné
hodiny, oproti dřívějším dvěma dnům. Dosáhla toho díky zrcadlení dat ve své
pobočce v New Jersey. "Dalším opatřením byla diverzifikace našeho internetového
připojení. Nyní máme připojení jak v New Yorku, tak v New Jersey, dříve jsme se
připojovali pouze přes New York," dodává Rittas.
Výzkumná firma TowerGroup doporučuje přeměnit části center zajišťujících
kontinuitu operací firmy a obnovu po katastrofě na zisková datová centra. Firmy
mají obvykle jedno aktivní datové centrum a pak neobsluhované záložní
středisko. Pokud zvolí takzvaný aktivní model, kdy záložní centra fungují nejen
při výjimečných událostech, tak se eliminuje nutnost přemístění IT zaměstnanců
v případě katastrofy.
Integrací IT prostředků pro obnovu po katastrofě s personálem do provozních
rozpočtů napříč geograficky rozptýlenými datovými centry také pomáhá setřít
čáru mezi obnovou v případě katastrofy a provozními výdaji.
"Optimální je mít neustále k dispozici kopii dat v náhradním centru, nikoliv
pouze některá data," říká Wayne Schletter, ředitel globálních technologií
společnosti Mizuno Capital Markets. "Nebudete chtít slepovat věci kousek po
kousku, když se něco stane. Chcete přece být připraveni ihned," dodává.

Klasické chyby
Steve Ulfelder

Obnova po katastrofě je nepříjemným úkolem. A také proto mají podle Scotta
Lundstroma, analytika AMR Research, prakticky ve všech firmách související
projekty nepřiměřeně nízkou prioritu.
"Neexistují žádní uživatelé, kteří by vyžadovali zajištění kontinuity operací
firmy," konstatuje Lundstrom. "A vzhledem k tomu, že v povaze prakticky všech
IT firem je nikoli prevence, ale hašení požárů, obnova po katastrofě nikdy
nezíská takové zdroje, které by si zasloužila," dodává.
Jelikož obnova po katastrofě stojí oproti ostatním IT projektům v pozadí,
zákonitě se stávají chyby. Zeptali jsme se IT manažerů a dalších expertů, na co
se při plánování obnovy provozu po katastrofě nejčastěji zapomíná. Zde je pět
klasických případů:

Chyba č. 1: Neví se, co je důležité
IT oddělení často zapomínají, že je třeba ptát se koncových uživatelů i
vedoucích pracovníků na to, které aplikace jsou pro ně nejpotřebnější. To vede
k chybným závěrům o prioritách v případě obnovy po katastrofě. Lidé kolem IT
mají tendenci předpokládat, že nejdříve je třeba obnovit výkonné podnikové
aplikace.
Ve skutečnosti mohou být nejpotřebnější aplikace daleko prozaičtější například
e-mail a nástroje pro plánování, jako je třeba Microsoft Outlook. Jak zjistíte
pravdu? Zeptejte se uživatelů.
"Samotná firma potřebuje plán pro případ, že dojde k narušení jejího chodu,"
objasňuje Elbert Lane, vedoucí vývojář softwaru firmy Gap, který se již po 20
let zabývá plánováním obnovy provozu po katastrofě u několika firem. "Je třeba
definovat postupy pro vyřízení papírování apod., takže otázka zní: Jak tyto
postupy obnovit? Nejedná se pouze o problém IT, ale o problém celé firmy."
A poučení? Lidé pohybující se kolem IT neustále slyší slovo "kritický" ve
spojení s CRM a ERP softwarem. Ale abyste zjistili, které aplikace chtějí
uživatelé skutečně obnovit nejdříve, stačí se jich prostě zeptat.

Chyba č. 2: Předpokládá se, že jde výhradně o záležitost IT
V případě krize může být výkonnost IT týmu záležitostí, která firmu zajímá ze
všeho nejméně. "Běžně se předpokládá, že kontinuita provozu firmy a obnova IT
systémů po katastrofě jsou jedna a táž věc," říká Don OConnor, CIO Southern
California Water. "Ale není tomu tak."
Dokonce i nedostatečně připravená IT oddělení se mnohdy zabývají tím, co by
dělala, pokud by došlo ke katastrofě. Ale lze totéž říci i o jiných odděleních
firem? "Podle mé zkušenosti je reakce ze strany IT poměrně rychlá. To, co
zaostává, jsou uživatelé," vysvětluje OConnor.
A poučení? Vedoucí pracovníci musejí pochopit, že rebootování systémů a obnova
dat je pouze jednou z částí problému. Plány pro obnovu provozu po katastrofě
musejí pamatovat také na provozní manažery a koncové uživatele, kteří budou v
krizi odpovídat za chod firmy. "Příliš často je kontinuita něčím, co dostává za
úkol IT," dodává Lundstrom. "Ale jedná se o problém celého podniku."

Chyba č. 3: Očekává se poslední bitva
Jak říká jedno přísloví, generálové se často připravují na svoji poslední
bitvu, a podobně firmy mrhají svými rozpočty na obnovu po katastrofě a svou
energii na přípravu na takovou katastrofu, která se odehrála naposledy. Byť je
to pochopitelné, současně tím porážejí samy sebe katastrofy jsou již svou
povahou prakticky nepředvídatelné.
Nedávná historie ukazuje působivý příklad. 11. září 2001 zdevastoval
teroristický útok na World Trade Center mnoho finančních firem sídlících v New
Yorku. Mnohé z nich by si bývaly přály mít záložní zařízení někde poblíž, a tak
taková zařízení za ohromné peníze začaly budovat hned za řekou v Jersey City.
Ale další závažná krize kontinuity operací firem velký výpadek proudu v srpnu
2003 zasáhla i Jersey City.
A poučení? I když je rozumné zvažovat určité široké krizové kategorie (útok
teroristů, hackerů, zemětřesení, požáry apod.), nemyslete si, že jste schopni
spolehlivě předvídat budoucnost. Neplánujte tedy specifické krizové události,
ale spíše jejich následky.

Chyba č. 4: Lidé jsou přehlíženi
Další lekce z 11. září: Špičkové záložní zařízení pomůže pouze tehdy, pokud je
někdo může používat. "Některé firmy měly záložní datová centra na jižním
Manhattanu," říká Carl Claunch, analytik Gartneru. Nicméně okamžitě po kolapsu
věží World Trade Center policie oblast uzavřela. "Samotné vybavení bylo v
pořádku, ale jen tam leželo a bylo k ničemu." A to se může stát i v takových
případech, kdy je budova uzavřena kvůli karanténě nebo když se rozbije výtah,
či je uzavřena důležitá silnice.
Dalším aspektem tohoto chytáku je odbornost těch, kteří nakonec k záložnímu
vybavení získají přístup. Příliš mnoho společností zejména těch, které
zanedbávají procvičování svých plánů pro obnovu spoléhá na IT hrdiny, kteří je
mají vytáhnout z krize. Ale jak poznamenává Lane: "Nikdy nevíte, zda budete mít
klíčový personál k dispozici."
A poučení? Zde se dostává ke slovu důkladná dokumentace. "Naši dokumentaci
vytváříme takovým způsobem, aby kdokoliv z firmy byl schopen aplikaci
restartovat," vysvětluje Lane. "Měli byste mít někoho, kdo je schopen všechno
nastartovat, byť pracuje třeba v podatelně."

Chyba č. 5: Cvičení jsou prováděna s pochybnými postupy
"Samozřejmě, firmy provádějí testování. Ale jelikož plné testování vyžaduje
velké množství zdrojů, jsou příslušná cvičení plánována dlouho dopředu,"
upozorňuje Claunch. A jaký je pak výsledek? IT pracovníci, hnaní přirozenou
touhou při cvičení vyniknout, podvádějí. "Připravují se. Sbírají nástroje,
přezkoumávají postupy. A pak, když se stane skutečná katastrofa, je to o něčem
zcela jiném!"
Toto je přetrvávající problém IT firem, které jsou vytíženy na maximum ještě
předtím, než se do jejich pracovní náplně dostane obnova po katastrofě. Lane
říká, že i v jejich firmě se cvičení plánují dopředu. "Jsme koncový prodejce,
musíme poskytovat podporu pro naše obchody, a to nepřetržitě," dodává.
A poučení? Zde nelze nalézt žádnou jednoduchou odpověď. Každý věří, že
překvapivý nácvik katastrof je efektivnější, ale provádět takový nácvik v
prostředí e-businessu, které je nepřetržitě v chodu, představuje ohromnou
zátěž. Claunch navrhuje, aby takové překvapivé testy byly prováděny vždy na
jednotlivé podskupině IT tak by se zbytek zaměstnanců mohl starat o běžný
provoz. Některé firmy využívají auditory, kteří mají zajistit, aby pracovníci
IT nespoléhali na předem připravené informace.

Byl pro vás článek přínosný?