Сервис мониторинга Statuser (проект Timeweb Cloud) рассказал о случае, который стоит разобрать каждому, кто встроил в продукт стороннюю LLM. У одного из клиентов ИИ-функция — автогенерация черновиков ответов для операторов поддержки — перестала работать. При этом обычный HTTP-монитор, нацеленный на адрес ИИ-гейтвея, всё это время исправно показывал зелёный статус.
Что произошло
Продукт клиента использовал модель, которая разбирала обращения покупателей и готовила для операторов поддержки готовые черновики ответов. В какой-то момент функция замолчала. Мониторинг ничего не заметил: HTTP-проверка отправляла обычный GET-запрос на адрес гейтвея и получала успешный ответ, поэтому статус оставался «работает».
Причина оказалась в другом слое. Провайдер снял конкретную модель с обслуживания, но сам гейтвей продолжал отвечать на инфраструктурные запросы. GET-проверка до генерации ответа не доходила и состояние выбранной модели не видела — она проверяла, что сервер на месте, а не то, что модель отвечает.
О сбое сообщили не системы мониторинга, а операторы поддержки, которые перестали получать подсказки в интерфейсе. То есть между «гейтвей доступен» и «функция продукта работает» есть промежуточный слой — сама модель, — и стандартная HTTP-проверка его не покрывает.
Кого это касается
Ситуация типична для любого продукта, где ИИ-функция подключена через сторонний API — официальный эндпоинт провайдера, гейтвей-агрегатор, корпоративный прокси или self-hosted модель. Симптом всегда один: сервис в целом не падает, отваливается конкретная функция — подсказки оператору, разбор обращений, ответы в чате, — а базовый мониторинг доступности продолжает рапортовать об успехе.
Особенно уязвимы схемы с несколькими моделями за одним совместимым API (OpenAI-совместимым или Anthropic-совместимым). В таком списке моделей могут соседствовать чат-модели, эмбеддинги, синтез и распознавание речи, модерация — и не все из них вообще умеют отвечать на запрос генерации. Успешный ответ от эндпоинта со списком моделей ничего не гарантирует для конкретной модели, которую использует продукт.
Отдельно стоит случай с кодом 429: разные провайдеры возвращают его и при превышении лимита запросов, и при нулевом балансе на счёте. Без разбора тела ответа отличить одно от другого нельзя, а для пользователя оба случая означают одно — модель недоступна.
Что можно сделать сейчас
Если продукт зависит от ИИ-модели через API, обычной HTTP-проверки гейтвея недостаточно. Нужен мониторинг, который отправляет настоящий запрос на генерацию и сверяет структуру ответа с контрактом API — например, наличие поля choices для OpenAI-совместимого API или content для Anthropic-совместимого.
Statuser в ответ на этот кейс добавил отдельный тип проверки для текстовых моделей. У неё два режима:
| Режим | Что проверяется | Расход токенов |
|---|---|---|
| Без ключа | Доступность гейтвея через список моделей; ответ с требованием авторизации тоже считается успехом | Не расходуются |
| С ключом | Реальный запрос на генерацию (`POST /chat/completions` или `POST /messages`), сверка структуры ответа | Расходуются |
Сервис также разбирает причину сбоя не только по HTTP-коду, но и по телу ответа: код 401 помечается как проблема с ключом, 410 — как модель, снятую с обслуживания, а 429 разделяется на превышение лимита и нулевой баланс.
Если отдельного мониторинга моделей пока нет, минимальный шаг — синтетическая проверка, которая раз в несколько минут дергает реальный эндпоинт генерации с коротким тестовым промптом и проверяет структуру ответа, а не только код 200.
Чего мы не знаем
В материале не указано, какой именно провайдер снял модель с обслуживания и сколько по времени функция была недоступна до того, как о ней сообщили операторы. Неизвестна и отрасль клиента — только то, что продукт использовал модель для обработки обращений в поддержку. Не сказано, предупреждал ли провайдер о прекращении поддержки модели заранее и был ли у клиента способ это отследить до инцидента.
