Как устроен деплой и обновления игр без перерывов

Зачем 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. Oптимизация и `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, миграции без простоя, идемпотентные деньги и жёсткая наблюдаемость. Следуя этому чек-листу, вы обновляете игры и платформу так, что игрок ничего не замечает — кроме того, что всё стало быстрее и стабильнее.