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

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

Заказчик хотел не просто ускорить проход, а научиться заранее предупреждать гостей о загрузке. Идея: на основе прогнозов автоматически отправлять сообщения — «На этом подъёмнике сейчас большая очередь, советуем переместиться на соседний». Это позволило бы распределять поток без расширения инфраструктуры и без участия персонала.

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

Главные сложности задачи:

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

- Отсутствие правил срабатывания. Не было определено: при каком пороге считать канатку перегруженной? Как часто отправлять? Учитывать ли время суток и сложность трасс? Чёткого регламента не существовало.

- Жёсткие сроки. Весь проект вместе с аналитикой двухлетних данных уместился в три месяца. Не было права на долгие согласования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Почему этот опыт важен для других проектов

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

Django-админка отлично справляется с ролью управляющего центра для таких задач. А главное — она позволяет бизнесу самостоятельно адаптировать логику без привлечения разработчиков, что экономит время и ресурсы.

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