Планирование сбоев поставщика для команд, использующих несколько моделей ИИ

Что на самом деле ломается во время сбоя

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

Именно такое неравномерное поведение и застаёт команды врасплох. Ответ в чате может всё ещё работать, потому что использует короткий промпт, а вот суммаризация уже ломается, потому что ей нужен более большой контекст. Классификация может продолжать работать, но структурированный вывод начинает приходить с ошибками. Пользователи не видят «один сбой». Они видят продукт, который странно себя ведёт в разных местах.

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

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

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

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

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

Составьте карту всех мест, где модель влияет на продукт

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

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

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

Храните один общий документ с одинаковыми полями для каждого потока: действие пользователя или внутренняя задача, которая запускает обращение; поставщик и точное имя модели; регион; цель обращения; что ломается при сбое; и человек, который владеет интеграцией.

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

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

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

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

Выберите порядок fallback

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

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

Не используйте одну цепочку fallback для всего. Разделите её по задачам. Чат, поиск, программирование и работа с изображениями ломаются по-разному, и у них не должен быть один и тот же резерв. Ваша лучшая модель для программирования может быть слишком медленной для живого чата. Модель для поиска может отлично подходить для извлечения, но плохо справляться с сумбурным вводом пользователя.

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

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

Установите одно автоматическое правило и одно ручное. Например, автоматически переключайте чат на следующего поставщика, если ошибки держатся выше 8% в течение 3 минут или p95-задержка превышает 10 секунд. Затем дайте одному дежурному человеку право отменить это правило, если резерв слишком дорогой, работает плохо или тоже начинает сбоить.

Понятный порядок и понятные триггеры убирают догадки, когда растёт давление.

Продумайте режимы деградации, которыми пользователи всё ещё смогут пользоваться

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

Начните с размера контекста. Длинные промпты стоят дороже, работают медленнее и первыми ломаются, когда у поставщика стресс. Уменьшайте большие окна истории, убирайте прикреплённые документы и удаляйте необязательные фоновые данные ещё до того, как трогать основной пользовательский поток. Если ассистент поддержки обычно читает последние 30 сообщений, на несколько часов ему может хватить и 8.

Сначала убирайте необязательные шаги

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

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

Оставьте полезный резервный результат

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

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

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

Напишите сообщения о сбое до того, как они понадобятся

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

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

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

We are having issues with some AI responses right now. Search, saved work, and exports still work. New long-form generation may fail or take longer. Please retry later if a request does not complete.

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

Thanks for flagging this. We are seeing failures in part of our AI workflow and the team is working on it now. Your existing data, saved projects, and manual editing are still available. Some generation requests may be delayed, shortened, or fail until service returns. We will send the next update by 3:00 PM UTC, even if the issue is still ongoing.

Несколько правил делают такие сообщения полезными:

• Скажите, что именно работает прямо сейчас.
• Опишите влияние на пользователя, а не внутреннюю драму.
• Назовите время следующего обновления, а не обещание починки.
• Не гадайте о первопричине.
• Не обвиняйте поставщика в публичном тексте.

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

Хороший текст о сбое звучит скучно. И это нормально. В плохой час скучный текст лучше, чем остроумный, всегда.

Проведите переключение так, чтобы не сделать хуже

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

Если триггер реальный, назовите его прямо. Возможно, доля ошибок превысила порог, задержка вышла за ваш предел или модель начала уходить в таймауты в одном регионе. Запишите, какое правило сработало, кто одобрил изменение и какая модель идёт следующей в вашем fallback-порядке. Эта короткая пауза потом сильно уменьшает количество догадок.

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

Осторожное переключение обычно выглядит так:

• Сначала отправьте небольшой кусок трафика, часто 5%–10%.
• Несколько минут следите за ошибками, задержкой и глубиной очереди.
• Проверяйте стоимость одного запроса и расход токенов, а не только uptime.
• Просмотрите выборку ответов на предмет ухудшения качества или сломанного форматирования.
• Увеличивайте трафик по шагам только если показатели остаются стабильными.

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

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

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

Простой пример с тремя поставщиками моделей

Команда поддержки использует одного бота на трёх сервисах. Поставщик A обрабатывает живой чат, потому что на обычной нагрузке даёт лучшие ответы. Поставщик B хранит embeddings для поиска, чтобы бот мог подтягивать правила по аккаунту, условия возврата и прошлые исправления. Поставщик C остаётся запасным вариантом для чата.

В 10:15 утра у поставщика A начинаются таймауты на пиковом трафике. Бот по-прежнему открывается, но ответы зависают на 20–40 секунд. Операторы начинают видеть дублирующиеся тикеты, потому что клиенты задают один и тот же вопрос дважды. Полного падения нет, и из-за этого проблема выглядит ещё грязнее. Люди продолжают пытаться пользоваться сервисом.

Команда не переключает всё сразу. Они сокращают контекст чата с последних 20 сообщений до последних 8, убирают несколько малоценных инструкций и оставляют retrieval на поставщике B. Это сразу снижает нагрузку на токены. Потом они переводят часть нового чата на поставщика C. Сначала запускают примерно 30% входящих разговоров вместо того, чтобы сразу переносить каждую сессию. Активные чаты остаются там, где были, если только они не падают дважды.

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

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

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

Ошибки, которые превращают плохой час в плохую неделю

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

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

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

Деньги тоже могут сделать плохой день ещё хуже. Во время failover использование часто растёт, потому что увеличиваются ретраи, а более медленные модели дольше держат запросы открытыми. Если лимиты расходов выключены, компания может проснуться с болезненным счётом сверху к самому сбою. Заранее ставьте лимиты трат, ограничения на rate limits и алерты для каждого поставщика.

Ещё один плохой шаг — слишком рано давать клиентам точное время восстановления. Люди помнят обещания сильнее, чем объяснения. Если вы скажете «через 30 минут всё вернётся» и опоздаете на три часа, доверие быстро упадёт. Лучше говорить, что сейчас работает, что деградировало и когда будет следующее обновление.

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

Спокойная команда с узким планом обычно восстанавливается быстрее.

Быстрые проверки для следующего учения

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

Пройдитесь по короткому чек-листу перед тем, как считать учение завершённым:

• Для каждой задачи, где работает модель, назовите первый fallback и второй fallback. Не останавливайтесь на «использовать другого поставщика». Запишите точный порядок для чата, извлечения, ранжирования, помощи с кодом или любого другого процесса, от которого зависит ваш продукт.
• Попросите одного человека найти сообщение для поддержки и шаблон обновления статуса. Если он не может найти оба меньше чем за две минуты, они слишком глубоко спрятаны.
• Убедитесь, что команда может отключать необязательные функции без деплоя. Feature flags, переключатели конфигурации или административные контролы здесь важнее, чем элегантный код.
• Проверьте, что дашборды разделяют стоимость, задержку и долю ошибок по моделям, а не только по областям продукта.
• Назначьте одного человека, который может запустить runbook после рабочего времени, не дожидаясь комитета.

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

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

Что делать дальше

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

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

Несколько привычек сильно упрощают это:

• Храните сообщения о сбое там же, где лежит runbook.
• Сохраните одно сообщение для медленного сервиса и одно для урезанной функциональности.
• Назначьте владельца для каждого действия и одного запасного человека.
• Запишите, как вы будете подтверждать, что fallback действительно работает.

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

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

Если вам нужен внешний взгляд, Олег Сотников на oleg.is помогает стартапам и небольшим командам усиливать планы AI failover, режимы деградации и инфраструктуру до того, как сбой покажет слабые места. Такой аудит часто полезен, когда нужно, чтобы кто-то посмотрел одновременно на поведение продукта, контроль расходов и то, как команда реально действует под давлением.