Гибридное облако: 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 и неизменяемый аудит.