Стала понятна главная причина дублирования билетов. При массовом наплыве пользователей сервера Ticketon перестали справляться с нагрузкой и сайт периодически становился недоступным. Чтобы решить эту проблему, команда экстренно решила использовать Cloudflare Waiting Room. В постмортеме напрямую не называется Cloudflare, но этот сервис упоминается в прошлом сообщении Алексея Ли.

Когда используется Cloudflare Waiting Room, пользователи перенаправляются на специальную страницу ожидания вместо того, чтобы случайным образом получать ошибки загрузки сайта. И система следит за тем, чтобы те пользователи, кто пришёл раньше, получили доступ к сайту раньше. Виртуальная очередь как снижает нагрузку на сайт, так и явно информирует пользователей, когда они смогут воспользоваться сервисом. Рекомендую прочитать статью о том, как использовать Waiting Room. А для тех, кто хочет узнать больше, есть хорошая статья о технических деталях работы сервиса.

Проблемы начались сразу же после включения электронной очереди. Чтобы понять причину, необходимо знать, как работает оплата на веб-сайтах. Для этого рекомендую посмотреть видео, где я рассказываю про работу платёжных провайдеров на примере Stripe. Другие платёжные провайдеры работают аналогично.

Когда пользователь заходит на сайт Ticketon, выбирает билет и нажимает "Оплатить", то оплату принимает не Ticketon, а отдельный сервис - платёжный провайдер. После того, как пользователь оплатил билет и платёжный провайдер снял деньги с карты, необходимо уведомить об этом Ticketon, чтобы он у себя отметил, что этот билет продан, и затем выслал ваучер покупателю. Для этого у Ticketon есть HTTP API эндпоинт, на который платёжный провайдер шлёт HTTP запросы с подтверждениями покупок билетов.

Проблема возникла именно с этим эндпоинтом.

Для повышения безопасности и надёжности системы Ticketon позволял слать запросы на эндпоинт только с ограниченного списка IP адресов - адресов платёжного провайдера. Это грамотное решение. Нельзя давать возможность кому угодно слать запросы на такой важный эндпоинт.

Так что же произошло после того, как команда подключила Cloudflare Waiting Room? В постмортеме это явно не указано, но я вижу только один возможный сценарий. Для того, чтобы Waiting Room заработал, нужно начать проксировать трафик через Cloudflare. То есть запросы от пользователей сначала отправляются на сервера Cloudflare и потом Cloudflare переотправляет запросы на сервера Ticketon. Это позволяет решить, перегружен ли сайт, и, если да, то вместо запроса на сайт Ticketon вернуть HTML-страницу электронной очереди.

Думаю, внимательные читатели уже поняли, что пошло не так.

После включения проксирования через Cloudflare запросы от платёжного провайдера стали также проходить через Cloudflare. И запросы на эндпоинт подтверждения покупок в Ticketon стали приходить с IP адресов Cloudflare, а не с IP адресов платёжного провайдера. Поэтому эти запросы блокировались. Покупки перестали подтверждаться.

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

Но подтверждение оплаты покупателем не доходило от платёжного провайдера до Ticketon. И Ticketon думал, что покупатель выбрал билет, перешёл на его оплату, но оплату не произвёл. Из-за этого через некоторое время бронь с билета снималась, и его мог купить уже другой человек. В итоге, было совершено более 10 тысяч таких повторных продаж.

К сожалению, в постмортеме не указано, как можно было предотвратить эту проблему. Поэтому я напишу 2 технических решения, которые позволили бы избежать сбоя:

1. Можно было начать проксировать через Cloudflare не все запросы на Ticketon, а только запросы от пользователей. Но для этого эндпоинт подтверждения платежей должен был изначально быть на другом (под)домене. Cloudflare позволяет включать проксировать только для конкретных доменов. Если бы эндпоинт был, к примеру, по адресу https://payments.ticketon.kz/webhook, то можно было не включать проксирование для payments.ticketon.kz, и проблема бы не возникла
2. Использование прокси по пути запроса от клиента к целевому серверу это частая практика. И поэтому нельзя смотреть только на IP адрес пришедшего запроса, чтобы понять, кто его изначальный отправитель. Для сохранения информации об IP адресе исходного отправителя прокси в переотправляемые запросы добавляют HTTP-заголовок X-Forwarded-For. Cloudflare тоже так делает. Поэтому сервера Ticketon должны были проверять наличие этого заголовка и брать IP адрес отправителя оттуда. Там бы они нашли адрес платёжного провайдера и проблема бы не возникла.

Указанные выше меры позволили бы избежать сбоя в этом конкретном случае. Но могут возникнуть и другие проблемы. Поэтому у команды должен был быть план на случай, когда такая важная часть общего процесса покупки перестала работать. К примеру, должна быть метрика отношения количества бронирований к количеству покупок. И в случае аномального изменения этой метрики, команде должен сразу прилетать алёрт. И затем у команды должны были быть средства быстро предотвращения проблемы. Например, автоматическое продление бронирования для всех неоплаченных билетов. Чтобы их нельзя было купить, пока команда не решит проблему.

На этом я завершаю анализ технических деталей и хочу поделиться своим мнением о постмортеме в целом.

Упор в документе сделан на организационных проблемах и на том, как их предотвращать в будущем. Я бы хотел, чтобы технические проблемы были проанализированы так же глубоко. Чтобы в посмортеме было больше технических деталей, таких как графики потребления ресурсов и времени обработки запросов, и описание того, что в сайте отказало под нагрузкой.

Но нужно отдать должное команде Ticketon и Freedom Holding в целом. Казахстанские компании всё ещё очень редко публикуют постмортемы, и шаг Ticketon заслуживает большого уважения. Это повышает прозрачность и помогает всему сообществу казахстанских ИТ-специалистов учиться на реальных ситуациях. Надеюсь, другие компании последуют примеру Ticketon и тоже будут публиковать разбор сбоев своих ИТ-систем. Это сделает рынок более зрелым, а продукты надёжнее.

P.S. Подписывайтесь на мой канал, чтобы получать подобные глубокие технические разборы и быть в курсе событий ИТ-индустрии https://t.me/drim_channel

ДОПОЛНЕНИЕ от 13 мая 2025 года:

В комментарии ниже написали, что причина сбоя была несколько другой. И заключалась в том, что запросы от платёжного провайдера просто не доходили до эндпоинта, потому что они вставали в очередь наравне с запросами от пользователей. Для корректной работы нужно было в конфигурации Cloudflare Waiting Room настроить Bypass Rules, чтобы запросы с IP адресов платёжных провайдеров не попадали в очередь ожидания. Либо настроить правило, чтобы в очередь не попадали запросы на конкретный URL эндпоинта Ticketon. Спасибо комментатору Владимиру за уточнение, это ценно.

И сервис упал.

Ситуация, когда интернет-сервисы не справляются с нагрузкой и перестают стабильно работать, не является редкой. На это есть разные причины. Возможно, маркетологи недооценили спрос. Или техническая команда неверно рассчитала сколько железа необходимо. Или с нагрузкой не справились внешние сервисы. Ситуация плохая и она бьёт по репутации компании. Но всё же она не критичная. Обычно команда достаточно быстро находит причины падения и устраняет их. Те, кто не смог купить билеты сразу, могут это сделать через некоторое время.

Но в случае с Ticketon ситуация оказалась гораздо хуже.

После падения сервис подняли и люди продолжили покупать билеты. И только позже стало понятно, что Ticketon даёт возможность купить несколько билетов на одно и то же место 💥

А вот это уже катастрофа. Представьте, что человек за 100 тысяч тенге купил билет и пришёл на концерт. А вокруг его места стоит ещё 5 человек с таким же билетом. На трибунах будет одна большая драка. И это сто процентов приведёт к срыву концерта.

Как только стала понятна проблема дублирования билетов, продажи тут же прекратили. Но множество одинаковых билетов уже было продано. Начались действия по минимизации ущерба. Кому-то смогли найти новые места, кому-то пришлось возвращать деньги вместа с компенсацией. Как итог - тысячи разгневанных клиентов, сотни миллионов тенге убытков для Ticketon и большой репутационный ущерб. Детали рекомендую прочитать в сообщениях руководителей Freedom Holding - компании, владеющей Ticketon. Вот сообщения Тимура Турлова - https://www.threads.net/@timurturlov/post/DIePx8Zt_VX Вот сообщения Алексея Ли - https://www.threads.net/@alexnomad/post/DIWntcuokzV

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

Менеджмент и маркетинг:

1. Реалистичная оценка ажиотажа: Понятно, что JLo – это мегазвезда для Казахстана. Ожидать стандартной нагрузки было нельзя. Менеджменту следовало не просто предположить высокий спрос, а заложить в планы пиковую, возможно, даже чрезмерную нагрузку, исходя из масштаба события и медийного шума. Это включает коммуникацию с технической командой о порядке ожидаемых цифр (не "будет много", а "ожидаем X десятков тысяч одновременных запросов в первую минуту").

2. Стратегия продаж: Запуск всех билетов одномоментно в полночь – классический рецепт для создания пиковой нагрузки. Менеджмент мог рассмотреть альтернативы:

* Предрегистрация/лотерея: Собрать заявки заранее и распределить возможность покупки.

* Поэтапный старт: Начинать продажи по секторам или ценовым категориям с интервалом в несколько часов.

* Очередь: Внедрить систему виртуальной очереди, которая пропускает на сайт ограниченное количество пользователей одновременно. Да, это тоже вызывает недовольство ожидающих, но предотвращает падение и хаос.

3. Коммуникация: Заранее предупредить пользователей о возможном высоком спросе и потенциальных сложностях, объяснить, как будет работать система (если используется очередь или поэтапный старт). Это управляет ожиданиями.

Техническая команда:

1. Нагрузочное тестирование: Это альфа и омега подготовки к таким событиям. Нужно было не просто проверить, что сайт работает, а симулировать реалистичный сценарий: одновременный заход десятков тысяч пользователей, массовые запросы к базе данных (проверка наличия мест, создание заказов). Тестирование должно выявить "узкие места" – будь то серверные мощности, пропускная способность сети, неоптимизированные запросы к БД или проблемы во внешних сервисах (например, эквайринг).

2. Масштабируемая архитектура: Современные облачные технологии позволяют гибко наращивать мощности (auto-scaling) под нагрузку. Команда должна была убедиться, что инфраструктура настроена на автоматическое или быстрое ручное масштабирование всех компонентов системы: веб-серверов, серверов приложений, баз данных.

3. Оптимизация: Проанализировать и оптимизировать самые ресурсоемкие операции, особенно те, что связаны с проверкой и бронированием мест. Использовать кэширование где возможно (например, для статической информации о мероприятии).

4. Самое главное! - предотвращение продажи дубликатов: Вот здесь и произошла катастрофа. Падение сервера – полбеды. Продажа одного места нескольким людям – это фундаментальная ошибка в логике приложения или управлении данными. Как это предотвратить:

* Атомарность операций: Процесс "проверить доступность места -> занять место -> создать заказ" должен быть атомарным. Это означает, что он либо выполняется целиком и успешно, либо полностью откатывается, если на каком-то этапе произошел сбой или место уже занято другим запросом. Это достигается с помощью механизмов транзакций в базах данных.

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

* Уникальные ограничения (unique constraints): На уровне базы данных должно быть жесткое ограничение, не позволяющее добавить две записи с одинаковым местом на одно и то же мероприятие. Это последняя линия обороны, которая не даст записать дубликат, даже если логика приложения даст сбой.

* Тестирование конкурентного доступа: Нужно было специально тестировать сценарии, когда несколько "покупателей" одновременно пытаются купить одно и то же место. Эти тесты должны доказать, что система корректно обрабатывает такие "гонки запросов" (race conditions).

5. План действий при сбоях (incident response plan): Что делать, если система все-таки упала? Как быстро ее поднять? Критически важно: перед тем как снова открывать продажи после сбоя, необходимо провести проверку целостности данных. Убедиться, что не возникло аномалий вроде "подвисших" заказов или некорректного статуса мест. Похоже, именно этот шаг был пропущен, что и привело к продаже дублей после восстановления работы.

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

Ticketon обещали опубликовать постмортем, где они опишут все причины, приведшие к этой ситуации. Посмотрим, насколько они будут пересекаться с тем, что я написал выше.

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