Čeština
Z praxe / Záložná prevádzka
Failover, RTO a RPO: ako rýchlo sa firma vráti do prevádzky?
Záloha, replikácia a failover riešia rozdielne problémy. Ako určiť prípustný výpadok, stratu dát a overiť návrat webu či interného systému?
Otázka „máme zálohu?“ je iba začiatok. Firma potrebuje vedieť, koľko času môže stratiť, koľko dát si môže dovoliť obnovovať a ktoré funkcie musia bežať počas problému. Z týchto odpovedí sa navrhuje technické riešenie.
RTO a RPO ľudskou rečou
RTO je cieľová najdlhšia prípustná doba od prerušenia služby po jej obnovenie. RPO vyjadruje prípustný časový úsek dát, o ktorý môže firma pri obnove prísť. Obe hodnoty vychádzajú z potrieb konkrétnej organizácie. Definície AWS Well-Architected.
Firma si môže stanoviť cieľ obnoviť objednávky do jednej hodiny a pripustiť stratu najviac pätnástich minút nových dát. Až následne sa overuje, či jej infraštruktúra a postupy tieto ciele zvládnu.
Záloha, replikácia a failover
Záloha
Uchováva obnoviteľný stav dát alebo systému. Potrebuje vhodné oddelenie, históriu a test čitateľnosti i obnovy.
Replikácia
Prenáša zmeny do ďalšieho prostredia. Sama nevylučuje prenos chybnej zmeny alebo poškodených dát.
Failover
Prepína službu na pripravenú náhradnú prevádzku. Vyžaduje dáta, kapacitu, prístupy a funkčný rozhodovací postup.
Tieto mechanizmy sa kombinujú podľa rizík a rozpočtu. Pri napadnutí je navyše dôležité obnovovať dôveryhodné prostredie a odstrániť príčinu, nie iba rýchlo spustiť jeho ďalšiu kópiu.
Čo môže brániť rýchlemu prepnutiu
- Záložná databáza neobsahuje potrebný stav alebo nemá primeranú kapacitu.
- Obe prostredia zdieľajú nefunkčnú identitu, DNS alebo riadiacu službu.
- Chýba prístup správcu alebo bezpečne uložený obnovovací kľúč.
- Nie je dohodnuté, kto môže vyhlásiť incident a spustiť obnovu.
- Po návrate sa nesprávne opakujú platby, rezervácie alebo integračné úlohy.
Testujte celý postup, nie iba štart servera
AWS vo svojich odporúčaniach zdôrazňuje pravidelné skúšanie failover a overenie cieľov obnovy. Upozorňuje aj na kapacitu a predpoklady, ktoré nemusia pri reálnom výpadku platiť. Odporúčania k testom obnovy.
Test vopred naplánujte podľa rizika, s oprávnenými ľuďmi a dohodnutými ochrannými podmienkami. Zahŕňajte detekciu, rozhodnutie, prístupy, spustenie, funkčné overenie a návrat do bežného režimu. Zapisujte čas aj prekážky.
Objednávka musí fungovať aj po obnove
Pri e-shope overte prihlásenie, produkty, platby, dopravu, sklad a potvrdenia. Pri internom systéme skúste skutočnú pracovnú úlohu. Po prepnutí treba vedieť, kde vznikajú nové dáta a ako sa neskôr zosúladia.
Výsledkom má byť záznam: čo sa obnovilo, za aký čas, s akým stavom dát a čo ešte nefungovalo. Až podľa neho sa dá rozumne zlepšovať plán.
Pomôžeme pomenovať kritické služby, dohodnúť RTO a RPO, navrhnúť záložné postupy a vykonať test v dohodnutom rozsahu. Cieľom je overiteľný postup pre ľudí aj technológie.
Zdroje a ďalšie čítanie
Odkazy vedú na pôvodné oznámenia, správy a dokumentáciu, z ktorých článok vychádza.
