Disaster recovery, zálohy, RTO/RPO, failover a především otázka, kterou si mnoho firem klade až po výpadku: opravdu umíme systém obnovit a vrátit se do práce?
Výpadek serveru. Poškozená databáze. Chyba po nasazení. Ransomware. Problémy s poskytovatelem infrastruktury. Náhodné smazání dat. Výpadek celého regionu.
Scénářů je mnoho. Problém je v tom, že většina firem se připravuje hlavně na to, aby k výpadku vůbec nedošlo.
A mnohem méně často se připravuje na situaci, kdy přesto nastane.
Právě to je oblast disaster recovery.
A zde vyvstává základní otázka: pokud vaše aplikace přestane dnes ve 14:00 fungovat, kolik času potřebujete k jejímu opětovnému spuštění a kolik dat při tom můžete ztratit?
Pokud odpověď zní „máme zálohu“, pak to ještě není odpověď na tuto otázku.
Záloha není disaster recovery
Záloha je kopie dat. Disaster recovery je proces obnovení provozu systému.
To je velmi důležité rozlišení.
Můžete mít denně vytvářené kopie databáze, a přesto nevědět:
-
zda je poslední kopie správná,
-
zda ji lze obnovit,
-
jak dlouho obnova potrvá,
-
zda po obnově bude databáze spolupracovat s aktuální verzí aplikace,
-
zda obnovíte i konfiguraci systému,
-
zda máte všechny klíče, certifikáty a tajemství potřebná ke spuštění prostředí,
-
zda je infrastruktura potřebná ke spuštění aplikace stále k dispozici,
-
kdo provede jednotlivé kroky,
-
zda celý proces spadá do byznysově přijatelného času.
NIST výslovně uvádí potřebu testování obnovy ze záloh a aktuální doporučení AWS také považují pravidelné testy recovery za způsob ověření, zda záloha skutečně umožní dosáhnout stanoveného RTO a RPO.
Proto je záloha součástí strategie recovery, nikoli její plnou obdobou.
Nejdůležitější otázka: co se stane po výpadku?
Představme si internetový obchod.
V 10:17 databáze přestane odpovídat.
Aplikační server stále běží, ale uživatelé se nemohou přihlásit. Objednávky nefungují. Administrátorský panel přestane odpovídat. Platební systém nedostává správné informace.
Tým situaci prověří.
Ukáže se, že poslední záloha databáze byla vytvořena v 8:00.
Teoreticky lze data obnovit.
Jenže pak vyvstávají další otázky;
- Ví se, kde se kopie nachází?
- Ví se, jak ji obnovit?
- Je osoba, která to umí, dostupná?
- Je záloha kompletní?
- Odpovídá konfigurace aplikace verzi uložené v kopii?
- Bude databáze po obnově fungovat s aktuální aplikací?
- A nejdůležitější: jak dlouho bude obnovení provozu obchodu trvat?
Pokud to nikdo předtím nezkontroloval, odpověď může být překvapivá.
RTO - jaký výpadek jsme schopni akceptovat?
RTO, tedy Recovery Time Objective, určuje maximální přijatelnou dobu obnovení systému po výpadku.
Například: RTO = 4 hodiny znamená, že organizace předpokládá možnost obnovit provoz systému nejpozději do čtyř hodin.
To však neznamená, že každá aplikace by měla mít RTO čtyři hodiny.
Pro interní systém používaný několikrát denně může být takový čas přijatelný. Pro prodejní platformu běžící 24/7 to může znamenat velmi vážné ztráty.
RTO by tedy mělo vycházet z byznysu, nikoli z toho, co momentálně nabízí infrastruktura.
NIST definuje RTO jako dobu, po kterou může systém zůstat ve fázi obnovy, než to negativně ovlivní činnost organizace.
RPO - kolik dat můžeme ztratit?
Druhým základním parametrem je RPO, tedy Recovery Point Objective.
RPO odpovídá na otázku: jak daleko do minulosti můžeme po výpadku s daty ustoupit?
Příklad: RPO = 1 hodina znamená, že organizace akceptuje potenciální ztrátu maximálně přibližně jedné hodiny dat.
Pokud systém selže v 15:00 a poslední použitelná kopie pochází z 14:00, právě takový scénář odpovídá stanovenému RPO. Ale pokud se záloha vytváří jednou denně, těžko lze očekávat RPO na úrovni jedné hodiny.
RPO tedy přímo ovlivňuje způsob vytváření kopií, replikace dat a návrh infrastruktury.
RTO nám říká především jak dlouho můžeme být nedostupní.
RPO říká kolik dat můžeme ztratit.
Tyto dva parametry by měly být stanoveny společně s byznysem, protože jejich dosažení souvisí s náklady a technickými řešeními. Microsoft také zdůrazňuje, že RTO a RPO by měly vycházet ze skutečných byznysových požadavků, a ne z abstraktního předpokladu „nulový výpadek a nulová ztráta dat“.
Záloha může existovat a přesto být nepoužitelná
To je jeden z nejnebezpečnějších mýtů v IT.
„Záloha se vytváří správně“ automaticky neznamená: „systém z ní lze obnovit“.
Kopie může být neúplná. Může být poškozená. Může obsahovat data, která nelze správně použít. Může být vytvořena způsobem, který neumožňuje obnovit celé prostředí.
Proto je třeba zálohu testovat skutečnou obnovou.
Nestačí zkontrolovat, zda soubor existuje.
Je třeba jej obnovit.
Spustit systém.
Zkontrolovat data.
Ověřit závislosti.
Zkontrolovat konfiguraci.
Změřit čas.
A odpovědět na otázku, zda výsledek odpovídá předpokladům RTO a RPO.
AWS jako typickou chybu uvádí právě obnovu zálohy bez ověření, zda obnovený prostředek skutečně funguje a zda lze s obnovenými daty pracovat.
Failover - když nechceme čekat na obnovu
Ne každá aplikace si může dovolit několikahodinové čekání na obnovení. V takových případech se používají mimo jiné mechanismy failover.
Failover znamená přepnutí provozu z primárního prostředí na připravené záložní prostředí.
Může jít o:
-
záložní server,
-
druhou zónu dostupnosti,
-
druhý region,
-
repliku databáze,
-
standby prostředí,
-
alternativní infrastrukturu připravenou ke spuštění.
V nejjednodušším modelu aplikace běží na jednom místě a v případě poruchy spustíme záložní prostředí. V pokročilejších řešeních část infrastruktury běží paralelně a je připravena převzít provoz.
Neexistuje však jedna strategie vhodná pro všechny.
Backup a restore jsou obvykle levnější, ale mohou znamenat delší dobu obnovy. Řešení typu warm standby nebo aktivní redundance mohou recovery výrazně zkrátit, ale vyžadují vyšší náklady a složitější infrastrukturu.
Failover je také třeba testovat
Zde se objevuje další problém.
Firma může mít záložní prostředí, ale nepoužila ho dva roky;
- Funguje stále ještě?
- Odpovídá konfigurace produkci?
- Má dostatečný výkon?
- Jsou všechny služby dostupné?
- Jsou certifikáty aktuální?
- Přepne se DNS správně?
- Připojí se aplikace k databázi?
- Bude mechanismus autorizace fungovat?
- Ví tým, co přesně má udělat?
Teprve test odpoví na tyto otázky.
AWS doporučuje pravidelné testování failoveru právě proto, aby se ověřilo fungování obnovovací cesty a zkontrolovalo, zda skutečné RTO a RPO odpovídají předpokladům.
Prostředí disaster recovery, které nikdy nebylo testováno, je zčásti jen předpokladem.
Disaster recovery není jen infrastruktura
Je snadné dívat se na DR výhradně prizmatem serverů.
To je chyba.
Recovery zahrnuje také:
- Data
Jsou všechna důležitá data chráněna? - Aplikaci
Máme správnou verzi kódu a možnost ji nasadit? - Konfiguraci
Víme, jaká nastavení jsou potřeba ke spuštění systému? - Tajemství a certifikáty
Máme bezpečný přístup ke klíčům, tokenům a certifikátům? - Externí závislosti
Co se stane, když nebude dostupný externí platební systém, API, poskytovatel identity nebo služba SaaS? - Infrastrukturu
Máme místo, kde lze aplikaci spustit? - Lidi
- Postupy
Existuje konkrétní runbook, nebo recovery stojí na znalostech jedné osoby?
To poslední je obzvlášť důležité.
Jestliže jen jeden administrátor ví, jak systém obnovit, nemáme ještě odolný postup. Máme závislost na konkrétním člověku.
Nejhorší okamžik pro psaní recovery postupu
Je chvíle, kdy systém už nefunguje.
Tehdy přichází tlak času, stres, telefonáty od zákazníků a otázky vedení.
Proto by měl být postup připraven dříve.
Měl by mimo jiné určovat:
-
kdy spouštíme disaster recovery,
-
kdo rozhoduje,
-
které systémy mají nejvyšší prioritu,
-
kde se nacházejí backupy,
-
jak je obnovit,
-
které závislosti je třeba spustit,
-
jak vypadá failover,
-
jak ověřit správnost fungování,
-
jak komunikovat poruchu,
-
kdy lze zahájit failback,
-
kdo schvaluje návrat do primárního prostředí.
V případě vážné poruchy by neměl být prostor pro otázku: „Co teď děláme?”
Postup by na to měl odpovědět předem.
DR by mělo být testováno jako funkce aplikace
Dobrou praxí je přistupovat k recovery podobně jako k testům softwaru. Nestačí jednou připravit postup.
Systém se mění.
Databáze roste.
Mění se závislosti.
Přibývá nová infrastruktura.
Mění se verze aplikací.
Objevují se nové integrace.
Mění se oprávnění.
Proto i strategie recovery vyžaduje průběžné ověřování.
Test lze začít jednoduchým scénářem: „Databáze byla ztracena. Obnovme ji z poslední kopie.”
Později lze přejít ke složitějším scénářům:
- „Aplikační server nefunguje.”
- „Celé produkční prostředí je nedostupné.”
- „Data byla zašifrována.”
- „Nepracuje hlavní region infrastruktury.”
- „Nemáme přístup k hlavnímu administrátorovi.”
Každý takový test může odhalit problémy, které při běžném provozu systému nejsou vidět.
Potřebuje každá aplikace pokročilé disaster recovery?
Ne.
A to je také důležité.
Navrhování infrastruktury odolné proti každému možnému scénáři může být neúměrně drahé.
Pokud porucha interní aplikace může znamenat hodinu nepohodlí, nemusíme nutně potřebovat infrastrukturu active-active ve více regionech. Pokud však porucha systému znamená zastavení prodeje, výroby, zákaznické podpory nebo kritického obchodního procesu, situace vypadá zcela jinak.
Nejprve je třeba určit dopad poruchy na byznys.
Teprve potom vybírat technologii.
To může vést k různým řešením:
Backup + restore
Jednodušší a levnější řešení pro systémy s nižší kritičností.
Warm standby
Záložní prostředí je částečně připravené a může být rychle spuštěno.
Hot standby
Záložní prostředí běží ve větší míře paralelně a je připraveno převzít zátěž.
Active-active
Dvě prostředí mohou současně obsluhovat provoz, čímž se omezuje závislost na jediném místě selhání.
Volba řešení by měla vycházet z RTO, RPO, kritičnosti systému, ceny výpadku a technických možností.
Checklist: je vaše aplikace připravena na výpadek?
Stojí za to si odpovědět na několik jednoduchých otázek.
1. Máme backup?
To je teprve začátek.
2. Je backup uložen způsobem, který ho chrání i před výpadkem produkčního prostředí?
3. Provedli jsme někdy plnou obnovu?
4. Jak dlouho restore skutečně trvá?
5. Známe RTO?
6. Známe RPO?
7. Dokážeme obnovit nejen data, ale i aplikaci a její konfiguraci?
8. Máme recovery postup?
9. Umí ho provést více než jedna osoba?
10. Testovali jsme failover?
11. Je záložní prostředí aktuální?
12. Otestovali jsme po posledních změnách v systému recovery znovu?
Pokud na několik otázek odpovídáme „nevím“, je to velmi vhodná chvíle podívat se na strategii disaster recovery.
Nejdůležitější test zní: „Ukaž“
V IT je velmi snadné říct:
- „Máme zálohu.“
- „Máme záložní server.“
- „Máme postup.“
- „Máme disaster recovery.“
- Ale bezpečnost systému by neměla stát pouze na prohlášeních.
Nejdůležitější otázka zní: Ukaž, že ho umíš obnovit.
- Spusť restore.
- Změř čas.
- Zkontroluj data.
- Otestuj aplikaci.
- Proveď failover.
- Ověř postup.
- Test zopakuj po významných změnách.
Teprve pak lze říct, že strategie recovery byla v praxi ověřena.
Backup chrání data. Recovery obnovuje byznys
To je asi ten nejdůležitější rozdíl.
Backup odpovídá na otázku: „Máme kopii?”
Disaster recovery odpovídá na mnohem těžší otázku: „Dokážeme se po havárii vrátit do provozu?”
A mezi jedním a druhým je celá architektura obnovy: RPO, RTO, replikace, backupy, restore, failover, konfigurace, postupy, odpovědnost a pravidelné testy.
Dobře navržený systém nepředpokládá, že k poruše nikdy nedojde. Předpokládá, že k poruše jednou dojde a bude třeba vědět, co dělat.
Protože skutečná odolnost aplikace nespočívá v tom, že se nikdy neporouchá. Spočívá v tom, že když se něco pokazí, organizace se dokáže vrátit do provozu předvídatelným, kontrolovaným způsobem a v souladu s požadavky byznysu.
Slovníček
Disaster Recovery (DR) - strategie a postupy umožňující obnovit provoz systémů po závažné havárii.
Backup - kopie dat určená k jejich pozdější obnově.
Restore - proces obnovy dat nebo systému ze zálohy.
RTO (Recovery Time Objective) - maximální akceptovatelný čas obnovení systému.
RPO (Recovery Point Objective) - maximální akceptovatelná ztráta dat vyjádřená v čase.
Failover - přepnutí provozu systému z primárního prostředí na záložní.
Failback - návrat provozu do primárního prostředí po odstranění příčiny poruchy.
Recovery test - test, který má potvrdit, že systém lze skutečně obnovit podle přijatých předpokladů.
Runbook - podrobný návod postupu v určitém scénáři poruchy.
