Як влаштований деплою і оновлення ігор без перерв

Навіщо zero-downtime релізи в казино

Будь-яка «мікропауза» в iGaming - це втрачені ставки, сесії і довіра. Оновлення повинні відбуватися непомітно для гравця: ставки продовжують прийматися, стрім не рветься, гаманець і леджер залишаються консистентними, а метрики не скачуть. Ключ - дисципліна версій, сумісність контрактів і покрокові викладки, що спостерігаються.

Опорні принципи

1. Сумісність вперед/назад. Нові версії зобов'язані розуміти старі події/поля, а старі клієнти - безпечно ігнорувати нові.

2. Immutable-асети. Статика та ігрові ресурси віддаються з хеш-іменами; ніякого «перезаписування» файлів.

3. Розділення шляху запису/читання. Грошові операції (hold/settle) ізольовані і атомарні, UI/асети змінюються незалежно.

4. Спостережуваність як контракт. Реліз без трейсингів/метрик - заборона.

5. Відкат - така ж норма, як і реліз. Готові образи, міграції «в обидві сторони», кнопка rollback без ручного шаманства.

Архітектура zero-downtime на практиці

1) Версії та контракти

SemVer для API/подій: `MAJOR. MINOR. PATCH', поле'eventVer/contractVer'в кожному повідомленні.

Expand→Migrate→Contract для схем БД: спочатку додаємо поля/індекси (expand), потім бекграунд-міграції (migrate), і тільки після вимикаємо легасі (contract).

Dual-write/Dual-read при зміні критичної логіки (наприклад, розрахунку бонусу): якийсь час пишемо в стару і нову таблиці, порівнюємо.

2) Асети і CDN

Бандли/спрайти/тексти: `app. a1b2c3. js`, `paytable. 98f0. png', заголовки:


Cache-Control: public, max-age=31536000, immutable

Маніфест асетів на сервері/в CDN. Перемикаємо посилання на новий маніфест - гравці миттєво отримують свіжий UI, старі сторінки продовжують жити з колишніми файлами (без битих посилань).

Tag-purge для часто мінливих JSON (каталоги/банери) +'stale-while-revalidate'для м'якої зміни.

3) Трафікові стратегії

Blue-Green для критичних компонентів (гаманець/леджер/bridge): тримаємо два ідентичні середовища, перемикаємо ingress/віртуальний сервіс за секунди.

Canary для API/ігрових шлюзів: 1-5% трафіку → аналіз SLO/фін-дельт → розширюємо до 100%.

Feature flags для UI і механік: включаємо під сегмент, регіон або гру, без релізу коду.

4) Live-ігри і RNG

Live (WebRTC/LL-HLS):

Міняємо плеєр/оверлеї окремо від відеопотоку (різні домени/конфіги).
Тайм-синхронізатор (server time) і «м'яке» перемикання на новий сигнал.

RNG/клієнт:

Нова збірка гри віддається як нова версія ресурсу. Вже почали раунд гравці закінчують його на старому клієнті/правилах.
В `round. settled'фіксуємо'calcVer'- версію розрахункового рушія, щоб спірні раунди відтворювалися «як було».

5) Гаманець і леджер - як не ламати гроші

Один письменник на шард. Перемикання письменника - окрема процедура (з блокуваннями) і тільки всередині AZ/регіону.

Ідемпотентність на всіх шляхах: `bet. place`, `round. settle`, `payout. request`, `cashier. webhook` — с `idempotencyKey`.

PITR і shadow-перевірки: під час канаркового розрахунку дублюємо проводки в «тінь», звіряємо агрегати (GGR/NGR) до промоушену.

Покроковий реліз без простою (еталонний сценарій)

1. Підготовка:

Контракт релізу: що'PATCH/MINOR/MAJOR', матриця сумісності.
Міграції'expand'застосовані заздалегідь, індекс-білди - онлайн.
Асети завантажені в CDN, маніфест готовий.

2. Канарний старт (API/ігрові шлюзи):

1-5% трафіку. Спостерігаємо p95/99'bet. place','settle','error _ rate', зростання'VOID', дисбаланс виплат.
Порівняння фінансів з контрольною групою (дельта <поріг).

3. Розширення/перемикання:

Збільшуємо відсоток до 25/50/100 або перемикаємо Blue-Green на ядрі грошей.
Включаємо фічі прапорами (локалі/ігри/регіони).

4. Міграція «migrate»:

Фонові джоби переносять дані/прогреси, включається dual-write.
Телеметрія валідує збіг метрик.

5. Оптимізація та «contract»:

Відключаємо легаси-читання, видаляємо «тіні» в наступному MINOR/MAJOR.
Оновлюємо каталоги схем/подій, закриваємо депрекейт.

6. Документація та ретро:

Пост-мортем/ретро навіть без інциденту: що поліпшити в SLO, алертах, чек-листах.

Спостережуваність і SLO під час релізу

SLI/SLO:

`bet. place p95'( ціль ≤ 150-250 мс),'error _ rate'( <0. 3%), `round. settle p95` (≤2 с), `payout. submit p95'( ≤800 мс).
Live QoS: `webrtc_rtt_ms`, `dropped_frames`, `aborted_rounds`.
Версійні теги: 'buildId','semver','contractVer','calcVer'в логах і трейсі.
Фін-дельти: порівняння GGR/NGR/hold за сегментами старої/нової гілки.

Відкати (rollback) без болю

Blue-Green: миттєве повернення маршруту на «синій».

Canary: зводимо трафік до 0%, відключаємо фічі прапором.

Асети: старий маніфест залишається доступним (immutable), гравці на старих сторінках не ламаються.

Дані: якщо був dual-write - при відкаті читаємо «старе» джерело; destructive-міграцій до confirm не було.

Організація та процеси

Change windows з охороною SRE: реліз-слоти під піки/спортивні події не чіпаємо.

Runbooks: чек-листи для перемикань ingress, ролей БД, прапора фічі, контактні ланцюжки.

Dark-launch: включаємо все, крім видимості в UI, проганяємо «приховане» навантаження.

Часті помилки (анти-патерни)

Перезапис асетів без версіяції → биті клієнти і «рожеві квадрати».

Ламаючі зміни подій/API «тихо» → відвал інтеграцій провайдерів і дашбордів.

Міграції schema + logic в одному кроці без dual-write → фінансові розбіжності.

Відсутність ідемпотентності → подвійні дебети при ретраях.

Єдиний перемикач відразу на 100% без канарок і метрик.

Змішування UI-релізу і розрахункового ядра в одному розгортанні.

Немає плану відкату або відкат вимагає «ручних» SQL.

Чек-лист zero-downtime релізу

Контракти та дані

SemVer +'contractVer/eventVer/calcVer'прописані і задокументовані.
Міграції'expand'застосовані заздалегідь;'migrate'- в фоні;'contract'- в наступному циклі.
Dual-write/Dual-read там, де змінюється фінлогіка.

Інфраструктура

CDN: immutable-асети, маніфест, tag-purge,'stale-while-revalidate'.
Blue-Green для ядра грошей; Canary для API/ігрових шлюзів.
Feature-flags для UI/механік; прапори управляються без деплоя.

Спостережуваність

Трейси з'buildId/semver/calcVer'; дашборди SLO і фін-дельт.
Алерти на зростання'VOID','error _ rate', деградацію live-QoS.

Відкат і безпека

Кнопка rollback (ingress/маршрутизація), старий маніфест доступний.
PITR і shadow-проводки для перевірки леджера.
Тест відкату відпрацьований на стейджі і в малому прод-сегменті.

Процеси

Runbooks перемикань; узгоджені change-вікна.
Dark-launch/канарка; ретро після релізу.

Zero-downtime в iGaming - це системна практика: версії і контракти, immutable-асети і CDN, blue-green/canary, міграції без простою, ідемпотентні гроші і жорстка спостережуваність. Дотримуючись цього чек-листа, ви оновлюєте ігри і платформу так, що гравець нічого не помічає - крім того, що все стало швидше і стабільніше.