EN Написать
← Назад к блогу
Серия: Почему AI-проекты проваливаются · Статья 4

Что делать, когда AI-агент «упал»: архитектура отказоустойчивости

Анатолий Лапков · январь 2025 г. · 12 мин чтения

Понедельник, 9 утра. Начало рабочей недели.

API OpenAI лёг. Или лимиты закончились. Или интернет в офисе пропал на час.

Что делает AI-агент? Правильно — ничего.

А процесс, который он обслуживал, встаёт. Заявки копятся. Договоры не согласовываются. Клиенты ждут.

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

Реальные сценарии сбоев

За год работы с AI-агентами я собрал коллекцию того, что может пойти не так.

Сбои провайдера LLM:

  • OpenAI: 2-3 крупных сбоя в год, плюс периодические замедления
  • Anthropic: реже, но бывает
  • GigaChat: стабильнее, но тоже не без проблем

Сетевые проблемы:

  • Интернет в офисе
  • Проблемы с DNS
  • Блокировки (привет, РКН)

Лимиты и квоты:

  • Закончились токены
  • Rate limiting
  • Превышен бюджет

Проблемы с данными:

  • Недоступна база знаний
  • Упала CRM, из которой агент берёт данные
  • Сломалась интеграция с почтой

Внутренние ошибки:

  • Баг в коде агента
  • Некорректные данные на входе
  • Бесконечный цикл

Каждый из этих сценариев может парализовать работу. И каждый нужно обработать.

Принципы отказоустойчивости

1. Graceful degradation

Система должна деградировать плавно, а не падать полностью.

Если основной LLM недоступен — переключаемся на резервный. Если резервный тоже недоступен — откладываем задачу в очередь. Если очередь переполнена — эскалируем на человека.

Каждый уровень деградации сохраняет какую-то функциональность.

Пример для согласования договоров:

Уровень 0 (норма): Агент работает, согласует автоматически
Уровень 1: Основной LLM недоступен → переключение на резервный
Уровень 2: Все LLM недоступны → задачи в очередь, уведомление оператору
Уровень 3: Очередь > 50 задач → эскалация руководителю, ручной режим
Уровень 4: Критический сбой → полная остановка, аварийное уведомление

2. Circuit breaker

Если сервис начал сбоить — временно прекращаем к нему обращаться.

Зачем? Чтобы не тратить время на заведомо неудачные запросы. Чтобы не усугублять проблемы перегруженного сервиса.

Как работает:

Состояния:
— Closed (норма): запросы идут как обычно
— Open (сбой): запросы не отправляются, сразу возвращаем ошибку
— Half-open (проверка): пропускаем один запрос, смотрим результат

Переходы:
— Closed → Open: 5 ошибок подряд
— Open → Half-open: через 60 секунд
— Half-open → Closed: успешный запрос
— Half-open → Open: неуспешный запрос

3. Retry with backoff

Если запрос не прошёл — повторяем. Но с умом.

Не сразу, а с увеличивающейся задержкой. Не бесконечно, а ограниченное число раз.

Типичная схема:

Попытка 1: сразу
Попытка 2: через 1 секунду
Попытка 3: через 2 секунды
Попытка 4: через 4 секунды
Попытка 5: через 8 секунд
После 5 попыток: отказ, эскалация

4. Fallback LLM

Резервный провайдер LLM. Если OpenAI лёг — используем Anthropic. Или GigaChat. Или локальную модель.

Важно: fallback должен быть протестирован заранее. Нельзя в момент сбоя узнать, что резервная модель не понимает ваши промпты.

5. Persistent queue

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

Когда сервис восстановится — обработаем накопившееся.

Мониторинг и алерты

Отказоустойчивая архитектура бесполезна без мониторинга. Нужно знать, что что-то пошло не так.

Что мониторить:

  1. Доступность внешних сервисов (LLM API, интеграции)
  2. Латентность запросов (резкий рост — признак проблем)
  3. Процент ошибок (выше порога — алерт)
  4. Размер очереди (растёт — не успеваем обрабатывать)
  5. Уровень деградации (на каком мы сейчас)

Кому алертить:

  • Уровень 1 (переключение на резервный): инженеру в Slack
  • Уровень 2 (очередь): оператору + инженеру
  • Уровень 3 (ручной режим): руководителю
  • Уровень 4 (критический сбой): всем + SMS

SLA для AI-системы

У любой production-системы должен быть SLA. AI-агент — не исключение.

Пример SLA:

Доступность: 99.5% (не более 3.6 часов простоя в месяц)
Время ответа: 95% запросов < 30 секунд
Время восстановления: < 15 минут для уровней 1-2, < 1 час для уровня 3
Потеря данных: 0 (все задачи сохраняются в очереди)

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

99% доступности — это 7 часов простоя в месяц. Можно обойтись базовым мониторингом.

99.9% — это 43 минуты в месяц. Нужен дежурный инженер, автоматическое переключение, резервирование.

99.99% — это 4 минуты в месяц. Нужна распределённая архитектура, мульти-регион, автоматическое восстановление.

Для большинства бизнес-процессов 99.5% достаточно. Но это нужно зафиксировать явно.

Чеклист вопросов подрядчику

Если вам внедряют AI-агента — задайте эти вопросы:

  1. Что произойдёт, если API провайдера LLM станет недоступен?
  2. Есть ли резервный провайдер? Протестирован ли он?
  3. Как система обрабатывает таймауты?
  4. Где хранятся задачи, которые не удалось обработать?
  5. Как я узнаю, что система деградировала?
  6. Какой SLA вы гарантируете?
  7. Что происходит при превышении лимитов?
  8. Как выглядит процедура восстановления после сбоя?

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

Типичные ошибки

1. «У нас стабильный интернет»

Интернет стабилен, пока не станет нестабильным. Провайдер LLM стабилен, пока не ляжет. Murphy’s law никто не отменял.

2. «Добавим резервирование потом»

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

3. «Мониторинг не нужен, мы и так увидим»

Не увидите. Особенно если сбой в 3 ночи. Или если деградация плавная. Или если все смотрят в другую сторону.

4. «Один провайдер LLM достаточно»

Монополия — это риск. OpenAI может поменять цены, ограничить доступ, изменить API. Или просто лечь в неподходящий момент.

Сколько это стоит

Отказоустойчивость — это дополнительные расходы.

Резервный LLM: +30-50% к стоимости inference (нужно тестировать на двух моделях)

Мониторинг: 50-100к на настройку + 10-20к/месяц на инфраструктуру

Очередь и хранилище: зависит от объёмов, обычно 5-10к/месяц

Время инженера на поддержку: 10-20% от времени разработки

В сумме: +10-15% к бюджету проекта.

Это не траты. Это страховка. Стоимость одного серьёзного сбоя обычно превышает эти расходы.

Выводы

AI-агент в продакшене должен быть отказоустойчивым. Это не опция, это требование.

Graceful degradation, circuit breaker, fallback LLM, persistent queue, мониторинг — это минимум.

Если интегратор не может ответить на вопросы про отказоустойчивость — ищите другого интегратора.

Подписывайтесь на канал:

Telegram @futex_ai