Разработка скринера листингов криптовалют: мониторинг, скоринг, алерты

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

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

Второе узкое место — время. Мониторинг размещений криптовалют строится на периодическом обходе, и задержка оповещения складывается из интервала опроса, отставания промежуточного хранилища и очереди на отправку. Анонс сначала появляется в разделе объявлений на Binance, позже дублируется в блоге площадки и в соцетях; если следить только за одним источником, первые минуты движения пары проходят без команды, а именно там и формируется основная часть цены.

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

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

Что даёт раннее обнаружение листинга: измеримые эффекты

Событие листинга живёт в коротком окне: от публикации анонса до старта торгов проходят минуты, реже — часы. Всё, что команда успевает сделать внутри этого окна — оценить проект, рассчитать объём, проверить риски — упирается в один параметр: как быстро пришло уведомление. Раннее обнаружение листинга сжимает время от анонса до решения с десятков минут ручного обхода сайтов и каналов бирж до нескольких секунд, а скорость реакции на событие перестаёт зависеть от того, кто из дежурных первым откроет страницу.

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

Снижение ложных срабатываний даёт вторая ступень — скоринг. Сначала жёсткие правила отсечения: тестовые анонсы, делистинги, повторные публикации, инструменты без ликвидности и без пары к торгуемой базе. Затем весовой скоринг по признакам: тип анонса, наличие контракта, история площадки, поведение цены вне торгов. В уведомления уходит 20–30% исходного потока, и доля пустых сигналов падает настолько, что дежурный перестаёт выключать канал.

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

Варианты мониторинга размещений: сравнение подходов

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

Как это сочетается на практике

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

Как мы строим конвейер мониторинга: этапы работ

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

1. Разбор задачи и инвентаризация источников. Определяем площадки в периметре, каналы анонсов, типичные задержки и сбои каждого источника.
2. Нормализация данных площадок. Единый справочник тикеров и названий, приведение типов пар, дат и статусов к одной схеме — события становятся сравнимыми между собой.
3. Дедупликация и склейка. Один листинг приходит из нескольких каналов: сопоставляем дубли и связываем анонс с уже известным инструментом.
4. Настройка порогов скоринга. Веса признаков и границы срабатывания выносим в конфигурацию — их можно править без пересборки и перезапуска сервиса.
5. Проверка на истории. Прогоняем правила по накопленным событиям, считаем долю верных и ложных сигналов, подкручиваем пороги до вывода в бой.
6. Доставка оповещений. Приоритеты, группировка и защита от потока однотипных сигналов, чтобы дежурный видел сообщение в своём канале.
7. Передача регламентов сопровождения. Инструкции по подключению источника, правке порога и разбору инцидентов плюс метрики здоровья конвейера.

Что заказчик получает на руки: артефакты и документация

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

• Конфигурации окружений. Манифесты развёртывания, переменные среды, секреты в защищённом хранилище — стенд поднимается из репозитория одной командой, без ручных правок на сервере.
• Схема источников. Перечень бирж и агрегаторов, порядок опроса, распределение лимитов между процессами, поведение при недоступности источника: пауза, повтор, переключение на резерв.
• Правила скоринга. Веса признаков, пороги, формула агрегации, версионирование правил и журнал правок — откат к предыдущей редакции без пересборки сервиса.
• Матрица маршрутизации оповещений. Класс сигнала, адресат, канал, приоритет, окно тишины и эскалация, если сигнал не подтвердили. Таблица правится вами, а не спрятана в коде.
• Регламенты эксплуатации. Пошаговые инструкции на типовые отказы, порядок дежурства, ограничители частоты и предохранители против лавины ложных срабатываний.
• Документация. Архитектурная схема, модель данных, описание внешних интеграций и инструкция для аналитика: как добавить источник или изменить порог.
• Приёмочные сценарии. Набор эталонных листингов с ожидаемыми оценками — при следующем изменении правил сразу видно, что именно сломалось.

Кейс: реакция на размещения сократилась с часов до минут

Что было до внедрения

Дежурная смена обходила вручную биржевые ленты, страницы объявлений и каналы проектов — круг проверок занимал 20–30 минут, поэтому о размещении узнавали через 40–90 минут после публикации. Часть событий приходила в нерабочие окна и терялась, часть дублировалась из разных источников, а по новому инструменту не хватало признаков для быстрого решения. Доля пропущенных размещений держалась около 15%, и примерно столько же времени уходило на разбор шума.

Что изменили

Событийный поток собрали из биржевых лент и публичных агрегаторов — котировки и метаданные подтягивали через CoinGecko — и привели к единой схеме: инструмент, площадка, время публикации, ссылка на первоисточник. Дедупликация по паре «инструмент + площадка» убрала повторные алерты, а очередь с приоритетами не давала событию потеряться в пик нагрузки. Скоринг считал признаки отдельно, поэтому порог по каждому каналу настраивался без переписывания логики.

Что стало

• Медиана обнаружения события: с 47 минут до 1,5 минуты, включая ночные окна.
• Доля пропущенных размещений: около 15% → меньше 2%, каждый пропуск виден в журнале.
• Ручная работа дежурной смены: минус примерно 70% — оператор подтверждает событие, а не ищет его.
• Ложные срабатывания после калибровки порогов: снизились вчетверо.

Чем потоковый мониторинг отличается от опроса по расписанию?

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

Развилка проходит по частоте событий и цене опоздания. Там, где площадка публикует листинги пакетами, поток выигрывает: опрос раз в минуту увидит факт, но пропустит порядок и первый всплеск, когда цена уже двинулась. На редких биржах с парой объявлений в сутки постоянное соединение избыточно — его разрывы приходится восстанавливать и отдельно добирать пропущенное.

Поэтому на практике строят гибридную схему сбора событий: поток — основной канал доставки, опрос — страховочный. Он периодически сверяет справочник листингов целиком, закрывает окна после обрыва связи и ловит события, которых не было в подписке. Сведение идёт по идентификатору инструмента и метке публикации, поэтому повторный приход того же события не рождает второе уведомление.

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

Технические сомнения по скорингу и оповещениям

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

Что делать с лимитами источников?

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

Как система переживает сбой источника или канала?

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

Как разделены права доступа?

Роли разведены: аналитик правит веса правил, наблюдатель видит только выдачу, администратор управляет источниками и ключами. Изменение порога проходит подтверждение и попадает в журнал.

Можно ли добавить свои каналы оповещений?

Транспорт отделён от логики скоринга: новый канал подключается адаптером, ядро не меняется. Фильтры по типам событий позволяют части команды получать только критичное.

Обсудим задачу: что нужно для старта работ

Для старта проекта не нужен документ на десятки страниц — достаточно вводных, по которым мы поймём объём и вернёмся с оценкой и планом работ по скринеру. Ниже то, что стоит подготовить к разговору; часть пунктов уточним на созвоне.

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

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