Failover AI-агентов: где именно ломается прод
Агент в проде ломается не тогда, когда модель отвечает плохо, а когда внешний шаг не отвечает вовсе. Запрос уходит к OpenAI, соединение открыто, ответа нет — и зависший агент держит рабочий поток до предельного времени ожидания. Пока он висит, очередь на обработку растёт, а пользователь не получает ни результата, ни внятной ошибки.
Второе типовое место — сбой цепочки вызовов. Агент обращается к инструменту, тот идёт в базу, база отвечает медленно; ошибка на одном шаге снаружи не видна, и цепочка возвращает пустой или частичный результат. Это опаснее явной ошибки: клиент считает данные верными и принимает решение на них.
Третье — исчерпанный лимит и деградация очереди. Провайдер отдаёт отказ по квоте, повторы уходят одновременно из всех обработчиков, и нагрузка вырастает кратно вместо того, чтобы снизиться. Один такой эпизод превращает деградацию сервиса в полный отказ.
Failover AI-агентов начинается с признания: любой внешний шаг может не ответить. Дальше — предельное время ожидания на каждом вызове, разрыв цепочки на изолированные шаги, автозамена на резервного исполнителя и правила, по которым система отдаёт честную ошибку вместо зависшего ответа. Разбираем, как это закрывается.
Что меняется после внедрения: время, потери, отказы
До внедрения устойчивости отказ инстанса агента замечал пользователь: запрос не прошёл, ответ вернулся неполным. Дежурный видел сбой в мониторинге через несколько минут, дальше — ручной разбор, переключение трафика, перезапуск. Время восстановления в такой схеме измеряется десятками минут, и каждая из них попадает в простой сервиса.
Failover-схема меняет это в измеримых величинах. Узел, не прошедший проверки здоровья, выводится из балансировки, трафик уходит на резервный, а незавершённые задачи переигрываются из очереди — время восстановления сокращается до десятков секунд и уже не требует ручных переключений. Платформа оркестрации уровня Kubernetes пересоздаёт упавшие экземпляры по заданному состоянию, поэтому восстановление одинаково проходит и в рабочее время, и ночью.
Отдельно уходит класс отказов «тихая деградация», когда процесс жив, но перестал отвечать по существу. Раньше такие случаи находили по косвенным признакам и разбирали вручную; теперь их закрывает тот же контур проверок. Доля ручных операций при сбое падает до единичных, плановых.
В сумме доступность контура перестаёт зависеть от того, кто из инженеров на смене и насколько быстро он среагирует. Это меняет не только цифры простоя, но и режим работы команды: дежурство смещается с тушения пожаров на разбор причин и профилактику.
Режимы резервирования: активный, горячий и холодный
Выбор режима резервирования определяется не привычкой, а ценой простоя и объёмом состояния, которое держит агент. Разница между схемами — в том, что уже поднято и прогрето к моменту сбоя, и сколько занимает failover: перевод трафика на резервный контур.
| Режим | Когда подходит | Ограничения |
|---|---|---|
| Активный резерв | Оба контура принимают запросы, отказ одного не прерывает диалоги. Для сценариев с жёстким требованием к непрерывности | Нужны идемпотентные операции и согласование состояния; дороже в сопровождении, расхождения между контурами сложно расследовать |
| Горячий резерв | Второй контур поднят и прогрет, но трафик не принимает. Переключение — секунды, покрывает большинство агентных сценариев | Нужен детектор деградации: штатные проверки готовности в оркестраторе (Kubernetes) видят падение, но не падение качества ответов |
| Холодный резерв | Некритичные и пакетные задачи, регламентные отчёты, внутренние ассистенты | Готовность — минуты, реальное время подъёма проверяется только учениями |
Комбинировать режимы нормально: критичный путь держим на активном резерве, фоновые задачи — на холодном. Горячая замена оправдана там, где есть куда перевести трафик и чем измерить качество, иначе резерв остаётся недоказанным. Отдельно проговорите поведение при отказе обоих контуров: честная очередь запросов с понятным ответом пользователю лучше, чем молчаливая потеря обращений.
Схемы failover: порядок внедрения в ваш контур
Внедрение failover — не установка библиотеки, а последовательность шагов, где каждый опирается на артефакты предыдущего. Пропустите карту отказов — резервирование закроет не те сбои; пропустите проверку на отказ — переключение впервые сработает в бою.
-
Аудит контура и карта отказов. Инвентаризируем узлы: модель, внешние инструменты, очереди, хранилище состояния. Для каждого фиксируем режим отказа — таймаут, ошибку, деградацию качества, недостоверный ответ — и его цену для сценария.
-
Выбор схемы failover. Активный резерв, горячий дубль, каскад маршрутов или деградация до более простой модели. Схему определяет критичность сценария, а не удобство реализации.
-
Проектирование переключения. Правила детекции — таймаут, код ответа, доля ошибок на окне — и лимиты повторов. Идемпотентность вызовов, чтобы повтор не создал дубль действия во внешней системе.
-
Реализация и вынос состояния. Состояние сессии переезжает в общее хранилище: резервный маршрут подхватывает контекст, а не начинает диалог заново. Заодно ограничиваем зону поражения одного узла.
-
Проверка на отказ. Учения на стенде: гасим узел, режем сеть, вводим задержки, отдаём некорректные ответы. Фиксируем, сработало ли переключение, за какое время, без дублей ли прошли действия.
-
Наблюдаемость. Метрики переключений, доля деградированных ответов, время восстановления. Алерты — на частоте срабатывания, иначе шум разовых сбоев скроет реальную деградацию.
-
Ввод в эксплуатацию и передача в дежурство. Регламент ручного вмешательства, инструкция дежурному, окно усиленного наблюдения и критерии отката на предыдущую схему.
Что передаём на руки: схемы, политики, регламенты
Сдаём не только работающий контур, но и всё, что нужно для его самостоятельной эксплуатации. Без этого первый же отказ агента превращается в простой до выяснения, кто и что должен делать: автоматика сработала, а дежурный не знает, куда смотреть и что переключать вручную. Поэтому вместе с решением уходит комплект артефактов, по которым команда заказчика действует без нас.
- Схема контура — потоки запросов, точки отказа, места включения автопереключения и логика автозамены агента при деградации.
- Политики доступа — роли, границы сервисных учёток, порядок выдачи и отзыва прав, отдельный доступ к логам и конфигурации.
- Регламент дежурства — кто реагирует на срабатывание, в какие сроки, что закрывает автоматика, а что остаётся человеку.
- Инструкции для команды — пошаговые сценарии: ручной перевод трафика, откат на предыдущую конфигурацию, возврат агента в пул после сбоя.
- Документация по конфигурации — пороги, таймауты, число повторных попыток и объяснение, почему выбраны именно такие значения.
- Чек-листы перед выкатом — что проверить в маршрутизации и политиках, чтобы изменение не сломало переключение.
- Журнал известных отказов — какие режимы уже наблюдались, чем гасились и какие пороги после этого менялись.
Артефакты остаются в вашем репозитории и обновляются вместе с контуром: меняем логику — в том же изменении правим схему и регламент.
Кейс: автозамена убрала ночные ручные переключения
Заказчик — круглосуточный сервис, где ассистенты отвечают на обращения клиентов и пауза в их работе видна сразу. До внедрения ночной отказ агента означал ручное дежурство: алерт, диагностика, переключение на резервного агента, проверка ответов и только потом сон. Цикл занимал в среднем 18–22 минуты, в неудачные ночи — до 40, и таких случаев набиралось 3–4 в месяц.
После внедрения автозамены переключение перестало быть решением человека. Проверка состояния агента уходит каждые 15 секунд, три неуспешных ответа подряд выводят его из ротации, замена поднимается из прогретого пула и сразу получает трафик, а исходный возвращается в строй после серии успешных проверок. Условия описаны декларативно, поэтому поведение одинаково для всех агентов, а метрики и история переключений собираются в Prometheus — утром видно, что именно произошло, без ручного разбора логов.
Метрики до и после
- Время до переключения трафика: 18–22 минуты → 40–60 секунд.
- Ручные ночные переключения: 3–4 в месяц → ноль за восемь месяцев наблюдений.
- Простой за месяц: 60–90 минут → единицы минут.
- Доля отказов, закрытых автоматически: около 95%, остальные — случаи, где нужно решение по данным, а не переключение.
Снижение простоя дало не только метрику: дежурный перестал быть частью ночного процесса. Инженер подключается, когда автозамена исчерпала варианты и нужен разбор причин, а не срочное спасение сервиса.
Что делать, если контур уже развёрнут в одном экземпляре?
Если контур уже работает в одном экземпляре, останавливать его ради резервирования нельзя — простой заметят пользователи, а не только мониторинг. Поэтому первым шагом идёт инвентаризация: где живёт состояние агента, что хранится в памяти процесса и что уже вынесено наружу. Всё, что осталось внутри одного экземпляра — контекст диалога, очередь заданий, счётчики лимитов, — придётся вынести в общее хранилище. Пока это не сделано, второй экземпляр поднять можно, но подхватить работу упавшего он не сможет.
Дальше выравниваем обработку так, чтобы повторный вызов не ломал результат. Агент, который перезапускает шаг после обрыва, должен либо продолжить с той же точки, либо безопасно пройти шаг заново — иначе после перевода на резерв появятся дубли заявок, писем или записей в учётной системе. Здесь же настраивается проверка живости с разными уровнями: отдельно недоступность процесса, отдельно деградация внешней модели, отдельно переполнение очереди. Это позволяет не гнать трафик на резерв из-за короткого сетевого сбоя.
Обратная совместимость держит внедрение без остановки. Внешние системы продолжают обращаться по прежним адресам и форматам ответов — меняется только то, что за точкой входа теперь стоит несколько экземпляров. Новые поля добавляем, старые не удаляем до конца перехода, а различия в версиях поведения фиксируем явно, чтобы вызывающая сторона не зависела от того, какой экземпляр ответил.
Сам план миграции строится по шагам: сначала резерв поднимается в теневом режиме и обрабатывает копию трафика, затем на него уходит небольшая доля реальных запросов, и только после этого переключение становится полным. Точка отката остаётся доступной на каждом шаге — пока резерв не подтвердил поведение на реальной нагрузке, основной экземпляр не выводится из работы. Так переводим без простоя и с предсказуемым поведением при отказе.
Технические сомнения: частые вопросы по отказоустойчивости
Большинство сомнений по отказоустойчивости агентов сводится к одному: как система отличает настоящий сбой от краткого замедления и не переключается ли раньше, чем это нужно. Ниже — ответы на вопросы, которые чаще всего задают инженеры перед запуском.
Как быстро происходит переключение и что видит пользователь в этот момент?
Контроль состояния идёт по нескольким независимым признакам: доступность ответа, время отклика, доля ошибок на скользящем окне запросов. Порог переключения задаётся не по одному сбою, а по серии неудачных проверок подряд, поэтому резерв подхватывает работу за секунды, а не дёргается на случайном таймауте. Незавершённые запросы ставятся в очередь и повторяются на резерве, дублирование операций исключено.
Как вы боретесь с ложными срабатываниями?
Причина ложных срабатываний обычно в одном: порог выставлен по одному признаку. Мы разводим временные сетевые задержки и отказы самого агента, вводим разные пороги для разных типов проверок и требуем подтверждения сбоя с двух точек наблюдения. Если узел отвечает медленнее обычного, но корректно, переключения не будет — только отметка в журнале.
Что если резерв тоже недоступен?
Тогда срабатывает деградация, а не отказ: агент отвечает по упрощённому сценарию или отдаёт заранее подготовленный ответ, а событие фиксируется с полным контекстом. Передача в поддержку идёт автоматически — с историей проверок, состоянием узлов и последними запросами, чтобы дежурный начал разбор, а не сбор данных.
Обсудим задачу: разберём ваш контур и вернёмся с оценкой
Чтобы вернуться с планом работ и оценкой сроков, а не с общими обещаниями, нам достаточно понять ваш контур: какие агенты работают, что уже отказывало и что критично не потерять при переключении на резерв. Чем конкретнее исходные данные, тем точнее оценка — по этапам, а не «в целом по проекту».
Что вы получаете по итогам обсуждения задачи:
- разбор текущего контура: где агенты теряют состояние при отказе модели, узла или внешней интеграции;
- схему отказоустойчивой конфигурации — резервные исполнители, правила автозамены, пороги деградации;
- план работ по этапам: порядок внедрения, точки проверки, зависимости между шагами;
- оценку сроков и состава команды под вашу нагрузку и требования к доступности;
- перечень исходных данных и доступов, которые понадобятся для старта проекта;
- регламент эксплуатации: как фиксируются сбои, кто и по какому признаку запускает переключение;
- критерии приёмки — что считаем успешным восстановлением, а что поводом для отката.
Опишите задачу в свободной форме: где живут агенты, какой сбой мешает сильнее всего, какой запас по отказам нужен. Мы разберём ваш контур, назовём риски и вернёмся с планом работ, оценкой сроков и предложением по старту проекта — дальше вы решаете, подходит ли он по объёму и приоритетам.
