Практическое руководство по реагированию на инциденты в агентных системах¶

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

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

1. Что считать инцидентом¶

Для агентной системы инцидентом обычно считаются не только отказ и деградация, но и такие события:

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

2. Первые 15 минут¶

В первые минуты цель не в полном анализе первопричины, а в том, чтобы ограничить ущерб и сохранить доказательства.

Минимальный порядок обычно такой:

Остановить или сузить рискованную цепочку.
Зафиксировать трассу и контекст сессии.
Понять, есть ли внешнее побочное действие.
Проверить, нужно ли отключать возможность, субъект или соединитель.
Зафиксировать, какой набор артефактов и какая волна поэтапного выпуска были активны во время инцидента.

3. Что нужно сохранить сразу¶

Если эти артефакты не сохранить в первые минуты, разбор инцидента быстро превращается в восстановление по памяти:

trace_id
session_id
agent_id
tool_principal
approval_id, если была цепочка подтверждения;
bundle_id
change_id
rollout_wave
события решений политики;
события решений по подтверждению;
записи памяти, которые были прочитаны или изменены;
сведения о allowed_egress и фактическом сетевом пути.

4. Быстрые действия по сдерживанию¶

Хорошее реагирование опирается на заранее подготовленные действия сдерживания:

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

Если таких действий нет, реагирование на инцидент становится спором о том, кто имеет право быстро что-то выключить.

5. Минимальная схема триажа¶

Полезно сразу отнести инцидент к одной из категорий:

policy_bypass
unauthorized_side_effect
dangerous_egress
memory_contamination
approval_failure
eval_escape
agentic_misalignment

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

Путь реагирования на дубль тикета

Для сквозного инцидента в триаже обращений поддержки сначала заморозь create_ticket или переведи его в обязательное подтверждение, сохрани trace_id, session_id, approval_id, tool_principal, idempotency_key, bundle_id и rollout_wave, затем проверь, было ли побочное действие уже создано. Если статус неизвестен, пометь запуск как side_effect_unknown, не повторяй запись вслепую и преврати разбор в шлюз оценки и поэтапного выпуска перед следующим выпуском.

Канонические сценарии реагирования

Реагирование на инцидент должно выбирать разные пути сдерживания для трех канонических сценариев. Триаж обращений поддержки сначала замораживает записывающую возможность, сохраняет доказательства подтверждения, idempotency_key, статус побочного эффекта и волну поэтапного выпуска. Внутренний ассистент знаний сначала ограничивает область поиска, приостанавливает записи в память, сохраняет происхождение источников, доказательства границы арендатора и решение контроля доступа. Координация инцидентов сначала фиксирует статус эскалации, побочные эффекты уведомлений, владение ответом, состояние передачи управления и то, кто является владельцем экстренного отката.

6. Что проверить в трассах и событиях¶

Во время первичного разбора важно быстро ответить на несколько вопросов:

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

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

7. Когда нужен откат, а когда локальное исправление¶

Не каждый инцидент требует полного отката. Но полагаться на локальное исправление можно только тогда, когда:

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

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

8. Что должно попасть в разбор инцидента¶

Полезный разбор инцидента в агентной системе обычно включает:

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

Хороший разбор заканчивается не только документом, но и обновлением артефактов жизненного цикла.

9. Что сделать сразу¶

Сначала пройди по короткому списку и отдельно отметь все ответы «нет»:

Можно ли быстро отключить одну возможность?
Можно ли восстановить цепочку trace -> session -> bundle -> rollout wave?
Понятно ли, какой субъект сделал внешний вызов?
Видно ли цепочку подтверждения и ее решение?
Можно ли временно остановить записи в память?
Есть ли владелец у действий сдерживания?
Возвращаются ли инциденты обратно в оценки и шлюзы поэтапного выпуска?