Skoro každý, kdo provozuje nějaký ten online projekt, už to asi zažil: dorazí SMS nebo automatický hovor z monitoringu, že něco nefunguje. Vašemu milovanému projektu je ouvej a žádá si vaši pozornost.
Nemusí to být ani katastrofa typu požár datacentra, nebo zemětřesení – vyřadit systémy zvládne i prasklé potrubí v budově, administrátorská chyba na síti v Indii nebo neodborný zásah uživatele. Pamětníci si jistě vzpomenou na rok 2007 a kauzu s heslem NBUSR123.
Ve vshosting~ děláme všechno pro to, abychom podobným situacím zabránili – víc se o tom dočtete v článku o našem nekompromisním zabezpečení. Přesto, ne všechny rizikové faktory a skutečnosti jsou v naší moci a vznik nenadálých situací tak nelze vyloučit. Scénář je pak vždy stejný. Najednou, bez jakéhokoliv varování, všechno zhasne a monitoring se rozsvítí rudě. Nic nefunguje. A co teď?
Můžete si stěžovat, nadávat, panikař… nebo aktivovat svoje disaster recovery plány. Scénáře, které jste sepsali v době klidu pro případ, že se něco hodně, ale hodně pokazí. Dokumenty, o kterých jste doufali, že je nikdy nebudete muset číst.
Co jsou disaster recovery plány a jak mají vypadat
Disaster recovery plány jsou dokumenty, které jasně popisují, jak dostat váš projekt zpět do funkčního stavu. Mají mnoho podob a pokrývají spoustu možných scénářů. Mohou to být jednoduché seznamy krizových přístupů ale i komplexní postupy, které zahrnují úkony napříč několika odděleními ve firmě.
Vždy by měly obsahovat:
- co je potřeba udělat
- kdo to má udělat
- jak to má udělat
- kde jsou dostupné zálohy
- v jakém pořadí nahazovat služby
- kdy obnovovat která data
Vhodné je zahrnout i přihlašovací údaje na krizové účty, ať je máte po ruce. Cílem disaster recovery plánů je vždy minimalizovat obchodní dopad katastrofy a co nejrychleji postavit projekt zpátky na nohy. Musí být napsány jasně a stručně. Protože když už podle nich budete postupovat, určitě to nebude v klidu a v pohodě.
Zálohovací řešení vám ušijeme na míru.
Je běžné, že disaster recovery plány nejsou čistě IT charakteru a mají přesah do dalších oddělení ve firmě. Kromě technického zvládnutí problému totiž potřebujete i udržovat kontakt se zákazníky, případně zajistit podklady pro právní oddělení. Proto je potřeba při sepisování disaster recovery plánů přibrat na pomoc zástupce jiných oddělení a konzultovat jednotlivé kroky s nimi. Musíte mít jistotu, že postupy dávají všem smysl a nezapomněli jste na nějaký netechnický dopad.
Při jejich tvorbě můžeme vycházet z principu letectví. Pokud dojde v letadle k problému, platí postup „Aviate, Navigate, Communicate“, tedy udržet letadlo ve vzduchu, zjistit, kde jste a kam se můžete vydat a až pak se zabývat komunikací.
V IT toto lze využít obdobně. Nejprve se snažte zachránit, co jde (tj. minimalizovat přímé dopady, klidně odstavením systémů). Dostaňte systém do dostatečně stabilní podoby, a až pak zajistěte komunikaci ven. Pokud máte k dispozici více administrátorů, lze proces paralelizovat, a je to i vhodné. Umíte si představit horší situaci, než když admina otravují s dotazy jeho kolegové z obchodu a customer supportu a ptají se, co mají říci klientům?
Krok 1: Udržte projekt „nad vodou“
Když letadlo spadne na zem, je konec. Přišli jste o letadlo, posádku, náklad i pasažéry. Proto je potřeba ho za každou cenu udržet ve vzduchu.
V IT to funguje podobně. Pokud přijdete o jednu službu, je potřeba minimalizovat dopady na ty další. Zabránit kaskádovému efektu. Nemůžete si dovolit přijít o všechno. A to i za cenu odstávky. Když přijdete o všechna data i systémy, je to pro firmu naprosté existenční riziko. Krátkodobá odstávka projektu je výrazně menší zlo než dlouhodobá obnova dat.
Typickým příkladem toho je chyba v aplikaci, která při updatu ukládá poškozená data. V tomto případě je mnohem lepší aplikaci odstavit a zabránit zničení většího množství dat, než ji nechat běžet a pracovat na vydání opravy.
Krok 2: Zorientujte se
Výborně, v prvním kroku jste úspěšně zabránili zničení všech dat. Nicméně stále vzniká škoda, aplikace je nedostupná, klienti začínají být naštvaní. To je správná chvíle začít zjišťovat, co se stalo, jaké jsou celkové dopady a připravit plán na obnovu.
Lze opravit aplikaci jednoduchým fixem? Je potřeba obnovit nějaká data ze zálohy? Jak dlouho bude trvat návrat do minimálního funkčního stavu? A jak dlouho bude trvat kompletní oprava? O kolik dat jste nenávratně přišli? To jsou všechno otázky, které jsou teď na stole, a na které potřebujete rychle znát odpověď.
Krok 3: Komunikujte se zákazníky
V této fázi už víte co se stalo, co musíte udělat i jaké jsou dopady na vaši společnost. Dokonce i jak dlouho bude trvat oprava. V tuto chvíli můžete komunikovat zákazníkům odhad časové náročnosti.
Doporučujeme vyčlenit jednoho pracovníka jako styčný bod pro komunikaci. Někoho, kdo bude od začátku mluvit s obchodem, podporou a se zákazníky. Zároveň bude sloužit jako štít stojící před adminy, kteří zachraňují situaci. Tuto roli se hodí přidělit někomu z řízení projektu, v agile světě by to byl project owner. A důležité je také zajistit, aby všichni ve firmě věděli, na koho se mají obracet s dotazy.
Komunikace ven je bezesporu důležitá, a v krizi o to víc. Avšak, neměla by být na úkor obnovy provozu. Hlavně pro obchod a podporu vždy platí, že informace, které jim předáváme, musí být aktuální a platné v daném časovém bodě. Nemusí být ale 100% přesné a neměnné. Vždy stavíme na tom, co v daném bodě víme.
Na začátku se situace může zdát snadno opravitelná, ale další průzkum může odhalit mnohem dramatičtější dopady. Anebo naopak. Proto doporučujeme nikdy nekomunikovat termíny a odhady jako definitivní. Pokaždé je potřeba říct „ale situace se může změnit“, vždy je potřeba pro jistotu počítat s výrazným prodloužením obnovy. S tím musí počítat všichni lidi ve firmě.
Pravomoce krizového řízení
V klidných dobách je pochopitelné, že velké investice nebo zásahy do infrastruktury je nutné konzultovat s vedením firmy a důkladně je naplánovat. Můžete déle vybírat nejvýhodnějšího dodavatele, dohodnout s ním dobré obchodní podmínky, zanalyzovat a otestovat dopady řešení. Jakmile ale udeří krize, rozvážnost jde z velké části stranou.
Záchranný tým potřebuje mít pravomoce činit rozhodnutí rychle a neřešit zcela optimální efektivitu či úspornost. Pokud vám „umře“ nějaký klíčový hardware a nemáte skladem náhradní kus, není prostor na vyjednávání s dodavateli. Je potřeba vzít firemní kartu, sednout do auta a vyrazit do nejbližšího obchodu, který má nový kus skladem. A to i za cenu vyšších nákladů. Je snad dlouhá odstávka vašeho projektu levnější?
Pokud fungujete v cloudu, záchranný tým musí mít pravomoc ihned spustit další instance – bez ohledu na rozpočet infrastruktury. Případně si dopředu stanovte hranice rozpočtu, přes které nelze jít, ale zvažte přitom náklady na každou minutu, kdy váš projekt nefunguje.
Zálohy, zálohy, zálohy
Zálohy a jejich obnova jsou nedílnou součástí každých disaster recovery plánů. A to nejen zálohy mít, ale jejich funkčnost pravidelně testovat a nastavit optimální zálohovací frekvenci. Bez ohledu na to, jestli máte infrastrukturu v cloud nebo ne.
I v cloudu je třeba zálohovat!
Často se setkáváme s názorem, že infrastrukturu a data v cloudu není třeba zálohovat. Slýcháváme, že: „proto si přece platíme cloud, abychom nemuseli utrácet za zálohy“. Tento přístup je chybný a u jeho zastánců může vést až ke krachu firmy.
V cloudu si pořizujete výpočetní kapacitu, prostor na storage a služby s ním spojené, ale nekupujete si bezpečnost vašich dat. Kupujete si pouze jistotu, že v případě problémů můžete data do cloudu obnovit a spustit novou sadu serverů. Je ale vaše zodpovědnost mít kopii dat k obnově, mít informace o konfiguraci serverů a mít popsaný postup nasazení aplikace.
Cloud vám poskytuje platformu, ale obchodní hodnotu jí dáváte vy. Cloud je vám v tom schopen pomoci georeplikací, nebo službou na zálohování. Zájem o její využití musíte mít vy, včetně toho dát jí smysl a mít připravený proces obnovy dat.
Testování kvality záloh a optimální backup frekvence
Potřebujete mít také jistotu, že zálohy jste schopni obnovit. Až příliš často se stává, že firma sice krásně zálohovala, ale když došlo na potřebu obnovy, zálohy byly nepoužitelné. A nemusí to být jenom chyba v záloze jako takové. Zálohy mohou být z důvodu problému nedostupné nebo nekompletní. A proto je třeba je pravidelně testovat. Vyzkoušet si, že jste schopni si data ze záloh obnovit, stejně tak, že zálohujete vše, co potřebujete – a v dostatečném množství.
Nikdy nebudete mít v záloze 100 % dat, vždy o něco přijdete. Zůstává otázkou, jestli můžete ztratit data za týden, za den nebo za hodinu. O kolik dat jste ochotni přijít? Respektive, kolik peněz je vaše firma ochotná do zálohování a obnovy dat investovat? Zde platí nelineární vztah – pokud zálohování 1x denně stojí XY kč, zálohování 2x denně nestojí 2 XY kč, ale klidně 5 XY, nebo 10 XY. Je třeba si říct, jestli mají data mimo zálohu takovou hodnotu, nebo jestli je výhodnější tato data již obětovat.
Co si z toho odnést
Nic není 100% a chyby se stávají. Každý admin už podobnou situaci zažil a nikdy to není příjemné. Přesto se vždy dá na situaci připravit předem a minimalizovat její dopady na chod firmy.
Není to zadarmo a není to snadné. A v klidných časech to může vypadat, že vám to nic nepřináší, ale zabrání to velkým problémům v budoucnu. A vždy se to vyplatí. Myslete na to.
Chcete se poradit o optimálním režimu zálohování pro váš projekt? Obraťte se na naše experty: konzultace@vshosting.cz. Zdarma vám připraví řešení na míru.