Когда игровой провайдер падает, иконки в лобби гаснут первыми. Но опасное происходит глубже, между ставкой и расчётом: раунды повисают, кошелёк уже списал деньги, а исход не подтверждён. Вернуть игры в каталог до закрытия этих раундов значит превратить технический сбой в спор о балансах и выплатах.
Остановка запуска важнее статуса "провайдер недоступен"
Исчезнувшие иконки видны всем. Деньги застревают в другом месте. Один кошелёк списал ставку, другой ждёт callback; исход может уже лежать в журнале игры, а в back office раунд всё ещё висит как pending. Возврат игры в каталог до расчёта превращает технический инцидент в спор о балансе, выводе средств и учёте.
Зелёный статус мониторинга оператору ничего не гарантирует. Цель другая: закрытый жизненный цикл каждого раунда, доказательства решений и открытие каталога после проверки зависимостей. Нужен общий сценарий для оператора, агрегатора, провайдера, поддержки и finance. У всех свои журналы, задержки и причины объявить восстановление раньше других.
Каталог должен быть управляемым контуром. Как устроены каталог, поиск и мерчандайзинг витрины онлайн-казино, так и stop-launch обязан блокировать карточку, поиск, избранное, "недавно играли", deeplink и промо-блоки, а не только основную выдачу.
Восемь этапов обработки инцидента: от сигнала до возврата каталога
Ярлыка "завершён или отменён" достаточно для отчёта, но не для инцидента. Цепочку состояний фиксируют в runbook до сбоя. Иначе support обещает возврат, provider присылает поздний win, а finance уже сделал ручную корректировку.
- Сигнал. Мониторинг, агрегатор или сам provider ловит недоступность, launch-ошибку или пропавшие callbacks. В журнал ложатся время, источник и game ID.
- Stop-launch. Новые сессии блокируются во всех каналах каталога. Факт запрета подтверждается логом с проверкой deeplink и поиска.
- Срез затронутых раундов. Пока запуск закрыт, оператор снимает неизменяемый список всех сессий, открытых до точки отсечения: round ID, player ID, ставка, статус и таймстампы.
- Ожидание авторитетного статуса. Provider подтверждает исход, отмену или отсутствие раунда подписанным API-ответом, файлом сверки или тикетом. Без этого документа классификация не завершается.
- Классификация. Каждый раунд получает один из трёх ярлыков (settled, void или pending investigation) с явной причиной и владельцем решения.
- Проверка кошелька. Debit, credit, rollback и итоговый баланс игрока сверяются по ledger с idempotency key.
- Recovery gate. Контрольный запуск, callback-проверка и подписи подтверждают, что новых зависших операций нет и сервис доступен.
- Закрытие. Каталог возвращён поэтапно, timeline, post-incident запись и коммуникации сохранены.
Pending не ошибка и не void. У оператора просто ещё нет основания менять баланс. Массовая отмена "очищает" очередь, но поздний callback может прийти после возврата ставки, и журнал провайдера останется единственным источником исхода в споре.
Интерфейс не должен сам повторно запускать незаконченный раунд: replay способен создать второй запрос до финального ответа. Возобновление допустимо, только если правила игры, интеграционный контракт и данные provider подтверждают безопасный continuation. Иначе система ждёт классификации.
Void не исправляет ошибку кошелька
Void отвечает за судьбу ставки, но не за фактическое состояние денег. Если debit не дошёл до кошелька, rollback необоснованно пополнит баланс. Если debit прошёл, а credit выигрыша задержался, снятие pending оставит игрока с меньшим балансом. Если записались и debit, и credit, компенсация даст двойную выплату.
Сверка одного раунда на примере
Возьмём спорный раунд с придуманными суммами. Ставка 50, выигрыш по журналу игры 180, валюта кошелька одна.
- debit -50, принят кошельком (ledger_93)
- credit +180, в кошельке отсутствует, хотя provider прислал win
- rollback не выполнялся
Корректный итог по раунду: -50 + 180 = +130. Фактически на балансе только -50, то есть недостача 180 относительно исхода.
Три варианта решения дают разный денежный результат:
- void с возвратом ставки: вернуть +50 → баланс 0. Но выигрыш 180 не выплачен, хотя журнал провайдера его подтверждает, то есть исход существовал и отмена неверна.
- дослать credit +180: -50 + 180 = +130, и это корректно, если win подтверждён авторитетно.
- компенсация без сверки credit: если позже придёт поздний credit +180, суммарно начислится 360, то есть переплата 180.
Итог: действие выбирают не по статусу "сбой закончился", а по тому, какие проводки уже приняты. Сначала фиксируют принятые debit/credit/rollback, затем классифицируют раунд.
Поэтому слоёв два. 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 отвечает, входит ли раунд в срез и кто владелец запроса к provider. Одна строка выглядит так:
INC-784 / rnd_8f2… / plr_hash_41… / game_221 / debit accepted / credit absent / opened 14:03:18 UTC. - 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 к открытым обращениям. При выдаче каталога через агрегатор проверяют всю цепочку целиком, от агрегатора до кошелька. Здоровый сервис может оставаться недоступным пользователю.
Масштаб меняет метод. При одном game ID все раунды можно прочитать вручную. При сбое десятков игр важнее идентификаторы, пакетная обработка и неизменяемый срез. Допустим, упали 40 игр одного провайдера, и в каждой в момент сбоя было по 25 открытых сессий: это 1 000 раундов, и при двух минутах на ручную сверку набирается больше 33 часов работы одного человека. Export нельзя переформировать так, чтобы исчезли учтённые записи. Поздний callback, задержанная доставка агрегатора или ошибка первоначальной выгрузки добавляются новой версией с причиной.
Каталог открывают ступенчато: контрольная игра или малая группа, основной набор, затем промо. Так новое зависание видно раньше, чем вырастет очередь спорных операций. Недоступная игра должна показывать нейтральный технический статус, а не ошибку регистрации или кассы.
Качество восстановления видно по хвосту pending-раундов
Время возврата карточек в лобби описывает успех лишь частично. Этот показатель проще всего улучшить, просто открыв каталог раньше, чем следовало. Нужны возраст и объём pending-очереди, доля подтверждённых финальных статусов, расхождения game log и wallet ledger, ручные корректировки и повторные обращения после закрытия тикета. Показатели режут по игре, provider, агрегатору, каналу запуска и причине решения.
Рост pending после снятия stop-launch означает неполное восстановление при зелёном мониторинге. Рост ручных корректировок указывает на слабую идемпотентность кошелька или недостаток export-данных. Волна жалоб после закрытия не всегда означает неверный расчёт: игрок мог не понять, почему ставка возвращена, выигрыш не начислен или раунд рассчитан позже.
Post-incident разбор отвечает на три вопроса:
- Где впервые потерялось событие: в игре, агрегаторе, очереди оператора или кошельке?
- Какой контроль остановил бы проблему раньше: callback-мониторинг, лимит возраста pending, launch-проверка или alert по ledger-расхождению?
- Что в runbook создало лишнее согласование?
Ответы превращаются в изменения событий, эскалаций и recovery gate; запись "провайдер восстановился" итогом разбора не считается.
Быстрое включение каталога сокращает видимую длительность outage, но переносит последствия в жалобы и ручные корректировки. Слабое звено runbook обычно лучше видно на старом инциденте, чем на учениях. Если по любому раунду из прошлого сбоя за десять минут не удаётся собрать состояние, владельца решения, журнал игры, запись кошелька и подтверждение возврата, а какое-то звено приходится выпрашивать у партнёра в переписке, то именно на этом звене следующий сбой и превратится в спор о балансе.