Почему обычный rolling deploy недостаточен
Код сервиса может не измениться, а поведение агента — измениться радикально после правки system prompt, alias модели или индекса RAG. Kubernetes видит здоровые pods, но не знает, что агент стал чаще выбирать опасный tool или расходовать вдвое больше токенов.
Progressive delivery связывает конкретную версию поведения с малой долей реального потока, измеряет результат и расширяет охват только после проверки. Это продуктовый эксперимент с эксплуатационными стоп-условиями, а не просто плавная замена контейнеров.
Соберите immutable agent bundle
В release manifest фиксируйте git SHA, prompt ID, точный model identifier и параметры, версии tool schemas, policy, retriever/index, memory schema и post-processing. Alias вроде latest допустим в конфигурации, но trace должен содержать разрешённую версию.
Bundle получает единый agent_version. Иначе после инцидента невозможно понять, какой из независимо обновившихся компонентов породил траекторию.
Четыре стадии безопасного релиза
- Offline: regression evals, contracts и replay трасс.
- Shadow: candidate читает копию production-входа, но не влияет на пользователя.
- Canary: малая стабильная когорта получает candidate.
- Ramp: доля растёт ступенями с паузами и gates.
Каждая стадия ловит свой класс ошибок. Offline даёт воспроизводимость, shadow — реалистичное распределение данных, canary — реальные outcomes, ramp — проблемы масштаба.
Shadow mode без двойных побочных эффектов
Нельзя просто отправить один запрос двум полноценным агентам: candidate может повторно отправить письмо или изменить CRM. В shadow все write-tools заменяются симуляторами, которые валидируют аргументы и записывают намерение. Read-tools используют snapshot, безопасную копию или разрешённый read-only доступ.
Сравнивайте не только финальный текст, но и выбранные tools, аргументы, число шагов, latency и прогноз стоимости. Отмечайте случаи, когда shadow не мог увидеть данные, доступные control, чтобы не считать их дефектом модели.
Feature flag должен возвращать вариант, а не boolean
Флаг new_agent=true быстро становится недостаточным. Возвращайте typed variant или bundle ID: stable, candidate_2027_04_11, safe_fallback. Default обязан указывать на известную стабильную версию при ошибке провайдера.
OpenFeature стандартизирует evaluation API и context независимо от конкретного flag-сервиса. Это снижает зависимость от поставщика, но правила и жизненный цикл флагов всё равно остаются ответственностью команды.
Выберите правильный targeting key
Процентный rollout должен быть детерминированным. Для чат-агента закрепляйте вариант за conversation_id или actor; для долгого workflow — за run_id. Request ID заставит один диалог прыгать между версиями, смешивая memory и tools.
OpenFeature определяет targeting key как строковый идентификатор субъекта fractional evaluation. Не передавайте email или другое PII, если достаточно внутреннего случайного ID или хеша.
Не меняйте вариант посреди workflow
Результат flag evaluation сохраняйте в состоянии run при старте. Возобновление из checkpoint должно использовать тот же bundle, даже если глобальный процент уже вырос. Исключение — emergency policy override, которое сознательно ограничивает возможности.
Иначе новый tool contract столкнётся со старой history, а анализ метрик припишет один outcome сразу двум вариантам.
Canary — это сегмент риска, а не случайные 5%
Начинайте с внутренних пользователей, synthetic jobs или низкорискового read-only сценария. Затем добавляйте репрезентативные языки, длины контекста, tenants и редкие маршруты. Случайные 5% могут не содержать ни одного критического действия.
Высокорисковые write-tools расширяйте отдельным флагом. Candidate может обслуживать 50% ответов, но иметь 0% автономных платежей до отдельного approval.
Инфраструктурный canary и поведенческий флаг решают разные задачи
Argo Rollouts умеет менять вес трафика и ставить паузы между ступенями; background analysis может прервать rollout. Это удобно для новой версии runtime. Но prompt или model variant часто выбирается внутри одного и того же pod.
Используйте оба уровня: traffic router защищает инфраструктуру, feature flag маршрутизирует поведение. В telemetry должны присутствовать и pod revision, и agent bundle.
Метрики продвижения: outcome, безопасность, цена
Задайте primary outcome: решённая заявка, принятый документ или завершённый workflow. Guardrails включают critical error rate, invalid tool calls, policy violations, human overrides, p95 latency, tokens и cost per success.
Считайте метрики по сегментам и используйте paired comparison там, где shadow обрабатывает тот же вход. Среднее улучшение не компенсирует ухудшение для одного языка или tenant.
Не загрязняйте эксперимент обучением и повторными попытками
Если неудачный candidate автоматически переключается на stable, пользовательский outcome выглядит успешным, а цена и дефект candidate скрываются. Логируйте каждую попытку и итог отдельно. Анализируйте intention-to-treat по первоначально назначенному варианту.
Не меняйте одновременно prompt, модель и retrieval, если цель — понять причинность. Для большого bundle-релиза можно проверить безопасность, но нельзя уверенно приписать улучшение одному компоненту.
Rollback и kill switch
Rollback должен означать атомарное переключение на заранее прогретый stable bundle. Он не должен ждать пересборки образа. Отдельные switches отключают candidate целиком, write-tools, memory writes или конкретный рискованный capability.
Старую версию не удаляйте сразу после 100% rollout: длительные workflows и cached conversations ещё могут на неё ссылаться. Retention определяется максимальным временем жизни состояния.
Телеметрия flag evaluation
На каждом run сохраняйте flag key, variant, reason, provider, agent version и targeting cohort. OpenFeature hooks подходят для единообразного добавления telemetry до и после evaluation.
Контекст можно распространять между сервисами, но не помещайте секреты и PII в OpenTelemetry Baggage: оно передаётся в headers и может уйти во внешний сервис. В span явно копируйте только безопасные release-атрибуты.
Автоматические gates и ручные паузы
Пример ступеней: internal → 1% → 5% → 20% → 50% → 100%. После каждой нужен минимальный объём наблюдений и полный business cycle. Быстрый трафик не помогает, если возвраты проявляются через сутки.
Hard gate немедленно откатывает при policy violation или повторном эффекте. Мягкий gate ставит rollout на паузу при статистической неопределённости, росте стоимости или недостатке выборки.
Жизненный цикл флагов
Каждый флаг имеет owner, дату создания, default, rollback target и дату удаления. После стабильного релиза код старого пути удаляют только после retention window и проверки незавершённых runs.
Долгоживущие флаги превращают систему в комбинаторный граф версий. В CI проверяйте неизвестные keys, типы variants и безопасное поведение при недоступном provider.
Чек-лист progressive delivery агента
- Agent bundle неизменяем и воспроизводим.
- Offline eval и contracts проходят до production.
- Shadow не выполняет реальные write-effects.
- Targeting key стабилен для всего workflow.
- Variant сохраняется в checkpoint и trace.
- Canary начинается с низкорискового сегмента.
- Outcomes, safety, latency и cost измеряются раздельно.
- Есть hard gates и минимальный размер выборки.
- Kill switch проверен до начала rollout.
- Stable bundle сохранён до окончания retention.