Разработка платформы координации поисково-спасательных работ

Подробности изложены в материале первоисточника. 12 августа в Алайском районе развернулась поисково-спасательная операция: волонтеры и спасатели искали группу альпинистов, не вернувшихся с пика Курумды. Массивы видеоматериалов с дронов копились часами, и традиционный ручной разбор отнимал драгоценное время, требуя фиксировать таймкоды, сверять телеметрию и переносить координаты вручную. Чтобы ускорить этот процесс, я сделал специализированную веб-платформу, которая объединила видео, кадры, точную телеметрию и обсуждение находок в едином интерфейсе.

Запуск MVP состоялся 15 августа, после чего инструмент непрерывно дорабатывался прямо в процессе реальных поисков. Платформа изначально создавалась с расчетом на то, чтобы выдерживать высокие нагрузки, работать в условиях нестабильного канала связи и предоставлять координаторам полную прозрачность процессов.

Автоматическая детекция и её ограничения

Изначально задумывалось, что основную работу выполнит искусственный интеллект: модель YOLO-World должна была автоматически находить людей, палатки и рюкзаки на кадрах без предварительного обучения на собственных датасетах. Из-за огромного разрешения 4K кадры нарезались на тайлы с перекрытием, а параллельный детектор цветовых аномалий пытался вычленить яркое снаряжение на сером склоне.

Однако на практике модель выдала более 183 тысяч рамок при всего 31 полезной пометке от людей. Отношение полезного сигнала к шуму оказалось слишком низким, а группировка детекций в сцены не спасла ситуацию — проверять ошибки алгоритма стоило дороже, чем искать объекты самостоятельно. В результате упор полностью сместился на ручной просмотр и удобство фиксации данных.

Производительность и специфика канала связи

Платформа транслировала данные наружу через бесплатный туннель Cloudflare, так как аренда полноценного сервера требовала регулярных затрат, а прямой проброс портов уперся в ограничения провайдера (CGNAT). Домашний интернет со скоростью отдачи 24 Мбит/с (реально доходило до 18,5 Мбит/с) принимал до десятка одновременных пользователей.

Поскольку исходное видео с дронов шло с битрейтом 30 Мбит/с, пиковые запросы превышали пропускную способность канала почти в пять раз. HTTP-видео деградировало мягко: плеер просто приостанавливал воспроизведение для дозагрузки буфера, обходясь без падений сервера. Тем не менее, для оптимизации работы воркер в фоновом режиме стал создавать облегченные копии файлов с меньшим битрейтом, что снизило нагрузку на сеть в девять раз и позволило хранить оригиналы в облаке Google Диска.

Первый вечер и оперативные правки

Уже в первый вечер эксплуатации выявились архитектурные уязвимости. Общая очередь обработки задерживала быстрые фотографии за многочасовыми видеофайлами, а детектор на CPU забирал все ресурсы процессора, полностью блокируя веб-интерфейс. Потребовалось срочно внедрить приоритезацию процессов, ограничить инференс и добавить тумблер ручного выбора файлов для анализа.

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

Архитектура без остановок

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

Интерфейс разметки был полностью адаптирован под клавиатурные сокращения для работы в полноэкранном режиме с зумом. Инструмент научился автоматически подставлять координаты из телеметрии SRT-файлов по текущему таймкоду, рассчитывать вероятные точки на земле и сохранять контекст обсуждений прямо внутри карточки конкретной находки.

Мониторинг и борьба с системными сбоями

Для контроля работоспособности системы были внедрены эндпоинты проверки здоровья, метрики Prometheus и дашборды Grafana с выводом тревог в Telegram. Ошибки обработки файлов, нехватка свободного дискового пространства и рассинхронизация процессов отслеживались в реальном времени, предотвращая скрытые отказы и падения сервиса.

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