DataOps-практики

1) Що таке DataOps і навіщо iGaming

DataOps - набір інженерних, продуктових і операційних практик, які роблять потік даних передбачуваним, швидким і безпечним: від джерел і контрактів до вітрин, BI і ML.
У iGaming ставки високі: регуляторика (KYC/AML/RG), гроші в реальному часі, маркетингові експерименти, часті релізи провайдерів ігор і PSP.

• Скорочення циклу «ідея → дані → метрика/модель».
• Стабільна якість і відтворюваність.
• Контрольовані зміни (rollout/rollback).
• Прозорість: хто за що відповідає, де «ламається».

2) Потік цінності (Value Stream)

1. Джерело/Контракт → 2) Ingestion → 3) Bronze/Silver/Gold → 4) Feature Store/BI → 5) Споживачі (продукт, аналітика, ML) → 6) Зворотній зв'язок.

На кожному етапі - артефакти, тести, метрики, власники і SLO.

3) Контракт-орієнтована розробка даних

Data Contracts: схема, типи, обов'язковість, допустимі значення, SLA свіжості/доставки, DQ-правила, приватність ('pii','tokenized').
Сумісність (SEMVER): MINOR - додавання, MAJOR - несумісність, PATCH - виправлення.
CI-гейти: блокуємо PR, якщо ламається контракт/немає тестів/ретеншну.
Угоди за даними з провайдерами/PSP/KYC: формати, підпис, ретраї, дедуплікація.

4) Тестування даних (до/під час/після)

До (design): тести контрактів, зразкові набори, генератори даних.

• Schema tests (тип/nullable/enum/сумісність),
• DQ-тести (валідність, унікальність, повнота, свіжість),
• Правила приватності (Zero-PII в логах/вітринах),
• Перевірки ідемпотентності та дедуп.
• Після (acceptance): регрес-тести вітрин/фіч, порівняння v1/v2 (tolerance bands), калібрування метрик.

5) Оркестрація та оточення

Оркестратор (Airflow/екв.) як джерело правди про прогони: залежності, ретраї, SLA, алерти.
Оточення: dev → stage → prod з промоушеном артефактів (таблиць, моделей, фіч-сетów).
Ізоляція за брендами/регіонами/тенантами: окремі схеми/каталоги/ключі шифрування.
Прапорці релізів і конфігурація як дані для перемикань без релога.

6) Релізи та стратегії розгортання

Blue-Green/Canary для вітрин і моделей: паралельна збірка v2, порівняння, частковий трафік.
Dual-write/dual-read на міграції схем.
Відкладені перемикання (feature flags) на низькому навантаженні і з оборотністю.
Backfill-плейбуки: дозавантаження історії, контрольні суми, мітки «recomputed».

7) Спостережуваність і алерти (Data Observability)

Свіжість/повнота/обсяги/аномалії по вузлах лінійджа.
Якість: pass-rate DQ, «червоні» шляхи для KPI.
Схеми/Контракти: події несумісності,% успішних перевірок.
Продуктивність: латентність пайплайнів, вартість (compute/storage).
Інтерпретованість: зв'язку «istochnik→vitrina/model», швидкий «path to dashboard/KPI».

8) Управління інцидентами

Sev-рівні (P1-P3), RACI, канали зв'язку.
Runbooks: часті причини (джерело недоставило, schema drift, key leak, фрод-шум).
Авто-мітигації: ретраї, перемикання на запасний канал, «заморожування» вітрин.
Пост-мортем: корінь проблеми, дії, prevention-задачі в беклогу.

9) Безпека, приватність і доступи в DataOps

mTLS/TLS 1. 3, підпис пакетів, хеші партій.
Токенізація/маскування у вітринах і логах; детокенізація тільки в «чистій зоні».
RBAC/ABAC/JIT з аудитом; break-glass для інцидентів.
Retention/Legal Hold узгоджені з пайплайнами (TTL, lifecycle).
Zero-PII в логах - метрика розділу.

10) BI/ML як повноцінні споживачі DataOps

BI: сертифікація «золотих» вітрин, заборона'SELECT', версіонування визначень KPI.
ML: Feature Store з версіями, registry моделей, champion-challenger, fairness/privacy-гейти, counterfactual-тести.

11) Метрики успіху (SLO/SLI)

• Freshness SLO (наприклад, payments_gold ≤ 15 хв, p95).
• Job Success Rate ≥ 99. 5%, Mean Time to Detect (MTTD) / Recover (MTTR).
• Lead Time for Change (ideya→prod), Deployment Frequency (релізи/нед).

• DQ Pass-Rate ≥ цільового порогу (по критичних шляхах).
• Schema Compatibility Pass в CI.
• Delta v1/v2 в допусках.

• Zero-PII in logs ≥ 99. 99%.
• Detokenization SLO і аудит 100%.
• Retention On-time Deletion ≥ цільового порогу.

• Час публікації звіту/вітрини.
• Зниження інцидентів даних, вплив на KPI (GGR, утримання) в межах контролю.

12) Шаблони (готово до використання)

12. 1 Data Contract (фрагмент)

yaml name: game_rounds_ingest owner: games-domain schema_version: 1. 6. 0 fields:
- name: round_id type: string required: true
- name: bet_amount type: decimal(18,2)
required: true dq_rules:
- rule: bet_amount >= 0
- rule: not_null(round_id)
privacy:
pii: false tokenized: true sla:
freshness: PT15M completeness: ">=99. 9%"
retention: P12M

12. 2 Check-лист PR для вітрини/фіч

• Оновлений контракт/схема, semver коректний
• Тести DQ/схем/регресу зелені
• Release Notes + імпакт по лінійджу
• План backfill/rollback готовий
• Порогові алерти і дашборди налаштовані
• Політики приватності/доступу дотримані

12. 3 Release Notes (ескіз)

Що: `rg_signals v1. 3. 0'- доданий'loss _ streak _ 7d '

Тип: MINOR, схема сумісна

Імпакт: BI `rg_dashboard`, ML `rg_model@2. x`

Валідація: dual-run 14 днів, delta ≤ 0. 3% за основними KPI

Rollback: прапор'rg _ signals. use_v1=true`

Власник/дата/тікет

12. 4 Runbook (інцидент «затримка платежів»)

1. Перевірити SLA джерела PSP, статус конектора.
2. Ретраї/перемикання на запасний endpoint.
3. Тимчасова деградація: публікуємо агрегати без деталізації.
4. Комунікація в #data -status, тікет в Incident Mgmt.
5. Пост-мортем, RCA, профілактика (квоти/кеш/контроль схем).

13) Ролі та відповідальність (RACI)

CDO/Data Governance Council - політика, стандарти (A/R).
Domain Owners/Data Stewards - контракти, якість, вітрини (R).
Data Platform/Eng - оркестратор, сховище, CI/CD, observability (R).
Analytics/BI Lead - сертифікація вітрин, KPI-визначення (R).
ML Lead - feature store, registry, моніторинг моделей (R).
Security/DPO - приватність, токенізація, доступи, ретеншн (A/R).
SRE/SecOps - інциденти, DR/BCP, SIEM/SOAR (R).

14) Дорожня карта впровадження

0-30 днів (MVP)

1. Визначити критичні шляхи (payments, game_rounds, KYC, RG).
2. Ввести контракти і CI-гейти (схеми, DQ, приватність).
3. Увімкнути спостережуваність: свіжість/повнота/аномалії + алерти.
4. Вітрини Gold: зафіксувати KPI і заборону'SELECT'.
5. Runbooks і канал #data -status, шаблон Release Notes.

30-90 днів

1. Dual-run і canary релізи вітрин/моделей; backfill-плейбуки.
2. Feature Store/Model Registry з версіонуванням.
3. Політики доступу (RBAC/ABAC/JIT) і Zero-PII в логах.
4. Дашборди SLO/вартості, автоматизація ретеншну/TTL.
5. Навчання команд DataOps (онбординг, практикуми).

3-6 місяців

1. Повний цикл champion-challenger моделей, fairness/privacy-гейти.
2. Гео/тенант-ізоляція, ключі та дані по юрисдикціях.
3. Автоматичні Release Notes з лінійджа і diff.
4. Регулярні пост-мортеми і квартальні DataOps-рев'ю.
5. Зовнішній аудит процесів (де потрібно ліцензією).

15) Анти-патерни

«Дані потім поправимо»: релізи без тестів/контрактів.
Непрозорі пайплайни: немає лінійджа і власників.
Ручні вивантаження «в обхід» DataOps-процесів.
Логи з PII, дампи прод-баз в пісочниці.
Відсутність rollback/backfill-плану.
KPI без версій і зафіксованих визначень.

16) Пов'язані розділи

Управління даними, Походження і шлях даних, Аудит і версійність, Контроль доступу, Безпека і шифрування, Токенізація даних, Моніторинг моделей, Політики зберігання, Етика даних.

Підсумок

DataOps перетворює розрізнені скрипти і «героїзм аналітиків» в керований виробничий конвеєр даних: зміни йдуть швидко, але передбачувано; якість і приватність контролюються; релізи оборотні; метрики і моделі відтворюються. Це фундамент масштабованої iGaming-платформи.