Система сповіщень AI-трейдинг-бота: де губляться сигнали
Сигнал відпрацював у стратегії, угода відкрилася — а повідомлення в Telegram немає. Ланцюжок доставки короткий: бот формує подію, кладе її в чергу, воркер надсилає в канал і чекає підтвердження.
Рветься він на останньому кроці: у клієнта Telegram стоїть таймаут на з’єднання, відправлення падає, повтор не передбачено — подія просто зникає з черги.
Затримка сповіщень на піках навантаження перетворюється на пропуск сигналу: поки воркер висить на одному завислому каналі, наступні події накопичуються й застарівають.
Окрема категорія збоїв — ліміти каналу доставки. Telegram зрізає частоту повідомлень при сплеску, поштовий шлюз приймає пачку листів і мовчки відбиває її, Discord обмежує кількість викликів з однієї адреси.
Якщо ретраї зроблено «в лоб», без ключа ідемпотентності, спроба дослати повідомлення перетворюється на дублі сповіщень: трейдер отримує один і той самий сигнал тричі й перестає довіряти каналу.
Найнеприємніший сценарій — перезапуск бота. Черга живе в пам’яті процесу, і все не відправлене при падінні стирається без сліду.
Збій відправлення при цьому часто навіть не пишеться в лог: про втрату дізнаєшся вранці, за розбіжністю між історією угод і тим, що прийшло в месенджер.
Саме на цих трьох точках — таймаут, ліміт, перезапуск — рветься доставка, і лагодяться вони разом. Нижче розбираємо, як це закривається.
Що дає відмовостійка доставка сигналів
Один канал і відсутність підтверджень прийому дають частку доставлених сигналів близько 97%: частина повідомлень гаситься лімітами бота, частина — мережевими таймаутами, частина — блокуванням на боці отримувача. Для торгової логіки втрата трьох відсотків — це пропущений вхід, про який ніхто не дізнався.
Підтвердження прийому по кожному каналу переводить доставку у вимірювану величину: в журналі видно не «відправили», а «прийнято отримувачем».
Повторне відправлення вмикається за таймаутом або негативною відповіддю, а ключ за ідентифікатором сигналу відсікає повтори — одна й та сама позиція не відкривається двічі.
Час доставки вважаємо не середнім, а за процентилями: медіана вкладається в частки секунди, а довгий хвіст одразу показує, де канал деградує.
Резервний канал підхоплює сигнал, якщо основний не підтвердив прийом за відведене вікно, — падіння одного сервісу більше не зупиняє розсилку.
Роль підстрахування не обов’язково віддавати другому месенджеру: пошта закриває її не гірше, поки основний канал відновлюється, а порядок обходу каналів налаштовується під конкретну логіку бота.
Так закривається цілий клас відмов: сигнал є в журналі, але не дійшов; дійшов двічі; дійшов через годину після входу. У звіті залишаються три контрольні величини — частка доставлених сигналів по кожному каналу, розподіл часу доставки та кількість спрацьованих перевідправок.
Канали доставки: месенджер, пошта, корпоративний чат
Канали вирішують різні завдання й не замінюють один одного: месенджер (у базовій зв’язці — Telegram) дає швидкість реакції на сигнал, електронна пошта — журнал угод і звітність, корпоративний чат — робочий простір чергової зміни. Вибір визначається не зручністю, а тим, хто і за який час зобов’язаний відреагувати на подію.
Обмеження в кожного свої, і саме вони задають схему доставки: ліміти на частоту повідомлень, права бота в закритому контурі, затримки доставки. Нижче — порівняння за придатністю для торгової системи.
| Канал | Коли підходить | Обмеження |
|---|---|---|
| Месенджер (бот) | Сигнали з реакцією за хвилини: вхід у позицію, захисний ордер | Ліміт на частоту відправлення, розрив сесії обриває доставку, факт отримання не підтверджується |
| Електронна пошта | Зведення, журнал угод, розбір інцидентів | Затримка доставки, ризик потрапляння в спам-фільтр, немає миттєвої реакції |
| Корпоративний чат | Чергова зміна бачить сигнал у спільному каналі, історія зберігається | Потрібні права в робочому просторі та своя точка прийому подій |
| Резервний канал | Критичні події при недоступності основних | Своя авторизація, контроль квот, вищі накладні на супровід |
Робоча схема зазвичай гібридна: критична подія йде в месенджер, дублюється в пошту для аудиту, а без підтвердження за заданий інтервал ескалується на резервний канал.
Відсікання повторів за ідентифікатором події не дає дублям розмножуватися при повторних відправленнях, журнал доставки показує, яким каналом сповіщення дійшло. Відмова одного каналу не перетворюється на пропущений сигнал.
Етапи впровадження: від аудиту каналів до передачі
Сповіщення в трейдинг-контурі — не повідомлення в чат, а сигнал, від якого залежить угода. Прийшло із затримкою або не прийшло — стратегія відпрацювала наосліп, а розбір інциденту починається з нуля. Тому роботи йдуть фіксованою послідовністю, де кожен етап закривається перевірюваним результатом.
- Аудит доставки. Розбираємо підключені канали та втрати: ліміти Telegram на частоту, спам-фільтри Email, обмеження Discord. Ділимо події на критичні й ті, що можна збирати в дайджест.
- Схема маршрутизації. Розкладаємо події за пріоритетами — вхід у позицію, стоп, помилка зв’язку з біржею, плановий звіт. Для кожного задаємо основний канал, резервний і правило повторного відправлення.
- Налаштування каналів. Розводимо ботів, відправників і права, готуємо шаблони повідомлень, розділяємо потоки за стратегіями та рахунками, щоб шум однієї не топив сигнали іншої.
- Складання відправлення. Черга з підтвердженням доставки та повторами: обрив зв’язку не з’їдає сповіщення, а дубль не приходить двічі. У кожного повідомлення — ідентифікатор і слід у журналі.
- Перевірка на збоях. Гасимо канал, заводимо відповідь у таймаут, зупиняємо процес відправлення й дивимося, що йде в резерв. Окремо — шквал подій: десять спрацьовувань не повинні перетворюватися на сотню повідомлень.
- Передача в експлуатацію. Віддаємо карту маршрутів, шаблони та інструкцію черговому. Оповіщення ставимо на сам стан доставки: система зобов’язана повідомляти, коли перестала повідомляти.
Далі схема живе своїм життям: новий канал або стратегія додаються в маршрут за один крок, без перезбирання всього контуру.
Конфігурації, схеми маршрутизації та регламенти
Після впровадження в команди замовника залишається не «чорна скринька», а набір артефактів, які можна прочитати, змінити й передати іншому інженеру.
Без будь-якого пункту нижче система працює, але втрачає керованість при першій зміні — новому каналі, зміні чергового або розборі збою.
- Конфігурація доставки — пріоритет каналів, пороги спрацьовування, пауза до повторного відправлення, обмеження частоти на канал і на отримувача. Окремі профілі для тестового й робочого контурів.
- Схема маршрутизації — таблиця «подія → канал → група отримувачів» для сигналів, угод, просадки й обриву потоку даних, плюс правила придушення дублів і період тиші.
- Шаблони повідомлень — розмітка для Telegram і Discord, текстова та HTML-версія листа, поля підстановки, правила скорочення довгих значень.
- Політики доступу — хто править маршрути, хто лише читає журнал доставки, хто підтверджує відправлення в критичні канали; ролі прив’язані до облікових записів.
- Регламент чергування — вікна покриття, порядок ескалації, події з обов’язковою реакцією та точка передачі зміни.
- Журнал доставки — записи по кожному відправленому, відкладеному й відкинутому повідомленню з причиною; за ним видно, на якому кроці загубилося сповіщення.
- Інструкція з відновлення — як заглушити шумний канал, перевести потік на резервний маршрут і що перевіряти першим, якщо бот замовк.
Комплект живе разом із системою: правки маршрутів і шаблонів проходять той самий порядок перевірки, що й код. Опишіть задачу — повернемося з оцінкою та планом, включно зі складом документації.
Кейс: доставка сигналів без пропусків і затримок
До впровадження сигнали йшли з торгового модуля напряму в кожен канал: відправлення йшло синхронно в циклі обробки, при сплеску волатильності черга зростала, і частина повідомлень відкидалася за таймаутом.
Дедуплікації не було — при перезапуску процесу частина сигналів ішла повторно, частина губилася. Розбір кожної розбіжності між сигналом і фактичним оповіщенням займав у команди кілька годин на тиждень.
Доставку винесли в окремий сервіс із чергою та ідемпотентними ключами: у кожної події є ідентифікатор, повтор при збої не створює дубль, а невдалі спроби йдуть у повтор із наростаючою паузою.
Канали Telegram, Email і Discord підключені як незалежні маршрути зі своїми правилами та пріоритетами.
На кожне повідомлення пишеться запис у журнал доставки зі статусами від постановки в чергу до підтвердження, а в Grafana зібрано панель за часткою доставлених і розподілом затримки за квантилями.
Якщо канал недоступний, правило перемикання заводить сигнал у резервний маршрут, а подія залишається в черзі до відновлення зв’язку. Втрата можлива лише при одночасній відмові всіх каналів, і такий випадок піднімає окреме оповіщення для чергового.
Метрики після: медіана доставки — 1,5–2,5 секунди проти 40–90 секунд до переробки, частка втрачених оповіщень упала з 6–8% до 0,1%, ручні розбори скоротилися з 15–20 на тиждень до 1–2 на місяць.
Кожна розбіжність тепер піднімається з журналу доставки за хвилини: видно, на якому кроці, в якому каналі та з якої причини повідомлення не дійшло.
Що робити, якщо бот уже надсилає сигнали напряму
Пряме відправлення всередині торгового циклу — найчастіше джерело втрат. Синхронний виклик стоїть у тому самому потоці, де рахується сигнал: канал відповів обмеженням за частотою або таймаутом — повідомлення пішло в нікуди, повторів немає, а наступний сигнал уже готовий. Через тиждень ніхто не відновить, чи був вхід і чому Telegram мовчав.
Винесення доставки вирішує це розділенням відповідальності. Логіка бота пише сигнал у журнал вихідних однією транзакцією з торговою подією, а окремий процес читає журнал і розносить повідомлення по каналах.
Ключ ідемпотентності — ідентифікатор сигналу плюс канал — гарантує, що повторна обробка не продублює сповіщення.
Переходити на таку схему краще поступово, не ламаючи працюючий код. Спочатку тіньовий режим: новий шлях дублює відправлення, старий залишається основним, журнали звіряються построково.
Потім канали перемикаються по одному, а попередня функція відправлення залишається обгорткою над чергою — зворотна сумісність зберігається, стратегії та обробники правити не потрібно.
Журналювання закриває питання довіри до системи. По кожній спробі пишемо статус, час, причину відмови та номер повтору; недоставлене йде в окрему чергу з наростаючою паузою між спробами.
Якщо частка втрат перевищує поріг, черговий отримує алерт — про мовчазного бота дізнаємося з метрики, а не від користувача.
Часті технічні питання щодо доставки сигналів
Доставка сигналу — це не «відправити текст у чат», а черга з підтвердженням. Модуль сповіщень працює окремим процесом: торгове ядро публікує подію й не чекає відповіді зовнішнього сервісу, тому недоступність каналу не гальмує логіку стратегії.
Кожному сигналу присвоюється порядковий номер та ідентифікатор події — повторне відправлення не перетворюється на дубль, отримувач відкидає вже бачене. Права налаштовуються окремо: відправник уміє лише публікувати, без читання історії та доступу до позицій.
Як зрозуміти, що сигнал справді дійшов?
Повідомлення проходить стани «створено → відправлено → доставлено», за ними ведеться журнал. Якщо час доставки вийшов за звичайний коридор, черговий отримує попередження, а критичний сигнал іде дублюючим каналом.
Чи може сповіщення завалити або сповільнити бота?
Ні: відправлення асинхронне й винесене за межі торгового циклу. При переповненні черги модуль деградує — пише в журнал і зрізає неприоритетні повідомлення, а не блокує ядро.
Як перевіряють канал перед підключенням?
Проганяємо синтетичний сигнал по кожному каналу: формат, час доставки, поведінка при обриві зв’язку та повтор після відновлення. На виході — звіт за затримками та втратами, а не «наче прийшло».
Хто і що бачить у каналах?
Доступ видається ролям: трейдери отримують сигнали, аналітика — зведення, адміністратор — журнал доставки. Ключі ботів зберігаються окремо від торгових, відкликаються однією командою та не дають прав на операції.
Обговоримо вашу схему доставки сигналів
Щоб оцінка була предметною, а не «на око», надішліть схему доставки сигналів і перелік типів повідомлень: що бот надсилає, у якому каналі це має опинитися і що вважається критичним.
За цією схемою ми збираємо склад робіт, оцінюємо обсяг і повертаємося з планом впровадження — з етапами, залежностями та точками перевірки.
Що розбираємо при обговоренні задачі:
- карту каналів: Telegram, Email, Discord — який тип сигналу куди йде і який канал основний, а який резервний;
- джерела подій: торгові сигнали, статуси виконання заявок, помилки, звіти за підсумками сесії;
- правила доставки: пріоритети, повтори при збої, захист від дублів, тихі години;
- шаблони сповіщень і поля: інструмент, напрямок, рівень входу та захисних заявок;
- доступи й секрети: як видаються боти, токени та поштові скриньки, де зберігаються ключі;
- моніторинг доставки: як дізнаємося, що повідомлення не пішло, і хто реагує першим;
- схему відкату: що відбувається при недоступності основного каналу і як перемикаємося.
Передачу схеми можна зробити текстом, таблицею або знімками поточної панелі — нам важлива логіка, а не формат. Опишіть задачу й додайте те, що вже є: повернемося з оцінкою робіт і планом впровадження.
