DR-стратегиялар және RTO/RPO
1) Базалық қағидаттар
1. Мақсаттар қаражаттан ерте. Алдымен RTO/RPO мен сыни сценарийлерді тұжырымдаймыз, содан кейін технологияны таңдаймыз.
2. Маңыздылығы бойынша сегменттеу. Барлық сервистер «алтынды» талап ете бермейді; бизнес-сыншылыққа қарай бөліңіз.
3. Деректер - DR. өзегі. Консистенттілік, репликалау, бұзылуды анықтау және қалпына келтіру нүктесі «темірден» маңызды.
4. Автоматтандыру және тексерілу. DR IaC, қалпына келтіру және телеметрия регресс-тесттерінсіз мағынасыз.
5. Оқу-жаттығулар мен дәлелдемелер. Тұрақты «game day» жоқ жоспар - дайындық иллюзиясы.
6. Қауіпсіздік және комплаенс. Шифрлау, оқшаулау, WORM/immutable-backup, DPA/юрисдикция.
2) Терминдер мен сәйкестіктер
RTO - оқиғадан бастап сервисті қалпына келтіруге дейінгі уақыт «қалыпты».
RPO - қалпына келтіру кезіндегі соңғы сау деректер нүктесінің «жасы».
RLO (Recovery Level Objective) - қалпына келтіруге міндетті функционалдық деңгейі (ең аз өміршең сервис).
MTD (Maximum Tolerable Downtime) - бизнеске тиімсіз зиян келтіретін табалдырық.
RTA/RPA (Actual) - практикадан нақты қалпына келтіру уақыты/нүктесі.
Байланыс: RTO ≤ MTD; RPA ≤ RPO. Мақсаттар мен фактілер арасындағы алшақтық - постмортем мен жақсартудың мәні.
3) DR-стратегиялар сыныптары (дайындық деңгейлері)
4) Өзіміз қорғайтын сценарийлер
Аймақты/бұлтты/ДӨО жоғалту (электрика, желі, провайдер).
Деректердің сыбайлас жемқорлығы/оператордың қатесі (жою, «сындырылған» репликалар, логикалық бүліну).
Зиянды бағдарламалық жасақтама/шифрлаушы (ransomware).
Шығу/конфигурация ақауы (жаппай outage).
Тәуелділіктің күйреуі (KMS, DNS, құпиялар, төлем провайдері).
Заңды оқиғалар (тыйым салу, деректерді юрисдикциядан шығаруға тыйым салу).
Әрбір сценарий үшін жауапты RTO/RPO, DR деңгейі, плейбук көрсетіңіз.
5) Деректер стратегиясы (RPO кілті)
5. 1 Бекеттер
Толық + инкременталды + транзакция журналдары (ДБ үшін).
Иммутабельді/WORM-сақтау орындары және оффлайн-көшірмелері («air-gapped»).
Метадеректері мен крипто қолтаңбалары бар бэкаптар каталогы; кесте бойынша тестілік қалпына келтіру.
5. 2 Репликалау
Синхронды (төмен RPO, ↑ жасырындылық, бүлінудің таралу қаупі).
Асинхронды (перф.-ге әсері төмен) RPO> 0; бүліну детекторымен біріктіру).
Ағынды репликалау және күйді қайта құру үшін CDC (Change Data Capture).
5. 3 Логикалық бұзылудан қорғау
Нұсқалау/» уақыт нүктесі» (PITR) N күн ≥ терезесімен.
Инварианттар сигнатурасы (баланстар, сомалар, чексуммалар) - «сынған» деректердің ерте бөлшегі.
«Баяу» репликация арналары (delay 15-60 мин) тез бұзылуға қарсы буфер ретінде.
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) Қосымша, күй, кэш
Стэйтлесс-қабат - кез келген өңірде масштабтаймыз және қайта іске қосамыз (Git-тегі бейне/чарт/манифесттер).
Жай-күйі (ДБ/кэш/кью): ақиқат көзі - ДБ-ның бірі; кэштер мен индекстер қайта генерацияланады.
Теңсіздік және re-drive - оқиғаларды қайта жеткізуге болады; outbox/inbox, дедуп және нұсқаларын пайдаланыңыз.
7) Желі және кіру нүктесі
GSLB/DNS-фейловер: latency/health-based, апат терезесіне қысқа TTL.
Anycast/L7-прокси: бірыңғай IP, өңірлердің денсаулығы бойынша бағыттау.
Өңірлік домендер және юрисдикция саясаты (PII үшін geo-pinning).
Сертификаттар/KMS фейловері: қосалқы тізбектер, dual-key.
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) Операциялық модель және автоматтандыру
IaC/GitOps: екінші өңірдің инфрақұрылымы = код, «бір таңбалы» өрістету.
Policy as Code: гейт «DR-манифесттері/бэкаптары/алерттері жоқ - релизі жоқ».
Runbooks: екі аймаққа бірдей қадамдық нұсқаулықтар мен «қызыл түймешік».
Құпиялар: қысқа өмір сүретін кред, OIDC федерациясы, компромисс/қайтарып алу жоспары.
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) Жаттығулар мен тесттер (Game Days)
Сценарийлер кестесі: ДБ жоғалту, «сынған» деректер, KMS істен шығу, өңірдің құлдырауы, кенеттен egress-лимит.
Жиілік: сыни-миссия үшін тоқсан сайын; жарты жылда бір рет - қалғандары үшін.
Оқу өлшемдері: RTA/RPA vs мақсаттар, автоматты қадамдар үлесі, қолмен араласу саны, плейбук қателіктері.
Chaos-smoke: тәуелділіктің азаюы 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) Плейбуктер (каноникалық шаблон)
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) DR бақылау өлшемдері
Replica lag (сек.), RPO-drift (нысаналы және нақты RPO арасындағы айырма).
Restore SLI: қоршаған орта бойынша суық/жылы қалпына келтіру уақыты.
Coverage: плейбуктері/бэкаптары бар сервистер %/PITR ≥ N күн.
Drill score: автоматты қадамдар үлесі, RTA тарату, қателер жиілігі.
Иммутабельділігі: WORM/air-gapped-те бэкап%.
Оқиға өлшемдері: кезектердің ұзындығы/фейловерден кейінгі re-drive жылдамдығы.
12) Құны және ымыраға келу
CapEx/OpEx: жылы стенд Active/Active арзан, бірақ Pilot Light қымбат.
Egress: өңіраралық/бұлт аралық репликация ақша тұрады; кэш/компрессия/жергілікті агрегаттар.
RTO/RPO vs $: қолжетімділіктің әрбір «тоғызы» және RPO секундтары бірнеше есе қымбат - бизнеспен келісіңіз.
Жасыл терезелер: batch-репликалар - арзан/« жасыл »сағаттарда.
13) Қауіпсіздік және комплаенс
«Тыныштықта» және «транзитте» шифрлау, өңірлер бойынша бөлек KMS-домендер.
Immutable-бэкаптар, ransomware қорғанысы: «3-2-1» (3 көшірме, 2 тасымалдағыш, 1 оффлайн), MFA-delete.
Юрисдикциялар: PII үшін geo-pinning, бэкаптарды оқшаулау, TTL үстінен Legal Hold.
Уақыт бойынша қолжетімділік: DR-операциялары үшін уақытша рөлдер, аудит журналы.
14) Қарсы үлгілер
«Жоспарды кейінірек жазамыз» - жаттығусыз DR.
Логикалық бұзылудан қорғаусыз репликалау қатені жылдам көбейтеді.
Бір KMS/құпия аймағы - фейловер мүмкін емес.
Тұрақты қалпына келтірілмейтін бэкаптар - «шредингер» DR.
Өңірлер арасындағы тығыз байланысты синхронды транзакциялар - каскадтық латенттілік/құлдырау.
Басымдығы жоқ: барлық үшін бірдей DR деңгейі (қымбат және пайдасыз).
15) Сәулетшінің чек-парағы
1. Сервистер мен сценарийлер бойынша RTO/RPO/RLO анықталған ба?
2. Жіктелген деректер: ақиқат көзі, PITR/терезе, WORM/immutable?
3. DR (Backup/Restore, Pilot, Warm, A/P, A/A) per-сервис деңгейі таңдалды ма?
4. Желі: GSLB/Anycast, сертификаттар/кілттер, «read-only» жалаушалары?
5. Қосымша: теңсіздік, outbox/inbox, өтемдік транзакциялар?
6. IaC/GitOps/Policy as Code: екінші аймақты жылжытуға бір нұқу?
7. Жаттығулар: кесте, KPI RTA/RPA, оқудан кейінгі әрекеттер?
8. Мониторинг: lag, RPO-drift, restore-SLI, drill-score, иммутабельді бэкаптар?
9. Қауіпсіздік/комплаенс: KMS-домендер, юрисдикциялар, Legal Hold?
10. Құны: egress бюджеті, «жасыл» терезелер, экономикалық негізделген деңгей?
16) Шағын рецептілер мен скетчтер
16. Postgres үшін 1 PITR (идея):
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 Логикалық бұзылудан қорғау (кідіртілген реплика):
yaml replication:
mode: async apply_delay: "30m" # window to roll back on corruption16. 3 Трафикті ауыстырып қосу (жалған API GSLB):
bash gslb set-weight api. example. com region-a 0 gslb set-weight api. example. com region-b 10016. 4 Фейловерден (жалған кодтан) кейінгі инварианттарды тексеру:
python assert total_balance(all_accounts) == snapshot_total assert no_duplicates(events_since(t_failover))Қорытынды
DR - бұл техникалық және ұйымдастырушылық шешімдерді зиян өсуіне қарағанда тезірек қабылдау қабілеті. Шынайы RTO/RPO-ны анықтаңыз, жеткілікті дайындық деңгейін таңдаңыз, инфрақұрылым мен тексерулерді автоматтандырыңыз, үнемі жаттығыңыз және нақты RTA/RPA-ны өлшеңіз. Сонда апат апатқа емес, болжамды аяқталатын басқарылатын оқиғаға айналады.