Подходы к созданию надёжных систем на примере ситуации с Ticketon
1 августа в Астане состоится концерт Дженнифер Лопес. Звёзды такой величины редко посещают Казахстан, поэтому это событие ожидаемо вызвало ажиотаж. Почитатели таланта знаменитости стали терпеливо ждать 11 апреля - день, когда в сервисе 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-индустрии Казахстана о том, насколько важен не только внешний функционал сервиса, но и его внутренняя надежность, особенно когда на кону стоят большие деньги и доверие тысяч людей. Надеюсь, нужные выводы будут сделаны и подобных ситуаций в будущем удастся избежать.