ابر ترکیبی: در prem + ابر

1) چرا هیبرید و چه زمانی توجیه می شود

رانندگان: الزامات قانونی (اقامت داده/PII)، سرمایه گذاری های پیش فرض موجود، تأخیر در سیستم های «اختصاصی»، کنترل هزینه، دسترسی به خدمات ابر مدیریت شده.
تجارت آف: پیچیدگی شبکه ها و امنیت، تکثیر صلاحیت ها، هماهنگ سازی داده ها و پیکربندی ها، خطرات عملیاتی.

شعار: قابل حمل که در آن بحرانی; ابر بومی که در آن سود آور است.

2) مدل های ترکیبی

On-prem extension: ابر به عنوان مرکز داده (میکروسرویس های جدید/تجزیه و تحلیل، جبهه).
ابر اول با مجریان محلی: هسته در ابر، در prem - سیستم های حسابداری/دروازه های پرداخت/ذخیره سازی PII.
ابر انفجار: قله الاستیک بار در ابر (دسته ای، تبلیغی قله)، حجم پایه - به صورت محلی.
DR به ابر: داغ/گرم ابر رزرو برای در PREM (RTO/RPO مدیریت).
Edge + Core: گره های PoP/edge به کاربر نزدیک تر هستند، داده های ریشه/ML در ابر است.

3) شبکه و اتصال

3. 1 کانال ها

Site-to-Site VPN (IPsec/SSL) - شروع به سرعت، تاخیر بالاتر، لرزش.
خطوط مستقیم (DC/ER/IC، MPLS) - SLA های قابل پیش بینی، تاخیر کمتر، گران تر.
Dual-Link + BGP - تحمل خطا و کنترل مسیریابی.

3. 2 آدرس و مسیرها

نمودار تک RFC1918 بدون تقاطع ؛ طرح CIDR برای سال های آینده.
NAT-گنبد فقط در مرزها ؛ شرق و غرب بدون NAT.
بخش/VRF برای جداسازی محیط (dev/stage/prod)، مستاجران، ارائه دهندگان.

3. 3 سیاست های زمان و DNS

تنها NTP (ساعت = سرنوشت برای رمزنگاری/امضا).
DNS Split-horizon: مناطق داخلی (svc. خوشه بندی local, corp.local), خارجی - عمومی.
GSLB مبتنی بر سلامت برای ترافیک ورودی.

4) هویت و دسترسی

فدراسیون SSO: OIDC/SAML، IdP پیش نمایش ↔ IdP ابر ؛ تهیه SCIM.
نقش ها بر اساس اصل کمترین امتیاز ؛ حساب های شیشه ای با MFA.
هویت دستگاه: SPIFFE/SPIRE یا mesh-PKI برای mTLS.
RBAC «پایان به پایان»: Git/CI/CD → خوشه/مش → کارگزاران/DB → سیاهههای مربوط.

5) بستر های نرم افزاری: Kubernetes + GitOps

5. 1 تنها لایه اعدام

خوشه در PREM و ابر با نسخه های مشابه/CRD.
GitOps (Argo CD/Flux): نمودار/پوشش تک، کنترل رانش، جریان تبلیغاتی.

5. 2 مش سرویس

Istio/Linkerd: mTLS به طور پیش فرض، تعادل آگاه از محل، بین خوشه ای شکست خورده.
سیاست های L7 (JWT، هدر، محدودیت نرخ، تلاش مجدد/مدار/زمان) - در کد آشکار.

5. 3 مثال (توپولوژی K8s و مش)

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 (تاخیر کم برای ادغام محلی).
توزیع SQL/NoSQL (سوسک/کاساندرا) با quorums محلی.
تکرار CDC/log (Debezium) بین حلقه ها ؛ عدم توانایی گردانندگان.

6. 2 شی/فایل/بلوک

استورهای S3-compatible (در prem MinIO + S3/GCS ابر) با تکرار/نسخه ؛ WORM برای حسابرسی

پشتیبان گیری: 3-2-1 (3 نسخه، 2 رسانه، 1 - خارج از سایت)، تأیید بازیابی منظم.

6. 3 کش و صف

خوشه Redis/KeyDB در هر سایت ؛ کش جهانی - تنها از طریق حوادث/TTL.
Kafka/Pulsar: MirrorMaker 2/تکرار کننده ؛ کلید - deadup/idempotency مصرف کنندگان.

7) امنیت و انطباق (اعتماد صفر)

mTLS در همه جا (مش)، TLS 1. 2 + در محیط ؛ غیر فعال کردن کانال های رمزگذاری نشده

اسرار: HashiCorp Vault/ESO ؛ نشانه های کوتاه مدت ؛ چرخش خودکار.
KMS/HSM: کلید های تقسیم شده در هر حوزه قضایی/مستاجر ؛ چرخش رمزنگاری برنامه ریزی شده.
تقسیم بندی: NetworkPolicies، میکرو تقسیم بندی (NSX/Calico)، ZTNA برای دسترسی به مدیریت.
سیاهههای مربوط: تغییر ناپذیر (Object Lock)، پایان دادن به پایان 'trace _ id'، PII/PAN پوشش.

8) قابلیت مشاهده، SLO و مدیریت حوادث

SDK OpenTelemetry در همه جا ؛ جمع آوری در PREM و در ابر.
نمونه برداری دم: 100٪ ошибок и p99، برچسب 'سایت = onprem' cloud '،' منطقه '،' مستاجر '.
SLO و بودجه خطا توسط برش (مسیر/مستاجر/ارائه دهنده/سایت) ؛ هشدار توسط نرخ سوختگی.
داشبورد پایان به پایان: RED/USE، نقشه وابستگی، مقایسه canary (قبل/بعد از مهاجرت).

9) CI/CD و پیکربندی

رجیستری تنها از مصنوعات (کش کشیدن از طریق در 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/وزن، بالا بردن آماده به کار در یک خوشه، پرچم ویژگی «حالت سبک».
• GameDays: سه ماهه - قطع سایت/کانال، تایید RTO واقعی/RPO.

11) هزینه و FinOps

خروج بین on-prem و ابر هزینه اصلی «پنهان» است ؛ کش و نگه داشتن پیاده روی به حداقل (SWR، لبه).
برچسب زدن: «سرویس»، «env»، «سایت»، «مستاجر»، «هزینه _ مرکز».
قانون 80/20: ما انتقال/نگه داشتن قابل حمل 20٪ از «هسته بحرانی»، بقیه - که در آن ارزان تر است.
معیارهای Downsampling، مراجع سیاهههای مربوط «گرم/سرد»، ردیابی نمونه بودجه آگاه است.

12) الگوهای قرار دادن بارهای کاری

13) نمونه هایی از پیکربندی

13. 1 S2S IPsec (ایده)

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

13. 2 ترافرم (قطعه برچسب/برچسب)

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 (راز از پیش نمایش به خوشه ابر)

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 ؛ اول طرح آدرس، سپس کانال.
یک حافظه پنهان جهانی «مشترک» با سازگاری قوی → تاخیر و تقسیم مغز.
Retrays without idempotency → double writoff/orders.
VPN «برهنه» بدون mTLS/Zero Trust در داخل - حرکت جانبی هنگام به خطر افتادن.
فقدان تمرینات DR: برنامه ها در واقعیت کار نمی کنند.
اختلاف بین نسخه های K8s/CRD/operators → عدم امکان نمودار یکنواخت.
سیاهههای مربوط در قالب آزاد بدون 'trace _ id' و ماسک غیر ممکن است.

15) ویژگی های iGaming/امور مالی

اقامت داده ها: PII/رویدادهای پرداخت - مدار مقدماتی/منطقه ای ؛ به ابر - aggregates/ناشناس.
PSP/KYC: چند ارائه دهنده ؛ مسیریابی هوشمند از ابر به دروازه های محلی، بازگشت به پشتیبان گیری ؛ webhooks از طریق یک کارگزار با deduplication.
«مسیرهای پول»: SLO های فردی بالاتر از کل ؛ HMAC/mTLS، 'Retry-After'، 'Idempotency-Key' مورد نیاز است.
حسابرسی: ذخیره سازی WORM (Object Lock)، سیاهههای مربوط به معاملات غیر قابل تغییر، ضبط دو طرفه (on-prem + cloud) برای رویدادهای بحرانی.
حوزه های قضایی: تقسیم بندی کلید KMS/Vault در هر کشور/برند ؛ بلوک های جغرافیایی در محیط.

16) تولید لیست آمادگی

• طرح آدرس، DNS، NTP - یک ؛ لینک های S2S + لینک های محافظت شده به جلو (BGP).
• هویت واحد (SSO/OIDC/SAML)، MFA، حداقل امتیاز ؛ SPIFFE/SPIRE برای خدمات.
• K8s در تمام سایت ها، GitOps، اپراتورهای مشابه/CRD ؛ مش سرویس с mTLS и LB محلی آگاه است.
• داده ها: CDC، تست سازگاری، سیاست های RPO/RTO، پشتیبان گیری 3-2-1 و درایوهای بازیابی منظم.
• امنیت: Vault/ESO، چرخش، NetworkPolicies، ZTNA ؛ لاگها تغییرناپذیرند.
• قابلیت مشاهده: OTel، نمونه برداری دم، SLO/بودجه توسط سایت/منطقه/مستاجر ؛ داشبورد قناري.
• CI/CD: تست قرارداد، اتصال IaC، اسکن تصویر ؛ دروازه های آزاد توسط SLO.
• DR-runbooks، GameDays، RTO واقعی/RPO واقعی را اندازه گیری کرد ؛ دکمه های برش/رول پشت.
• FinOps: محدودیت خروج، برچسب ها و گزارش ها، متریک/سیاهههای مربوط/مسیرهای پیاده روی سیاست حفظ.
• ویژگی های iGaming: اقامت داده ها، چند PSP، حسابرسی WORM، SLO های فردی برای پرداخت.

17) TL ؛ دکتر متخصص

ترکیبی = پلت فرم اعدام مشترک (K8s + GitOps + مش + OTel + خرک) در دو جهان: در PREM و ابر. شبکه و هویت را برنامه ریزی کنید، داده ها را از طریق CDC/idempotency قابل حمل کنید، امنیت را در Zero Trust متمایز کنید، SLO/Error Budgets را اندازه گیری کنید، و دکتر را برای iGaming آموزش دهید، داده ها و پرداخت ها را در حوزه قضایی نگه دارید، از مسیریابی هوشمند چند PSP و حسابرسی غیرقابل تغییر استفاده کنید.