70. Disaster recovery a business continuity plánování

Úvod a kontext

Škálovatelnost z minulé lekce řeší, jak zvládnout růst za normálních
podmínek. Disaster recovery (DR) řeší opačnou otázku: co se stane,
když celé datacentrum nebo celý cloudový region vypadne — požár,
přírodní katastrofa, rozsáhlý výpadek poskytovatele, nebo lidská
chyba, která smaže produkční data? Tato lekce ukazuje, jak na tyto
scénáře plánovat předem, ne je řešit improvizovaně, až nastanou.

Teorie

Disaster recovery vs. business continuity

Disaster recovery (DR) je technický plán, jak obnovit IT systémy
po závažné události — jaké kroky, v jakém pořadí, s jakými nástroji.
Business continuity (BC) je širší pojem — jak firma jako celek
pokračuje v provozu i mimo IT (např. náhradní komunikační kanály se
zákazníky, ruční procesy, pokud systémy nejedou). Tato lekce se
soustředí hlavně na DR, protože to je oblast, kde má DevOps/SRE
inženýr přímou odpovědnost, ale BC je kontext, do kterého DR plán
zapadá.

RTO a RPO — dvě klíčová čísla DR plánu

• RTO (Recovery Time Objective) — jak dlouho smí trvat, než se
  systém po katastrofě vrátí do provozu. RTO 4 hodiny znamená, že
  firma akceptuje až 4hodinový výpadek, než musí být služba znovu
  dostupná.
• RPO (Recovery Point Objective) — kolik dat smí být ztraceno,
  vyjádřeno v čase. RPO 1 hodina znamená, že je akceptovatelné
  přijít o data vzniklá za poslední hodinu před havárií (typicky
  odpovídá frekvenci záloh nebo replikace).

Tato dvě čísla nejsou technické detaily, ale obchodní
rozhodnutí — musí je schválit byznys, protože nižší RTO/RPO
znamená vyšší náklady na infrastrukturu (častější zálohy, aktivní
druhý region, redundantní systémy). DevOps tým čísla implementuje,
ale nemá je vymýšlet sám bez konzultace s byznysem.

Strategie zálohování a obnovy

Navazuje na zálohování databází z modulu 6, rozšířené na celou
infrastrukturu:

• Pravidelné automatizované zálohy s definovanou retencí
  (kolik verzí se drží, jak dlouho) a uložené mimo primární
  lokalitu — záloha uložená na stejném disku/serveru jako
  produkční data nechrání proti ztrátě celého serveru.
• Infrastructure as Code (moduly 10) jako součást DR plánu —
  pokud je celá infrastruktura popsaná v Terraformu/Ansible, obnova
  neznamená ruční rekonstrukci serverů z paměti, ale spuštění
  terraform apply v nové lokalitě.
• Pravidelné testování obnovy. Záloha, která nebyla nikdy
  vyzkoušena, se v praxi řadu firem stala "zálohou, která se
  nedala obnovit", protože záloha byla poškozená nebo neúplná a
  nikdo si toho nevšiml, dokud nebylo pozdě. DR plán bez
  pravidelného testu je jen teorie.

Architektury podle úrovně dostupnosti

• Zálohuj a obnov (backup & restore). Nejlevnější varianta —
  data se pravidelně zálohují, v případě havárie se infrastruktura
  postaví znovu (ideálně přes IaC) a data se obnoví ze zálohy. Má
  vysoké RTO (hodiny až dny), nízké náklady.
• Pilot light. Minimální verze produkční infrastruktury běží
  neustále v záložním regionu (např. jen databáze s replikací), ale
  aplikační vrstva se aktivuje/škáluje až při havárii. Střední
  RTO/náklady.
• Warm standby. Zmenšená, ale plně funkční kopie produkčního
  prostředí běží trvale v záložním regionu a v případě havárie se
  jen zvětší (přeškáluje). Nižší RTO, vyšší náklady.
• Multi-site active/active. Produkce běží současně ve více
  regionech a zátěž se mezi nimi rozděluje průběžně (ne jen při
  havárii). Nejnižší RTO (blízké nule), nejvyšší náklady a
  architektonická komplexita — vyžaduje řešit i konzistenci dat mezi
  regiony.

Volba mezi těmito úrovněmi je opět obchodní rozhodnutí založené na
tom, kolik firma reálně ztratí (finančně, reputačně) za hodinu
výpadku, oproti tomu, kolik stojí nižší RTO/RPO.

Cloudové nástroje pro DR

Cloud platformy (modul 11) usnadňují multi-region DR strategie —
např. AWS nabízí replikaci S3 mezi regiony (cross-region
replication), RDS umí read repliky v jiném regionu s možností
povýšení na primární, a Route 53 umí automaticky přesměrovat
provoz do jiného regionu na základě health checků. To výrazně
snižuje náklady oproti budování vlastního druhého datacentra, ale
princip zůstává stejný — bez otestovaného plánu obnovy jsou tyto
nástroje jen potenciál, ne záruka.

Praktický příklad

Zjednodušený DR runbook (navazuje na runbooky z modulu 14) pro
scénář "primární region AWS eu-central-1 je nedostupný", strategie
warm standby v eu-west-1:

# DR Runbook: Výpadek primárního regionu (eu-central-1)

RTO: 30 minut | RPO: 5 minut (RDS cross-region read replika)

## Kroky obnovy
1. Potvrdit, že jde o skutečný výpadek regionu, ne jen naší
   aplikace (zkontrolovat AWS status page a health check dashboard).
2. Povýšit RDS read repliku v eu-west-1 na primární databázi:
   `aws rds promote-read-replica --db-instance-identifier app-db-replica-euw1`
3. Přeškálovat warm standby Deployment v eu-west-1 z minReplicas=2
   na produkční kapacitu (viz HPA z minulé lekce):
   `kubectl -n prod scale deployment app --replicas=20`
4. Přesměrovat DNS (Route 53) na eu-west-1 load balancer:
   `aws route53 change-resource-record-sets --hosted-zone-id ... \
     --change-batch file://failover-to-euw1.json`
5. Ověřit klíčové health checky a dashboardy.
6. Informovat stakeholdery (viz komunikace z incident managementu).

## Test tohoto runbooku
Naposledy otestováno: 2024-01-15 (čtvrtletní DR cvičení).
Naměřený reálný RTO: 22 minut.

Shrnutí

Disaster recovery plánuje pro scénář ztráty celé lokality, nikoliv
jen jednoho serveru. Klíčová dvě čísla, RTO (jak dlouho smí trvat
obnova) a RPO (kolik dat smí být ztraceno), jsou obchodní
rozhodnutí, která určují, jakou ze čtyř úrovní architektury zvolit
— od levného backup & restore po drahé multi-site active/active.
Cloud platformy DR výrazně usnadňují (cross-region replikace,
automatický failover), ale bez pravidelně testovaného runbooku
zůstává DR plán jen teorií, na kterou se nelze spolehnout ve
skutečné krizi.

Kontrolní otázky

1. Proč jsou RTO a RPO obchodní, ne čistě technická rozhodnutí, a
   kdo by je měl schvalovat?
2. Jaký je rozdíl mezi strategiemi "pilot light" a "warm standby" z
   hlediska nákladů a rychlosti obnovy?
3. Proč je pravidelné testování obnovy ze zálohy stejně důležité
   jako samotné zálohování?
4. Mini cvičení: pro interní firemní wiki s nízkou návštěvností
   a tolerancí k několikahodinovému výpadku navrhněte nejvhodnější
   ze čtyř úrovní DR architektury a zdůvodněte proč.