By Alexey Lee — 30 апр. 2025

Анализ инцидента с продажей билетов на JLo на Тикетоне

Алексей Ли:

11 апреля 2025 года при запуске концерта на JLo на Тикетоне произошел сбой, который повлек дублирование более 10 тыс. билетов и кризисную ситуацию. За 13 лет работы Тикетона технический сбой такого масштаба случился впервые. Это породило большое количество непрогнозируемых событий, на устранение которых потребовалось более 1 недели и решение акционера выплатить щедрые компенсации клиентам, с бюджетом в сотни миллионов тенге.

Резюме:

11 апреля 2025 года при запуске продаж билетов на концерт JLO на платформе Ticketon произошёл масштабный инцидент, вызванный совокупностью управленческих, процессных и технологических недоработок, который показал:

необходимость улучшения  процессов управления массовыми продажами;
недостаточную подготовку fallback-механизмов проверки транзакций при отказах и необходимость active polling статуса транзакций;
архитектурные ограничения старой платформы;
и непротестированное внедрение технологического решения (комнаты ожидания), без оценки его влияния на критические бизнес-потоки.

Отсутствие сквозного планирования на случай отказов привело к дублированию более 10 000 билетов, кризисной нагрузке на команды и необходимости принятия решения о дополнительных компенсациях клиентам.

Инцидент стал триггером к углубленной трансформации Ticketon: пересмотру бизнес-процессов, ускоренному переходу на новую технологическую платформу, и интеграции компании в общую экосистему Freedom Lifestyle Group.

Предыстория:

Тикетон я начал запускать в 2012 году, и недолго спустя в качестве кофаундера к проекту присоединился Константин Горожанкин. Проект начинался как стартап, и быстро перерос в лидирующую платформу по продаже билетов в Казахстане. Я вышел из проекта в 2015, оставаясь одним из учредителей, до 2020 года когда мы вышли из проекта. За это время, с 2015 по 2020, программный код платформы рос под управлением аутсорсинговой компании. Платформа очень сильно выросла, и как никакая другая платформа учитывает нюансы практически всех спортивных и концертных площадок в Казахстане, билетных и турникетных интеграций, но при этом она уже тяжело поддавалась дальнейшему росту, отладке и имела предел пропускной способности. Долгое время компания существовала как изолированное государство, не привлекая ресурсы холдинга, и холдинг старался не разрушать культуру и самодостаточность компании. В 2023 году стало очевидным, что необходимы изменения. Константин Горожанкин вышел из Набсовета в начале 2024 года, команда Фридома провела оптимизации легаси-кода, а начиная с ноября 2024 года выделенная команда под руководством отдельного лидера начала разработку новой технологической платформы Тикетон, но к моменту инцидента с билетами JLo платформа запущена не была, и ресурсы поддержки старой платформы были сведены к минимуму, что в том числе создало дефицит ресурсов в день Х.

Я присоединился к Фридому осенью 2024 года, чтобы начать трансформацию компаний, входящих в группу Lifestyle – и с января 2025 года мы начали централизовывать ряд функций, но к моменту инцидента Тикетон всё ещё оставался достаточно изолированной компанией в плане операционного управления.

День Х:

Ожидая высокую нагрузку и ажиотаж, исходя из опыта продаж прошлых мероприятий, технические команды Тикетона и холдинга увеличили ресурсы на серверах, и стандартно подготовили команды поддержки и подрядчиков, осуществляющих разработку и поддержку платформы.

11 апреля 2025 года в 11:00, после запуска продаж билетов на концерт JLo, наблюдалась массовая проблема загрузки основного сайта:

Пользователи сталкивались с ошибками о том, что на сайте идут технические работы.
Веб-сайт периодически то загружался, то снова становился недоступным.
База данных показывала нестандартно высокую нагрузку на запись и множественные блокировки транзакций.
Запросы к ключевым таблицам базы данных выполнялись с существенными задержками или не завершались вовсе.

Инцидент был замечен практически сразу, т. к. все технические специалисты, а также руководитель Тикетона и тех.лидеры холдинга были подключены к одной видеоконференции, где осуществлялся общий мониторинг работоспособности сервиса. Дополнительно об инциденте сообщили пользователи через соцсети и канал поддержки, почти сразу после начала продаж. 

Предварительное увеличение ресурсов на серверах помогли незначительно, т.к. легаси-код давал лишь несущественные улучшения даже при кратном увеличении ресурсов.

В районе 12 часов виртуальная комната ожидания стабилизирует ситуацию. Примерно в это же время коллеги проинформировали меня, и мы начинаем писать пост о том, что мы в курсе ситуации и работаем над ее решением.

Учитывая отложенный механизм сверки продаж в legacy-системе, в 12:54 обнаруживается проблема, что количество выписываемых билетов необычайно мало. Проверка оплат выявляет большое количество расхождений. Идентифицирована проблема: IP адреса платежного подсервиса не внесены в белые списки, ввиду чего в систему Тикетон не поступают подтверждения от платёжных систем и соответственно не завершаются продажи билетов, а спустя определённое время снимается бронь. Проблему исправили и количество подтверждённых проданных билетов начало расти. В это же время представитель платёжной системы предоставил для сверки количество проведенных платежей – которых оказалось на тысячи больше, чем проданных билетов. В этот момент я, периодически присоединяясь к виртуальному консилиуму, поняв масштаб потенциальной проблемы, принял решение останавливать продажи, невзирая на регламенты организаторов. Масштаб проблемы командой Тикетона был оценен в один день ("до утра"), и мы отключились от штаба.

Последствия

В первый день работает локальный штаб, остается в ночь. Во второй день (суббота) становится понятно что масштабы растут. В воскресенье утром мы осознали, что Тикетон не способен урегулировать последствия самостоятельно, и мы создаем полноценный штаб от лайфстайл-группы.

Все обмены билетов занимали гораздо больше времени, чем команда оценила изначально, ввиду сложного урегулирования справедливых недовольств клиентов. Кроме того, в случаях выявления броней находились случаи, где люди выкупали большее количество билетов, чем разрешил организатор. Threads явился отдушиной гнева клиентов, но также затруднял разрешение ситуаций, т.к. некоторые клиенты, являясь друзьями или родственниками, писали с разных аккаунтов об одной и той же проблеме.

Каждый из дней была надежда, что к утру или сможем договориться на доп.концерт, или команда найдет билеты (например, из блоков, выкупленных турагентствами). Это оттягивало тяжелые финальные решения, и вызывало накопление большего количества негатива у клиентов.

Спустя четверо суток, в вечер вторника мы поняли, что дальнейший поиск билетов может растягиваться бесконечно долго, растягивая и томительные ожидания для разочарованных клиентов, и акционер принял волевое решение выплатить компенсации +100% тем, кому не нашли билетов и вернули платеж, а также вернуть 50% стоимости билетов тем, кого пересадили на другие места.

В сухом остатке:

В подготовках к большим событиям должен быть action-plan на случай, если все иные меры не сработали (например, увеличенные мощности серверов оказались недостаточны).
Под давлением ситуации инженеры ввели непроверенное решение; Так впредь делать нельзя. Черные лебеди могут запускать всю цепную реакцию.
В консилиумах, где необходимо большое количество специалистов разного профиля, должны быть люди, чья ответственность не размывается с увеличением группы. Консилиумы создают "групповую динамику", лидеры должны уметь принимать непопулярные решения.
Если бы по тем 11 тыс билетов, которые не подтвердились сразу, сделали бы возврат день-в-день, не пытаясь спасти ситуацию для каждого клиента в отдельности, то возможно шоковая волна кризиса сжалась бы в один день, не растягиваясь на "многосерийную драму" (но это неточно). 
Когда масштаб происшествия большой, и нет отработанных скриптов, то лучше не заходить в сценарии, где требуется индивидуальная работа от операторов, от которых в иное время требуются простые операции. Это может растягивать кризис на неопределенно долгое время.
В оценке масштаба и планировании последствий нельзя недооценивать вероятность того, что в каждой ветке принятия решений всё будет идти по наихудшему сценарию, растягивая процесс на дни (и недели в каких-то случаях). Планировать по наихудшему сценарию, строить "оперативный штаб" исходя из этого масштаба: если в условиях недостаточной информации потенциально масштаб большой, уметь эскалировать максимально быстро – "плохие новости должны ходить быстро". Это должно быть вшито в процедуры эскалации – онбординг и тренинги.
Процедуры развертывания штаба:

Более жестко и ритмично координировать штаб, сразу назначать начальника штаба, ставить раскладушки, воду еду.
Могут быть необходимы самые разные специалисты – включая, например, дата-специалистов умеющих работать с сырыми данными. Активировать всех важно сразу, в первый день, и настраивать на работу в ночь – "надеемся на лучшее, готовимся к худшему".
Если компания является частью холдинга, она должна уметь активировать "облако ресурсов" большего периметра максимально быстро и отработанно – для этого необходима унификация инструментов и процедуры активации "облака".

При разработке новой платформы (6-9 месяцев) новая команда не может работать в отрыве от проблем легаси-платформы. Это приводит к неспособности новой команды включаться в решение нестандартных проблем.

Тикетон 2.0

С начала 2025 года мы начали интеграцию Тикетона в группу Lifestyle для того, чтобы унифицировать стандарты, усилить менеджерский состав, внедрить продуктовые подходы. После инцидента мы ускоряем процесс интеграции в Lifestyle-группу, и переход должен совершиться в течение следующих нескольких недель. Новая платформа Тикетона также будет интегрирована гораздо раньше, чем планировали ранее, и будет проходить параллельную обкатку.

Тикетон 2.0 – уже скоро!

Алексей Ли, куратор Lifestyle-группы Freedom, в которую входит компания Тикетон