В июне 2023 года у OpenAI случился масштабный сбой. ChatGPT и API были недоступны несколько часов. Компании, которые встроили GPT в критичные процессы, оказались в интересной ситуации: чат-боты молчали, автоматические ответы не отправлялись, скоринг-модели не работали. У кого был план B — пережили это с минимальными потерями. У кого не было — узнали, что такое зависимость от внешнего сервиса.

Это не страшилка — это реальность. Любой AI-сервис может стать недоступным. Внешние API падают. Локальные модели сбоят. Сети ломаются. И вопрос не «случится ли это», а «когда случится и будете ли вы готовы».

В этой статье разберём, как построить resilient AI-систему: что делать до сбоя (подготовка), во время (реагирование) и после (восстановление и улучшение).

Почему AI может стать недоступным

Для начала поймём, от чего защищаемся.

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

Если вы используете внешний API (OpenAI, Anthropic, Yandex GPT, GigaChat), он может упасть. Инфраструктурные проблемы на их стороне. Перегрузка при пиковых нагрузках. Плановые и внеплановые обновления.

Частота: редко, но случается. Длительность: от минут до часов.

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

Проблемы на пути между вами и провайдером. DDoS-атака на вас или на промежуточные узлы. Проблемы у вашего интернет-провайдера. Блокировки (особенно актуально для зарубежных сервисов в отдельных странах и регионах).

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

Вы исчерпали rate limits. Закончился бюджет на API. Аккаунт заблокирован из-за нарушения политик (или ошибки на стороне провайдера).

Проблемы с локальными моделями

Если модель развёрнута у вас — свои причины сбоев. Hardware failure (особенно GPU). Out of memory при пиковой нагрузке. Баги в инференс-сервере. Неудачное обновление модели.

Деградация качества

Это не полная недоступность, но тоже проблема. Модель работает, но отвечает плохо. После обновления изменилось поведение. Галлюцинации участились. Такие случаи тоже требуют fallback.

Принцип graceful degradation

Ключевой принцип resilience — graceful degradation: постепенная деградация функциональности вместо полного отказа.

Идея: если AI недоступен, система продолжает работать, пусть с ограниченной функциональностью. Лучше простой ответ, чем никакого. Лучше эскалация на человека, чем тупик. Лучше базовая автоматизация, чем остановка процесса.

Примеры graceful degradation:

Чат-бот: LLM недоступна → rule-based бот отвечает на простые вопросы, сложные — на оператора.

Скоринг: AI-модель недоступна → fallback на простые эвристики или ручной review.

Генерация контента: AI недоступен → использование шаблонов или отложенная генерация.

Резервные сценарии: от «лучшего» к «хоть какому-то»

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

Переключение на другого AI-провайдера

Самый незаметный для пользователя вариант. OpenAI упал — переключились на Anthropic. Yandex GPT недоступен — пошли в GigaChat. Облако сбоит — запустили локальную модель.

Звучит просто, но есть подвох: разные модели ведут себя по-разному. Промпт, идеально работающий на GPT-4, может давать странные результаты на Claude. Поэтому нужны заранее протестированные адаптеры и credentials, которые не протухли.

Переход на упрощённую модель

Если даже альтернативный провайдер недоступен, можно пожертвовать качеством ради доступности. GPT-4 заменяем на GPT-3.5. Большую модель — на маленькую локальную. Полноценный LLM — на классификатор с шаблонами.

Клиент получит ответ попроще, но получит. Это лучше, чем таймаут.

Старый добрый rule-based бот

Помните ботов до эпохи LLM? Keyword matching, деревья решений, жёстко прописанные скрипты. Никакого «интеллекта», зато работает без внешних зависимостей. Для топ-20 самых частых вопросов этого достаточно.

Передача живому человеку

Когда автоматика не справляется — честно признаёмся и зовём оператора. «Извините, я сейчас не могу ответить. Наш специалист свяжется с вами через 5 минут». Главное — чтобы этот специалист действительно был готов и знал контекст.

Очередь на потом

Для задач, которые могут подождать: email-ответы, ночная аналитика, batch-обработка документов. Складываем в очередь, обрабатываем когда AI вернётся. Для real-time чата не годится, но для многих сценариев — вполне.

Архитектура resilient AI-системы

Как технически реализовать fallback?

Circuit breaker pattern

Паттерн из микросервисной архитектуры, отлично работающий для AI.

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

Состояния circuit breaker: Closed — нормальная работа, запросы идут в AI. Open — AI считается недоступным, запросы идут в fallback. Half-open — проверочный режим, часть запросов идёт в AI для теста.

Параметры: порог ошибок для переключения в Open (например, 5 ошибок за 30 секунд), время ожидания перед переходом в Half-open, количество успешных запросов для возврата в Closed.

Retry with backoff

При временных сбоях — повторные попытки с нарастающими интервалами.

Пример: первая попытка — сразу, вторая — через 1 секунду, третья — через 4 секунды, четвёртая — через 16 секунд. Если все неуспешны — fallback.

Важно: не retry'ить бесконечно, это создаёт нагрузку на и так перегруженный сервис.

Timeout management

Таймауты должны быть разумными. Слишком короткий — много false negative (сервис работает, но медленно). Слишком длинный — пользователь ждёт.

Типичные значения: для real-time чата — 5-10 секунд, для background task — 30-60 секунд, для batch — можно больше.

Health checks

Регулярная проверка доступности AI-сервисов.

Passive: анализ ответов на реальные запросы. Если много ошибок — алерт.

Active: отдельные проверочные запросы (ping/health endpoint). Не нагружают сервис, дают быструю индикацию.

Пример реализации: чат-бот с fallback

Рассмотрим конкретный пример архитектуры.

Нормальный режим

User Message → Input Filter → OpenAI GPT-4 → Output Filter → Response

С fallback

User Message → Input Filter → [Circuit Breaker]
    ↓ (Closed: AI доступен)
    OpenAI GPT-4 → Output Filter → Response

    ↓ (Open: AI недоступен)
    Fallback Layer:
      1. Попробовать Anthropic Claude (если настроен)
      2. Если недоступен → Rule-based Bot
      3. Если не справился → Эскалация на оператора

Код (pseudo-code)

async def get_bot_response(user_message):
    # Попытка основного AI
    if circuit_breaker.is_closed():
        try:
            response = await openai_api.call(user_message, timeout=10)
            circuit_breaker.record_success()
            return response
        except (Timeout, APIError) as e:
            circuit_breaker.record_failure()
            log.warning(f"Primary AI failed: {e}")

    # Fallback 1: альтернативный провайдер
    if anthropic_enabled:
        try:
            response = await anthropic_api.call(user_message, timeout=10)
            return response
        except Exception as e:
            log.warning(f"Secondary AI failed: {e}")

    # Fallback 2: rule-based
    rule_response = rule_based_bot.try_answer(user_message)
    if rule_response:
        return rule_response

    # Fallback 3: эскалация
    create_support_ticket(user_message)
    return "Извините, я сейчас не могу ответить. Наш специалист свяжется с вами в ближайшее время."

Подготовка к сбоям: checklist

Что нужно сделать заранее?

Инвентаризация зависимостей

Какие AI-сервисы используются? Для каких функций? Какова критичность каждой функции?

Составьте карту зависимостей: функция → AI-сервис → критичность → требуемый fallback.

Настройка альтернативных провайдеров

Если основной — OpenAI, заведите аккаунт в Anthropic или другом. Протестируйте промпты на альтернативе. Убедитесь, что качество приемлемое. Держите credentials актуальными.

Разработка rule-based fallback

Определите top-20 самых частых запросов. Напишите для них шаблонные ответы. Настройте keyword matching или простой классификатор. Это покроет значительную часть нагрузки.

Подготовка команды операторов

Кто будет обрабатывать эскалации? Знают ли они контекст (что бот обычно делает)? Есть ли процесс передачи диалога?

Обучите операторов и проведите учебную тревогу.

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

Настройте: мониторинг доступности AI-сервисов, алерты на деградацию (рост latency, ошибок), дашборд для real-time видимости.

Кто получает алерты? Что делать при получении? Документируйте runbook.

Тестирование

Chaos engineering для AI: искусственно отключите основной провайдер и проверьте, как работает fallback. Сделайте это до того, как реальный сбой проверит вас.

Что делать, когда всё упало

Вот сценарий, который стоит иметь под рукой.

Сначала — убедиться, что проблема реальная. Ложные срабатывания случаются. Проверьте status page провайдера, попробуйте запрос вручную, посмотрите — это у всех так или у отдельных пользователей.

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

Включить резервный режим. В идеале circuit breaker сделает это сам. Если нет — ручками. И сразу проверить, что fallback действительно отвечает.

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

Следить за восстановлением. Периодически тыкайте основной сервис тестовыми запросами. Когда заработает — возвращайтесь постепенно, не всем трафиком сразу.

После — разбор полётов. Что сломалось, как отреагировали, что можно было сделать лучше. Без этого шага вы будете наступать на одни и те же грабли.

Метрики resilience

Как измерить, насколько система устойчива?

MTBF (Mean Time Between Failures) — среднее время между сбоями. Показывает надёжность.

MTTR (Mean Time To Recovery) — среднее время восстановления. Показывает, как быстро возвращаемся к норме.

Availability — процент времени, когда сервис доступен. 99.9% = ~8 часов downtime в год.

Degraded time — время работы в режиме fallback. Система работает, но не оптимально.

Fallback success rate — процент запросов, успешно обработанных в fallback-режиме.

Особые случаи

Критичные системы

Для систем, где сбой недопустим (безопасность, здоровье, финансы), требования выше.

Рассмотрите: избыточность (несколько независимых AI-систем параллельно), локальный backup (модель на своём железе как последний рубеж), человек как обязательный элемент (не полностью автономные решения).

Геораспределённые системы

Если пользователи в разных регионах — сбой может быть локальным. Используйте региональные endpoints провайдеров. Настройте geo-aware routing. Fallback может включать переключение на другой регион.

Batch vs Real-time

Для batch-процессов стратегия другая. Можно подождать — ставим в очередь. Можно частично обработать — обрабатываем, что можем, остальное откладываем. Deadline более гибкий.

Стоимость resilience

Resilience не бесплатна. Затраты включают:

Дополнительные провайдеры — если держите backup в Anthropic, платите за аккаунт (даже если почти не используете).

Разработка fallback — время на создание rule-based бота, адаптацию промптов.

Инфраструктура — мониторинг, алертинг, логирование.

Тестирование — chaos engineering, учебные тревоги.

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

Вопрос: оправданы ли эти затраты? Зависит от стоимости downtime. Если час простоя чат-бота стоит $10,000 в потерянных продажах — инвестиции в resilience окупаются быстро. Если бот — minor feature с малым трафиком — может быть достаточно простого fallback.

Итог

AI-системы падают. Вопрос не в этом — вопрос в том, будете ли вы готовы.

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

Начните с простого: разберитесь, какие AI-функции у вас критичные, а какие могут подождать. Для критичных — полный набор fallback-сценариев. Для остальных — хватит базового.

И главное: план B, который ни разу не тестировали — это не план. Это надежда. А надежда — плохая стратегия для продакшена.