Учитываемые признаки

Клиент называет временное окно и долю сбоев, а не ограничивается фразой «всё плохо».
Сбои содержат читаемые HTTP-коды состояния или коды ошибок, по которым можно разделить уровни.
Статус провайдера, собственная конфигурация маршрутизации и записи о ретраях клиента пока не согласованы.

«В пиковые часы постоянно падает. С вашим маршрутом что-то не так?»

Такое сообщение появляется в клиентском чате сервиса, который перепродаёт доступ к AI API. Реакции бывают двух видов. Одна — извиниться и провести ночь за перенастройкой весов маршрутизации. Другая — сначала задавать вопросы, пока клиент не решит, что вы уходите от ответа.

Обе реакции объединяет одно допущение: что вы уже знаете, что именно означает слово «нестабильно». В составном сценарии ниже проблема как раз в этом допущении.

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

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

Слово «нестабильно» не говорит, на каком уровне произошёл сбой

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

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

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

Превратите это в поля, с которыми можно сверяться

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

Временное окно, в котором произошли сбои, с точностью до минуты
Распределение HTTP-кодов состояния на неуспешных запросах, например сколько пришлось на 429, а сколько на 503
Код ошибки и строку типа ошибки в теле ответа
Кривую общего объёма запросов, которую зафиксировала ваша сторона в том же окне

Третий пункт пропускают чаще всего. Многие смотрят только на код состояния: 429 означает лимит, 503 означает, что провайдер лежит. В большинстве случаев такое чтение верно, но оно упускает один важный случай, а этот случай в этом бизнесе рядовой.

429 и 503 указывают в противоположные стороны

В документации провайдера эти две ошибки обрабатываются раздельно.

429 с типом rate_limit_error означает, что был затронут лимит частоты. 503 с типом service_unavailable_error означает, что запрошенная модель временно перегружена. Первое — проблема квоты, второе — проблема ёмкости. В первом случае вы настраиваете собственный ритм запросов; во втором сделать можно очень немногое, кроме соблюдения Retry-After и повторной попытки позже либо переключения маршрута.

Для атрибуции отсюда следует вот что: 503 вместе с перегрузкой модели — один из немногих сигналов, который прямо возлагает ответственность на провайдера. Если в окне сбоев доминирует 503, а не 429, то «нестабильный маршрут» в целом указывает в верном направлении, и разговор переходит к резервным маршрутам и политике деградации.

Если же окно почти целиком состоит из 429, направление меняется. Потому что у 429 есть подраздел, который почти никто не читает внимательно.

slow_down: скорость роста у клиента, а не сбой провайдера

В той же документации есть абзац, который стоит прочитать дословно:

A slow_down error can occur even when your traffic is within its requests-per-minute and tokens-per-minute limits. It reflects how quickly traffic increased, not whether you exhausted those limits.

Опубликованное практическое правило: как только трафик достигает миллиона входных токенов в минуту, он не должен расти быстрее чем на 50 процентов каждые 15 минут. Выше этого наклона начинает появляться slow_down.

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

На этом цель атрибуции смещается с вопроса «стабилен ли провайдер» на вопрос «кто и с каким наклоном отправляет запросы».

Усилитель ретраев: почему «отправить ещё раз» делает хуже

Следующий пункт фактически закрепляет ответственность на стороне клиента.

В документации по квотам есть предупреждение: Unsuccessful requests still count toward your per-minute rate limit. Continuously resending a request without backing off makes throttling worse.

За этим предложением стоит распространённый дефект реализации. Клиент получает 429, немедленно повторяет, снова получает отказ, снова немедленно повторяет. Если при этом работает параллелизм, каждый отказ умножается на коэффициент параллельности и превращается в самоусиливающийся всплеск запросов. Вы видите резкий рост доли сбоев. Провайдер видит ключ, объём запросов по которому увеличился в разы за секунды. Настоящая причина — в цикле ретраев клиента без задержек.

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

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

Уровень, который пропускают: конфигурация маршрутизации и общие ключи

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

Лимиты частоты привязаны к ключу, а не к клиенту. Как только трафик двух клиентов идёт через один ключ, вы связали их квоты, их неуспешные ретраи и их пиковые нагрузки. Клиент A запускает пакетную задачу в пиковые часы, клиент B ведёт живые диалоги, и клиент B чувствует «нестабильный маршрут».

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

Меняйте по одной переменной за раз

К этому моменту доказательств достаточно для гипотезы. У следующего шага есть жёсткое ограничение: меняйте по одной переменной за раз.

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

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

Когда этот разбор не работает

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

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

Во-вторых, провайдер сводит коды ошибок к общему 500 или к собственному формату тела ответа, и коды состояния больше не несут ясного смысла. Шаг «разделить по коду состояния» отпадает, и остаются кривые запросов в перекрёстной проверке с публичной страницей статуса провайдера.

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

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

Дальше по теме

ИССЛЕДОВАНИЯ И ОПРЕДЕЛЕНИЯ

Как обнаруживается Signal, заслуживающий внимания

Методика показывает, как Top Prospect находит и упорядочивает Signals, которые стоит проверить, сохраняет исходный контекст Telegram, удаляет дубли и помогает определить порядок просмотра. Решение о дальнейших действиях остаётся за вами.

Открыть методику и определения

«У вас нестабильный маршрут»: отделите сбой провайдера от своей конфигурации и ретраев клиента