Disaster recovery, zálohy, RTO/RPO, failover a predovšetkým otázka, ktorú si mnohé firmy kladú až po výpadku: naozaj dokážeme obnoviť systém a vrátiť sa do práce?
Výpadok servera. Poškodená databáza. Chyba po nasadení. Ransomware. Problémy s poskytovateľom infraštruktúry. Náhodné zmazanie dát. Výpadok celého regiónu.
Scenárov je veľa. Problém je v tom, že väčšina firiem sa pripravuje predovšetkým na to, aby k výpadku vôbec nedošlo.
A oveľa zriedkavejšie sa pripravuje na situáciu, keď predsa len nastane.
Práve to je oblasť disaster recovery.
A tu sa objavuje základná otázka: ak vaša aplikácia dnes o 14:00 prestane fungovať, koľko času potrebujete na jej opätovné spustenie a koľko dát pri tom môžete stratiť?
Ak odpoveď znie „máme zálohu“, stále to nie je odpoveď na túto otázku.
Záloha nie je disaster recovery
Záloha je kópia dát. Disaster recovery je proces obnovy fungovania systému.
Ide o veľmi dôležité rozlíšenie.
Môžete mať denne vytvárané kópie databázy, a napriek tomu nevedieť:
-
či je posledná kópia správna,
-
či sa dá obnoviť,
-
ako dlho obnova potrvá,
-
či po obnove bude databáza spolupracovať s aktuálnou verziou aplikácie,
-
či obnovíte aj konfiguráciu systému,
-
či máte všetky kľúče, certifikáty a tajomstvá potrebné na spustenie prostredia,
-
či je infraštruktúra potrebná na spustenie aplikácie stále k dispozícii,
-
kto má vykonať jednotlivé kroky,
-
či celý proces spĺňa čas prijateľný z pohľadu biznisu.
NIST priamo upozorňuje na potrebu testovania obnovy zo záloh a aktuálne odporúčania AWS takisto považujú pravidelné recovery testy za spôsob overenia, či záloha skutočne umožní dosiahnuť stanovené RTO a RPO.
Preto je záloha súčasťou stratégie obnovy, nie jej plnohodnotnou náhradou.
Najdôležitejšia otázka: čo sa stane po výpadku?
Predstavme si internetový obchod.
O 10:17 databáza prestane odpovedať.
Aplikačný server stále beží, ale používatelia sa nemôžu prihlásiť. Objednávky nefungujú. Administrátorský panel prestane reagovať. Platobný systém nedostáva správne informácie.
Tím preverí situáciu.
Ukáže sa, že posledná záloha databázy bola vytvorená o 8:00.
Teoreticky sa dá dáta obnoviť.
Ale potom sa objavia ďalšie otázky;
- Vieme, kde sa kópia nachádza?
- Vieme, ako ju obnoviť?
- Je osoba, ktorá to vie urobiť, dostupná?
- Je záloha kompletná?
- Zodpovedá konfigurácia aplikácie verzii uloženej v kópii?
- Bude databáza po obnove fungovať s aktuálnou aplikáciou?
- A najdôležitejšie: ako dlho potrvá obnovenie fungovania obchodu?
Ak to nikto predtým neoveril, odpoveď môže prekvapiť.
RTO - aký dlhý výpadok sme schopní akceptovať?
RTO, teda Recovery Time Objective, určuje maximálny prijateľný čas obnovenia systému po výpadku.
Napríklad: RTO = 4 hodiny znamená, že organizácia predpokladá možnosť obnoviť fungovanie systému najneskôr do štyroch hodín.
To však neznamená, že každá aplikácia by mala mať RTO štyri hodiny.
Pre interný systém používaný niekoľkokrát denne môže byť taký čas prijateľný. Pre predajnú platformu fungujúcu 24/7 to môže znamenať veľmi vážne straty.
RTO by teda malo vychádzať z biznisu, nie z toho, čo práve ponúka infraštruktúra.
NIST definuje RTO ako čas, počas ktorého môže systém zostať vo fáze obnovy, kým to negatívne ovplyvní činnosť organizácie.
RPO - koľko dát môžeme stratiť?
Druhým základným parametrom je RPO, teda Recovery Point Objective.
RPO odpovedá na otázku: ako ďaleko do minulosti sa môžeme po výpadku vrátiť s dátami?
Príklad: RPO = 1 hodina znamená, že organizácia akceptuje potenciálnu stratu maximálne približne jednej hodiny dát.
Ak systém zlyhá o 15:00 a posledná použiteľná kópia pochádza z 14:00, práve taký scenár spadá do stanoveného RPO. Ak sa však záloha vykonáva raz denne, ťažko očakávať RPO na úrovni jednej hodiny.
RPO teda priamo ovplyvňuje spôsob vytvárania záloh, replikácie dát a návrh infraštruktúry.
RTO nám hovorí predovšetkým ako dlho môžeme byť nedostupní.
RPO hovorí koľko dát môžeme stratiť.
Tieto dva parametre by sa mali stanoviť spoločne s biznisom, pretože ich dosiahnutie súvisí s nákladmi a technickými riešeniami. Microsoft tiež zdôrazňuje, že RTO a RPO by mali vychádzať zo skutočných biznisových požiadaviek, nie z abstraktného predpokladu „nula výpadkov a nula straty dát“.
Záloha môže existovať a napriek tomu byť nepoužiteľná
Je to jeden z najnebezpečnejších mýtov v IT.
„Záloha sa vytvára správne” automaticky neznamená: „systém sa z nej dá obnoviť”.
Kópia môže byť neúplná. Môže byť poškodená. Môže obsahovať dáta, ktoré sa nedajú správne použiť. Môže byť vytvorená spôsobom, ktorý neumožní obnoviť celé prostredie.
Preto treba zálohu testovať skutočným obnovením.
Nestačí skontrolovať, či súbor existuje.
Treba ho obnoviť.
Spustiť systém.
Skontrolovať dáta.
Overiť závislosti.
Skontrolovať konfiguráciu.
Zmerať čas.
A odpovedať na otázku, či výsledok zodpovedá predpokladom RTO a RPO.
AWS ako typickú chybu uvádza práve obnovu zálohy bez overenia, či obnovený zdroj skutočne funguje a či je možné používať obnovené dáta.
Failover - keď nechceme čakať na obnovu
Nie každá aplikácia si môže dovoliť niekoľko hodín čakania na obnovenie. V takých prípadoch sa používa napríklad mechanizmus failover.
Failover znamená prepnutie fungovania z primárneho prostredia na pripravené záložné prostredie.
Môže to byť:
-
záložný server,
-
druhá dostupnostná zóna,
-
druhý región,
-
replika databázy,
-
standby prostredie,
-
alternatívna infraštruktúra pripravená na spustenie.
V najjednoduchšom modeli aplikácia beží na jednom mieste a v prípade poruchy spúšťame záložné prostredie. V pokročilejších riešeniach časť infraštruktúry beží paralelne a je pripravená prevziať prevádzku.
Neexistuje však jedna stratégia vhodná pre všetkých.
Backup a restore sú zvyčajne lacnejšie, ale môžu znamenať dlhší čas obnovenia. Riešenia typu warm standby alebo aktívna redundancia môžu výrazne skrátiť recovery, ale vyžadujú vyššie náklady a zložitejšiu infraštruktúru.
Failover treba tiež testovať
Tu sa objavuje ďalší problém.
Firma môže mať záložné prostredie, ale dva roky ho nepoužila;
- Stále funguje?
- Zodpovedá konfigurácia produkcii?
- Má dostatočný výkon?
- Sú dostupné všetky služby?
- Sú certifikáty aktuálne?
- Prepne sa DNS správne?
- Pripojí sa aplikácia k databáze?
- Bude fungovať mechanizmus autorizácie?
- Vie tím, čo presne má urobiť?
Až test dá odpoveď na tieto otázky.
AWS odporúča pravidelne testovať failover práve preto, aby overil fungovanie cesty obnovenia a skontroloval, či skutočné RTO a RPO zodpovedajú predpokladom.
Prostredie disaster recovery, ktoré sa nikdy netestovalo, je len čiastočne predpokladom.
Disaster recovery nie je len infraštruktúra
Ľahko sa dá pozerať na DR výlučne cez prizmu serverov.
To je chyba.
Recovery zahŕňa aj:
- Dáta
Sú všetky dôležité údaje chránené? - Aplikáciu
Máme správnu verziu kódu a možnosť jej nasadenia? - Konfiguráciu
Vieme, aké nastavenia sú potrebné na spustenie systému? - Tajomstvá a certifikáty
Máme bezpečný prístup ku kľúčom, tokenom a certifikátom? - Externé závislosti
Čo sa stane, ak nebude dostupný externý platobný systém, API, poskytovateľ identity alebo služba SaaS? - Infraštruktúru
Máme miesto, kde sa dá aplikácia spustiť? - Ľudí
Je jasné, kto rozhoduje o spustení procedúry? - Postupy
Existuje konkrétny runbook, alebo recovery stojí na vedomostiach jednej osoby?
To posledné je obzvlášť dôležité.
Ak iba jeden administrátor vie, ako obnoviť systém, ešte nemáme odolný postup. Máme závislosť od konkrétneho človeka.
Najhorší moment na písanie recovery procedúry
Je to okamih, keď systém už nefunguje.
Vtedy prichádza tlak času, stres, telefonáty od zákazníkov a otázky vedenia.
Preto by mala byť procedúra pripravená vopred.
Mala by určiť okrem iného:
-
kedy spúšťame disaster recovery,
-
kto prijíma rozhodnutie,
-
ktoré systémy majú najvyššiu prioritu,
-
kde sa nachádzajú zálohy,
-
ako ich obnoviť,
-
ktoré závislosti treba spustiť,
-
ako vyzerá failover,
-
ako overiť správnosť fungovania,
-
ako komunikovať poruchu,
-
kedy možno začať failback,
-
kto schvaľuje návrat do primárneho prostredia.
V prípade vážnej poruchy by nemalo byť miesto na otázku: „Čo teraz robíme?”
Procedúra by na to mala odpovedať vopred.
DR by sa malo testovať ako funkcia aplikácie
Dobrá prax je pristupovať k recovery podobne ako k testom softvéru. Nestačí raz pripraviť procedúru.
Systém sa mení.
Databáza rastie.
Menia sa závislosti.
Pribúda nová infraštruktúra.
Menia sa verzie aplikácií.
Objavujú sa nové integrácie.
Menia sa oprávnenia.
Preto si stratégia recovery vyžaduje aj priebežnú kontrolu.
Test možno začať jednoduchým scenárom: „Databáza bola stratená. Obnovme ju z poslednej kópie.”
Neskôr možno prejsť k zložitejším scenárom:
- „Aplikačný server nefunguje.”
- „Celé produkčné prostredie je nedostupné.”
- „Údaje boli zašifrované.”
- „Nepracuje základný infraštruktúrny región.”
- „Nemáme prístup k hlavnému administrátorovi.”
Každý takýto test môže odhaliť problémy, ktoré pri bežnej prevádzke systému nevidno.
Potrebuje každá aplikácia pokročilé disaster recovery?
Nie.
A to je tiež dôležité.
Navrhnúť infraštruktúru odolnú voči každému možnému scenáru môže byť neúmerne drahé.
Ak porucha internej aplikácie môže znamenať hodinu nepríjemností, nevyhnutne nepotrebujeme infraštruktúru active-active vo viacerých regiónoch. Ak však porucha systému znamená zastavenie predaja, výroby, zákazníckej podpory alebo kritického obchodného procesu, situácia vyzerá úplne inak.
Najprv treba určiť vplyv poruchy na biznis.
Až potom vyberať technológiu.
To môže viesť k rôznym riešeniam:
Backup + restore
Jednoduchšie a lacnejšie riešenie pre systémy s nižšou kritickosťou.
Warm standby
Záložné prostredie je čiastočne pripravené a môže byť rýchlo spustené.
Hot standby
Záložné prostredie beží vo väčšej miere paralelne a je pripravené prevziať záťaž.
Active-active
Dve prostredia môžu súčasne obsluhovať prevádzku, čím sa obmedzí závislosť od jedného miesta poruchy.
Výber riešenia by mal vyplývať z RTO, RPO, kritickosti systému, nákladov na odstávku a technických možností.
Checklist: je vaša aplikácia pripravená na poruchu?
Oplatí sa odpovedať si na niekoľko jednoduchých otázok.
1. Máme backup?
To je len začiatok.
2. Je backup uložený spôsobom, ktorý ho chráni aj pred poruchou produkčného prostredia?
3. Urobili sme niekedy úplné obnovenie?
4. Ako dlho restore skutočne trvá?
5. Poznáme RTO?
6. Poznáme RPO?
7. Vieme obnoviť nielen dáta, ale aj aplikáciu a jej konfiguráciu?
8. Máme recovery procedúru?
9. Vie ju vykonať viac než jedna osoba?
10. Testovali sme failover?
11. Je záložné prostredie aktuálne?
12. Po posledných zmenách v systéme sme recovery otestovali znova?
Ak na niekoľko otázok odpovedáme „neviem“, je to veľmi dobrý moment pozrieť sa na stratégiu disaster recovery.
Najdôležitejší test znie: „Ukáž”
V IT je veľmi ľahké povedať:
- „Máme zálohu.”
- „Máme záložný server.”
- „Máme postup.”
- „Máme disaster recovery.”
- Ale bezpečnosť systému by nemala stáť výlučne na vyhláseniach.
Najdôležitejšia otázka znie: Ukáž, že ho vieš obnoviť.
- Spusť restore.
- Zmeraj čas.
- Skontroluj údaje.
- Otestuj aplikáciu.
- Vykonaj failover.
- Skontroluj postup.
- Zopakuj test po významných zmenách.
Až potom možno povedať, že stratégia recovery bola overená v praxi.
Backup chráni dáta. Recovery obnovuje biznis
To je asi najdôležitejší rozdiel.
Backup odpovedá na otázku: „Máme kópiu?”
Disaster recovery odpovedá na oveľa náročnejšiu otázku: „Viemе sa po havárii vrátiť k fungovaniu?”
A medzi jedným a druhým sa nachádza celá architektúra obnovy: RPO, RTO, replikácia, zálohy, restore, failover, konfigurácia, postupy, zodpovednosť a pravidelné testy.
Dobre navrhnutý systém nepredpokladá, že sa porucha nikdy nestane. Predpokladá, že raz sa stane a bude treba vedieť, čo robiť.
Pretože skutočná odolnosť aplikácie nespočíva v tom, že sa nikdy nepokazí. Spočíva v tom, že keď sa niečo pokazí, organizácia sa vie vrátiť k fungovaniu predvídateľným, kontrolovaným a s požiadavkami biznisu zosúladeným spôsobom.
Slovníček
Disaster Recovery (DR) - stratégia a postupy umožňujúce obnoviť fungovanie systémov po vážnej poruche.
Backup - kópia údajov určená na ich neskoršie obnovenie.
Restore - proces obnovy údajov alebo systému zo zálohy.
RTO (Recovery Time Objective) - maximálny akceptovateľný čas obnovy systému.
RPO (Recovery Point Objective) - maximálna akceptovateľná strata údajov vyjadrená časom.
Failover - prepnutie fungovania systému z primárneho prostredia na záložné.
Failback - návrat fungovania do primárneho prostredia po odstránení príčiny poruchy.
Recovery test - test, ktorý má potvrdiť, že systém možno skutočne obnoviť v súlade s prijatými predpokladmi.
Runbook - podrobný návod postupu v konkrétnom scenári poruchy.
