Очереди по 30 минут: как мы научили курорт предупреждать гостей
Или история о том, как 30 сценариев и одна Django-админка перераспределили потоки лыжников.
Представьте: горнолыжный курорт в разгар сезона. Утром популярные канатки забиты — очереди по 30 минут, люди мёрзнут, нервничают. А соседние подъёмники в это же время пустуют. Персонал пытается регулировать потоки вручную, но это невозможно — одновременно следить за всеми зонами и быстро сообщать гостям, куда лучше ехать.
Заказчик хотел автоматизировать оповещения: чтобы гости сами получали сообщения в Telegram/SMS: «На этом подъёмнике сейчас большая очередь, советуем переместиться на соседний». На основе прогнозов загрузки система должна была предупреждать заранее, перераспределяя потоки без расширения инфраструктуры.
Прогностическую модель разрабатывал другой подрядчик. Нам поручили админку, которая будет получать прогнозы и запускать оповещения. Дедлайн — 3 месяца.
Что мы сделали
Команда из двух человек разработала Django-админку с гибкими сценариями оповещений. В ней можно создавать и настраивать сценарии без изменения кода — достаточно пары кликов.
Система интегрирована с внешним API прогнозов, проверяет несколько последовательных значений и отправляет сообщение только при подтверждении триггера. Это защита от спама и ложных срабатываний.
Параллельно мы провели бизнес-анализ двухлетних данных по загрузке канаток и на их основе подготовили 30 сценариев для разных пиковых ситуаций.
Самое сложное началось, когда мы подключились к внешним прогнозам
Данные «скакали»: канатка то на 200 человек, то на 500, то на 1000 в течение нескольких минут. Если бы мы реагировали на каждое изменение — гости получили бы шквал противоречивых сообщений, а персонал — груду ложных срабатываний.
Пришлось придумать защиту: система проверяет несколько прогнозов подряд и отправляет оповещение только когда значения подтверждаются.
Второй момент — не было правил, по которым это должно работать. При каком пороге считать канатку перегруженной? Как часто отправлять? Учитывать ли время суток и сложность трасс?
Всё это собирали по кусочкам: предлагали гипотезы, обсуждали с заказчиком, проверяли на тестовых данных. Провели 4–5 волн настроек — часть параметров добавляли, часть убирали. Это была не доработка «по наитию», а практическая проверка гипотез вместе с заказчиком.
Стали связующим звеном между внешним API и логикой оповещений: знали, как должны работать сценарии, и помогали довести триггеры до ума. Без бюрократии, без долгих согласований.
Что получилось
Система запущена, прошла интеграционные тесты, 30 сценариев приняты заказчиком и подтверждены его аналитикой.
Было: В пиковые часы популярные канатки перегружены, очереди до 30 минут, персонал не успевает регулировать потоки.
Стало: Система автоматически отправляет гостям оповещения, перераспределяя потоки. Ложных срабатываний нет, гости не получают спам, персонал не отвлекается на ложные тревоги.
Отдельный интересный момент
Внешний API иногда работал некорректно. Мы постоянно мониторили, фиксировали проблемы и оперативно передавали заказчику. Они правили свою часть, мы параллельно дорабатывали логику. Так, итерациями, за месяц превратили «сырую» идею в готовую систему с 30 сценариями.
Мы показали, что Django-админка отлично подходит не только для управления контентом, но и для гибких сценариев оповещений с защитой от спама. Опыт работы с нестабильными данными и жёсткими дедлайнами пригодится в любом проекте, где есть внешние прогнозы и задача автоматически реагировать на них.
Полный разбор кейса — с деталями логики, настройкой порогов и результатами — читайте на сайте: https://itfox-web.ru/ru/cases/razrabotali-adminku-s-gibkimi-stsenariiami-dlia-gornolyzhnogo-kurorta-?utm_source=teletype&utm_medium=article&utm_campaign=alert_case