Scenariusze rekonwalescencji klęsk żywiołowych

1) Dlaczego DR jest potrzebne i jaki jest cel

Recovery Disaster Recovery (DR) to zestaw architektur, procesów i szkoleń do odzyskiwania usług po katastrofach (awaria centrum danych/regionu, utrata danych, błędy konfiguracji masy). Celem DR jest osiągnięcie docelowych RTO/RPO przy kontrolowanych kosztach i ryzyku przy zachowaniu zaufania klientów i zgodności z przepisami.

Cel czasu odzyskiwania (RTO) - czas przestoju.
Cel punktu odzysku (RPO) - dopuszczalna utrata danych (czas od ostatniego punktu spójnego).
RLO (cel poziomu odzysku): poziom funkcjonalności, który powinien powrócić w pierwszej kolejności (minimalna opłacalna usługa).

2) Klasyfikacja systemów według krytyki

Poziom 0 (istotne): płatności, login, KYC, transakcje podstawowe - RTO ≤ 15 min, RPO ≤ 1-5 min.
Poziom 1 (wysoki): panele operacyjne, raporty D-1 - RTO ≤ 1 h, RPO ≤ 15-60 min.
Poziom Tier II (średnia): zaplecze, analityka w czasie zbliżonym do rzeczywistego - RTO ≤ 4-8 godzin, RPO ≤ 4-8 godzin.
Poziom 3 (niski): pomocniczy niekrytyczny - RTO ≤ 24-72 h, RPO ≤ 24 h.

Przypisanie obiektów RTO/RPO docelowych Tier + do każdej usługi w katalogu usług; decyzje i budżety powinny być sprawdzane przeciwko nim.

3) Model zagrożenia i scenariusze

Wykonane przez człowieka: awaria AZ/region/dostawca, degradacja sieci/DNS, awaria bazy danych/pamięci masowej, błąd uwalniania masy.
Czynnik ludzki: błędne konfiguracje/IaC, usuwanie danych, kluczowy kompromis.
Naturalne/zewnętrzne: pożar/powódź, przerwy w dostawie energii, blokady prawne.
Dla każdego - ocenić prawdopodobieństwo/wpływ, link do scenariusza DR i playbook.

4) wzory architektury DR

1. Active-Active (Multi-Region): Oba regiony obsługują ruch.

Plusy: minimalny RTO/RPO, wysoka stabilność.
Wady: złożoność/spójność danych, wysoka cena.
Gdzie: read-heavy, buforowane ładunki, usługi bezpaństwowe, multi-master DB (ścisłe zasady konfliktu).

2. Active-Passive (Hot Standby): Gorący pasywny posiada w pełni podgrzewaną kopię.

RTO: minuty; RPO: minuty. Wymaga automatycznego awaryjnego i replikacji.

3. Warm Standby: część zasobów jest rozgrzewana, skalowanie w razie wypadku.

RTO: dziesiątki minut; RPO: 15-60 minut. Bardziej ekonomiczne, ale dłuższe.

4. Pilot Light: minimalna „iskra” (metadane/obrazy/skrypty) + szybkie rozłożenie.

RTO: godziny; RPO: godziny. Tanie, odpowiednie dla poziomu 2-3.

5. Kopia zapasowa i przywracanie: kopie zapasowe offline + ręczne nagrzewanie.

RTO/RPO: godziny/dzień. Tylko za niską krytykę i archiwum.

5) Dane i spójność

• Synchroniczny - niemal zerowy RPO, ale na stolcu/latentnost.
• Asynchroniczny - lepsza wydajność, RPO> 0 (ogon kłód).
• Spójność: Wybierz model (silny/ewentualny/przyczynowy). Dla płatności - ściśle, dla analityki - ostatecznie.
• Migawki: Tworzenie spójnych punktów regularnie + dzienniki sklepu (WAL/redo).
• Transakcje międzyregionalne: unikać 2PC; używać operacji idempotent, deli-and-repeat (retry z deduplication), event sourcing.
• Kolejki/autobusy: replikacja/lustrowanie, DLQ, zamawianie i idempotencja konsumentów.

6) Sieć, ruch i DNS

GSLB/Anycast/DNS: polityki awaryjne/awaryjne, niskie TTL (ale nie za dużo), kontrole zdrowotne z kilku regionów.
Routing L7: mapy regionalne, flagi degradacji (ograniczenie funkcji).
Prywatne linki/VPN: kanały kopii zapasowych dla dostawców (PSP/KYC/CDN).
Ograniczenie prędkości: ochrona przed burzą podczas odzyskiwania.

7) Stateful vs bezpaństwowiec

Bezpaństwowiec nosi skrypt/autoskale; stateful wymaga spójnej strategii danych (replikacja, migawki, promocja repliki, kworum).
Pamięć podręczna/sesje: zewnętrzne (Redis/Memcached) z replikacją krzyżową lub ponownym zalążkiem; przechowywać sesje w żetonach (JWT) lub udostępnionym magazynie.

8) wyzwalacze DR i automatyka

SLO szyny ogrodnicze i sondy kworum → automatyczny runbook awaryjny regionu.
Zmiana zamrożenia w przypadku wypadku: zablokować nieistotne zwolnienia/migracje.
Infrastruktura jako kod: rozmieszczenie manifestów czuwania, kontrola dryfowania.
Promocja roli: automatyczna promocja repliki DB + pisarze/opatrunek tajemnic.

9) Komunikacja i zgodność

Pokój wojenny: IC/TL/Comms/Scribe; Okresy aktualizacji SEV.
Strona statusu: geografia wpływu, ETA, obroty robocze.
Przepisy: terminy powiadamiania, bezpieczeństwo danych, niezmienne przechowywanie dowodów.
Partnerzy/dostawcy: potwierdzone kontakty, dedykowany kanał.

10) Badania i ćwiczenia DR

Tablop: Omówienie scenariusza i rozwiązań.
Dzień gry (stage/prod-light): symulacja awarii AZ/regionów, wyłączenie dostawcy, reset DNS.
Przywracanie testów: okresowe przywracanie kopii zapasowych w izolacji i walidacja integralności.
Chaos/Wtrysk awarii: kontrolowana sieć/węzeł/awaria zależności.
Ćwiczenia KPI: osiągnięte RTO/RPO, wady playbook, CAPA.

11) Finansowanie i wybór strategii (FinOps)

Policz $ za zredukowane RPO/RTO: im niższe cele, tym droższe kanały, licencje, rezerwy.
Hybryda: Poziom 0 - aktywny/gorący; Poziom 1 - ciepło; Poziom 2-3 - pilot/kopia zapasowa.
Drogie dane: użyj zimnych warstw (archiwum/S3/GLACIER), przyrostowych migawek, deduplikacji.
Okresowy przegląd kosztów DR-infra i certyfikatów/licencji.

12) Mierniki dojrzałości DR

RTO (rzeczywisty) i RPO (rzeczywisty) dla każdego Tier.
DR Coverage:% usług z projektowanym skryptem/playbook/test.
Sukces kopii zapasowej i przywrócenie sukcesu: Codzienny sukces kopii zapasowych i sprawdzonych przywraca.
Czas do ogłoszenia katastrofy: Szybkość decyzji o awarii.
Czas awaryjny powraca do normalnej topologii.
Ćwiczenia wad: znaleziono luki/nauki.
Kompletność dowodów zgodności.

13) Listy kontrolne

Przed wdrożeniem DR

• Katalog usług zawiera Tier, RTO/RPO, zależności i właścicieli.
• Wybrany wzór (AA/AP/WS/PL/BR) według poziomu i budżetu.
• Udokumentowane są umowy dotyczące spójności i replikacji.
• GSLB/DNS/routing i kontrole zdrowia skonfigurowane i przetestowane.
• Kopie zapasowe, migawki, dzienniki zmian - włączone, zaznaczone dla przywrócenia.
• Playbooks DR i kontakty dostawców są aktualne.

Podczas wypadku (krótko)

• Ogłosić SEV i zebrać pokój wojenny; zamrozić uwolnienia.
• Sprawdź kworum sond; rejestruje wpływ/geografię.
• Execute Failover Runbook: Traffic, Promotion DB, Kolejki, Cache.
• Umożliwia degradację-UX/wartości graniczne; publikuje aktualizacje na temat SLA.
• Zbieranie dowodów (linia czasu, wykresy, dzienniki, polecenia).

Po wypadku

• Obserwować częstotliwości SLO N; wykonać awarię zgodnie z planem.
• Prowadzenie AAR/RCA; wydanie CAPA.
• Aktualizacja odtwarzaczy, katalizatorów alarmowych, przypadków testowych DR.
• Sprawozdanie dla zainteresowanych stron/organów regulacyjnych (w razie potrzeby).

14) Szablony

14. 1 karta skryptowa DR (przykład)

ID: DR-REGION-FAILOVER-01
Scope: prod EU ↔ prod US
Tier: 0 (Payments, Auth)
Targets: RTO ≤ 15m, RPO ≤ 5m
Trigger: quorum(probes EU, US) + burn-rate breach + provider status=red
Actions:
- Traffic: GSLB shift EU→US (25→50→100% with green SLIs)
- DB: promote US-replica to primary; re-point writers; freeze schema changes
- MQ: mirror switch; drain EU DLQ; idempotent reprocess
- Cache: invalidate region-specific keys; warm critical sets
- Features: enable degrade_payments_ux
- Comms: status page update q=15m; partners notify
Guardrails: payment_success ≥ 98%, p95 ≤ 300ms
Rollback/Failback: EU green 60m → 25→50→100% with guardrails
Owners: IC @platform, DB @data, Network @netops, Comms @support

14. 2 Runbook „Promuj repliki bazy danych” (fragment)

1) Freeze writes; verify WAL applied (lag ≤ 30s)
2) Promote replica; update cluster VIP / writer endpoint
3) Rotate app secrets/endpoints via remote config
4) Validate: read/write checks, consistency, replication restart to new secondary
5) Lift freeze, monitor errors p95/5xx for 30m

14. 3 Plan ćwiczeń DR (krótki)

Purpose: to check RTO/RPO Tier 0 in case of EU failure
Scenario: EU incoming LB down + 60s replication delay
Success criteria: 100% traffic in US ≤ 12m; RPO ≤ 5m; SLI green 30m
Artifacts: switching logs, SLI graphs, step times, command output

15) Anty-wzory

„Są kopie zapasowe” bez regularnych testów.
Sekrety/punkty końcowe nie są automatycznie przełączane.
Brak idempotencji → duplikat/lost transactions on redelivery.
Identyczne konfiguracje dla regionów bez flag funkcji degradacji.
Długi czas do ogłoszenia w obawie przed „fałszywym alarmem”.
Dostawcy monoregionalni (PSP/KYC) bez alternatywy.
Nie ma planu awaryjnego - żyjemy w topologii awaryjnej „na zawsze”.

16) Plan realizacji (6-10 tygodni)

1. Ned. 1-2: klasyfikacja usług według poziomu, ustawienie docelowego RTO/RPO, wybór wzorców DR.
2. Ned. 3-4: tworzenie replikacji/kopii zapasowych, GSLB/DNS, procedury promocji; playbooks i runbooks i.
3. Ned. 5-6: pierwsze ćwiczenia DR (tabletop → etap), mierniki mocowania i CAPA.
4. Ned. 7-8: Ćwiczenia ograniczone ruchem Prod-Light; automatyzacja awaryjna.
5. Ned. 9-10: optymalizacja kosztów (FinOps), przeniesienie poziomu 0 na gorący/AA, ćwiczenia kwartalne i regulamin sprawozdawczości.

17) Sedno sprawy

Skuteczne DR nie dotyczy tylko kopii zapasowych. Są to spójna architektura, automatyzacja awaryjna/awaryjna, dyscyplina danych (idempotencja/replikacja), szkolenia i przejrzysta komunikacja. Kiedy RTO/RPO są prawdziwe, odtwarzacze są wypracowywane, a ćwiczenia są regularne, katastrofa zamienia się w kontrolowane zdarzenie, po którym usługi szybko i przewidywalnie wracają do normy.