Гібридна хмара: on-prem + cloud

1) Навіщо гібрид і коли це виправдано

Драйвери: вимоги регуляторів (data residency/PII), існуючі on-prem інвестиції, latency до «власних» систем, контроль вартості, доступ до керованих сервісів хмари.
Компроміси: складність мереж і безпеки, дублювання компетенцій, синхронізація даних і конфігів, операційні ризики.

Мотто: portable там, де критично; cloud-native там, де вигідно.

2) Моделі гібрида

On-prem extension: хмара як розширення ЦОД (нові мікросервіси/аналітика, фронти).
Cloud-first з локальними якорями: ядро в хмарі, on-prem - системи обліку/платіжні шлюзи/PII-сховища.
Cloud-bursting: еластичні піки навантаження в хмару (batch, promo-піки), базовий обсяг - локально.
DR to Cloud: гарячий/теплий резерв у хмарі для on-prem (RTO/RPO керовані).
Edge + Core: PoP/edge-вузли ближче до користувача, кореневі дані/ML - в хмарі.

3) Мережа і зв'язність

3. 1 Канали

Site-to-Site VPN (IPsec/SSL) - швидко стартувати, вище латентність, jitter.
Прямі лінії (DC/ER/IC, MPLS) - передбачувані SLA, нижче затримки, дорожче.
Dual-link + BGP - відмовостійкість і контроль маршрутизації.

3. 2 Адресація та маршрути

Єдина RFC1918 схема без перетинів; CIDR-план на роки вперед.
NAT-domes тільки на кордонах; east-west без NAT.
Segment/VRF для ізоляції середовищ (dev/stage/prod), тенантів, провайдерів.

3. 3 Політики часу і DNS

Єдиний NTP (годинник = доля для криптографії/підписів).
Split-horizon DNS: внутрішні зони (svc. cluster. local, corp.local), зовнішні - публічні.
Health-based GSLB для вхідного трафіку.

4) Ідентичність і доступ

Федерація SSO: OIDC/SAML, on-prem IdP ↔ хмарний IdP; SCIM-провіжінінг.
Ролі за принципом least privilege; break-glass акаунти з MFA.
Машинна ідентичність: SPIFFE/SPIRE або mesh-PKI для mTLS.
RBAC «наскрізний»: Git/CI/CD → кластер/mesh → брокери/БД → логи.

5) Платформа: Kubernetes + GitOps

5. 1 Єдиний шар виконання

Кластери on-prem і cloud з однаковими версіями/CRD.
GitOps (Argo CD/Flux): єдині чарти/оверлеї, дрейф-контроль, промо-потоки.

5. 2 Сервіс-меш

Istio/Linkerd: mTLS за замовчуванням, locality-aware балансування, failover міжкластерно.
Політики L7 (JWT, headers, rate limits, retry/circuit/timeout) - в коді маніфестів.

5. 3 Приклад (K8s topology & mesh)

yaml anti-affinity and distribution by zones on-prem cluster spec:
topologySpreadConstraints:
- maxSkew: 1 topologyKey: topology. kubernetes. io/zone whenUnsatisfiable: DoNotSchedule labelSelector: { matchLabels: { app: api } }
Istio DestinationRule: local cluster priority, then trafficPolicy cloud:
outlierDetection: { consecutive5xx: 5, interval: 5s, baseEjectionTime: 30s }

6) Дані та сховища

6. 1 Бази

On-prem master, cloud read-replica (аналітика/каталоги).
Cloud master + on-prem cache (низька латентність для локальних інтеграцій).
Distributed SQL/NoSQL (Cockroach/Cassandra) з локальними кворумами.
CDC/лог-реплікація (Debezium) між контурами; ідемпотентність обробників.

6. 2 Об'єктні/файлові/блокові

S3-сумісні стори (on-prem MinIO + cloud S3/GCS) з реплікацією/версуванням; WORM для аудиту.
Бекапи: 3-2-1 (3 копії, 2 носії, 1 - offsite), регулярна верифікація відновлення.

6. 3 Кеш і черги

Redis/KeyDB кластера per-site; глобальний кеш - тільки через події/TTL.
Kafka/Pulsar: MirrorMaker 2/replicator; ключ - дедуп/ідемпотентність консьюмерів.

7) Безпека та відповідність (Zero Trust)

mTLS скрізь (mesh), TLS 1. 2 + на периметрі; заборона нешифрованих каналів.
Секрети: HashiCorp Vault/ESO; короткоживучі токени; авто-ротація.
KMS/HSM: ключі сегментовані per юрисдикція/тенант; крипто-ротації за розкладом.
Сегментація: NetworkPolicies, micro-segmentation (NSX/Calico), ZTNA для адмін-доступу.
Журнали: незмінні (Object Lock), наскрізні'trace _ id', маскування PII/PAN.

8) Спостережуваність, SLO і управління інцидентами

OpenTelemetry SDK скрізь; Collector на on-prem і в хмарі.
Tail-sampling: 100% ошибок и p99, labels `site=onprem|cloud`, `region`, `tenant`.
SLO і Error Budgets по зрізах (маршрут/тенант/провайдер/сайт); алерти по burn-rate.
Наскрізні дашборди: RED/USE, карти залежностей, канарські порівняння (до/після міграцій).

9) CI/CD і конфіги

Єдиний registry артефактів (pull-through cache на on-prem).
Промо-потік: dev → stage(on-prem) → canary(cloud) → prod; або навпаки - залежно від мети.
Перевірки: контракт-тести (OpenAPI/gRPC/CDC), статичний аналіз, лінтінг IaC, скан образів, SLO-гейти.

10) DR/BCP (план безперервності)

• каталоги/лендінги: RTO 5-15 хв, RPO ≤ 5 хв;
• платежі/гаманці: RTO ≤ 5 хв, RPO ≈ 0-1 хв (кворум/синхрон в межах майданчика).
• Runbook: перемикання GSLB/weights, підняття standby в кластері, feature-flags «полегшеного режиму».
• GameDays: щокварталу - відключення майданчика/каналу, перевірка реальних RTO/RPO.

11) Вартість і FinOps

Egress між on-prem і хмарою - головний «прихований» витрата; кешуйте і зводьте походи до мінімуму (SWR, edge).
Тегування: `service`, `env`, `site`, `tenant`, `cost_center`.
Правило 80/20: переносимо/тримаємо переносяться 20% «критичного ядра», решта - там, де дешевше.
Downsampling метрик, ретенції логів «гаряче/холодне», бюджет-aware sampling трейсингу.

12) Патерни розміщення workload'ів

13) Приклади конфігів

13. 1 IPsec S2S (ідея)

onprem ↔ cloud: IKEv2, AES-GCM, PFS group 14, rekey ≤ 1h, DPD 15s, SLA monitoring jitter/packet-loss

13. 2 Terraform (фрагмент тегів/лейблів)

hcl resource "kubernetes_namespace" "payments" {
metadata {
name = "payments"
labels = {
"site"    = var. site    # onprem    cloud
"tenant"   = var. tenant
"cost_center" = var. cc
}
}
}

13. 3 Vault + ESO (секрет з on-prem в кластер хмари)

yaml apiVersion: external-secrets. io/v1beta1 kind: ExternalSecret spec:
refreshInterval: 1h secretStoreRef: { kind: ClusterSecretStore, name: vault-store }
target: { name: psp-hmac, creationPolicy: Owner }
data:
- secretKey: hmac remoteRef: { key: kv/data/payments, property: HMAC_SECRET }

14) Антипатерни

Перетинаються CIDR → NAT-хаос; спершу адресний план, потім канали.
Один «загальний» глобальний кеш з сильною консистентністю → латентність і split-brain.
Ретраї без ідемпотентності → подвійні списання/замовлення.
«Голий» VPN без mTLS/Zero Trust всередині - lateral movement при компрометації.
Відсутність DR-навчань: плани не працюють в реальності.
Різнобій версій K8s/CRD/операторів → неможливість єдиних чартів.
Логи у вільному форматі без'trace _ id'і маскування - форензика неможлива.

15) Специфіка iGaming/фінансів

Data residency: PII/платіжні події - в on-prem/регіональному контурі; в хмару - агрегати/анонім.
PSP/KYC: multi-провайдери; smart-routing з хмари на локальні шлюзи, fallback на резервного; вебхуки через брокер з дедупом.
«Шляхи грошей»: окремі SLO вище загального; обов'язкові HMAC/mTLS,'Retry-After','Idempotency-Key'.
Аудит: WORM-сховище (Object Lock), незмінні журнали транзакцій, двосторонній запис (on-prem + cloud) для критичних подій.
Юрисдикції: сегментація ключів KMS/Vault per країна/бренд; гео-блоки на периметрі.

16) Чек-лист prod-готовності

• Адресний план, DNS, NTP - єдині; канали S2S + прямі лінії з резервом (BGP).
• Єдина ідентичність (SSO/OIDC/SAML), MFA, least privilege; SPIFFE/SPIRE для сервісів.
• K8s у всіх майданчиках, GitOps, однакові оператори/CRD; service mesh с mTLS и locality-aware LB.
• Дані: CDC, тести консистентності, політики RPO/RTO, бекап 3-2-1 і регулярні restore-дриди.
• Безпека: Vault/ESO, ротація, NetworkPolicies, ZTNA; журнали незмінні.
• Спостережуваність: OTel, tail-sampling, SLO/бюджети по site/region/tenant; канарські дашборди.
• CI/CD: контракт-тести, лінтинг IaC, скан образів; release-гейти по SLO.
• DR-runbooks, GameDays, виміряні фактичні RTO/RPO; кнопки cutover/roll-back.
• FinOps: egress-ліміти, теги та звіти, політика ретеншну метрик/логів/трейсів.
• iGaming-специфіка: data residency, multi-PSP, аудит WORM, окремі SLO для платежів.

17) TL; DR

Гібрид = загальна платформа виконання (K8s + GitOps + mesh + OTel + Vault) на двох світах: on-prem и cloud. Плануйте мережу та ідентичність, робіть дані переносяться через CDC/ідемпотентність, розмежовуйте безпеку по Zero Trust, вимірюйте надійність SLO/Error Budgets і регулярно тренуйте DR. для iGaming тримайте дані і платежі в юрисдикції, використовуйте multi-PSP smart-routing і незмінний аудит