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

1. Вводная задача от заказчика, проблематика, цели

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

Цель — автоматизировать процесс оповещения гостей на основе прогнозов загрузки: чтобы система сама отправляла сообщения в Telegram/SMS с рекомендацией переместиться на менее загруженный подъёмник. Это позволило бы перераспределять потоки без расширения инфраструктуры и без участия персонала.

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

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

• Нестабильные прогнозы. Внешний API выдавал скачки: значение загрузки менялось с 200 до 500 до 1000 человек в течение нескольких минут.

• Отсутствие правил срабатывания. Не было определено: при каком пороге считать канатку перегруженной, как часто отправлять, учитывать ли время суток и сложность трасс.

• Жёсткие сроки. Весь проект вместе с аналитикой двухлетних данных — 3 месяца.

• Ограниченные ресурсы. Команда — два человека: разработчик и бизнес-аналитик.

• Внешний API сбоил. Требовался постоянный мониторинг и оперативная связь с заказчиком.

2. Описание реализации кейса и творческого пути по поиску оптимального решения

Команда АЙТИФОКС разработала Django-админку с гибкой логикой срабатывания оповещений. Система позволяет создавать и настраивать сценарии без изменения программного кода — достаточно пары кликов в интерфейсе.

Ключевые технические решения:

• Интеграция с внешним API. Система получает прогнозы загрузки канатных дорог через API внешней прогностической системы.

• Защита от ложных срабатываний. Система проверяет несколько последовательных прогнозов и отправляет оповещение только при подтверждении триггера. Это исключает реакцию на случайные скачки данных. Если бы мы реагировали на каждое изменение, гости получили бы шквал противоречивых сообщений, а персонал — груду ложных срабатываний.

• Гибкие пороги загрузки. На основе тестирования мы определили, что оповещение должно срабатывать при загрузке 80–90% от пропускной способности канатки. Раньше система считала канатку перегруженной слишком рано — предупреждения уходили впустую. Подняли пороги — теперь сообщения приходят только когда это действительно нужно.

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

• Учёт зон и сложности трасс. Курорт разделён на зоны, трассы разной сложности. На «синих» трассах больше всего гостей — там оповещения быстрые и точные. На «чёрных» людей меньше, но цена ошибки выше: если гости массово поедут не туда, перегрузят другую зону. Для каждой зоны настроили свои правила.

• Бизнес-анализ и сценарии. Параллельно с разработкой мы провели анализ двухлетних данных по загрузке канатных дорог и на их основе подготовили 30 сценариев оповещений для разных пиковых ситуаций.

• Итеративный подход. Мы провели 4–5 волн настроек. Часть параметров добавляли, часть убирали. Это была не доработка «по наитию», а практическая проверка гипотез вместе с заказчиком. Тестировали на единственном киоске, который привезли в офис, и итерациями доводили логику до ума.

• Мониторинг внешнего API. Поскольку внешняя система работала с перебоями, мы постоянно мониторили её состояние, фиксировали проблемы и оперативно передавали заказчику для исправления.

3. Результаты сотрудничества

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

Что мы обеспечили:

• Защиту от нерелевантных рассылок. Сообщения уходят только при подтверждении тренда — гости не получают спам, персонал не отвлекается на ложные срабатывания.

• Гибкие настройки под зоны, время суток и сложность трасс. Система учитывает все особенности курорта и отправляет только релевантные сообщения.

• Готовую админку для бизнеса. В интерфейсе можно добавлять новые сценарии без переписывания кода — это экономит время и ресурсы.

• Полную интеграцию с внешней прогностической системой. Данные поступают стабильно, оповещения запускаются автоматически.

Бизнес-эффект:

• Очереди на популярных канатках сокращаются за счёт перераспределения потоков.

• Гости получают полезные уведомления и перестают нервничать.

• Персонал освобождён от ручного регулирования очередей.

• Курорт не тратит средства на расширение инфраструктуры.

Отзыв менеджера проекта (Алексей Алимов):

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