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

8 часовтишины — и подписка снимается
только 200другой ответ доставкой не считается
один из двухоба способа сразу включить нельзя
адрес и сертификатбез них подписки не будет

1. Короткий ответ: молчание бывает двух разных видов

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

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

Ключевая мысль всей статьи: во втором случае связь не просто прерывается на время неполадки. Она разрывается насовсем, и после починки сервера бот сам не оживёт — подписку нужно создать заново.

2. Два способа получать события, и включить оба нельзя

Справка платформы описывает выбор без вариантов толкования.

API поддерживает два типа уведомлений о действиях пользователей с ботом — выбор зависит от этапа работы. Для production-окружения — только Webhook. Для разработки и тестирования — Webhook или Long Polling. Использовать одновременно оба типа нельзя — выберите один из них.

Справка платформы MAX для разработчиков

Разница между способами — в том, кто делает первый шаг.

Webhook — платформа приходит к вам. Как формулирует справка, Webhook после новых действий в чат-боте сам отправляет запрос на сервер. Вы один раз сообщаете адрес, куда присылать события, и дальше платформа стучится туда сама по мере надобности.

Long Polling — вы приходите к платформе. Бот делает периодические запросы без триггера в боте, то есть спрашивает о новостях по расписанию, независимо от того, произошло что-нибудь или нет.

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

3. Восемь часов без ответа — и платформа отписывает бота

Это центральный факт, ради которого написан весь материал. Формулировка справки:

Если доставка не удалась или от Webhook-endpoint не получен успешный ответ, выполняются повторные попытки отправки событий. Если в течение 8 часов ответ не получен, бот автоматически от него отписывается.

Справка платформы MAX для разработчиков

Разберём по частям, потому что каждая половина этой фразы меняет картину поломки.

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

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

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

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

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

4. Что считается ответом: только код 200

Второй факт, который объясняет львиную долю необъяснимых поломок. Требование к принимающей стороне сформулировано жёстко:

Webhook-endpoint должен возвращать HTTP 200. Если доставка не удалась или от Webhook-endpoint не получен успешный ответ, выполняются повторные попытки отправки событий.

Справка платформы MAX для разработчиков

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

Переадресация — не успех. Если адрес переехал и на старом месте стоит перенаправление, для платформы это не подтверждение доставки.

Страница ошибки — не успех. Красивая страница «что-то пошло не так», отданная с кодом ошибки, не спасает: важен код, а не содержимое.

Долгий ответ — риск. Если обработка события занимает много времени и соединение обрывается по таймауту, успешного ответа платформа не увидит, даже если событие в итоге обработано.

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

5. Что должно работать на стороне бота

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

Чтобы работать с Webhook, необходимо настроить публичный сервер с защищённым соединением HTTPS и статичным IP-адресом.

Справка платформы MAX для разработчиков

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

Для повышения безопасности при получении вебхуков прекращается поддержка самоподписанных сертификатов и передачи данных по HTTP. Используйте HTTPS и сертификаты, удостоверенные доверенными центрами сертификации, в том числе сертификаты Минцифры.

Справка платформы MAX для разработчиков

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

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

6. Почему Long Polling нельзя оставлять в рабочем режиме

Второй способ выглядит проще: не нужен ни публичный адрес, ни сертификат, ни статичный адрес. Справка это подтверждает и тут же объясняет, почему простота обманчива.

Получение обновлений с помощью Long Polling ограничено по скорости и сроку хранения событий — этот способ не подходит для production-окружения. Рекомендуем на всех этапах работы использовать Webhook.

Справка платформы MAX для разработчиков

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

Задержка ответов из-за ожиданий и таймаутов может привести к накоплению очереди открытых соединений, поэтому использовать его для production-окружения нельзя.

Справка платформы MAX для разработчиков

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

Если бот работал безупречно, пока о нём никто не знал, и стал терять сообщения после первой заметной рассылки — это классический признак того, что на боевом сервисе остался отладочный способ получения событий.

7. Подписка — это ещё и адресная книга бота

У подписки есть вторая роль, о которой редко думают, пока она не откажет. Через неё бот узнаёт, где он вообще состоит.

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

Следствие первое. Бот не может «осмотреться» и составить список своих чатов по требованию. Он знает ровно то, что ему прислали событиями.

Следствие второе. Пока подписки нет, бот не узнает и о том, что его куда-то добавили. Для стороннего наблюдателя это выглядит как «бота добавили в группу, а он не здоровается».

Следствие третье. Восемь часов простоя стоят дороже, чем кажется: теряются не только сообщения, но и события о добавлениях, выходах и изменениях, за время отписки прошедшие мимо.

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

8. Четыре симптома и что за ними стоит

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

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

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

9. Что спросить у того, кто делал бота

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

Каким способом бот получает события. Правильный ответ для работающего сервиса один. Отладочный способ на боевом сервисе — повод переделать, а не спорить.

Что происходит, если наш сервер полежит ночь. Если в ответ звучит «поднимется и заработает», уточните про восемь часов и снятие подписки. Хорошее решение восстанавливает подписку самостоятельно при старте.

Чей сертификат стоит на принимающем адресе. Самодельный сертификат не годится — нужен выданный доверенным центром.

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

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

Последний пункт стоит превратить в требование. Разница между «бот сломался и мы узнали об этом от клиентов» и «бот сломался и мы узнали об этом сами» — это одна регулярная проверка списка подписок.

10. Что из этого следует владельцу

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

Молчание бота не всегда поломка бота. В половине случаев сломана связь, а не логика, и чинится это в другом месте.

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

Простой стоит дороже времени простоя. Кроме сообщений теряются события о том, куда бота добавили и что с ним произошло.

Требования к инфраструктуре ужесточаются со временем. Решение, работавшее раньше, может остановиться без единой правки в коде — сертификаты тому пример.

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

Если смотреть шире, весь этот сюжет — про разницу между «сервис запущен» и «сервис поддерживается». Бота можно завести за один вечер, и он будет работать. Останется ли он работать через полгода, зависит не от сценария, а от того, кто следит за связью и как быстро он узнаёт о её обрыве.

Ведёте канал или чат в MAX

В каталоге MAX Official собраны каналы и чаты с описанием, тематикой и числом подписчиков. Полезно посмотреть, как устроены площадки в вашей нише, прежде чем строить вокруг них сервисы.

Открыть каталог каналов

11. Чего в справке нет

Честный список того, на что первоисточник ответа не даёт. Если решение упирается в один из этих пунктов, опираться на догадку не стоит — вопрос лучше задать поддержке платформы.

  • Сколько именно повторных попыток выполняется и с каким интервалом. Сказано только, что они есть.
  • Уведомляют ли владельца о снятии подписки. Про оповещение не сказано ничего, а действие выполняется без его участия.
  • Что происходит с событиями, накопившимися за время недоступности. Доставляются ли они после восстановления связи или теряются безвозвратно.
  • Каков срок хранения событий у отладочного способа. Ограничение названо, число — нет.
  • Восстанавливается ли подписка автоматически, если сервер снова начал отвечать до истечения порога. Из формулировки следует, что да, но прямо это не написано.

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

12. Частые вопросы

Почему бот в MAX перестал отвечать, хотя сервер работает?

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

Через сколько платформа отписывает бота от событий?

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

Какой ответ считается успешным?

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

Можно ли включить оба способа получения событий сразу?

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

Подойдёт ли самодельный сертификат на сервере бота?

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

Как узнать, жива ли подписка, не дожидаясь жалоб?

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

бот MAX не отвечаетбот замолчалподписка на событиявебхук MAXвосстановить ботасервер ботасертификат для вебхука
Материал подготовлен по официальной справке платформы MAX для разработчиков. Требования и формулировки интерфейса могут меняться с обновлениями — сверяйтесь со справкой на момент чтения.