Перейти к содержанию

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

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

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

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

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, восстановление после дубля тикета и шлюз оценки/обновления. Внутренний ассистент знаний фиксирует устаревший поиск, разрывы привязки к источникам, загрязнение памяти, нарушение контроля доступа и восстановление происхождения знаний. Координация инцидентов фиксирует задержку эскалации, побочные эффекты уведомлений, разрыв владения ответом, сбой передачи управления и обновление обучения после инцидента.

Расширение для маршрута проверки уязвимости

Предлагаемый контракт по мотивам Anthropic CVD связывает finding_id с incident_id, если инцидент действительно зарегистрирован: не каждый кандидат является инцидентом. Это расширение документационной схемы, не реализованные поля reference runtime.

Поле Смысл
finding_id, duplicate_of, discovered_at Стабильная находка, связь дубликатов и начало когорты
review_requested_at, review_events[] Постановка в очередь; проверяющий, независимость, время, ревизия, вердикт и защищённые ссылки на доказательства
disclosure_events[] Получатель, время, ссылка на отчёт и route_at_send: independently_reviewed / direct_unreviewed на момент отправки
maintainer_response Время и содержание ответа отдельно от вердикта валидности
severity_assessments[] Значение, автор оценки, время и область применимости
remediation Статус unknown / pending / patched / wont_fix, выпуск/commit патча, время и доказательство; для принятия риска — владелец и основание
deployment_verification Затронутые ресурсы, установленная версия, время и результат проверки регрессии; неизвестные ресурсы не считаются исправленными
as_of, evidence_access_policy Дата актуальности данных и ограничения доступа/раскрытия

null означает отсутствие сведений, а не отрицательный результат. История сохраняет поздние и противоречивые оценки; статус независимой проверки нельзя вывести из отправки, ответа или присвоенного CVE. Один finding может иметь несколько advisory.

Предлагаемые, пока не выполненные здесь сценарии проверки:

  1. Прямая отправка и ответ сопровождающего без независимого review: запись остаётся вне знаменателя independently reviewed; поздняя проверка добавляет событие, не меняя историю отправки.
  2. Патч выпущен без ответа на отчёт: upstream-исправление допустимо при наличии доказательства, но локальный риск не закрывается до проверки применения.
  3. Один дефект имеет CVE и GHSA, дубликат отчёта и неизвестную установку: показатели считают уникальные findings; выпуск не превращается в доказательство установки.

Предлагаемое расширение: пакет свидетельств и отрицательные результаты

По мотивам Cloudflare Managed Defense; имена полей ниже предложены книгой, не являются API провайдера или уже реализованной схемой runtime.

  • evidence_package_id, package_version, package_digest, investigation_id, tenant_id, subject, scope, window_start, window_end, collected_at, policy_version: фиксируют границы снимка. Для каждого источника сохраняются версия API/запроса, параметры, время наблюдения, ссылки на исходные артефакты и coverage_gaps.
  • check_id, claim_id, query_ref, execution_status (completed | timeout | unavailable | denied), match_count, coverage_ref и evidence_refs описывают конкретную проверку. match_count: 0 допустим только для завершённого запроса, не как замена ошибки; при обрезанной выдаче требуется явная отметка неполноты.
  • negative_evidence_state: not_checked | checked_no_match | absence_supported. Использовать только для соответствующих отрицательных/неопределённых исходов; положительные находки хранятся отдельно. absence_supported требует проверяемой связи утверждения с областью/окном и свидетельства достаточного покрытия, а не только нулевого счётчика.
  • citation_validation отдельно от claim_support_review; для последнего сохранять проверяющего/метод, результат и обоснование. Существующая ссылка другого клиента, дела или версии пакета недопустима независимо от правдоподобия текста. Права проверяются до передачи содержимого модели; допустимые межклиентские агрегаты проходят отдельную политику допуска.
  • recommendation_status (supported | insufficient_evidence | needs_review) и причины отказа от рекомендации не заменяют статус инцидента. Недостаток свидетельств не означает ложное срабатывание или разрешение на действие.

Повторное получение данных создаёт новую версию пакета с видимой связью с прежней, а не меняет вход старого заключения. Сохранять артефакты в пределах политики доступа, минимизации и хранения; digest не даёт ни авторизации, ни гарантии истинности. Для воспроизведения фиксировать также версии модели, промпта и проверяющего. Четыре предлагаемых сценария приведены в кейсе координации инцидентов.

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?
  • Видно ли, какой принципал и путь подтверждения участвовали в событии?
  • Зафиксированы ли действия сдерживания?
  • Есть ли связь инцидент -> разбор -> исправляющее действие?
  • Возвращаются ли инциденты в оценки, шлюзы поэтапного выпуска и обновления жизненного цикла?

Что делать дальше