Розгортання конфігурацій

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. Спостережуваність by design: аудит, метрики застосування, drift-детектор.
8. Безпека: мінімальні привілеї, секрети окремо, SoD/4-eyes на ризиковані зміни.

3) Модель конфігурацій

Статичні: рідко змінюються, вимагають релізу (порти, таймаути ядра).
Динамічні: застосовуються без рестартів (роутинг PSP, фічі, ліміти).
Секрети: ключі/токени; окремий контур (KMS/Secret Manager).
Артефакти: файли правил/меппінги (BIN→bank, 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. Progressive Delivery: прод-канареїка (1-5%) → 25% → регіон/тенант → 100%.
6. Post-monitoring: 30-60 хв метрик/алертів; фіксація результату.
7. Promotion/Rollback: мітки релізу, швидкий відкат через Git revert/« previous version ».

6) Стратегії розкатки

Канареечная за сегментами: `tenant=A, geo=TR, bank=BIN_XXXX`.
За регіонами: EU→LATAM→APAC, з урахуванням годинникових піків.
За функціоналом: включення прапора (feature flag) з guardrails (TTL, ліміти охоплення).
Blue/Green для конфіг-джерела: переключення читачів на новий снапшот.

7) Динамічне завантаження та сумісність

Гаряче перезавантаження (watchers/консули/OTel Collector pipeline reload).
Подвійний формат (v1 + v2): прод зчитує обидва, виробники пишуть в новий.
Узгодженість: версія у відповідях API/метриках, щоб бачити «хто на якій конфігурації».

8) Безпека, секрети, SoD

Секрети окремо: зберігання в KMS/Secret Manager, шифрування на рівні поля, доступи по ABAC.
SoD/4-eyes: зміна платіжного роутингу/лімітів бонусів/PII-експорту - тільки через подвійне схвалення.
JIT-права: тимчасові токени для операцій, повний аудит.
Перевірки безпеки: лінтер забороняє PII/тестові ключі в конфігу прод.

9) Валідації перед застосуванням

Схеми (JSON Schema/Protobuf), лінтери, перевірки кардинальності.
Семантика домену: немає циклів/дублікатів/» чорних дір», сумісність з поточними залежностями.
Shadow-трафік/симуляції: «прогнати» новий роутинг/правила на реальному потоці як читання-без-запису.
SLO-гейт: червоні SLI → заборону на промоушн.

10) Спостережуваність і аудит

Метрики розгортання: час застосування, успіх, частка охоплення, помилки парсингу, rollbacks.
Події: хто/що/коли/навіщо, diff (включаючи приховування секретів).
Drift-детектор: порівняння «що в Git» і «що в рантаймі»; алерт при розбіжності.
Екземпляри (exemplars): посилання на'trace _ id'операцій читання конфігів.

11) Каталог типових конфігів (iGaming)

Payments routing: PSP по GEO/BIN/методу; ліміти ретраїв; фічі 3DS.
KYC/AML: провайдери, таймаути, TTL, правила fallback/ручної перевірки.
Risk & RG: velocity-ліміти, денні/місячні капи, гео-винятки.
Games/Core: коефіцієнти кешу, розміри пулів, фічефлаги (історія повторів, нові режими).
Ops/Observability: алерт-пороги, 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) Відкати (rollback) і безпека змін

Реверс через Git: `revert`/“promote previous”.
Атомарний перемикач: читачі перемикаються на колишній снапшот.
Критерії авто-відкату: деградація SLI/KRI, зростання помилок парсингу/валідатора.
Комунікації: інцидент-бот публікує статус при авто-відкаті.

14) Мульти-тенант і гео-резиденство

Простори імен на рівні файлів/папок і ключів ('tenant/region/env').
Політики читання: сервіси бачать тільки свій скоуп.
Гео-копії конфігів (EU/LATAM/APAC) і затримка реплікацій з SLA.
Різні вікна розкатки для різних юрисдикцій (комплаєнс/свята).

15) Продуктивність і вартість (FinOps)

Кеш снапшотів: локальний/розподілений; TTL/ETag/If-None-Match.
Розмір конфігов: ліміти на обсяг і глибину структур; розбиття на модулі.
Карта доступу: топ-споживачі читань; оптимізація частоти пулінгу.
Вартість помилок: лічильник «дорогих» відкатів/додаткових канарок.

16) Інтеграції

Алертинг/SLO: гейт промоушна, авто-відкати.
Release-gates: блокування релізів коду, якщо розкочування конфігів не завершено.
Інцидент-бот: команди '/config promote', '/config rollback', посилання на диффи і дашборди.
Workflow Engine: human-task на високоризикові зміни; таймери ескалацій.

17) KPI/KRI функції

Lead Time конфігурації: PR→prod.
Change Failure Rate (CFR): частка змін з відкатом.
MTTR конфіг-інциденту.
Drift rate: частота розбіжностей Git↔runtime.
SLO-gates pass rate: частка змін, що пройшли гейти без ручних винятків.
Вартість на зміну: CPU/IO, канарки, інциденти.

18) Дорожня карта впровадження (6-10 тижнів)

Нед. 1–2: каталог конфігів, схеми, лінтери; Git-репо; базовий CI (валідація/дифф).
Нед. 3–4: GitOps-реконсайлер, dry-run/staging, статус-дашборди; фічефлаги з TTL.
Нед. 5–6: policy-as-code (SoD/вікна/freeze/SLO-гейти), канарні розкатки, авто-відкат.
Нед. 7–8: drift-детектор, секрети через KMS, мульти-тенант і гео-копії, інцидент-бот інтеграції.
Нед. 9–10: навантажувальні/хаос-тести розкатки, FinOps-звіт, навчання команд і шаблони.

19) Шаблони артефактів

PR Template: мета, ризик-клас, область (tenant/region), план розкатки, план відкату, результати dry-run.
Policy Pack: SLO-гейти, SoD/4-eyes, freeze-календар, ліміти розміру/кардинальності.
Runbook: «як прочитати поточну версію/дифф/стан канарок», «як вручну зупинити промоушн».
Config Catalog: власник, схема, читачі, частота оновлень, комплаєнс-нотатки.

20) Антипатерни

Ручні правки «в адмінці» без Git/аудиту.
Конфіги, змішані з кодом реліз-артефакту, без можливості гарячої заміни.
Відсутність схем/валідацій → падіння при парсингу.
Глобальна одномоментна розкатка без канарок.
Загальні секрети в конфігу; секрети в Git.
Немає відкатів/TTL/guardrails у фічефлагів.
Відсутність drift-детектора.
Зняття SLO-гейтів «за дзвінком» і без запису.

Підсумок

Розгортання конфігурацій - це керований конвеєр: дані зі схемами → політики і гейти → GitOps і прогресивна доставка → гаряче завантаження і оборотність → спостережуваність і аудит → безпеку і вартість. Такий каркас дозволяє швидко і безпечно змінювати поведінку iGaming-платформи, зберігаючи SLO, виручку і відповідність регуляторним вимогам.