AI ускорил релизы. Теперь система должна переживать сбои

AI-агенты ускорили релизы, и сбоев стало больше. Таймауты, circuit breaker, идемпотентность и фолбэк моделей: как готовить систему к отказу.

  • Больше изменений - больше аварий
  • Где ломается система с AI внутри
  • Что Ньюман предлагает сделать до аварии
  • Как мы закладываем это в AI-интеграции

Повод

Сэм Ньюман, автор «Building Microservices», выпустил книгу «Building Resilient Distributed Systems» и обсудил её с Гергеем Оросом в подкасте The Pragmatic Engineer. Главная тема разговора: AI-агенты пишут больше кода, команды чаще выкатывают изменения, и по наблюдению собеседников инцидентов в проде становится больше. Моя мысль такая: бизнес выигрывает от ускорения разработки с AI, только если его система заранее умеет переживать сбои.

Если не умеет, часы, сэкономленные на разработке, компания теряет на простоях.

Больше изменений - больше аварий

Каждый деплой несёт риск

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

Ревьюер пропускает код быстрее, чем успевает в нём разобраться. Это видно в данных.

Команда DORA в Google в отчёте Accelerate State of DevOps 2024 посчитала: рост использования AI на 25% связан с падением стабильности поставки на 7,2% и пропускной способности на 1,5%.

Стабильность в DORA складывается из двух метрик: доли изменений, после которых случился сбой, и времени восстановления. В опросах разработчики отмечают рост личной продуктивности, при этом метрики продакшена у тех же команд ухудшаются.

Для руководителя вывод простой: AI в разработке добавляет нагрузку на эксплуатацию.

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

Где ломается система с AI внутри

Когда AI работает внутри продукта, у системы появляются три точки отказа, которых раньше не было или которые были слабее. Провайдер модели. У OpenAI, Anthropic, GigaChat и YandexGPT случаются отказы, срабатывают лимиты запросов, растёт задержка: обычный ответ приходит за 2 секунды, в час пик за 40. Система, которая ждёт ответ синхронно, в эти 40 секунд висит целиком. Интеграции. AI-агент, который проверяет остатки в 1С или обогащает карточку товара в Akeneo, зависит от этих систем.

На закрытии месяца 1С отвечает медленно, и агент передаёт эту задержку дальше по цепочке. Свежий код. Модель пишет код под «счастливый путь», если в задаче не описаны сбои. Таймауты, частичные ответы и повторная доставка сообщения в таком коде часто остаются без обработки.

Что Ньюман предлагает сделать до аварии

  1. Приёмы из книги известны давно. AI переводит их из разряда хорошей практики в обязательный минимум. ###

  2. Таймауты и повторы У каждого внешнего вызова должен быть явный предел ожидания.

  3. Повторный запрос отправляют с растущей паузой (exponential backoff) и случайным разбросом (jitter), чтобы тысяча клиентов не ударила по сервису одновременно в момент, когда он поднимается после падения. ###

  4. Предохранитель и переборки Circuit breaker работает как автомат в электрощитке.

  5. После серии ошибок он перестаёт слать запросы в сломанный сервис и сразу возвращает запасной ответ. Bulkhead, или переборка, выделяет каждой зависимости свой пул ресурсов: медленный поиск по каталогу забирает только свои потоки и не трогает потоки оформления заказа. ### Идемпотентность

  6. Операция идемпотентна, если её повтор не меняет результат.

  7. Сообщение «списать оплату» с уникальным ключом можно доставить дважды, а деньги спишутся один раз.

  8. Без идемпотентности каждый повтор запроса рискует создать дубль заказа.

Оценить, где ИИ даст эффект в вашем процессе

Как мы закладываем это в AI-интеграции

  1. В проектах KT.Team мы закладываем эти приёмы в архитектуру с первого спринта.

  2. Встраивать их в работающую систему после первой аварии дольше и дороже.

  3. Вызовы моделей идут через LLM & Security Gateway.

  4. Шлюз держит таймауты и лимиты, считает токены и переключает запрос на резервную модель: если Claude не ответил за отведённое время, шлюз отправляет запрос в Qwen или GigaChat.

  5. Задачи с персональными данными шлюз маршрутизирует только в российский контур.

  6. Приложение про этот выбор ничего не знает и просто получает ответ.

  7. Обмен с учётными системами мы строим через очередь: Apache Kafka или шину Datareon.

  8. Если 1С недоступна полчаса, сообщения ждут в очереди, а сайт продолжает принимать заказы.

  9. Потребители сообщений идемпотентны, поэтому повторная доставка не создаёт дублей. В AI-native development код пишет агент, а в прод его пропускают гейты: автотесты, канареечный релиз на малую долю трафика и автоматический откат при росте ошибок.

  10. Скорость даёт агент, а до клиентов доходят только коммиты, прошедшие гейты.

Три вопроса к каждой зависимости

Выпишите внешние зависимости вашей системы: модели, ERP, PIM, платёжный сервис, доставку. Для каждой письменно ответьте на три вопроса.

Сколько секунд мы ждём ответа, прежде чем сдаться?

Что видит пользователь, когда зависимость недоступна?

Кто узнаёт о сбое и через сколько минут

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

Вердикт

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

Источник

Gergely Orosz, «Building resilient AI-powered software, and planning for when things go wrong», The Pragmatic Engineer: интервью с

Сэмом Ньюманом о книге «Building Resilient Distributed Systems»

, https://newsletter.pragmaticengineer.com/p/building-resilient-systems. Цифры по стабильности поставки: Google DORA, Accelerate State of DevOps Report 2024.

Обсудить статью: AI ускорил релизы. Теперь система должна…

Укажите email или телефон, чтобы мы могли вам ответить.

Отправить через: