ჰიბრიდული ღრუბელი: on-prem + cloud

1) რატომ არის ჰიბრიდი გამართლებული?

დრაივერები: რეგულატორების მოთხოვნები (მონაცემთა რეგულირება/PII), არსებული on-prem ინვესტიციები, „საკუთარი“ სისტემების ლატენცია, ღირებულების კონტროლი და კონტროლირებადი ღრუბლის სერვისებზე წვდომა.
კომპრომისები: ქსელებისა და უსაფრთხოების სირთულე, კომპეტენციების დუბლირება, მონაცემების სინქრონიზაცია და კონფისკაცია, ოპერაციული რისკები.

მოტო: portable იქ, სადაც კრიტიკულია; cloud-native იქ, სადაც სასარგებლოა.

2) ჰიბრიდის მოდელები

On-prem გაფართოება: ღრუბელი, როგორც მონაცემთა ცენტრის გაფართოება (ახალი მიკრო სერვისები/ანალიტიკა, ფრონტები).
Cloud-first ადგილობრივი წამყვანი: ბირთვი ღრუბელში, on-prem - სააღრიცხვო/გადახდის საკეტი/PII საცავი.
Cloud-bursting: ელასტიური დატვირთვის მწვერვალები ღრუბელში (batch, promo-piki), ძირითადი მოცულობა ადგილობრივად.
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/with), ტენანტები, პროვაიდერები.

3. 3 დროისა და DNS პოლიტიკოსები

ერთი NTP (საათი = ბედი კრიპტოგრაფიის/ხელმოწერებისთვის).
Split-horizon DNS: შიდა ზონები (svc. cluster. ადგილობრივი, 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 - მტევანი/მასის ბროკერები/BD ლოგები.

5) პლატფორმა: Kubernetes + GitOps

5. 1 შესრულების ერთი ფენა

მტევანი on-prem და cloud იგივე ვერსიებით/CRD.
GitOps (Argo CD/Flux): ერთიანი ჩარტები/ოვერლეი, დრიფტის კონტროლი, პრომო ნაკადები.

5. 2 მესის სერვისი

Istio/Linkerd: mTLS, ნაგულისხმევი დაბალანსება, 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 ოსტატი, cloud read-replica (ანალიტიკა/კატალოგები).
Cloud master + on-prem cache (დაბალი ლატენტობა ადგილობრივი ინტეგრაციისთვის).
Distributed SQL/Nockroach/Cassandra) ადგილობრივი კვორუმებით.
CDC/ლოგიკური რეპლიკაცია (Debezium) კონტურებს შორის; გადამამუშავებლების იდემპოტენტურობა.

6. 2 ობიექტის/ფაილური/ბლოკი

S3 თავსებადი ნაკადები (on-prem MinIO + cloud S3/GCS) რეპლიკაციით/ვერსიით; WORM აუდიტისთვის.
Bacaps: 3-2-1 (3 ეგზემპლარი, 2 გადამზიდავი, 1 - ოფსეტური), აღდგენის რეგულარული გადამოწმება.

6. 3 კეში და რიგები

Redis/KeyDB მტევანი per-site; გლობალური ქეში - მხოლოდ მოვლენების/TTL მეშვეობით.
Kafka/Pulsar: MirrorMaker 2/replicator; გასაღები არის dedup/idempotence consumers.

7) უსაფრთხოება და შესაბამისობა (Zero Trust)

mTLS ყველგან (mesh), TLS 1. 2 + პერიმეტრზე; დაშიფრული არხების აკრძალვა.
საიდუმლოებები: HashiCorp Vault/ESO; ხანმოკლე ნიშნები; მანქანის როტაცია.
KMS/HSM: გასაღებები სეგმენტირებულია პერ იურისდიქციის/ტენანტის მიერ; კრიპტო როტაცია გრაფიკით.
სეგმენტი: ქსელის პოლიტიკა, მიკრო-სეგმენტაცია (NSX/Calico), ZTNA admin წვდომისთვის.
ჟურნალები: უცვლელი (Obect Lock), 'trace _ id', შენიღბვა PII/PAN.

8) დაკვირვება, SLO და ინციდენტების მართვა

OpenTelemetry SDK ყველგან; კოლექტორი on-prem და ღრუბელში.
Tail-sampling: 100% ошибок и p99, labels `site=onprem|cloud`, `region`, `tenant`.
SLO და Error Budgets სექციებში (მარშრუტი/ტენანტი/პროვაიდერი/საიტი); ალერტები burn-rate.
დაშბორდები: RED/USE, დამოკიდებულების რუქები, კანარის შედარებები (მიგრაციის შემდეგ).

9) CI/CD და კონფიგურაცია

ერთჯერადი არტეფაქტები (pull-through cache on-prem).
Promo Stream: dev-stage (on-prem), canary (cloud) და cloud; ან პირიქით - მიზნის მიხედვით.
შემოწმებები: კონტრაქტის ტესტები (OpenAPI/gRPC/CDC), სტატიკური ანალიზი, IaC ლინტინგი, სურათების სკანირება, SLO კარიბჭე.

10) DR/BCP (უწყვეტობის გეგმა)

• კატალოგები/ლენდინგი: RTO 5-15 წთ, RPO - 5 წთ;
• გადახდები/საფულეები: RTO - 5 წთ, RPO - 0-1 წთ (კვორუმი/სინქრონი საიტის შიგნით).
• Runbook: GSLB/weights- ის შეცვლა, კლასტერში სტანდარტის ამაღლება, „მსუბუქი რეჟიმის“ განათება.
• GameDays: კვარტალურად - საიტის/არხის გამორთვა, რეალური RTO/RPO შემოწმება.

11) ღირებულება და FinOps

Egress on-prem- სა და ღრუბელს შორის არის მთავარი „ფარული“ მოხმარება; გააჩერეთ და შეამცირეთ მოგზაურობები მინიმუმამდე (SWR, edge).
tegiration: 'service', 'env', 'site', 'tenant', 'cost _ center'.
წესი 80/20: ჩვენ გადავიტანთ/ვატარებთ „კრიტიკული ბირთვის“ 20% -ს, დანარჩენი კი - იქ, სადაც იაფია.
Downsampling metrick, logs „ცხელი/ცივი“, ბიუჯეტის ასორტიმენტი.

12) სამუშაო ადგილების განლაგების ნიმუშები

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.
Retrai idempotence - ორმაგი ჩამოწერა/შეკვეთები.
„შიშველი“ VPN გარეშე mTLS/Zero Trust შიგნით არის ლათინური მოძრაობა კომპრომისზე.
DR სავარჯიშოების არარსებობა: გეგმები სინამდვილეში არ მუშაობს.
ოპერატორების K8s/CRD/ვერსიების შეუსაბამობა არის ერთიანი ჩარტების შეუძლებლობა.
Logs უფასო ფორმატით 'trace _ id "და შენიღბვის გარეშე - წინსვლა შეუძლებელია.

15) iGaming/ფინანსების სპეციფიკა

მონაცემთა აღდგენა: PII/გადახდის მოვლენები - on-prem/რეგიონულ წრეში; ღრუბელში - დანაყოფები/ანონიმი.
PSP/KYC: მრავალ პროვაიდერები; smart-routing ღრუბელიდან ადგილობრივ კარიბჭეებზე, fallback სარეზერვო; ვებჰუკები ბროკერით ბაბუით.
„ფულის გზები“: ცალკეული SLO უფრო მაღალია, ვიდრე საერთო; სავალდებულოა HMAC/mTLS, 'Retry-After', 'Idempotency-Key'.
აუდიტი: WORM საცავი, უცვლელი გარიგების ჟურნალები, ორმხრივი ჩანაწერი (on-prem + cloud) კრიტიკული მოვლენებისთვის.
იურისდიქცია: KMS/Vault per გასაღებების სეგმენტი ქვეყანა/ბრენდი; გეო-ბლოკები პერიმეტრზე.

16) მზადყოფნის სიის სია

• მისამართის გეგმა, DNS, NTP - გაერთიანებულია; არხები S2S + პირდაპირი ხაზები რეზერვით (BGP).
• ერთიანი თვითმყოფადობა (SSO/OIDC/SAML), MFA, გრძელი პირადი; SPIFFE/SPIRE მომსახურებისთვის.
• K8s ყველა საიტზე, GitOps, იგივე ოპერატორები/CRD; service mesh с mTLS и locality-aware LB.
• მონაცემები: CDC, თანმიმდევრულობის ტესტები, RPO/RTO პოლიტიკოსები, 3-2-1 ზურგჩანთა და რეგულარული გამანადგურებელი.
• უსაფრთხოება: Vault/ESO, როტაცია, ქსელის პოლიტიკა, ZTNA; ჟურნალები უცვლელია.
• დაკვირვება: OTel, tail-sampling, SLO/ბიუჯეტები site/region/tenant; კანარის დაშბორდები.
• CI/CD: კონტრაქტის ტესტები, IaC ლინტინგი, სურათების სკანირება; release gates SLO.
• DR-runbooks, GameDays, იზომება ფაქტობრივი RTO/RPO; cutover/roll-back ღილაკები.
• FinOps: egress limites, ჭდეები და მოხსენებები, რეტენის პოლიტიკა მეტრიკის/ლოგოების/ტრეისების შესახებ.
• iGaming სპეციფიკა: მონაცემთა მიმოხილვა, multi-PSP, WORM აუდიტი, ცალკეული SLO გადახდისთვის.

17) TL; DR

ჰიბრიდი = ზოგადი შესრულების პლატფორმა (K8s + GitOps + mesh + OTel + Vault) ორ სამყაროში: on-prem და cloud. დაგეგმეთ ქსელი და თვითმყოფადობა, გააკეთეთ მონაცემები CDC/idempotence საშუალებით, განასხვავეთ უსაფრთხოება Zero Trust- ით, გაზომეთ SLO/Error Budgets- ის საიმედოობა და რეგულარულად გაწვრთნეთ DR- ები. iGaming- სთვის, შეინახეთ მონაცემები იურებაში, გამოიყენეთ muned Pus- ში, გამოიყენეთ pris- ით, გამოიყენეთ pprats და გამოიყენეთ ped-pprous და გამოიყენეთ price-pricts და გამოიყენეთ უცვლელი აუდიტი