კონფიგურაციის განლაგება

1) რატომ

კონფიგურაცია უფრო ხშირად იცვლება, ვიდრე კოდი და პირდაპირ გავლენას ახდენს შემოსავალზე (PSP როუტინგი, ლიმიტები, კოეფიციენტები, წინა ფიჩები) და შესაბამისობა (KYC/AML, RG). ჩვენ გვჭირდება განმეორებითი, დამოწმებული და შექცევადი პროცესი ჩამორთმევის პროდუქტების მიწოდებისთვის, მკაცრი ნებართვით და დაკვირვებით.

2) პრინციპები

1. Configuration as Data: კონფიგურაცია - ვერსირებული მონაცემები (YAML/JSON) და არა „ხელით დაწკაპუნება“.
2. Schema-first: ნებისმიერი ჩანაწერი თანმიმდევრულია სქემის საწინააღმდეგოდ (JSON Schema/Protobuf).
3. პოლიტიკოსები, როგორც კოდი: კარიბჭეები, დაშვება, SoD - პოლიტიკოსის საცავში.
4. GitOps: ჭეშმარიტების ერთადერთი წყარო არის Git; მტევნები შესაბამისობაში არიან რეკონსერვატორთან.
5. პროგრესული მიწოდება: კანარის ჩამოსხმა, სეგმენტების მიხედვით (GEO/ტენანტი/ბანკი/პროვაიდერი).
6. Zero-downtime: ბირთვული გრაგნილები, ორმაგი ბუფერიზაცია, ფორმატის თავსებადობა.
7. დაკვირვება: აუდიტი, გამოყენების მეტრიკა, დრიფტის დეტექტორი.
8. უსაფრთხოება: მინიმალური პრივილეგიები, საიდუმლოებები ცალკე, SoD/4-eyes სარისკო ცვლილებებისთვის.

3) კონფიგურაციის მოდელი

სტატიკური: იშვიათად იცვლება, საჭიროა გამოშვება (პორტები, ბირთვის ტაიმაუტები).
დინამიური: გამოიყენება გადატვირთვის გარეშე (routing PSP, ficks, limites).
საიდუმლოებები: გასაღებები/ნიშნები; ცალკეული წრე (KMS/საიდუმლო მენეჯერი).
არტეფაქტები: წესების/mappings ფაილები (BIN - ბანკი, GEO - PSP, ბონუსის ლიმიტები).

მისამართების გასაღებები: 'tenant', 'region', 'environment', 'service', 'version', 'segment' (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 კონფიგურაციის საცავში: მონაცემები + ბმული ტიკეტზე/ცვლაზე.
2. Lint/Validate: CI: სქემები, ბმულები, სემანტიკა (კონფლიქტური წესები), dry-run სტენდზე.
3. Policy Gates: SoD/4-eyes, რისკის კლასი, freeze ფანჯრები, SLO სტატუსის შესაბამისობა.
4. Staging Apply: ინტეგრაციის ტესტების/სინთეზის პროგნოზი, SLI შემოწმება.
5. პროგრესული მიწოდება: prod canareika (1-5%) - 25% - რეგიონი/ტენანტი - 100%.
6. Post-monitoring: 30-60 წუთი მეტრიკი/ალერტები; შედეგის დაფიქსირება.
7. Promotion/Rollback: გამოშვების ეტიკეტები, სწრაფი გამოტოვება Git revert/„ წინასწარი ვერსია “.

6) განლაგების სტრატეგია

კანარის სეგმენტები: 'tenant = A, geo = TR, bank = BIN _ XXXX'.
რეგიონების მიხედვით: EU - LATAM - APAC, საათის მწვერვალების გათვალისწინებით.
ფუნქციონალური თვალსაზრისით: დროშის ჩართვა guardrails (TTL, დაფარვის შეზღუდვები).
Blue/Green კონფისკაციის წყაროსთვის: მკითხველთა ახალ Snapshot- ზე გადასვლა.

7) დინამიური დატვირთვა და თავსებადობა

ცხელი გადატვირთვა (watchers/კონსულები/OTel Collector pipeline reload).
ორმაგი ფორმატი (v1 + v2): ორივე კითხულობს პროდუქციას, მწარმოებლები წერენ ახალს.
კოორდინაცია: ვერსია API/მეტრიკის პასუხებში, რათა ნახოთ „ვინ არის რომელ კონფიგურაციაში“.

8) უსაფრთხოება, საიდუმლოებები, SoD

საიდუმლოებები ცალკე: შენახვა KMS/Secret მენეჯერში, დაშიფვრა ველის დონეზე, წვდომა ABAC- ზე.
SoD/4-eyes: გადახდის როუტინგის/ბონუსის ლიმიტის შეცვლა/PII ექსპორტი - მხოლოდ ორმაგი დამტკიცებით.
JIT უფლებები: ოპერაციების დროებითი ნიშნები, სრული აუდიტი.
უსაფრთხოების შემოწმებები: ლინტერი კრძალავს PII/ტესტის გასაღებებს პროდ კონფისკაციაში.

9) ვალიდაცია გამოყენებამდე

სქემები (JSON Schema/Protobuf), ლინტერი, რადიკალური შემოწმება.
დომენის სემანტიკა: არ არსებობს ციკლები/დუბლიკატები/“ შავი ხვრელები“, თავსებადობა მიმდინარე დამოკიდებულებასთან.
Shadow ტრაფიკი/სიმულაციები: ახალი routing/წესები რეალურ ნაკადზე, როგორც კითხვის გარეშე ჩაწერა.
SLO კარიბჭე: წითელი SLI - აქციების აკრძალვა.

10) დაკვირვება და აუდიტი

განლაგების მეტრიკა: გამოყენების დრო, წარმატება, დაფარვის წილი, პარსინგის შეცდომები, rollbacks.
მოვლენები: ვინ/რა/როდის/რატომ, diff (საიდუმლოებების დამალვის ჩათვლით).
დრიფტის დეტექტორი: შედარება „რა არის Git“ და „რა არის rantime“; ალერტი განსხვავების დროს.
ეგზემპლარები: ბმული „trace _ id“ ჩამორთმევის წაკითხვის ოპერაციებზე.

11) ტიპიური კონფიგურაციების კატალოგი (iGaming)

Payments routing: PSP GEO/BIN/მეთოდით; ჭიდაობის შეზღუდვები; fici 3DS.
KYC/AML: პროვაიდერები, ტაიმაუტები, TTL, fallback/სახელმძღვანელო შემოწმების წესები.
Risk & RG: velocity-limites, დღის/თვის ქუდი, გეო-გამონაკლისი.
Games/Core: ქეში კოეფიციენტები, ტყვიის ზომა, გამეორების ისტორია, ახალი რეჟიმები).
Ops/Observability: alert ბარიერები, sampling წესები, retention კლასები, სინთეზური.
Status/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:' revert '/“ promote previous“.
ატომური შეცვლა: მკითხველები გადადიან წინა snapshot- ზე.
მანქანის უკანდახევის კრიტერიუმები: SLI/KRI დეგრადაცია, პარსინგის/მოვალეობის შემსრულებლის შეცდომების ზრდა.
კომუნიკაციები: ინციდენტი-ბოტი აქვეყნებს სტატუსს მანქანის უკან დაბრუნებისას.

14) მულტფილმი-ტენანტი და გეო-რეზიდენცია

სახელების სივრცეები ფაილების/საქაღალდეების და გასაღებების დონეზე ('tenant/region/env').
კითხვის პოლიტიკოსები: სერვისები მხოლოდ თავიანთ ნაგავს ხედავენ.
კონფიგურაციის გეო-ასლი (EU/LATAM/APAC) და SLA- სთან რეპლიკების შეფერხება.
სხვადასხვა ფანჯრები სხვადასხვა იურისდიქციისთვის (შესაბამისობა/არდადეგები).

15) პროდუქტიულობა და ღირებულება (FinOps)

Snaphots Cash: ადგილობრივი/განაწილებული; TTL/ETag/If-None-Match.
ჩამორთმევის ზომა: სტრუქტურების მოცულობისა და სიღრმის შეზღუდვები; დაყოფა მოდულებად.
წვდომის რუკა: კითხვის ტოპ მომხმარებლები; ტყვიის სიხშირის ოპტიმიზაცია.
შეცდომების ღირებულება: „ძვირადღირებული“ გამოტოვების მრიცხველი/დამატებითი კანარი.

16) ინტეგრაცია

Alerting/SLO: Gate არის სარეკლამო, ავტო-გამოტოვება.
Release-gates: კოდების გამოშვებების დაბლოკვა, თუ ჩამორთმევა არ დასრულებულა.
ინციდენტი-ბოტი: ბრძანებები '/config promote ', '/config rollback', ბმულები დიფებისა და დაშბორდის შესახებ.
Workflow Engine: human-task მაღალი რისკის ცვლილებებზე; ესკალაციის ტაიმერები.

17) KPI/KRI ფუნქციები

Lead Time კონფიგურაცია: PR პროდ.
Change Failure Rate (CFR): დაკარგული ცვლილებების წილი.
MTTR ჩამორთმეული ინციდენტი.
Drift rate: Git - runtime განსხვავებების სიხშირე.

SLO-gates pass

ცვლილების ღირებულება: CPU/IO, კანარი, ინციდენტები.

18) განხორციელების გზის რუკა (6-10 კვირა)

ნვე. 1-2: ჩამორთმევის კატალოგი, სქემები, ლინტერი; Git-repo; ძირითადი CI (შესაბამისობა/).
ნვე. 3-4: GitOps-reconsiler, dry-run/staging, სტატუს დაშბორდი; ფიჩეფლაგები TTL- ით.
ნვე. 5-6: policy-as-code (SoD/windows/freeze/SLO კარიბჭეები), კანარის ჩამოსხმა, მანქანის გამოტოვება.
ნვე. 7-8: დრიფტის დეტექტორი, საიდუმლოებები KMS- ის საშუალებით, მულტფილმის ტენანტი და გეო ასლები, ინციდენტის ბოტი ინტეგრაცია.
ნვე. 9-10: დატვირთვის/ქაოსის ტესტები, FinOps ანგარიში, გუნდების სწავლება და შაბლონები.

19) არტეფაქტების შაბლონები

PR Template: მიზანი, რისკის კლასი, რეგიონი (tenant/region), განლაგების გეგმა, დაბრუნების გეგმა, dry-run შედეგები.
Policy Pack: SLO კარიბჭეები, SoD/4-eyes, freeze კალენდარი, ზომების/კარდინალების ლიმიტები.
Runbook: „როგორ წაიკითხოთ მიმდინარე ვერსია//კანარის მდგომარეობა“, „როგორ ხელით შეაჩეროთ პოპულარობა“.
Config Catalog: მფლობელი, სქემა, მკითხველი, განახლების სიხშირე, შესაბამისობის შენიშვნები.

20) ანტიპატერები

სახელმძღვანელო რედაქტირება „admink- ში“ Git/აუდიტის გარეშე.
ჩამორთმევა, რომელიც შერეულია გამომავალი არტეფაქტის კოდით, ცხელი ჩანაცვლების შესაძლებლობის გარეშე.
სქემების/ვალიდაციის არარსებობა და პარსინგში ვარდნა.
გლობალური ერთჯერადი განლაგება კანარის გარეშე.
საერთო საიდუმლოებები კონფისკაციაში; საიდუმლოებები Git- ზე.
არ არის გამოტოვებული/TTL/guardrails ფიჩეფლაგებში.
დრიფტის დეტექტორის არარსებობა.
SLO კარიბჭეების ამოღება „ზარზე“ და ჩაწერის გარეშე.

შედეგი

კონფიგურაციის განლაგება კონტროლირებადი კონვეიერია: მონაცემები GitOps- ის პოლიტიკის და კარიბჭეების სქემებით და პროგრესული მიწოდებით, ცხელი დატვირთვა და შექცევადობა, დაკვირვება და აუდიტი, უსაფრთხოება და ღირებულება. ასეთი ჩარჩო საშუალებას გაძლევთ სწრაფად და უსაფრთხოდ შეცვალოთ iGaming პლატფორმის ქცევა, შეინარჩუნოთ SLO, შემოსავალი და შესაბამისობა მარეგულირებელი მოთხოვნების შესაბამისად.