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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Нужны артефакты поэтапного выпуска?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сквозной кейс: канареечная волна после дубля

Перед 5% поэтапным выпуском агента поддержки команда должна показать не только успешную проверку статуса и создание тикета. Разбор должен показать, что регрессионный шлюз против дублей тикета пройден, create_support_ticket имеет стратегию идемпотентности, side_effect_unknown останавливает запуск до сверки, трассы сохраняют результат, а владелец отката уже назначен. Иначе контрольная волна проверяет надежду, а не готовность.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • использует ли путь теперь 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
    - slo_defined
    - rollback_plan
    - oncall_owner
    - approval_queue_owner
    - session_expiry_signals_visible
    - orchestration_pattern_reviewed
  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
    - approval_backlog_unbounded
    - paused_runs_without_expiry
    - capability_session_reinit_unmodeled
    - orchestration_pattern_change_unreviewed

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

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

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

from dataclasses import dataclass


@dataclass
class RolloutReadiness:
    trace_coverage: bool
    offline_eval_pass: bool
    slo_defined: bool
    rollback_plan: bool
    approval_path_defined: bool


def ready_for_rollout(state: RolloutReadiness) -> bool:
    return (
        state.trace_coverage
        and state.offline_eval_pass
        and state.slo_defined
        and state.rollback_plan
        and state.approval_path_defined
    )

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Шаблон завершения главы

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

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

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

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

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

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

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

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

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

  1. Anthropic, Building Effective AI Agents ↩

  2. American Bar Association, BC Tribunal Confirms Companies Remain Liable for Information Provided by AI Chatbot ↩

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