Система уведомлений 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 — какой тип сигнала куда идёт и какой канал основной, а какой резервный;
- источники событий: торговые сигналы, статусы исполнения заявок, ошибки, отчёты по итогам сессии;
- правила доставки: приоритеты, повторы при сбое, защита от дублей, тихие часы;
- шаблоны уведомлений и поля: инструмент, направление, уровень входа и защитных заявок;
- доступы и секреты: как выдаются боты, токены и почтовые ящики, где хранятся ключи;
- мониторинг доставки: как узнаём, что сообщение не ушло, и кто реагирует первым;
- схему отката: что происходит при недоступности основного канала и как переключаемся.
Передачу схемы можно сделать текстом, таблицей или снимками текущей панели — нам важна логика, а не формат. Опишите задачу и приложите то, что уже есть: вернёмся с оценкой работ и планом внедрения.
