Развертывание конфигураций

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→банк, 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→прод.
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, выручку и соответствие регуляторным требованиям.