Rate limits для ботов становятся скрытым сбоем, когда система принимает работу, но завершает её поздно, повторяет действие или теряет задачу среди автоматических попыток. Процессы могут оставаться зелёными, пока возраст очереди растёт. Защита API требует общей квоты, устойчивых очередей, ограниченных повторов, идемпотентных обработчиков, отдельного маршрута для неисправимых сообщений и тревог по незавершённой работе.
Проведите учение с общей квотой
Соберите тестовый стенд с семью ботами для поиска, классификации, подготовки, проверки, обогащения, уведомлений и отчётности. Все используют одну квоту внешнего API, но создают задачи с разной скоростью и важностью. Это синтетическое учение, а не описание инцидента MYOD или клиента. Постепенно увеличьте входящий поток до появления ограничений и наблюдайте реакцию каждого потребителя.
В слабой схеме каждый бот повторяет запрос самостоятельно. Попытки синхронизируются, занимают оставшуюся квоту и создают ещё больше работы. Быстрые фоновые процессы вытесняют проверку и уведомления. При этом общий health check может показывать исправность. Поэтому применяйте правила против выдуманных фактов ИИ-агентов и считайте состояние по событиям очереди и провайдера.
В карточку учения входят принятые и завершённые задачи, глубина очереди, возраст самого старого элемента, число активных потребителей, ответы ограничения, попытки, расход запросной или токенной квоты, дублирующие действия, dead-letter и сквозная трасса. Разделяйте показатели по маршрутам и приоритетам, иначе среднее время скроет остановку важного процесса.
Ограничьте поток до обращения к API
Перед общим API поставьте единый admission controller. Он знает действующие квоты провайдера и распределяет пропускную способность по утверждённому приоритету. Производители помещают работу в очередь, а потребители забирают её с безопасной скоростью. Пиковая нагрузка остаётся в буфере и не переносится мгновенно на зависимость.
Очередь не создаёт дополнительную квоту. Если средний входящий поток выше безопасной обработки, возраст задач продолжит расти. Заранее определите отложенную обработку, отказ от низкого приоритета и ручную проверку. Неверные или постоянно падающие сообщения отправляйте в dead-letter, чтобы они не вращались бесконечно. Контролируйте не только размер очереди, но и старейшую задачу.
Логической операции нужен ключ идемпотентности или эквивалентная сверка состояния. API мог принять запрос, а ответ потеряться, после чего бот повторит действие. Без защиты повторно уйдёт уведомление или изменится запись. Необратимые действия держите за дополнительным согласованием. Тесты перед внедрением ИИ помогают проверить потерянный ответ, дубликат и исчерпанную квоту.
Повторяйте выборочно и докажите восстановление
Повторяйте только временные ошибки и учитывайте рекомендации провайдера. Используйте экспоненциальную задержку со случайным разбросом, верхний предел ожидания и общий бюджет попыток. Разброс уменьшает одновременные столкновения потребителей. Неверные параметры, отсутствие права или истёкший бизнес-срок должны завершать маршрут, а не расходовать квоту.
Включите единое управление и повторите исходную нагрузку. Приёмка требует ограниченной параллельности, продвижения важных задач, отсутствия дублирующих эффектов, видимого dead-letter и связи исходной задачи со всеми попытками и итогом. Сверьте также чеклист защиты данных компании, потому что журналы и очереди могут содержать чувствительные поля.
Проверьте справедливость внутри одного приоритета. Один длинный запрос не должен блокировать все короткие задачи, а крупный пакет не должен обходить общий бюджет дроблением. Для этого admission controller учитывает не только количество запросов, но и прогнозируемый размер работы. Фактический расход возвращается в планировщик после завершения, чтобы следующая выдача квоты опиралась на наблюдаемые данные.
Ещё один тест касается перезапуска потребителя. Возьмите задачу, остановите обработчик после принятия ответа провайдера, но до фиксации локального статуса, затем запустите его снова. Идемпотентность должна связать новую попытку с прежней операцией и не допустить второго эффекта. В журнале остаются обе попытки, состояние подтверждения и окончательное решение.
Квоты и правила провайдера могут различаться по модели, проекту и типу запроса, поэтому конфигурация не должна быть одной постоянной цифрой в коде. Сервис управления хранит актуальные лимиты, версию и источник настройки. При неизвестном значении он снижает поток и сообщает оператору, а не предполагает запас.
Частые вопросы
Процессы продолжают принимать задачи, а повторы расходуют квоту, возраст очереди растёт и отдельные рабочие маршруты перестают продвигаться.
Устойчивая очередь поглощает пики и позволяет потребителям соблюдать общую квоту, учитывать приоритет, сохранять задачи и видеть их возраст.
Повторяйте только классифицированные временные ошибки, следуйте правилам провайдера, ограничивайте задержку и общий бюджет попыток.
Повтор логической операции возвращает или подтверждает прежний результат, а не создаёт второе уведомление, изменение записи или другой эффект.
Для длительного ограничения подготовьте ручной drain: остановить низкий приоритет, сохранить задачи, уведомить владельцев процессов, постепенно вернуть обработку и сверить каждый незавершённый элемент. Тревога должна называть маршрут, возраст, квоту и ответственного. Если нужен аудит такого контура, обсудите управление и аудит ИИ-агентов с MYOD.
