Агент сломал production. Что писать в postmortem?

Допустим, AI-агент изменил конфигурацию, запустил не ту команду или удалил данные. Production лежит.

Самый бесполезный вывод такого расследования:

«Модель ошиблась».

Это примерно как написать в RCA «разработчик ошибся» и гордо закрыть инцидент.

В обычном postmortem мы спрашиваем:

— что произошло; 
— почему защита не сработала; 
— как предотвратить повтор.

Для инцидента с AI этого недостаточно. Нужно восстановить всю цепочку принятия решения.

Какой контекст получил агент? 
Были ли в нём актуальные данные, ограничения и состояние системы?

Какие инструкции ему дали? 
Не допускали ли они несколько трактовок? Было ли явно сказано, чего делать нельзя?

Какой инструмент позволил выполнить опасное действие? 
Зачем агенту вообще был доступен production, удаление данных или запуск команд без ограничений?

Где должна была сработать проверка? 
Перед генерацией решения, перед выполнением команды или после изменения?

Можно ли было проверить результат автоматически? 
Например, через dry run, тест, diff, health-check или откат.

Почему человек одобрил изменение? 
Он увидел понятный diff и оценил последствия — или просто нажал Approve, потому что «AI обычно справляется»?

Root cause почти никогда не находится внутри модели.

Обычно он находится в системе вокруг неё:

— слишком широкие права; 
— недостаточный контекст; 
— неоднозначные инструкции; 
— отсутствие проверок; 
— непрозрачный результат; 
— формальное человеческое одобрение.

AI-инциденты не требуют отказаться от агентов. Они требуют проектировать их как потенциально ошибающихся участников процесса.

Хороший postmortem отвечает не на вопрос «почему AI ошибся?», а на вопрос «почему одна ошибка смогла дойти до production и причинить ущерб?».

Идемпотентность: что произойдёт, если запрос придёт дважды

Пользователь нажал кнопку «Оплатить».

Ответ не пришёл.

Он нажал ещё раз.

А сеть решила тоже поучаствовать и повторила первый запрос.

Что должно произойти?

Правильный ответ обычно не такой:

«Будем надеяться, что второй запрос не успеет».

Для таких ситуаций существует идемпотентность.

Если упростить, идемпотентная операция при повторном выполнении приводит систему к тому же конечному состоянию, что и при первом.

Это особенно важно там, где повтор стоит дорого:

— списание денег; 
— создание заказа; 
— начисление бонусов; 
— отправка сообщения; 
— обработка события из очереди.

Например, клиент отправляет запрос на создание платежа вместе с Idempotency-Key.

Сервис получает ключ, выполняет операцию и сохраняет результат.

Если запрос с тем же ключом приходит повторно, сервис не создаёт ещё один платёж, а возвращает результат уже выполненной операции.

Звучит просто.

Но дальше начинается архитектура.

Нужно решить:

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

Например, недостаточно просто записать ключ после списания денег.

Сервис может успеть провести платёж, упасть до сохранения ключа, а после повтора провести платёж ещё раз.

Поэтому идемпотентность — это не заголовок в HTTP-запросе. Это согласованность ключа, состояния операции и её результата.

Особенно заметна эта проблема в распределённых системах.

Клиент повторяет операцию после тайм-аута.

Сеть повторно доставляет запрос.

Consumer получает одно событие несколько раз.

Формально хочется доставки «ровно один раз». Фактически обеспечить её по всей цепочке обычно намного сложнее, чем нарисовать на архитектурной диаграмме.

Поэтому хорошая система строится не вокруг надежды:

«Сообщение придёт один раз».

А вокруг гарантии:

«Если оно придёт ещё раз, ничего страшного не произойдёт».

Мы не пытаемся сделать распределённую систему идеальной.

Мы проектируем её так, чтобы ожидаемые сбои были безопасными.

AI может делать пять задач параллельно. Это не значит, что нужно запускать пять

AI-агенты почти убрали ограничение на скорость старта работы.

Человеку нужно разобраться в задаче, освободить время, переключить контекст. Агенту достаточно выдать ещё один промпт.

И вот уже через пару часов:

— открыто пять PR; 
— три ждут ревью; 
— два меняют одни и те же файлы; 
— один устарел ещё до проверки; 
— человек физически успевает нормально посмотреть только один.

Агент не ускорил поставку. Он просто быстрее создал очередь незавершённой работы.

Мы привыкли обсуждать WIP-лимиты как способ защитить разработчиков от многозадачности. С AI появляется другая причина: защищать нужно систему проверки.

У команды ограничена не только скорость написания кода. Ограничены ревью, тестирование, продуктовая проверка и способность принимать решения.

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

Если команда может качественно проверить два изменения в день, десять параллельных агентов не дадут десятикратного ускорения. Они дадут восемь лишних PR в очереди.

Я бы начал с простых правил:

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

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

WIP-лимит нужен не только людям. Он нужен системе проверки.