استقرار تنظیمات

1) چرا

پیکربندی بیشتر از کد تغییر می کند و به طور مستقیم بر درآمد (مسیریابی PSP، محدودیت ها، ضرایب، ویژگی های جلو) و انطباق (KYC/AML، RG) تاثیر می گذارد. ما نیاز به یک فرایند قابل تکرار، قابل تایید و برگشت پذیر برای ارائه پیکربندی به مواد غذایی، با تحمل سخت و قابل مشاهده است.

2) اصول

1. پیکربندی به عنوان داده: پیکربندی - داده های نسخه شده (YAML/JSON)، نه «کلیک های دستی».
2. Schema-first: هر ورودی در برابر طرح (JSON Schema/Protobuf) معتبر است.
3. سیاست ها به عنوان کد: دروازه ها، تحمل ها، SoD - در مخزن سیاست.
4. GitOps: تنها منبع حقیقت Git است ؛ خوشه ها توسط آشتی دهنده مطابقت دارند.
5. تحویل مترقی: نورد قناری، توسط بخش (GEO/مستاجر/بانک/ارائه دهنده).
6. Zero-downtime: سوئیچ اتمی، دو بافر، سازگاری فرمت.
7. قابلیت مشاهده توسط طراحی: ممیزی، معیارهای برنامه، آشکارساز رانش.
8. امنیت: حداقل امتیازات، اسرار به طور جداگانه، SoD/4-eyes برای تغییرات خطرناک.

3) مدل پیکربندی

استاتیک: به ندرت تغییر می کند، نیاز به انتشار (پورت ها، زمان بندی هسته).
پویا: بدون راه اندازی مجدد (مسیریابی PSP، ویژگی ها، محدودیت ها) استفاده می شود.
اسرار: کلید/نشانه ؛ یک حلقه جداگانه (KMS/مدیر مخفی).
مصنوعات: فایل های قانون/نقشه ها (BIN → بانک، GEO → PSP، محدودیت پاداش).

آدرس کلید: «مستاجر»، «منطقه»، «محیط زیست»، «سرویس»، «نسخه»، «بخش» (psp/bank_group/device).

4) فرمت ها و طرح ها

json
{
"$schema": "https://json-schema. org/draft/2020-12/schema",
"title": "pspRouting",
"type": "object",
"properties": {
"version": {"type": "string"},
"rules": {
"type": "array",
"items": {
"type": "object",
"required": ["geo","binGroup","primary","fallback"],
"properties": {
"geo": {"type":"string"},
"binGroup":{"type":"string"},
"primary":{"type":"string"},
"fallback":{"type":"array","items":{"type":"string"}},
"limits":{"type":"object","properties":{"perMinute":{"type":"integer"}}}
}
}
}
},
"required": ["version","rules"]
}

5) چرخه عمر (GitOps)

1. Authoring: PR برای پیکربندی مخزن: data + ticket/change link.
2. Lint/Validate: CI: نقشه ها، مراجع، معانی (قوانین درگیری)، خشک اجرا در غرفه.
3. سیاست گیتس: SoD/4-eyes، کلاس ریسک، پنجره های یخ زده، انطباق با وضعیت SLO.
4. مرحله بندی اعمال: تست ادغام اجرا/synthetics، بررسی SLI.
5. تحویل پیشرو: قناری مواد غذایی (1-5٪) → 25٪ → منطقه/مستاجر → 100٪.
6. نظارت پس از: 30-60 دقیقه متریک/هشدار ؛ نتیجه را تصحیح کنید.

7. ارتقاء/بازگشت: علائم انتشار، بازگشت سریع از طریق گیت بازگشت/» نسخه قبلی«

6) استراتژی نورد

قناری بر اساس بخش: 'tenant = A, geo = TR, bank = BIN _ XXXX'.
بر اساس منطقه: EU → LATAM → APAC، با توجه به قله های ساعتی.
توسط قابلیت: گنجاندن یک پرچم (پرچم ویژگی) با guardrails (TTL، محدودیت پوشش).
آبی/سبز برای منبع پیکربندی: تغییر خوانندگان به یک عکس فوری جدید.

7) بارگیری پویا و سازگاری

راه اندازی مجدد داغ (ناظران/کنسول ها/بارگیری مجدد خط لوله جمع کننده OTel).
دو فرمت (v1 + v2): هر دو توسط تولید کنندگان خوانده می شوند، آنها به یک جدید می نویسند.
سازگاری: نسخه در پاسخ/معیارهای API برای دیدن «چه کسی در چه پیکربندی است».

8) امنیت، اسرار، SoD

اسرار به طور جداگانه: ذخیره سازی در KMS/مدیر مخفی، رمزگذاری در سطح زمینه، دسترسی از طریق ABAC.
SoD/4-eyes: تغییر مسیریابی پرداخت/محدودیت پاداش/PII-صادرات - تنها از طریق تایید دو برابر.
حقوق JIT: نشانه های موقت برای عملیات، حسابرسی کامل.
بررسی های امنیتی: linter کلید های PII/test را در prod config ممنوع می کند.

9) اعتبار سنجی قبل از استفاده

طرح ها (JSON Schema/Protobuf)، خطوط، چک های کاردینالیتی.
معناشناسی دامنه: بدون حلقه/تکراری/» سیاه چاله ها»، سازگاری با وابستگی های فعلی.
ترافیک سایه/شبیه سازی: «رانندگی» مسیریابی/قوانین جدید در یک جریان واقعی به عنوان خواندن بدون نوشتن.
دروازه SLO: SLI قرمز → ممنوعیت ارتقاء.

10) قابلیت مشاهده و حسابرسی

معیارهای استقرار: زمان برنامه، موفقیت، میزان پوشش، خطاهای تجزیه، بازپرداخت.
رویدادها: چه کسی/چه چیزی/چه زمانی/چرا، تفاوت (از جمله مخفی کردن اسرار).

آشکارساز رانش: مقایسه «چه چیزی در Git» و «چه چیزی در زمان اجرا» است ؛ هشدار در صورت وجود اختلاف

موارد مرجع «ردیابی _ id» از پیکربندی خوانده می شود.

11) کاتالوگ تنظیمات معمولی (iGaming)

مسیریابی پرداخت: PSP توسط GEO/BIN/روش ؛ محدودیت های بازپرداخت ؛ ویژگی های 3DS

KYC/AML: providers, timeouts, TTL, fallback/manual validation rules.
ریسک و RG: محدودیت سرعت، کلاه روز/ماه، جغرافیایی استثنا.
بازی ها/هسته: ضرایب حافظه پنهان، اندازه استخر، فیکفلاگ ها (تاریخچه پخش، حالت های جدید).
عملیات/قابلیت مشاهده: آستانه هشدار، قوانین نمونه برداری، کلاس های نگهداری، مصنوعی.
وضعیت/Comms: قالب پیام، محلی سازی، برنامه به روز رسانی.

12) بسته بندی پیکربندی نمونه (آشکار)

yaml apiVersion: cfg. platform/v1 kind: ConfigRelease metadata:
id: payments-routing-2025-11-01 change: "RTE-421: reroute TR BIN_4571 → PSP2"
spec:
scope:
tenants: [brandA, brandB]
regions: [EU]
segments:
geo: [TR]
strategy:
steps:
- name: canary coverage: "5%"
duration: "20m"
- name: ramp coverage: "25%"
duration: "30m"
- name: region-full"
coverage: "100%"
gates:
require:
- policy: "slo-green"
- approval: ["Payments Lead","Compliance"]
- freeze: "not-in-effect"
rollback:
to: "payments-routing-2025-10-29"
autoIf:
- metric: "auth_success_rate"
condition: "drop>10% for 10m"

13) بازپرداخت و تغییر امنیت

معکوس از طریق Git: «بازگشت »/« ترویج پیشگیری».
سوئیچ اتمی: خوانندگان به عکس فوری قدیمی تغییر می کنند.
معیارهای بازگشت خودکار: تخریب SLI/KRI، افزایش خطاهای تجزیه/اعتبار سنج.
ارتباطات: ربات حادثه وضعیت را در هنگام بازگشت خودکار منتشر می کند.

14) چند مستاجر و جغرافیایی اقامت

فایل/پوشه و فضاهای نام سطح کلید ('tenant/region/env').
سیاست های خواندن: خدمات فقط دامنه خود را می بینند.
Geo-copies of configs (EU/LATAM/APAC) و تاخیر تکرار با SLAs.
پنجره های مختلف رول برای حوزه های مختلف (انطباق/تعطیلات).

15) عملکرد و هزینه (FinOps)

کش عکس فوری: محلی/توزیع شده ؛ TTL/ETag/If-none-match.
اندازه پیکربندی: محدودیت در حجم و عمق سازه ها ؛ مدولاسیون.
کارت دسترسی: مصرف کنندگان برتر قرائت ؛ بهینه سازی فرکانس کشیدن.
هزینه اشتباهات: یک شمارنده از «گران» kickbacks/canaries اضافی.

16) ادغام

هشدار/SLO: ارتقاء دروازه، بازپرداخت خودکار.
Release-gates: مسدود کردن انتشار کد در صورت عدم تکمیل تنظیمات.
ربات حادثه: دستورات '/config promote ', '/config rollback', لینک به منتشر و داشبورد.
موتور گردش کار: وظیفه انسانی برای تغییرات پر خطر ؛ تایمر افزایش.

17) توابع KPI/KRI

پیکربندی زمان سرب: PR → prod.
نرخ شکست تغییر (CFR): درصد تغییرات با برگشت.
MTTR پیکربندی حادثه.
نرخ رانش - نرخ اختلاف Git↔runtime.
SLO-gates pass rate: نسبت تغییراتی که از گیت ها بدون استثناء دستی عبور کرده اند.
هزینه هر تغییر: CPU/IO، قناری ها، حوادث.

18) نقشه راه پیاده سازی (6-10 هفته)

«ند». 1-2: کاتالوگ پیکربندی ها، نمودارها، خطوط ؛ گیت ریپو ؛ CI پایه (اعتبار/تفاوت).
«ند». 3-4: GitOps-reconciler، خشک اجرا/مرحله بندی، داشبورد وضعیت ؛ ficheflags با TTL.
«ند». 5-6: خط مشی به عنوان کد (SoD/windows/freeze/SLO-gates)، رول های قناری، بازگشت خودکار.
«ند». 7-8: آشکارساز رانش، اسرار از طریق KMS، چند مستاجر و جغرافیایی، ربات حادثه ادغام.
«ند». 9-10: تست نورد بار/هرج و مرج، گزارش FinOps، آموزش تیم و قالب ها.

19) الگوهای مصنوعی

PR الگو: هدف، کلاس ریسک، منطقه (مستاجر/منطقه)، برنامه نورد، برنامه برگشت، نتایج خشک اجرا.
بسته سیاست: دروازه های SLO، SoD/4-eyes، تقویم یخ، محدودیت اندازه/کاردینالیتی.
Runbook: «چگونه به خواندن نسخه فعلی/تفاوت/دولت از canaries», «چگونه به صورت دستی متوقف ارتقاء».
پیکربندی کاتالوگ: مالک، طرح، خوانندگان، فرکانس به روز رسانی، یادداشت های انطباق.

20) ضد گلوله

ویرایش دستی «در پنل مدیریت» بدون Git/audit.
Configs مخلوط با کد انتشار مصنوعی، غیر قابل تعویض داغ.
عدم وجود طرحها/اعتبارسنجی سقوط → در طول تجزیه.
جهانی یک بار بدون قناری.

اسرار مشترک در پیکربندی ؛ رازها در Git

بدون کیک/TTL/guardrails در ficheflags.
بدون آشکارساز رانش.
حذف دروازه های SLO «در تماس» و بدون ضبط.

مجموع

استقرار تنظیمات یک خط لوله مدیریت شده است: داده ها با طرح ها → سیاست ها و دروازه ها → GitOps و تحویل مترقی → بارگذاری داغ و برگشت پذیری → مشاهده پذیری و حسابرسی → امنیت و هزینه. این چارچوب به شما اجازه می دهد تا به سرعت و با خیال راحت رفتار پلت فرم iGaming را تغییر دهید، در حالی که SLO، درآمد و انطباق را حفظ می کنید.