Чому скринер нових лістингів ламається на потоці даних
Скринер нових лістингів ламається не на пошуку за ключовими словами, а на потоці даних.
Майданчик тихо змінює розмітку сторінки анонсів, додає блок із рекомендованими парами або переводить список на підвантаження — і правило розбору, яке ще вчора діставало тікер, сьогодні повертає порожній рядок.
Пропуск події розміщення при цьому не піднімає помилку: збирач чесно забирає сторінки, а нормалізація мовчки відкидає все, що не збіглося зі шаблоном, і в логах це виглядає як спокійний день без новин.
Друге вузьке місце — час. Моніторинг розміщень криптовалют будується на періодичному обході, і затримка оповіщення складається з інтервалу опитування, відставання проміжного сховища та черги на відправлення.
Анонс спершу з'являється в розділі оголошень на Binance, пізніше дублюється в блозі майданчика й у соцмережах; якщо стежити лише за одним джерелом, перші хвилини руху пари минають без команди, а саме там і формується основна частина ціни.
Третє — зведення подій. Один і той самий лістинг приходить із кількох джерел із різними заголовками та часом публікації, і без склейки за парою «актив — майданчик» з'являються дублікати подій, від яких сигнал знецінюється.
Гірший зворотний випадок: система мовчить, а про розміщення команда дізнається з чату — отже, частина джерел не покрита опитуванням, і відмова не видна ні в логах, ні в метриках.
Розбираємо, як це закривається: які місця відмови перевіряємо і що ставимо на кожне, щоб пропуск і дубль ловилися до того, як їх помітить людина.
Що дає раннє виявлення лістингу: вимірювані ефекти
Подія лістингу живе в короткому вікні: від публікації анонса до старту торгів минають хвилини, рідше — години.
Все, що команда встигає зробити всередині цього вікна — оцінити проєкт, розрахувати обсяг, перевірити ризики — впирається в один параметр: як швидко надійшло повідомлення.
Раннє виявлення лістингу стискає час від анонса до рішення з десятків хвилин ручного обходу сайтів і каналів бірж до кількох секунд, а швидкість реакції на подію перестає залежати від того, хто з чергових першим відкриє сторінку.
Під капотом це кілька незалежних шарів збору: підписки на анонсні канали та сторінки бірж, подієві потоки торгових інтерфейсів, періодичне опитування статусів торгів.
Кожне джерело приводить дані до єдиної схеми події — майданчик, тікер, тип інструмента, час анонсу, час старту, — після чого спрацьовує дедуплікація за складеним ключем і контроль свіжості.
Великі майданчики на кшталт Binance публікують той самий анонс кількома каналами з розбіжністю в секунди, і без нормалізації команда отримує три повідомлення про одну подію.
Зниження хибних спрацювань дає другий щабель — скоринг. Спершу жорсткі правила відсікання: тестові анонси, делістинги, повторні публікації, інструменти без ліквідності та без пари до торгової бази.
Потім ваговий скоринг за ознаками: тип анонса, наявність контракту, історія майданчика, поведінка ціни поза торгами. У повідомлення йде 20–30% вихідного потоку, і частка порожніх сигналів падає настільки, що черговий перестає вимикати канал.
Окремо йде клас відмов, який раніше коштував найдорожче: повний пропуск події при падінні одного джерела. Резервне джерело, черга з гарантією доставки та метрика затримки на кожному шарі перетворюють «не помітили» на вимірюване «обробили за секунди».
Варіанти моніторингу розміщень: порівняння підходів
Майданчики розкривають нові розміщення по-різному: в одних є відкрита стрічка анонсів, у других — лише сторінка торгів, у третіх оголошення йде в розсилку або в чат спільноти.
Тому порівняння підходів починається не з «який спосіб кращий», а з питання, де з'являється першоджерело і яку затримку вважаємо прийнятною.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Опитування за розкладом | Майданчики без відкритої стрічки подій | Затримка дорівнює інтервалу опитування, зайві запити, пропуск знятих анонсів |
| Потокова підписка | Майданчик сам віддає події, важливі перші хвилини | Залежність від стабільності каналу, потрібен дозбір пропущеного |
| Зовнішній агрегатор ринкових даних | Потрібне широке охоплення майданчиків і звірка | Затримка посередника, неповні поля, розбіжність із першоджерелом |
| Ручний обхід каналів | Закриті анонси та нестандартні майданчики | Не масштабується, залежить від людини, немає гарантії повноти |
Як це поєднується на практиці
Потік подій проти опитування — не альтернатива, а розподіл ролей: потік дає швидкість, опитування закриває майданчики без підписки й страхує від пропусків.
Зовнішній агрегатор ринкових даних тримаємо незалежним контуром звірки — розбіжність із першоджерелом часто і є найраннішим сигналом. Вхідні події дедуплікуємо за ідентифікатором розміщення та часом першого анонсу, інакше один лістинг приходить в алерти тричі.
Як ми будуємо конвеєр моніторингу: етапи робіт
Скринер збирається поетапно, і перший крок — не код, а інвентаризація: де майданчик публікує анонси, з якою затримкою вони з'являються, у якому вигляді приходять і що відбувається при пропуску.
До впровадження скринера ми фіксуємо перелік джерел, частоту подій і допустимий час реакції — тоді конвеєр обробки подій проєктується під реальний потік, а не під середній по ринку.
- Розбір задачі та інвентаризація джерел. Визначаємо майданчики в периметрі, канали анонсів, типові затримки та збої кожного джерела.
- Нормалізація даних майданчиків. Єдиний довідник тікерів і назв, приведення типів пар, дат і статусів до однієї схеми — події стають порівнюваними між собою.
- Дедуплікація та склейка. Один лістинг приходить із кількох каналів: зіставляємо дублі та пов'язуємо анонс із уже відомим інструментом.
- Налаштування порогів скорингу. Ваги ознак і межі спрацювання виносимо в конфігурацію — їх можна правити без перезбирання та перезапуску сервісу.
- Перевірка на історії. Проганяємо правила по накопичених подіях, рахуємо частку вірних і хибних сигналів, підкручуємо пороги до виведення в бій.
- Доставка оповіщень. Пріоритети, групування та захист від потоку однотипних сигналів, щоб черговий бачив повідомлення у своєму каналі.
- Передача регламентів супроводу. Інструкції з підключення джерела, правки порогу та розбору інцидентів плюс метрики здоров'я конвеєра.
Що замовник отримує на руки: артефакти та документація
Поставка влаштована так, щоб систему можна було експлуатувати й розвивати без нас. Передаємо не лише працюючий сервіс, а й налаштування, докази їхньої коректності та документи, за якими черговий інженер або аналітик вносить зміни, не розбираючи код повністю.
- Конфігурації середовищ. Маніфести розгортання, змінні середовища, секрети в захищеному сховищі — стенд піднімається з репозиторію однією командою, без ручних правок на сервері.
- Схема джерел. Перелік бірж і агрегаторів, порядок опитування, розподіл лімітів між процесами, поведінка при недоступності джерела: пауза, повтор, перемикання на резерв.
- Правила скорингу. Ваги ознак, пороги, формула агрегації, версіонування правил і журнал правок — відкат до попередньої редакції без перезбирання сервісу.
- Матриця маршрутизації оповіщень. Клас сигналу, адресат, канал, пріоритет, вікно тиші та ескалація, якщо сигнал не підтвердили. Таблиця правиться вами, а не схована в коді.
- Регламенти експлуатації. Покрокові інструкції на типові відмови, порядок чергування, обмежувачі частоти та запобіжники проти лавини хибних спрацювань.
- Документація. Архітектурна схема, модель даних, опис зовнішніх інтеграцій та інструкція для аналітика: як додати джерело або змінити поріг.
- Приймальні сценарії. Набір еталонних лістингів з очікуваними оцінками — при наступній зміні правил одразу видно, що саме зламалося.
Кейс: реакція на розміщення скоротилася з годин до хвилин
Що було до впровадження
Чергова зміна обходила вручну біржові стрічки, сторінки оголошень і канали проєктів — коло перевірок займало 20–30 хвилин, тому про розміщення дізнавалися через 40–90 хвилин після публікації.
Частина подій приходила в неробочі вікна й губилася, частина дублювалася з різних джерел, а щодо нового інструмента бракувало ознак для швидкого рішення. Частка пропущених розміщень трималася близько 15%, і приблизно стільки ж часу йшло на розбір шуму.
Що змінили
Подієвий потік зібрали з біржових стрічок і публічних агрегаторів — котирування та метадані підтягували через CoinGecko — і привели до єдиної схеми: інструмент, майданчик, час публікації, посилання на першоджерело.
Дедуплікація за парою «інструмент + майданчик» прибрала повторні алерти, а черга з пріоритетами не давала події загубитися в пік навантаження. Скоринг рахував ознаки окремо, тому поріг по кожному каналу налаштовувався без переписування логіки.
Що стало
- Медіана виявлення події: з 47 хвилин до 1,5 хвилини, включно з нічними вікнами.
- Частка пропущених розміщень: близько 15% → менше ніж 2%, кожен пропуск видно в журналі.
- Ручна робота чергової зміни: мінус приблизно 70% — оператор підтверджує подію, а не шукає її.
- Хибні спрацювання після калібрування порогів: знизилися вчетверо.
Чим потоковий моніторинг відрізняється від опитування за розкладом?
Потік і опитування розв'язують одну задачу — дізнатися про лістинг раніше за ринок, — але платять за це по-різному. Потокова підписка віддає подію в момент публікації: постійне з'єднання тримає затримку в секундах і зберігає порядок оголошень.
Опитування за розкладом дає рівномірне й передбачуване навантаження, зате час між проходами — сліпа зона, і сплеск лістингів усередині неї губиться.
Розвилка проходить за частотою подій і ціною запізнення. Там, де майданчик публікує лістинги пакетами, потік виграє: опитування раз на хвилину побачить факт, але пропустить порядок і перший сплеск, коли ціна вже рушила.
На рідкісних біржах із парою оголошень на добу постійне з'єднання надлишкове — його розриви доводиться відновлювати й окремо дозбирати пропущене.
Тому на практиці будують гібридну схему збору подій: потік — основний канал доставки, опитування — страхувальний. Він періодично звіряє довідник лістингів повністю, закриває вікна після обриву зв'язку та ловить події, яких не було в підписці.
Зведення йде за ідентифікатором інструмента та міткою публікації, тому повторний прихід тієї самої події не народжує друге повідомлення.
Режим обирають за одним критерієм: скільки часу сигнал залишається цінним. Якщо він живе хвилини, опитування як єдине джерело не годиться — потрібен потік із швидким відновленням підписки. Якщо подія актуальна годинами, достатньо опитування, і ускладнювати схему немає сенсу.
Гібрид дає ще одну властивість — деградацію без сліпоти: при відмові потоку збір продовжується опитуванням, а такі події позначаються як менш оперативні.
Технічні сумніви щодо скорингу та оповіщень
Найчастіше до старту запитують про пороги, ліміти та поведінку системи при збоях. Нижче — п'ять сценаріїв і те, як вони розв'язуються на рівні конфігурації; перевірити кожен можна на пілотному наборі джерел.
Як налаштувати чутливість і не потонути в хибних спрацюваннях?
Поріг збирається з ваг ознак: вік пулу, обсяг, розподіл власників. Перші тижні система йде в режимі спостереження — поріг калібрується за накопиченою вибіркою, а не за інтуїцією.
Що робити з лімітами джерел?
Опитування йде через пул джерел і чергу з пріоритетами, розклад розподіляє навантаження. При впиранні в ліміт перевірка йде на резервне джерело, а критичні дані звіряються за двома незалежними точками.
Як система переживає збій джерела чи каналу?
Події буферизуються й не губляться: недоставлене йде повторно, дедуплікація за хешем відсікає дублі. Журнал показує, що саме не доставлено і в який момент.
Як розділені права доступу?
Ролі розведені: аналітик править ваги правил, спостерігач бачить лише видачу, адміністратор керує джерелами та ключами. Зміна порогу проходить підтвердження і потрапляє в журнал.
Чи можна додати свої канали оповіщень?
Транспорт відділений від логіки скорингу: новий канал підключається адаптером, ядро не змінюється. Фільтри за типами подій дозволяють частині команди отримувати лише критичне.
Обговоримо задачу: що потрібно для старту робіт
Для старту проєкту не потрібен документ на десятки сторінок — достатньо ввідних, за якими ми зрозуміємо обсяг і повернемося з оцінкою та планом робіт по скринеру. Нижче те, що варто підготувати до розмови; частину пунктів уточнимо на дзвінку.
- Перелік бірж і мереж і визначення події: що вважаємо новим лістингом — анонс, відкриття торгів, появу пари.
- Джерела: офіційні канали оголошень, програмні інтерфейси бірж, дані з блокчейну — і чи є до них доступи.
- Правила скорингу: які ознаки важливі (ліквідність, обсяг, вік проєкту, розподіл власників) і з якого балу сигнал вважається значущим.
- Канали оповіщень та їхній пріоритет: месенджер, вебхук у вашу систему, пошта — кому і в якому вигляді йде повідомлення.
- Вимоги до затримки: скільки секунд від публікації до оповіщення допустимо і що робити при пропуску джерела.
- Історія та аналітика: за який період зберігати події і чи потрібна вибірка за минулими лістингами.
- Середовище та доступи: де розгортаємо, чи потрібен тестовий контур, хто відповідає за ключі до зовнішніх сервісів.
З цим набором ми повертаємося з оцінкою та планом робіт: черговість етапів, що входить у перший працюючий контур, які перевірки якості і як ви будете приймати результат. Опишіть задачу — почнемо з розбору ввідних.
