Тихий отказ 7 ботов опаснее громкого: как rate limit убил автоматизацию незаметно

24 марта 2026 года я обнаружил, что семь моих AI-агентов не работали. Не упали с ошибкой. Не выдали алерт. Не написали мне в Telegram. Просто молчали — тихо, незаметно, в то время как система выглядела полностью рабочей.

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

Этот случай изменил моё понимание того, что значит «надёжная автоматизация». До него я думал, что надёжность — это когда система не падает. После — понял, что надёжность — это когда система не может упасть незаметно.

Что случилось

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

В тот день провайдер начал отдавать ошибку перегрузки на все запросы. Не постоянно — каждый раз по-разному. Иногда запрос проходил, иногда возвращал 429 Too Many Requests или 503 Service Unavailable. Это называется rate limiting — когда сервис ограничивает частоту запросов или временно перестаёт принимать нагрузку из-за перегруженности.

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

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

Почему тихий отказ хуже громкого

Когда система падает громко — ты знаешь об этом сразу. Алерт в Telegram, красный статус в мониторинге, пользователи пишут «что-то не работает». Это неприятно, но понятно: вот проблема, вот где она, иди чини.

Когда система отказывает тихо — ты не знаешь ничего. Внешние индикаторы зелёные. Мониторинг молчит. Ты идёшь заниматься другими делами, уверенный, что всё работает. А система в этот момент тихо не делает то, что должна.

В моём случае «то, что должна» — это обработка лидов, мониторинг бронирований, публикация контента, проверка статусов. Семь агентов, семь направлений работы. Все остановились, никто не сообщил.

Если бы сервер упал — я бы узнал за минуты. Если бы бот выдал 500-ю ошибку — я бы получил алерт. Но когда бот молча перестаёт работать, потому что внешний API временно недоступен, — это нигде не видно. Ты видишь только результат спустя несколько часов: задачи не выполнены, лиды не обработаны, контент не опубликован.

Как я обнаружил проблему

Обнаружил случайно. Написал в Telegram-чат агенту «опубликуй пост» — он ответил «запускаю агента». И тишина. Ни подтверждения публикации, ни ошибки.

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

Начал копать глубже. Открыл внутренние логи агента — и увидел цепочку: запрос к API → 429 Too Many Requests → повтор через 5 секунд → снова 429 → повтор → снова отказ. Агент честно пытался, честно получал отказы, и в конце концов сдавался без единого уведомления наружу.

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

Немедленное решение: переключение на другой движок

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

Агенты ожили. Начали обрабатывать накопившиеся задачи. Публикации пошли, лиды начали обрабатываться. Потери от простоя — несколько часов работы, которую придётся наверстать вручную или принять как недополученную.

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

Системное решение: цепочка запасных движков

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

Решение: цепочка запасных движков (fallback chain). Вместо одного провайдера — три, расположенные в порядке приоритета. Агент всегда пробует первый. Если первый не отвечает или возвращает ошибку — автоматически переключается на второй. Если второй тоже недоступен — переключается на третий. Если все три недоступны — тогда уже отправляет алерт мне.

Техническая реализация: каждый агент при запуске задачи пробует провайдеров по порядку. Если за 10 секунд не получил ответа или получил ошибку 4xx/5xx — переключается на следующего без уведомления. Логирует переключение в файл (для аудита), но не прерывает работу.

Дополнительно: добавил экспоненциальный backoff при повторных попытках. Если провайдер вернул 429 — значит, он перегружен, и бомбить его повторными запросами каждые 5 секунд только ухудшает ситуацию. Лучше подождать: первый повтор через 30 секунд, второй через 2 минуты, третий через 10 минут. После трёх попыток — переход к следующему провайдеру.

Второй слой: мониторинг результатов, не только состояния

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

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

Добавил второй слой мониторинга: проверку результатов. Для каждого типа агентов — своя метрика «живости»:

• Агент публикации контента: должен публиковать хотя бы один пост в N часов. Если нет — алерт.
• Агент мониторинга лидов: должен создавать карточки лидов из чатов. Если за 6 часов ноль новых карточек — подозрительно.
• Агент бронирований: должен получать данные из eZee каждые 2 часа. Если данные не обновлялись дольше — проверка.
• Агент отчётности: должен генерировать ежедневный отчёт. Если к 9 утра отчёта нет — алерт.

Это «мониторинг по результату», а не «мониторинг по состоянию». Агент может быть технически активен и при этом не делать ничего полезного. Мониторинг результата ловит именно эту ситуацию.

Технически: отдельный скрипт проверяет эти метрики каждые 30 минут. Если какой-то агент не дал ожидаемого результата за ожидаемое время — пишет мне в Telegram с указанием конкретного агента и последней успешной активности.

Третий слой: явная обработка ошибок в каждом агенте

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

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

Это болезненное изменение в краткосрочной перспективе: первые несколько дней после внедрения количество сообщений резко выросло. Появились ошибки, которые раньше происходили тихо и теперь стали видимыми. Пришлось их исправлять.

Но это именно то, что нужно: система не может молчать о проблемах. Если что-то идёт не так — лучше узнать сразу, чем через несколько часов обнаружить, что задача не выполнена.

Что изменилось

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

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

После: агенты продолжают работу при отказе провайдера (переключаются автоматически). Если переключение не помогает — я узнаю об этом в течение 30 минут. Потери — минуты, не часы.

Примерно за первый месяц после внедрения цепочки запасных движков система 4 раза автоматически переключилась с основного провайдера на резервный. Ни одного из этих переключений я не заметил в режиме реального времени — просто видел в утреннем отчёте «провайдер A был недоступен с 03:20 до 04:15, работали через провайдера B». Это именно тот результат, который нужен.

Урок про зависимость от внешних сервисов

Этот инцидент поднял более широкий вопрос: как строить автоматизацию, если она зависит от внешних сервисов, которые ты не контролируешь?

Внешние API ломаются. Не потому что плохо сделаны — просто это сложные распределённые системы, в которых иногда что-то идёт не так. Rate limiting — это нормальная защита от перегрузки. Временная недоступность — это реальность любого облачного сервиса.

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

Конкретно для AI-агентов это означает: никогда не подключать всех агентов к одному провайдеру без резервного. Не потому что провайдер ненадёжен — а потому что зависимость от единственного внешнего источника делает систему хрупкой.

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

Чеклист для тех, кто строит автоматизацию

На основе этого и похожих инцидентов я составил для себя минимальный список вопросов при проектировании любого агента или автоматизированного процесса:

• Что происходит, если внешний сервис недоступен? Агент остановится молча? Переключится на резервный? Сообщит об ошибке?
• Как я узнаю, что агент не делает свою работу? Только если увижу отсутствие результата? Или есть проверка по результату с алертом?
• Куда попадают ошибки, которые агент не смог обработать? В лог-файл, который никто не читает? Или напрямую мне?
• Есть ли резервный вариант для каждого критического компонента? Провайдер AI, база данных, внешние API — что происходит при их недоступности?
• Что случится с задачей, если агент упал посередине? Она потеряется? Встанет в очередь и будет повторена?

Ни один из этих вопросов не требует сложных технических решений. Но без явных ответов на них система будет периодически тихо ломаться — и ты будешь узнавать об этом слишком поздно.

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