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

Заказчик

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

Задача

Разработать Django-админку для управления сценариями оповещений гостей через Telegram/SMS на основе прогнозов загрузки, исключив ложные срабатывания.

Как мы за 3 месяца разработали систему оповещений для горнолыжного курорта, которая перераспределяет потоки гостей без ложных срабатываний

Вводная часть

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

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

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

Сложности и ограничения

Когда мы начали разбираться, выяснилось, что самое трудное — не написать админку, а понять, как она должна себя вести.

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

2. Отсутствие правил. Не было определено: при каком пороге считать канатку перегруженной? Как часто отправлять? Учитывать ли время суток и сложность трасс? Всё это мы собирали по кусочкам: предлагали гипотезы, обсуждали с заказчиком, проверяли на тестовых данных.

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

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

Что мы сделали

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

1. Защита от ложных срабатываний

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

Как это работает:

? Система получает прогноз от внешнего API.

? Сравнивает с предыдущими значениями.

? Если тренд подтверждается несколько раз подряд — отправляет сообщение.

? Если значение единичное и нестабильное — игнорирует.

Это простое решение решило проблему спама и ложных тревог.

2. Гибкие пороги загрузки

Сначала система считала канатку перегруженной слишком рано, хотя на самом деле люди ещё могли поместиться. Из-за этого предупреждения уходили впустую, а персонал отвлекался на ложные срабатывания. Мы подняли пороги — теперь оповещение срабатывает, только когда загрузка достигает 80–90% от пропускной способности.

3. Настройка времени отправки

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

4. Учёт зон и сложности трасс

Курорт разделён на зоны, трассы разной сложности:

? На «синих» трассах больше всего гостей — там оповещения быстрые и точные.

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

Для каждой зоны настроили свои правила срабатывания.

5. Бизнес-анализ и 30 сценариев

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

6. Итеративный подход

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

Технические детали

Стек технологий:

? Django — для админки и управления сценариями

? PostgreSQL — для хранения настроек и логов срабатываний

? REST API — для интеграции с внешней прогностической системой

? Telegram Bot API и SMS-шлюз — для отправки оповещений

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

Как мы работали

Проект длился около трёх месяцев. Команда — два человека: разработчик и менеджер проекта.

Типичный цикл выглядел так:

1. Анализировали данные по загрузке канаток и проектировали сценарии.

2. Реализовывали настройки в админке и подключали к API.

3. Тестировали срабатывание триггеров на тестовых данных.

4. Обнаруживали проблему — связывались с командой заказчика.

5. Они правили свою часть или уточняли требования, а мы дорабатывали логику.

6. Через несколько дней — снова проверка новой версии.

Так, итерациями, мы за месяц превратили «сырую» идею в готовую систему с 30 сценариями. Тестировали на единственном киоске, который привезли в офис. Менеджер «играл роль гостя» — пробовал разные сценарии, искал проблемы. Без бюрократии и долгих согласований — сразу звонили заказчику и правили.

Результат

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

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

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

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

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

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

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

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

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

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

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

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

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

Перейти на сайт