Разработка Django-админки для автоматических оповещений гостей горнолыжного курорта на основе прогнозов загрузки

Главное о кейсе

Заказчик — крупный горнолыжный курорт. В пиковые часы популярные канатки перегружены — очереди до 30 минут, соседние подъёмники пустуют. Персонал не успевает управлять потоками вручную.

Задача — автоматизировать оповещения гостей (Telegram/SMS) на основе прогнозов загрузки: «На этом подъёмнике большая очередь, переместитесь на соседний». Прогностическую модель разрабатывал другой подрядчик. Нам поручили админку, которая получает прогнозы по API и запускает оповещения по сценариям.

Ключевые ограничения:

прогнозы от внешнего API нестабильны — скачки от 200 до 1000 человек за минуту;
отсутствие правил срабатывания (пороги, время суток, зоны);
дедлайн — 3 месяца;
команда — 2 человека.

Разработана Django-админка с гибкой логикой срабатывания. Сценарии настраиваются без изменения кода. Внедрена защита от ложных срабатываний — проверка нескольких последовательных прогнозов перед отправкой. Настроены пороги загрузки (80–90%), учёт времени суток, зон и сложности трасс. Проведён анализ двухлетних данных, подготовлено 30 сценариев. Выполнено 4–5 итераций настройки логики с заказчиком.

Система прошла интеграционные тесты, 30 сценариев приняты заказчиком и подтверждены аналитикой. Ложные срабатывания исключены, гости не получают спам. Админка позволяет добавлять новые сценарии без разработчиков.

Как проект изменил жизнь пользователей

Гости перестали стоять в очередях по 30 минут. Получают уведомление, когда канатка перегружена, и направляются на свободный подъёмник. Сообщения приходят только при подтверждении прогноза — без спама и противоречивых рекомендаций. Гости планируют маршрут, избегая загруженных зон. Персонал освобождён от ручного регулирования очередей и сосредоточен на помощи гостям и безопасности. Количество жалоб на очереди снизилось.

Бизнес-задача и ее решение

Бизнес-задача: сократить очереди на канатных дорогах без расширения инфраструктуры, перераспределив потоки гостей. Снизить нагрузку на персонал. Исключить ложные срабатывания и спам. Учесть время суток, зоны и сложность трасс.

Решение: Django-админка, интегрированная с API прогнозов. Система проверяет несколько прогнозов подряд и отправляет оповещения только при подтверждении триггера. Настроены пороги загрузки (80–90%), время отправки в зависимости от времени суток, правила для разных зон и трасс. Проведён анализ двухлетних данных, подготовлено 30 сценариев. Выполнено 4–5 итераций настройки с заказчиком. Сценарии настраиваются в админке без программистов.

Эффект: курорт не тратит средства на строительство новых канаток, очереди сокращаются за счёт перераспределения потоков. Персонал перераспределён на полезные задачи.

Крафт (мастерство), реализация, технические детали

Стек: Django, PostgreSQL, REST API, Telegram Bot API, SMS-шлюз.

Ключевые решения:
Защита от ложных срабатываний. Система накапливает несколько прогнозов и отправляет сообщение только при подтверждении тренда. Это исключает реакцию на случайные скачки данных.
Гибкая архитектура сценариев. Сценарии хранятся в БД и настраиваются через админ-интерфейс без изменения кода. Бизнес самостоятельно управляет порогами, временем отправки, текстами, привязкой к зонам и времени суток.
Анализ двухлетних данных и 30 сценариев. Сценарии учитывают зоны, время суток и сложность трасс. Для каждой зоны — свои правила.
Итеративная настройка. 4–5 волн настроек с заказчиком на основе тестирования на реальных данных.
Мониторинг внешнего API. Постоянный контроль стабильности, проблемы фиксировались и передавались заказчику.
Django-админка как управляющий центр. Быстрая разработка, гибкое управление настройками, расширяемость.

Инсайты, гипотезы, процесс создания и взаимодействия с заказчиком

Главный инсайт: сложность не в интеграции, а в логике. Когда данные нестабильны и правил нет — критически важна защита от спама и гибкая настройка. «Очевидные» решения на тестовых данных разваливались в реальности.

Проверенные гипотезы:
пороги загрузки: подняли до 80–90% — ложные срабатывания ушли;
время отправки: сделали настраиваемым — днём быстрее, вечером деликатнее;
зоны и трассы: для каждой зоны свои правила.

Процесс: 3 месяца, команда из 2 человек. Цикл: анализ данных → реализация в админке → тестирование → обнаружение проблемы → связь с заказчиком → исправление → повторная проверка. За месяц превратили «сырую» идею в систему с 30 сценариями. Тестировали на единственном киоске в офисе. Без бюрократии — сразу звонили заказчику.

Коммуникация: заказчик не имел чёткого регламента. Всё собирали по кусочкам: гипотезы, обсуждения, проверка на данных. Стали связующим звеном между API и логикой оповещений. Постоянный мониторинг внешнего API, оперативная передача проблем.

Прочая информация о кейсе

Отзыв менеджера проекта (Алексей Алимов): «С технической точки зрения сложность была не в стеке, а в логике срабатывания. Пришлось много раз перепроверять гипотезы, подстраивать пороги, учитывать время суток и зоны. В итоге сценарии получились рабочие, заказчик их принял».

Скриншоты