Каждый деплой несёт риск
Представьте команду, которая выкатывала пять изменений в неделю и ревьюила каждое. С агентом изменений становится десятки в день, а ревьюеров столько же, сколько было.
AI-агенты ускорили релизы, и сбоев стало больше. Таймауты, circuit breaker, идемпотентность и фолбэк моделей: как готовить систему к отказу.
Сэм Ньюман, автор «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 работает внутри продукта, у системы появляются три точки отказа, которых раньше не было или которые были слабее. Провайдер модели. У OpenAI, Anthropic, GigaChat и YandexGPT случаются отказы, срабатывают лимиты запросов, растёт задержка: обычный ответ приходит за 2 секунды, в час пик за 40. Система, которая ждёт ответ синхронно, в эти 40 секунд висит целиком. Интеграции. AI-агент, который проверяет остатки в 1С или обогащает карточку товара в Akeneo, зависит от этих систем.
На закрытии месяца 1С отвечает медленно, и агент передаёт эту задержку дальше по цепочке. Свежий код. Модель пишет код под «счастливый путь», если в задаче не описаны сбои. Таймауты, частичные ответы и повторная доставка сообщения в таком коде часто остаются без обработки.
Приёмы из книги известны давно. AI переводит их из разряда хорошей практики в обязательный минимум. ###
Таймауты и повторы У каждого внешнего вызова должен быть явный предел ожидания.
Повторный запрос отправляют с растущей паузой (exponential backoff) и случайным разбросом (jitter), чтобы тысяча клиентов не ударила по сервису одновременно в момент, когда он поднимается после падения. ###
Предохранитель и переборки Circuit breaker работает как автомат в электрощитке.
После серии ошибок он перестаёт слать запросы в сломанный сервис и сразу возвращает запасной ответ. Bulkhead, или переборка, выделяет каждой зависимости свой пул ресурсов: медленный поиск по каталогу забирает только свои потоки и не трогает потоки оформления заказа. ### Идемпотентность
Операция идемпотентна, если её повтор не меняет результат.
Сообщение «списать оплату» с уникальным ключом можно доставить дважды, а деньги спишутся один раз.
Без идемпотентности каждый повтор запроса рискует создать дубль заказа.
В проектах KT.Team мы закладываем эти приёмы в архитектуру с первого спринта.
Встраивать их в работающую систему после первой аварии дольше и дороже.
Вызовы моделей идут через LLM & Security Gateway.
Шлюз держит таймауты и лимиты, считает токены и переключает запрос на резервную модель: если Claude не ответил за отведённое время, шлюз отправляет запрос в Qwen или GigaChat.
Задачи с персональными данными шлюз маршрутизирует только в российский контур.
Приложение про этот выбор ничего не знает и просто получает ответ.
Обмен с учётными системами мы строим через очередь: Apache Kafka или шину Datareon.
Если 1С недоступна полчаса, сообщения ждут в очереди, а сайт продолжает принимать заказы.
Потребители сообщений идемпотентны, поэтому повторная доставка не создаёт дублей. В AI-native development код пишет агент, а в прод его пропускают гейты: автотесты, канареечный релиз на малую долю трафика и автоматический откат при росте ошибок.
Скорость даёт агент, а до клиентов доходят только коммиты, прошедшие гейты.
Выпишите внешние зависимости вашей системы: модели, 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.