Глава 18. Чеклист промышленного запуска¶

1. Начнем с момента, когда команда должна сказать “да” или “нет”¶

Продолжим тот же кейс поддержки.

Команда уже прошла длинный путь:

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

Теперь наступает самый неприятный вопрос:

Можно ли выпускать этого агента хотя бы на первые 5% клиентов?

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

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

Даже если у тебя уже есть:

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

это все еще не означает, что систему безопасно запускать в промышленную среду.

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

Для этого и нужен чеклист раскатки.

2. Чеклист нужен не как бюрократия, а как защита от самообмана¶

Почти каждая команда хотя бы раз попадала в знакомую ситуацию:

• “в тестах все было нормально”;
• “мы думали, что подтверждение точно сработает”;
• “мы не ожидали именно такого входа”;
• “если что, быстро откатим”.

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

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

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

Это не теоретический риск: даже пользовательский AI-сценарий может превратиться во внешний ущерб и обязательство компании, как показал кейс Moffatt v. Air Canada.²

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

3. Что обязательно должно быть закрыто перед первой волной поэтапного выпуска¶

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

Для агентной платформы обычно есть как минимум семь обязательных блоков:

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

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

Для нашего кейса поддержки это означает: прежде чем выпускать даже малую контрольную волну на 5%, команда должна быть готова ответить не только “работает ли штатный путь”, но и “что именно произойдет при частичном сбое”.

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

4. Корректность рантайма¶

На этом уровне полезно задавать очень приземленные вопросы:

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

Для нашего агента поддержки это значит, например:

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

Это базовый слой. Если он шатается, все следующие проверки уже менее полезны.

5. Готовность безопасности и политик¶

Перед поэтапным выпуском особенно важно проверить:

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

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

Для кейса поддержки ключевой вопрос звучит так:

Может ли агент создать тикет, прочитать статус или сохранить профильную запись хотя бы по одному пути, который не пройдет через политику и контрольный след?

Если ответ “да” или “не уверены”, поэтапный выпуск еще рано начинать.

6. Готовность возможностей¶

Каждую возможность, которая идет в промышленную среду, полезно прогонять по короткому операционному шаблону:

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

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

Для нашего агента поддержки create_support_ticket и check_access_request_status выглядят рядом в каталоге, но готовность у них разная:

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

flowchart LR
    A["Рантайм"] --> H["Готовность к промышленной среде"]
    B["Безопасность"] --> H
    C["Возможности"] --> H
    D["Наблюдаемость"] --> H
    E["Оценки и SLO"] --> H
    F["Операционная готовность"] --> H
    G["Владение и откат"] --> H

7. Готовность наблюдаемости и оценок¶

Очень частая ошибка: выкатывать систему, надеясь потом “добавить нормальную трассировку”.

До промышленной среды стоит убедиться, что:

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

DeepMind AI Control Roadmap добавляет к этому полезную контрольную тройку: coverage, recall и time-to-response.³ Перед расширением поэтапного выпуска команда должна знать не только “есть ли мониторинг”, но и какую долю релевантных действий/планов он покрывает, насколько часто supervisor действительно ловит опасные события и как быстро система способна заблокировать, поставить на паузу, устранить или эскалировать проблему.

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

OpenAI Deployment Simulation добавляет сюда еще один полезный pre-deployment signal: не только прогонять заранее написанные сложные задания, но и переигрывать реалистичные контексты будущей выкладки с candidate model до выпуска.⁴ Для агентной платформы это означает, что readiness gate может требовать deployment_simulation_report: какая prompt/session distribution была взята за основу, какие нежелательные поведения измерялись, насколько оценки откалиброваны после фактической выкладки, и где simulation fidelity недостаточна для решения о расширении. Это не заменяет adversarial evals и tail-risk red teaming, потому что редкие события ниже частоты выборки могут не всплыть, но закрывает другой пробел: насколько модель или агент поведет себя на похожем на production распределении, а не только в узнаваемом тестовом наборе.

Для tool-heavy agent trajectories такой сигнал особенно важен. OpenAI отдельно показывает, что live tool calls при предрелизной симуляции могут быть опасны или нереалистичны, поэтому окружение инструментов нужно симулировать с высокой fidelity: состояние репозитория на момент исходной траектории, база прошлых tool-call/response pairs, read-only connectors и явное сравнение с реальными rollouts. В терминах этой книги это превращается в выпускное требование: если canary зависит от инструментов, файлов, сети или внешних систем, то rollout gate должен видеть не только offline_eval_pass, но и simulation_environment_fidelity, tool_simulator_scope, representative_prefix_window, post_release_calibration_plan и список behaviors, где simulation не дает достаточной уверенности.

Если этого нет, первый же инцидент превращается в расследование вслепую.

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

• какой путь выбрал агент;
• был ли повторный вызов инструмента;
• какой idempotency_key использовался;
• какой шлюз политики сработал,

то первая волна выкладки уже превращается в лотерею.

8. Готовность пути подтверждения¶

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

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

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

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

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

Очень практичный шлюз поэтапного выпуска звучит так:

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

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

8.1. Прерывания в возможности с состоянием тоже должны входить в готовность поэтапного выпуска¶

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

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

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

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

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

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

Перед поэтапным выпуском команда должна уметь явно сказать:

• использует ли путь теперь routing, хотя раньше там был фиксированный рабочий процесс;
• приносит ли parallelization новый риск вокруг состояния объединения, повторного чтения или порядка подтверждений;
• добавляет ли orchestrator-workers поверхности делегированных рабочих агентов, безопасные каталоги для рабочих агентов или новые точки проверки;
• вставляет ли prompt chaining новые контрольные точки, в которых меняется семантика истечения, паузы или повтора.

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

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

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

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

9. Операционная готовность¶

Отдельный слой, который часто забывают:

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

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

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

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

10. Практические правила готовности к поэтапному выпуску¶

Если нужен короткий операционный каркас, обычно достаточно таких правил:

1. Ни один поэтапный выпуск не должен начинаться без покрытия трассировкой, плана отката и понятного владельца.
2. Ни одна пишущая возможность не должна идти в контрольную волну без идемпотентности, нормализации результата и видимости политик.
3. Высокорисковые потоки нужно проверять отдельно от штатного пути.
4. Контрольная волна, теневой режим и лимиты радиуса воздействия должны быть частью дизайна, а не аварийной импровизацией.
5. Очереди подтверждений, возраст приостановленных запусков и накопление ручной проверки должны считаться сигналами поэтапного выпуска, а не невидимым операционным шумом.
6. Изменения в выборе схемы оркестрации должны рассматриваться как изменения управления средой исполнения и проходить явную проверку до поэтапного выпуска.
7. Если доказательства выпуска зависят от суждений проверяющего, поэтапный выпуск надо останавливать, когда команда больше не доверяет качеству проверяющего или связи его доказательств.
8. Если команда уже не доверяет трассам, обработке подтверждений или оценкам, поэтапный выпуск надо останавливать, а не “донаблюдать в проде”.

11. Пример политики чеклиста запуска¶

Ниже очень практичный шаблон:

rollout:
  require:
    - trace_coverage
    - policy_prechecks
    - capability_owners
    - offline_eval_pass
    - duplicate_ticket_eval_passed
    - slo_defined
    - rollback_plan
    - oncall_owner
  rollout_mode:
    initial: canary
    max_tenant_exposure_pct: 5
    require_shadow_period: true
  block_if:
    - unknown_side_effect_path_missing
    - direct_tool_access_present
    - policy_decisions_not_traced

Такой checklist хорош тем, что делает готовность предметом инженерного разговора, а не уверенности в голосе автора релиза.

12. Простой кодовый пример шлюза готовности¶

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

from agent_runtime_ref.rollout import RolloutPolicy, assess_rollout


def ready_for_rollout(
    config: dict[str, object],
    observed_checks: dict[str, bool],
) -> dict[str, object]:
    policy = RolloutPolicy.from_dict(config)
    assessment = assess_rollout(policy, observed_checks)
    return {
        "ready": assessment.ready,
        "missing_required": list(assessment.missing_required),
        "blocking_signals": list(assessment.blocking_signals),
    }

observed_checks должны поступать из проверенного манифеста, а не из ручных галочек. Отсутствующий обязательный сигнал и активный block_if дают разные диагностические списки, но оба удерживают ready=false.

13. Что чаще всего ломается в процессе запуска¶

Проблемы очень узнаваемы:

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

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

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

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

14. Быстрый тест зрелости готовности к поэтапному выпуску¶

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

Более сильная планка такая:

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

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

Рубрика готовности 0–4. Оценка 0 означает отсутствие воспроизводимых контрактов и доказательств; 1 — документированные контракты без исполняемых проверок; 2 — детерминированные проверки с пробелами в материальных доказательствах; 3 — готовность к контрольной волне с проверенным пакетом и владельцем отката; 4 — наблюдаемую промышленную эксплуатацию с отрепетированным реагированием и выводом из эксплуатации. Любой жесткий блокер принудительно возвращает решение hold независимо от суммы баллов. Машиночитаемая рубрика находится в docs/companion/examples/readiness-rubric-support-ticket.yaml.

14.1. Практикум: пройти цепочку trace → eval gate → rollout wave → containment¶

Чеклист промышленного запуска становится сильным только тогда, когда он связывает наблюдаемое поведение системы с конкретным выпускным решением. Недостаточно написать “трассы есть”, “оценки пройдены”, “откат подготовлен”. Нужно показать, какая трасса доказывает какой путь, какая оценка блокирует какую волну, какое условие удерживает расширение и какой containment включается при неизвестном результате.

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

rollout_decision_record:
  release_name: support_agent_ticket_creation_wave_2
  release_owner: customer_ops_platform
  decision_time: 2026-06-21T10:00:00Z
  target_wave:
    name: operator_assisted
    population: support_operators_eu_pilot
    traffic_limit: 10_percent_of_eligible_requests
    write_capabilities_enabled:
      - support.order.create_ticket
  evidence:
    trace_sample:
      required_paths:
        - happy_path_ticket_created
        - policy_requires_confirmation
        - confirmation_timeout
        - tool_unknown_result
        - verifier_rejects_inconsistent_state
      required_events:
        - run_start
        - policy_precheck
        - capability_selected
        - tool_policy_decision
        - approval_requested
        - approval_resolved
        - tool_execution
        - verification_result
        - run_complete
    eval_gate:
      suite: eval.support.ticket_creation.policy_edges
      pass_rate: 0.992
      critical_failures: 0
      known_accepted_failures:
        - slow_operator_resolution_in_sandbox
    slo_snapshot:
      confirmation_queue_p95_age: 3m
      ticket_creation_p95_latency: 8s
      verifier_rejection_rate: 0.7_percent
      unknown_result_rate: 0.1_percent
  decision_rules:
    expand_when:
      - eval_gate.critical_failures == 0
      - unknown_result_rate <= 0.2_percent
      - confirmation_queue_p95_age <= 5m
      - verifier_rejection_rate <= 1_percent
    hold_when:
      - confirmation_queue_p95_age > 5m
      - verifier_rejection_rate > 1_percent
      - policy_reason_code_distribution_shifts == true
    freeze_when:
      - unknown_result_rate > 0.5_percent
      - missing_required_trace_event_detected == true
      - on_call_owner_unavailable == true
    rollback_when:
      - critical_eval_regression_detected == true
      - unauthorized_write_detected == true
      - repeated_idempotency_conflict == true
  containment:
    default_action: hold_wave
    safe_mode:
      disable_write_capabilities: true
      keep_read_only_assistance: true
      require_operator_confirmation_for_all_writes: true
    rollback_playbook_ref: rollback.support.ticket_creation.v1
    customer_communication_ref: comms.support_agent_limited_beta.v1

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

Первый уровень — trace. Команда не просто смотрит на наличие логов, а требует образцы конкретных путей: штатный путь, подтверждение, таймаут подтверждения, неизвестный результат инструмента и отказ проверяющего. Такой набор нужен потому, что первые инциденты обычно происходят не на счастливом пути. Если система умеет показать только успешный запуск, она еще не готова к расширению волны.

Второй уровень — eval gate. Оценка должна иметь отношение к переходу, который команда собирается сделать. Для операторской волны важны не только общие ответы модели, но и политические границы, объяснимость подтверждения, корректность отказов и отсутствие критических регрессий. Если eval suite не покрывает новые риски этой волны, зеленый результат почти ничего не доказывает.

Третий уровень — rollout wave. Волна должна быть описана как управляемая популяция и набор включенных возможностей. “Включаем для 10%” недостаточно. Нужно понимать, какие пользователи или операторы входят в эти 10%, какие write-capabilities действительно активированы, какие ограничения на трафик действуют и какие условия остановят расширение.

Четвертый уровень — containment. Хороший выпуск заранее знает, что делать при неопределенности. Не каждый сбой требует полного отката. Иногда достаточно удержать волну, выключить пишущие возможности, оставить read-only помощь и потребовать подтверждение для всех действий. Но это решение должно быть готово до инцидента. Если команда впервые обсуждает safe mode во время сбоя, safe mode фактически отсутствует.

Удобно перевести правила решения в короткую таблицу:

Обрати внимание на различие между hold, freeze и rollback. В слабых процессах все это называют “остановить релиз”, но для агентной системы разница важна. hold означает: текущая волна не ухудшается критически, но доказательств для расширения недостаточно. freeze означает: появились сигналы, что контрольная поверхность неполная, поэтому новые включения запрещены. rollback означает: система уже нарушила ключевое условие безопасности, корректности или доверия, поэтому нужно возвращать состояние к заведомо безопасной конфигурации.

Хорошая практика — заранее определить, какие артефакты должен приложить владелец выпуска к каждому решению:

• для expand: ссылку на eval gate, образцы трасс всех обязательных путей, снимок SLO и список включенных возможностей;
• для hold: сигнал, который удержал волну, срок следующего пересмотра и владельца устранения причины;
• для freeze: отсутствующий контроль или недостоверный сигнал, решение о safe mode и критерий разморозки;
• для rollback: нарушенное правило, затронутые возможности, выполненные шаги playbook и проверку восстановления.

Это особенно важно для книг и внутренних руководств по ИИ-агентам: читателю нужно видеть не только “архитектурно правильно”, но и “как это выглядит в день запуска”. В день запуска не хватает времени вспоминать главы про трассы, SLO и политики. Поэтому выпускная запись должна собрать их в один операционный документ.

После заполнения rollout_decision_record команда должна уметь ответить на простой вопрос: “Почему мы имеем право расширить эту волну именно сейчас?” Если ответ опирается на трассы, оценки, SLO, явные правила и готовый containment, поэтапный выпуск похож на инженерное решение. Если ответ звучит как “вроде всё работает”, это еще не выпускная готовность.

15. Что делать сразу после этой главы¶

Если хочешь быстро проверить готовность перед выкладкой, пройди по короткому списку:

1. Есть ли формальный шлюз готовности?
2. Ясны ли владелец и дежурный на этот поэтапный выпуск?
3. Пройдут ли трассы, решения политик и результаты инструментов сквозь телеметрию?
4. Есть ли контрольный или теневой этап?
5. Есть ли план отката и ограничение радиуса воздействия?
6. Проверены ли высокорисковые потоки отдельно, а не только штатный путь?
7. Есть ли у подтверждения видимое правило ограничения времени и накопления очереди для приостановленных запусков?

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

16. Что читать дальше¶

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

17. Полезные справочные страницы¶

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

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

• Глава 17. Слой политик и каталог возможностей
• Часть VII. Эталонная реализация
• Часть VIII. Жизненный цикл агентной системы
• Источники