Production agent operations: launch, control, incidents and postmortems

Production-ready агент — это не «модель хорошо отвечает в демо». Это система, у которой закрыты организационные и технические пункты, и каждый проверяется буквально, а не «в целом да»:

• Владелец: конкретный человек/команда, отвечающие за агента, с полномочиями его остановить. «Агент общий» = «агент ничей».
• SLO и метрики: качество (онлайн-eval score), latency p95, error rate, cost per day — с дашбордом и порогами, а не «посмотрим по ощущениям».
• Runbook: письменная инструкция on-call — как диагностировать, как деградировать, как остановить (следующий раздел).
• Kill switch: проверенный, срабатывающий за секунды, доступный on-call без эскалаций.
• Audit trail: append-only журнал действий, включая отклонённые (урок про безопасность).
• Бюджет с жёстким потолком: дневной лимит расходов на модель, при достижении — деградация или остановка, а не сюрприз в счёте.
• Approval-петля для рискованных действий и человек, который реально её разбирает: очередь подтверждений, которую никто не смотрит, — это театр безопасности.
• Проверенные границы: red-team прогон инъекций и лимитов пройден на текущей версии.

Простой тест на честность: если некому нажать стоп в три часа ночи в субботу — агент не production-ready, какими бы ни были его метрики качества. Автономность агента без операционной обвязки — это не автоматизация, а неуправляемый процесс с правами в ваших системах.

Этот чеклист — ворота: он проходится до выдачи агенту прав на реальные действия, и повторно — при каждом расширении этих прав.

У агента больше движущихся частей, чем у обычного сервиса: промпты, версии моделей, схемы инструментов, retrieval-конфигурация, пороги маршрутизации. Правило номер один: всё это — версионируемые артефакты в git, а изменение любого из них — релиз, проходящий полный путь. «Быстро подкрутили промпт в проде» — самый частый источник инцидентов вида «вчера работало».

Путь релиза:

1. Dev: изменение в ветке, ревью diff-а промпта наравне с ревью кода.
2. Offline eval gate в CI: golden set, включая red-team кейсы; регрессия блокирует мерж (урок про evals).
3. Staging: агент с реальными инструментами, направленными на sandbox-окружения (тестовая CRM, почтовый ящик-ловушка). Здесь проверяется то, чего не видит offline-набор: реальные тайминги инструментов, ошибки интеграций, поведение цикла на живых данных.
4. Canary в prod: доля трафика или ограниченный сегмент пользователей, с включённой approval-петлёй даже для действий, которые планируется автоматизировать — первые недели человек подтверждает и попутно размечает качество решений агента. Это дешёвый способ набрать доверие и данные одновременно.
5. Постепенное расширение автономии: снятие approval с классов действий — по накопленной статистике (например, 98%+ одобрений без правок за две недели), а не по нетерпению.

Rollback — переключение на предыдущую версию артефакта за секунды, потому что предыдущая версия никуда не удалялась. Если откат требует «вспомнить, какой был промпт», у вас нет отката. Каждый ответ агента в проде несёт версии всех артефактов в trace — иначе инциденты нельзя привязать к релизам.

Алерты для агента строятся по симптомам, а не по причинам — причин много, симптомов мало. Минимальный набор:

• Рост доли ошибок tool calls (интеграция сломалась или агент стал генерировать невалидные вызовы).
• Рост доли провалов валидации вывода / repair rate (деградация модели или промпта).
• Всплеск отклонённых approvals (агент стал предлагать плохие действия — самый тревожный сигнал).
• Латентность p95 и глубина очереди approvals (люди не успевают разбирать — агент фактически стоит).
• Скорость расхода бюджета (зацикливание или всплеск трафика).
• Онлайн-eval score на выборке ответов (тихая деградация качества).

Runbook пишется до инцидента и отвечает на три вопроса без размышлений в три ночи:

1. Как диагностировать: где дашборд, как найти trace по жалобе, как отличить «сломалась интеграция» от «деградировала модель» (подсказка: по error-типам tool calls).
2. Как деградировать частично: перевести агента в suggest-only режим (готовит действия, но всё через approval), отключить конкретный инструмент, переключить на резервную модель. Частичная деградация почти всегда лучше полной остановки — сервис живёт, риск снят.
3. Как остановить полностью: kill switch, что произойдёт с задачами в полёте, куда пойдут пользователи, как сохраняется журнал.

Эскалация должна называть роли и сроки: on-call инженер (минуты) → владелец агента (если причина не найдена за 30 минут) → владелец бизнес-процесса (если затронуты клиенты или деньги). Отдельно — правило для approvals: если очередь подтверждений не разбирается, действия по таймауту отклоняются, не одобряются. Тишина — это «нет».

Инциденты с агентами будут — вопрос не «если», а «насколько быстро вы учитесь». Порядок реакции: стоп-кран по runbook (suggest-only или полная остановка) → фиксация traces и журнала → оценка масштаба по audit trail: что агент реально сделал, какие действия прошли, какие были отклонены, затронуты ли данные или деньги → коммуникация затронутым → и только потом спокойный разбор.

Postmortem обязательно blameless: вопрос всегда «какая дыра в системе это позволила», never «кто виноват». Причина прагматичная: в системе с LLM корневая причина почти никогда не «человек ошибся» — это промпт, допускающий трактовку, инструмент без лимита, отсутствующий eval-кейс, слишком рано снятый approval. Поиск виноватых гарантирует, что следующий инцидент будут скрывать до последнего.

Структура документа: timeline из audit trail (когда началось, когда заметили, когда остановили — разрыв «началось → заметили» сам по себе метрика зрелости мониторинга); корневая причина через цепочку «почему» до системного уровня; и action items трёх обязательных типов:

1. Guard: новый лимит, суженный scope, allowlist, изменение схемы инструмента — архитектурная защита, а не «поправили формулировку в промпте».
2. Eval-кейс: сценарий инцидента добавлен в golden set / red-team набор и с этого момента гоняется на каждом релизе.
3. Обновление runbook/алертов: если инцидент заметили позже, чем могли, — какой сигнал должен был сработать.

Критерий закрытия жёсткий: инцидент закрыт, когда регрессионный тест, воспроизводящий сценарий, зелёный на текущей версии — не когда «починили и вроде работает». Через пару кварталов такой петли red-team набор агента становится главным активом его надёжности: это конденсированная история всех способов, которыми он ломался, прогоняемая на каждый релиз.