Strategie DR i RTO/RPO
1) Podstawowe zasady
1. Cele przed środkami. Najpierw formułujemy RTO/RPO i krytyczne scenariusze, a następnie wybieramy technologię.
2. Segmentacja ze względu na znaczenie. Nie wszystkie usługi wymagają „złota”; podzielić przez krytykę biznesową.
3. Dane są rdzeniem DR. Spójność, replikacja, wykrywanie korupcji i punkt odzysku są ważniejsze niż sprzęt.
4. Automatyzacja i weryfikowalność. DR jest bez znaczenia bez IaC, regresji regresji i telemetrii.
5. Nauki i dowody. Plan bez regularnego „dnia gry” jest iluzją gotowości.
6. Bezpieczeństwo i zgodność. Szyfrowanie, izolacja, WORM/niezmienne kopie zapasowe, DPA/jurysdykcje.
2) Warunki i korespondencje
RTO - czas od momentu zdarzenia do momentu przywrócenia usługi „normalnej”.
RPO jest „wiekiem” ostatniego zdrowego punktu danych przy odzyskiwaniu.
RLO (Cel poziomu odzysku) - poziom funkcjonalności, który musi zostać przywrócony (minimalna opłacalna usługa).
MTD (Maximum Tolerable Downtime) - próg, po którym przedsiębiorstwo ponosi niedopuszczalne szkody.
RTA/RPA (Actual) - rzeczywisty czas/punkt odzysku z praktyk.
Komunikacja: RTO ≤ MTD; RPA ≤ RPO. Różnica między celami a faktem jest przedmiotem pośmiertnego i poprawy.
3) klasy strategii DR (poziomy gotowości)
4) Scenariusze, przed którymi bronimy
Utrata regionu/chmury/centrum danych (elektryczność, sieć, dostawca).
Uszkodzenie danych/błąd operatora (usunięcie, uszkodzone repliki, uszkodzenie logiczne).
Malware/ransomware.
Wada uwolnienia/konfiguracji (awaria masy).
Upadek uzależnienia (KMS, DNS, tajemnice, dostawca płatności).
Zdarzenia prawne (blokowanie, zakaz wywozu danych z jurysdykcji).
Dla każdego scenariusza należy określić RTO/RPO, poziom DR, playbook, osoby odpowiedzialne.
5) Strategie danych (klucz do RPO)
5. 1 Kopie zapasowe
Pełne + przyrostowe + dzienniki transakcji (dla DB).
Magazyny immutable/WORM i kopie offline („air-gapped”).
Katalog kopii zapasowych z metadanymi i podpisami kryptograficznymi; planowane przywracanie testów.
5. 2 Replikacja
Synchroniczny (niski poziom RPO, α latentnost, ryzyko rozprzestrzeniania się łupów).
asynchroniczny (niski wpływ na perf, RPO> 0; łączyć z dzieckiem psującym).
CDC (Change Data Capture) do replikacji strumieniowej i odbudowy stanu.
5. 3 Ochrona przed korupcją logiczną
Wersioning/” punkty w czasie” (PITR) z oknem ≥ N dni.
Niezmienne podpisy (salda, sumy, chexumy) to wczesne wykrycie „złamanych” danych.
„Powolne” kanały replikacji (opóźnienie 15-60 minut) jako bufor przeciwko natychmiastowej korupcji.
python def pick_restore_point(pitr, anomaly_signals, max_age):
healthy = [p for p in pitr if not anomaly_signals. after(p. time)]
return max(healthy, key=lambda p: p. time if now()-p. time <= max_age else -1)6) Zastosowanie, status, pamięć podręczna
Warstwa bezpaństwowa - skala i ponowne uruchomienie w dowolnym regionie (obraz/wykres/manifest w Git).
Status (DB/caches/kew): źródłem prawdy jest jeden z DB; bufory i indeksy są nadmiarowe.
Idempotencja i ponowne kierowanie - ponowne dostarczenie zdarzeń jest dopuszczalne; używać skrzynki odbiorczej/skrzynki odbiorczej, dedup i wersji.
7) Punkt wejścia i sieci
GSLB/DNS-feilover: latency/health-based, short TTL to crash window.
Anycast/L7 proxy: pojedyncze IP, regionalne szlaki zdrowotne.
Dziedziny regionalne i polityka jurysdykcyjna (geosiatka dla PII).
Plik certyfikatu/KMS: łańcuchy zapasowe, klucz podwójny.
python if slo_breach("region-a") or health("region-a")==down:
route. shift(traffic, from_="region-a", to="region-b", step=20) # канарим enable_readonly_if_needed()8) Model operacyjny i automatyka
IaC/GitOps: druga infrastruktura regionalna = kod, wdrożenie „pojedynczego przycisku”.
Polityka jako kod: brama „brak manifestów DR/kopie zapasowe/wpisy - brak zwolnienia”.
Runbooks: instrukcje krok po kroku i „czerwony przycisk” identyczny z obydwoma regionami.
Sekrety: kredyty krótkotrwałe, federacja OIDC, plan kompromisu/wycofania.
rego package dr deny["Missing PITR ≥ 7d"] {
input. db. pitr_window_days < 7
}
deny["No restore test in 30d"] {
now() - input. db. last_restore_test > 3024h
}9) Ćwiczenia i testy (Dni gry)
Tabela scenariuszy: utrata bazy danych, „uszkodzone” dane, awaria KMS, spadek regionu, nagły limit wyjścia.
Częstotliwość: kwartalnie dla misji krytycznych; raz na pół roku - dla reszty.
Wskaźniki ćwiczeń: RTA/RPA vs bramki, proporcja automatycznych kroków, liczba interwencji ręcznych, błędy playbook.
Chaos-dym w uwolnieniach: degradacja zależności nie powinna „łamać” ścieżek DR.
T0: cut off the primary database (firewall drop)
T + 2m: GSLB shift 20% of traffic, then 100% at SLO_ok
T + 6m: checking business invariants and lag replication
T + 10m: post-drill: fixing RTA/RPA, playbook improvements10) Playbooks (szablon kanoniczny)
yaml playbook: "dr-failover-region-a-to-b"
owner: "platform-sre"
rto: "15m"
rpo: "5m"
triggers:
- "health(region-a)==down"
- "slo_breach(payments)"
prechecks:
- "backup_catalog ok; last_restore_test < 30d"
- "pitr_window >= 7d"
steps:
- "Announce incident; open war-room; assign IC"
- "Freeze writes in region-a (flag write_readonly)"
- "Promote db-b to primary; verify replication stopped cleanly"
- "Shift GSLB 20%→50%→100%; monitor p95/error"
- "Enable compensations and re-drive queues"
validation:
- "Business invariants (balances, duplicate_checks)"
- "Synthetic tests green; dashboards stable 30m"
rollback:
- "If db-b unhealthy: revert traffic; engage restore from PITR T-Δ"
comms:
- "Status updates each 15m; external note if SEV1"11) Wskaźniki obserwowalności DR
Opóźnienie repliki (sec), dryf RPO (różnica pomiędzy docelowym a rzeczywistym RPO).
Przywróć SLI: czas regeneracji na zimno/ciepło według środowiska.
Zasięg:% usług z odtwarzaniem/kopiami zapasowymi/PITR ≥ N dni.
Wynik wiertła: odsetek kroków automatycznych, dystrybucja RTA, wskaźnik błędów.
Immutability:% kopii zapasowych w WORM/air-gapped.
Metryki zdarzeń: długość kolejki/prędkość ponownego napędu po fałszywym.
12) Koszty i kompromisy
CapEx/OpEx: Ciepłe stoisko jest tańsze niż Active/Active, ale droższe niż Pilot Light.
Egress: międzyregionalne/międzychmurowe koszty replikacji; kruszywa cache/compression/lokalne.
RTO/RPO vs $: każda „dziewięć” dostępności i sekunda RPO są kilka razy droższe - koordynować z biznesem.
Zielone okna: replikacja partii - w tanich/” zielonych„ godzinach.
13) Bezpieczeństwo i zgodność
Szyfrowanie „w spoczynku” i „w tranzycie”, oddzielne domeny KMS według regionu.
Niezmienne kopie zapasowe, ochrona ransomware: „3-2-1” (3 kopie, 2 media, 1 offline), MFA-delete.
Jurysdykcje: geosiatka do PII, lokalizacja kopii zapasowych, Legalna blokada na górze TTL.
Dostęp do czasu: tymczasowe role w operacjach DR, dziennik audytu.
14) Anty-wzory
„Napiszmy plan później” - DR bez ćwiczeń.
Replikacja bez ochrony przed uszkodzeniem logicznym - natychmiast pomnoży błąd.
Jeden region KMS/tajemnic - nie feilover możliwe.
Kopie zapasowe bez regularnych przywróceń - „Shredinger” DR.
Ściśle powiązane transakcje synchroniczne między regionami to opóźnienia/upadek kaskadowy.
Brak priorytetów: ten sam poziom DR dla wszystkiego (drogie i bezużyteczne).
15) Lista kontrolna architekta
1. Zdefiniowany RTO/RPO/RLO według usługi i scenariusza?
2. Dane niejawne: źródło prawdy, PITR/okno, WORM/immutable?
3. Czy DR (Backup/Restore, Pilot, Warm, A/P, A/A) jest wybrany dla danej usługi?
4. Sieć: GSLB/Anycast, certyfikaty/klucze z marginesem, flagi tylko do odczytu?
5. Aplikacja: idempotencja, skrzynka odbiorcza/skrzynka odbiorcza, kompensowanie transakcji?
6. IaC/GitOps/Polityka jako Kod: jedno kliknięcie na uruchomienie drugiego regionu?
7. Wiertło: Harmonogram, KPI RTA/RPA, działania po szkoleniu?
8. Monitoring: lag, RPO-drift, restore-SLI, wiertnica, niezmienne kopie zapasowe?
9. Bezpieczeństwo/Zgodność: KMS Domeny, jurysdykcje, legalne posiadanie?
10. Koszt: budżet wyjścia, zielone okna, ekonomicznie solidny poziom?
16) Mini przepisy i szkice
16. 1 PITR dla Postgres (pomysł):
bash base backup daily + WAL archive pg_basebackup -D/backups/base/$ (date +% F)
archive_command='aws s3 cp %p s3://bucket/wal/%f --sse'
restore pg_restore --time "2025-10-31 13:21:00Z"...16. 2 Ochrona przed korupcją logiczną (opóźniona replika):
yaml replication:
mode: async apply_delay: "30m" # window to roll back on corruption16. 3 Przełączanie ruchu (GSLB pseudo-API):
bash gslb set-weight api. example. com region-a 0 gslb set-weight api. example. com region-b 10016. 4 Kontrola niezmienników po podaniu feilovera (pseudokoda):
python assert total_balance(all_accounts) == snapshot_total assert no_duplicates(events_since(t_failover))Wnioski
DR jest zdolność do podejmowania decyzji technicznych i organizacyjnych szybciej niż szkód rośnie. Identyfikacja realistycznych RTO/RPO, wybór odpowiedniej dostępności, zautomatyzowanie infrastruktury i kontroli, regularne ćwiczenia i pomiar rzeczywistych RTA/RPA. Wtedy wypadek nie zamieni się w katastrofę, ale w kontrolowany incydent z przewidywalnym wynikiem.