Схема записи инцидента и связи с разбором¶

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

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

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

1. Зачем нужна отдельная запись инцидента¶

Без отдельного артефакта инцидента разбор обычно распадается на несколько несвязанных кусков:

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

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

2. Базовые сущности¶

Минимальная схема обычно строится вокруг двух сущностей:

incident_record
incident_postmortem_link

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

3. Запись инцидента¶

incident_record фиксирует, что произошло, какой был радиус воздействия и какие артефакты были активны во время события.

kind: incident_record
incident_id: inc-2026-04-09-001
title: "Несанкционированный путь записи ticket_write во время вводного прогона"
severity: sev2
status: contained
category: unauthorized_side_effect
detected_at: 2026-04-09T09:14:00Z
detected_by: automated_detection
agent_id: support-triage-ref
trace_id: trace-2026-04-09-001
session_id: session-2026-04-09-001
bundle_id: bundle-2026-04-07-a
change_id: chg-2026-04-07-001
rollout_wave: canary
tool_principal: svc-ticket-writer
approval_id: apr-2026-04-09-001
idempotency_key: ticket-req-2026-04-09-001
affected_surfaces:
  - approval_path
  - tool_gateway
  - rollout_gate
containment_actions:
  - force_mandatory_approval
  - disable_ticket_write_v1
owner: platform-operations

Ключевые поля здесь такие:

category позволяет связывать инцидент с таксономией разбора и обновлениями оценок;
bundle_id, change_id и rollout_wave связывают инцидент с решением о поэтапном выпуске и его волной;
tool_principal, approval_id и idempotency_key сокращают путь до реального побочного эффекта и показывают, мог ли повтор безопасно сопоставиться с уже созданным объектом;
affected_surfaces помогает не сводить разбор к одному только ответу модели.

Запись инцидента для ветки дубля тикета

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

Канонические сценарии инцидентов

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

4. Связь инцидента с разбором¶

incident_postmortem_link связывает конкретный инцидент с исправляющими действиями и артефактами жизненного цикла.

kind: incident_postmortem_link
incident_id: inc-2026-04-09-001
postmortem_id: pm-2026-04-09-001
corrective_actions:
  - change_id: chg-2026-04-09-003
  - bundle_id: bundle-2026-04-09-b
  - eval_dataset_update: eval-set-2026-04-09
  - retirement_plan: retire-ticket-write-v1
owners:
  - platform-safety
  - platform-runtime
status: open

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

5. Как это связано со схемой трасс¶

Запись инцидента почти всегда опирается на схему трасс:

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

6. Как это связано с подтверждениями и набором политик¶

Запись инцидента особенно важна, когда нужно быстро восстановить:

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

Поэтому схема инцидента должна стоять рядом с:

7. Как это связано с управлением изменениями и поэтапным выпуском¶

Разбор инцидента редко заканчивается только фазой сдерживания.

Обычно нужно понять:

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

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

8. Связь со справочным пакетом¶

В agent_runtime_ref уже есть несколько базовых механизмов, которые делают эту схему полезной на практике:

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

Даже если пакет пока не хранит полноценный incident_record, книга уже может фиксировать, какие поля такая запись должна иметь.

9. Минимальные инварианты¶

У зрелого слоя инцидентов обычно есть такие инварианты:

инцидент имеет стабильный incident_id;
trace_id и session_id сохраняются сразу;
bundle_id, change_id и rollout_wave можно восстановить без догадок;
действия сдерживания фиксируются явно;
инцидент связывается с исправляющими действиями;
разбор ведет к обновлению артефактов жизненного цикла, оценок или наборов политик.

10. Что чаще всего ломается¶

Типовые проблемы обычно такие:

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

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

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

Есть ли у инцидента стабильный incident_id?
Можно ли быстро восстановить trace_id, session_id, bundle_id и change_id?
Видно ли, какой принципал и путь подтверждения участвовали в событии?
Зафиксированы ли действия сдерживания?
Есть ли связь инцидент -> разбор -> исправляющее действие?
Возвращаются ли инциденты в оценки, шлюзы поэтапного выпуска и обновления жизненного цикла?