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

Сквозная цепочка доказательств: от запроса к решению о поэтапном выпуске

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

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

Что ты должен уметь после этой страницы

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

Зачем нужна эта страница

Несколько глав книги уже описывают части этой цепочки:

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

Главный тезис

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

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

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

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

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

Минимальная карта общих сущностей

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

Как минимум один управляемый запуск должен оставаться читаемым через такие сущности, как:

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

В более зрелых системах в эту цепочку обычно входят и:

  • release_identity;
  • change_id;
  • session_id;
  • incident_id;
  • verifier_contract_id или линия происхождения: как менялся набор контрактов проверяющего;
  • handoff_artifact_id, если длинная работа пересекает границу сброса контекста или передачи роли.1

Смысл не в идеальной терминологии. Смысл в том, чтобы связь оставалась проверяемой.

Полезно мыслить цепочку доказательств как цепочку связанных записей, а не как набор разрозненных артефактов

flowchart LR
    A["run_id"] --> B["trace_id"]
    A --> C["policy_bundle_version"]
    A --> D["approval_id"]
    A --> E["evaluation_result_id"]
    C --> F["release_identity"]
    C --> G["artifact_id"]
    E --> H["verifier_contract_id"]
    E --> I["incident_id"]
    I --> J["rollout judgment"]

Один сквозной запуск

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

Шаг 1. Пользовательский запрос входит в систему

Пользователь отправляет сообщение с просьбой открыть тикет по производственному инциденту клиента.

Уже в этот момент система должна создать хотя бы:

  • run_id для конкретного выполнения;
  • trace_id для цепочки событий;
  • ссылку на активные policy_bundle_version и release_identity.

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

Шаг 2. Оценка политики определяет границы допустимого

Слой политик определяет:

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

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

Шаг 3. Вызовы инструментов и События среды исполнения создают сырую историю

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

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

  • какие входные данные были приняты или отклонены;
  • какие вызовы инструментов были сделаны;
  • были ли retries;
  • ставилась ли сессия на паузу;
  • редактировался ли output;
  • какая конкретная причина сбоя, например в поле failure_reason, сохранилась для деградировавших путей, показывалась ли она в описании для оператора вроде latest_failure_reason в момент проверки и продолжал ли этот запуск учитываться как traceable_failed_runs на уровне проверки сессии;
  • где именно система остановилась до side effects.

Без этого слоя дальнейшее judgment превращается не в реконструкцию, а в пересказ.

Шаг 4. Подтверждение создает запись о человеческом решении

Слой политик требует подтверждения перед созданием тикета.

На этом шаге должна появиться или быть привязана запись approval_id, связанная с:

  • run_id;
  • trace_id;
  • policy_bundle_version;
  • release_identity;
  • запрошенной capability и risk tier.

Если утверждение отклонено, это не просто исход взаимодействия. Это часть управляемой истории запуска.

Если утверждение просрочено, это тоже доказательство. Оно не должно исчезать внутри состояния интерфейса.

Шаг 5. Оценки и проверка превращают историю в суждение

После этого запуск может попасть в разбор оценки вне сети, оценки в сети или сравнение с регрессией.

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

Именно это позволяет команде различать:

  • разовый сбой;
  • регрессию policy;
  • деградацию, привязанную к конкретному release;
  • проблему доверия к verifier;
  • сбой approval path.

Шаг 6. Разбор инцидента превращает доказательства в рабочее реагирование

Если запуск выявил серьезную проблему, в игру вступает глава 21.

Теперь команде нужна одна связанная запись, которая показывает:

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

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

Шаг 7. Решение о раскатке использует ту же цепочку

Наконец, глава 20 использует эти доказательства, чтобы ответить на вопрос выпуска:

  • раскатку можно продолжать;
  • раскатку нужно остановить;
  • нужен откат;
  • набор политик требует пересмотра;
  • набор артефактов нужно заменить;
  • контракт подтверждения нужно ужесточить.

Это последняя причина, по которой сквозная цепочка доказательств так важна. Решение о раскатке не должно опираться только на интуицию или панели. Оно должно опираться на цепочку, которая уже связывает поведение среды исполнения, контроли, подтверждение, доказательства и идентичность выпуска.

Один пример на уровне артефактов

Компактная управляемая запись для такого run может выглядеть так:

run_id: run-support-042
trace_id: trace-support-042
session_id: session-support-007
policy_bundle_version: 2026.04.19
release_identity: release-support-triage-2026-04-19-canary
approval_id: approval-118
artifact_id: artifact-bundle-2026-04-19-a
change_id: change-2026-04-19-17
verifier_contract_id: verifier-contract-v3
evaluation_result_id: eval-result-042
incident_id: incident-2026-04-19-3
latest_rollout_decision: pause-canary

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

Что оператор должен уметь восстановить

Для одного подозрительного запуска оператор должен быстро ответить на все вопросы ниже:

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

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

Чего эта страница не заменяет

Отдельно важно не потерять линию происхождения артефактов: без нее доказательственный каркас тоже распадается. Эта линия происхождения артефактов должна оставаться видимой для оператора.

Эта страница не заменяет соседние главы:

  • глава 11 по-прежнему отвечает за сбор сырых доказательств;
  • глава 13 по-прежнему отвечает за проверяемое суждение;
  • глава 17 по-прежнему отвечает за политики в управляемой среде исполнения;
  • глава 20 по-прежнему отвечает за release judgment;
  • глава 21 по-прежнему отвечает за реагирование в контуре заверения;
  • глава 22 по-прежнему отвечает за происхождение, линию происхождения артефактов и доказательственный каркас.

Эта страница только делает явной соединительную ткань между ними.

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

  1. Anthropic, Harness design for long-running application development. ↩