Остановка запуска важнее статуса «провайдер недоступен»
Сбой провайдера — не только исчезнувшие иконки: между ставкой и финальным расчётом остаются раунды. Один кошелёк списал ставку, другой ждёт callback; исход может быть в журнале игры, а в back office — pending. Возврат игры в каталог до расчёта превращает технический инцидент в спор о балансе, выводе средств и учёте.
Цель оператора — не зелёный статус, а закрытый жизненный цикл каждого раунда, доказательства решений и открытие каталога после проверки зависимостей. Нужен общий сценарий для оператора, агрегатора, провайдера, поддержки и finance: у всех свои журналы, задержки и причины объявить восстановление раньше других.
Каталог должен быть управляемым контуром. Как устроены каталог, поиск и мерчандайзинг витрины онлайн-казино, так и stop-launch обязан блокировать карточку, поиск, избранное, «недавно играли», deeplink и промо-блоки, а не только основную выдачу.
Раунд проходит восемь состояний, а не два
«Завершён или отменён» достаточно для отчёта, но не для инцидента. Цепочку состояний нужно зафиксировать в runbook до сбоя, не подстраивая под спор: иначе support обещает возврат, provider присылает поздний win, а finance уже сделал ручную корректировку.
| Состояние инцидента | Что делает система и команда | Доказательство перехода |
|---|---|---|
| Сигнал получен | Мониторинг, агрегатор или provider фиксирует недоступность, launch-ошибку либо отсутствие callbacks | Время, источник, game ID |
| Stop-launch активен | Новые сессии блокируются во всех каналах каталога | Лог запрета, проверка deeplink и поиска |
| Срез затронутых раундов | Создаётся неизменяемый список открытых до отсечения раундов | Export: round ID, player ID, stake, status, timestamps |
| Ожидание авторитетного статуса | Provider подтверждает исход, отмену или отсутствие раунда | Подписанный API-ответ, файл сверки или тикет |
| Классификация решения | Раунд получает settled, void или pending investigation | Resolution reason и владелец |
| Проверка кошелька | Сверяются debit, credit, rollback и баланс игрока | Wallet ledger, idempotency key, сверка |
| Recovery gate | Подтверждаются отсутствие новых зависших операций и доступность сервиса | Контрольный запуск, callback-проверка, подписи |
| Инцидент закрыт | Каталог возвращается поэтапно, журнал и доказательства сохраняются | Timeline, post-incident запись, коммуникации |
Pending — не ошибка и не void: у оператора ещё нет основания менять баланс. Массовая отмена «очищает» очередь, но поздний callback может прийти после возврата ставки, а журнал провайдера остаться единственным источником исхода в споре.
Интерфейс не должен сам повторно запускать незаконченный раунд: replay способен создать второй запрос до финального ответа. Возобновление допустимо только если правила игры, интеграционный контракт и данные provider подтверждают безопасный continuation; иначе система ждёт классификации.
Void не исправляет ошибку кошелька
Void отвечает за судьбу ставки, но не за фактическое состояние денег. Если debit не дошёл до кошелька, rollback необоснованно пополнит баланс. Если debit прошёл, а credit выигрыша задержался, снятие pending оставит игрока с меньшим балансом. Если записались debit и credit, компенсация даст двойную выплату.
Поэтому есть два слоя: provider определяет, существовал ли раунд, принят ли исход и разрешена ли отмена; кошелёк оператора — какие проводки приняты, отклонены или повторены и в каком порядке. Provider не должен единолично менять баланс, а finance — объявлять игровую запись void без игрового журнала.
Время клиента, агрегатора, game server и wallet service может различаться. Срез — не «последний час по экранным часам», а согласованная точка отсечения с часовым поясом, correlation ID и правилами поздних callbacks. Раунды, начатые до stop-launch и завершённые после него, отмечаются отдельно: они не доказывают неработающую блокировку и сверяются штатно.
Не следует оценивать инцидент только по GGR. Отмена выигрышных раундов может временно улучшить маржу, но не показывает долг игроку и контрактный риск. Решения принимаются по операционным статусам; финансовый эффект анализируется после закрытия отдельно по каждой сессии.
Пять команд держат один инцидент
Без заранее названных ролей агрегатор ждёт файл provider, provider относит кошелёк к оператору, а support не может объяснить игроку ситуацию. В RACI R — исполнитель, A — окончательное решение, C — консультация, I — информирование.
| Действие | Оператор | Агрегатор | Provider | Support | Finance |
|---|---|---|---|---|---|
| Объявить инцидент и присвоить ID | A/R | C | C | I | I |
| Включить stop-launch во всех точках каталога | A | R | C | I | I |
| Передать affected-round export | A | C | R | I | C |
| Определить settled, void или investigation | A | C | R | I | C |
| Сверить проводки кошелька и корректировки | A | I | C | I | R |
| Ответить игрокам и закрыть жалобы | A | I | C | R | C |
| Открыть recovery gate и вернуть каталог | A/R | R | C | I | C |
Оператор сохраняет A за решения о балансе и доступности каталога: даже если агрегатор скрывает игры, бренд, лицензия и коммуникация принадлежат оператору. Provider несёт R за авторитетную запись раунда и технический статус; finance — за проводки и документацию ручных корректировок, но не за игровую математику.
Support нельзя оставлять лишь в I. Игроки раньше дашборда присылают скриншоты, называют game round и замечают списание. Поддержка собирает обращения под incident ID, не обещает срок возврата без правила и не закрывает тикет «обратитесь позже». Ей нужны статусы: ожидание данных provider, подтверждённая отмена, расчёт или ручная проверка.
Четыре артефакта заменяют переписку догадками
Сообщение «всё восстановлено» не доказывает закрытие. Минимальный пакет должен быть доступен через неделю при жалобе, аудите или расхождении журналов. Это обезличенные формы, а не шаблоны полей без адаптации к API партнёров.
| Артефакт | Обезличенный пример | Решение, которое он поддерживает |
|---|---|---|
| Affected-round export | INC-784 / rnd_8f2… / plr_hash_41… / game_221 / debit accepted / credit absent / opened 14:03:18 UTC |
Входит ли раунд в срез, владелец и запрос к provider |
| Stop-launch log | 14:05:02 UTC / game_221 disabled / channels: lobby, search, favourites, deeplink / aggregator ack: received |
Новые запуски остановлены не только в карусели |
| Wallet check | rnd_8f2… / debit ledger_93… / rollback none / credit none / final balance verified at 15:11 UTC |
Нужны отмена, расчёт выигрыша или ожидание операции |
| Recovery gate | provider health pass / callback test pass / pending queue reviewed / support brief sent / owner approval recorded |
Игру можно вернуть без новых спорных раундов |
В export нужны технические, но не открыто передаваемые персональные данные: псевдонимизированный player ID, round ID, game ID, provider transaction ID, сумма в валюте кошелька, время, debit/credit, причина решения и incident ID. Полные данные остаются в защищённом контуре, сохраняя трассировку и снижая риск утечки.
Stop-launch проверяют глазами игрока. Отключённая карточка при рабочем deeplink не является остановкой; то же относится к избранному, недавно открытым играм, промо и нативному приложению с отдельным кэшем. Раннее восстановление одного канала возможно только как осознанный staged rollout с отдельной фиксацией.
Лицензия меняет правила фиксации и уведомлений
Нет общего правила, по которому interrupted game автоматически void через заданное число минут. Исход определяется правилами игры, лицензией, интеграционным договором, политикой жалоб и территорией игрока; сроки хранения журналов, event records и порог уведомления регулятора также зависят от юрисдикции.
| Территория и первичный источник | Что проверить до решения по инциденту |
|---|---|
| Великобритания, Remote Gambling and Software Technical Standards Комиссии по азартным играм | Требования к удалённому ПО, защищённости игровых функций, журналам и процедурам; условия лицензии о жалобах и уведомлениях регулятора |
| Онтарио, стандарты интернет-гейминга AGCO | Честность игры, хранение записей, обработка инцидентов и ожидания к информированию игроков |
Документы задают направление, но не заменяют оценку случая. До восстановления устанавливают лицензию бренда, владельца журналов, необходимость уведомления и допустимое описание для игрока. Контракт с provider должен определять передачу event records, сроки ответа, авторитетный источник результата, повторные запросы и эскалацию; иначе спор о раунде станет спором партнёров.
Возврат каталога начинается с recovery gate
Рабочий API provider ещё не причина снять stop-launch. Первый health check не показывает порядок callbacks, накопленную очередь событий и старые кэшированные статусы. Recovery gate отделяет техническое восстановление от пользовательской доступности.
Минимум: контрольная сессия, подтверждённые debit и credit в тестовом контуре, callback у оператора, отсутствие роста pending после включения ограниченной группы игр и готовность support к открытым обращениям. При выдаче каталога через агрегатор проверяют всю цепочку, а не прямой endpoint provider: здоровый сервис может оставаться недоступным пользователю.
При одном game ID можно прочитать все раунды вручную; при сбое десятков игр важнее идентификаторы, пакетная обработка и неизменяемый срез. Export нельзя переформировать так, чтобы исчезли учтённые записи. Поздний callback, задержанная доставка агрегатора или ошибка первоначальной выгрузки добавляются новой версией с причиной.
Каталог открывают ступенчато: контрольная игра или малая группа, основной набор, затем промо. Это позволяет заметить новое зависание до роста очереди спорных операций, а не скрыть проблему. Недоступная игра должна показывать нейтральный технический статус, не ошибку регистрации или кассы.
Качество восстановления видно по хвосту pending-раундов
Успех — не только время возврата карточек в лобби. Нужны возраст и объём pending-очереди, доля подтверждённых финальных статусов, расхождения game log и wallet ledger, ручные корректировки и повторные обращения после закрытия тикета. Показатели режут по игре, provider, агрегатору, каналу запуска и причине решения.
Рост pending после снятия stop-launch означает неполное восстановление при зелёном мониторинге. Рост ручных корректировок указывает на слабую идемпотентность кошелька или недостаток export-данных. Волна жалоб после закрытия не всегда означает неверный расчёт: игрок мог не понять, почему ставка возвращена, выигрыш не начислен или раунд рассчитан позже.
Post-incident разбор отвечает на три вопроса: где впервые потерялось событие — в игре, агрегаторе, очереди оператора или кошельке; какой контроль раньше остановил бы проблему — callback-мониторинг, лимит возраста pending, launch-проверка или alert по ledger-расхождению; что в runbook создало лишнее согласование. Ответы превращаются в изменения событий, эскалации и recovery gate, а не в запись «провайдер восстановился».
Надёжный каталог возвращается после доказательства, а не после пинга
Незавершённый раунд требует дисциплины данных и ролей: оператор блокирует новые запуски всеми путями, сохраняет срез, получает авторитетный статус игры, сверяет кошелёк и затем открывает recovery gate. Быстрое включение каталога сокращает видимую длительность outage, но переносит последствия в жалобы и ручные корректировки.
Зрелый процесс оставляет воспроизводимую цепочку: состояние инцидента, владелец решения, журнал раунда, запись кошелька и подтверждение безопасного возврата. Она защищает игрока, оператора и партнёров, когда технический сбой закончился, а спор о балансе начался.