Выкатка: CI, shadow, canary, rollback

Версия агента — это набор, а не образ

У обычного сервиса версия — это код. У агента поведение меняется и без строчки кода: новый prompt, новая модель, новый индекс. Поэтому версия агента — неизменяемый bundle (набор), который версионируют целиком:

• digest образа (хэш, а не tag latest);
• ID модели или файл весов с квантизацией;
• хэш prompt и описаний tools со схемами;
• версия индекса и параметры retrieval;
• eval-набор, результаты ворот и запись об одобрении.

ID набора пишется в каждый trace. Тогда на вопрос аудитора «какая версия ответила клиенту 3 марта и кто её утвердил» есть ответ одной строкой из журнала и одним commit в Git.

CI: ворота до слияния

Путь начинается с pull request. CI (continuous integration, автоматические проверки на каждое изменение) запускает unit-тесты, linters (проверки стиля кода) и offline eval suite (набор задач с проверкой ответа) как ворота. Слияние блокируется, если доля нарушений политики выросла или успех задач упал ниже порога, записанного заранее. Пороги считают отдельно по сегментам, которые важны бизнесу, — например, по языкам: средний балл скрывает провал на 20 % трафика.

Дальше: сборка образа, подпись (cosign кладёт подпись в registry, кластер принимает только подписанные образы), неизменяемый digest вместо tag. Staging (тестовая среда) синхронизируется из Git, проходят smoke-тесты (быстрые проверки «живо ли»). Миграция схемы базы — отдельный шаг, который падает, если версия схемы не та, что ждёт код. Без этого шага код новой версии встречает старую схему и падает молча.

Shadow: настоящий трафик без риска

Shadow (теневой режим, traffic mirroring) отправляет новой версии копию реальных запросов. Она отвечает, но ответы отбрасываются: клиенты видят только старую версию. В Istio это описано как «fire and forget», долю копируемого трафика задаёт mirrorPercentage. Сравнивают старую и новую версию на одних и тех же запросах: маршрут, вызванные tools, отказы, latency.

Ловушка: tools в shadow — только на чтение или mock (заглушка). Иначе теневая версия по-настоящему заблокирует карту клиента. Shadow — единственный этап, где ни один клиент не видит новую версию. Поэтому банк начинает с него.

Rolling, blue-green, canary — когда что

Canary — правило для всего, что меняет поведение агента: 1 % → 5 % → 25 % → 100 %. В Argo Rollouts анализ описывает AnalysisTemplate: метрики, пороги (successCondition) и допустимое число провалов (failureLimit). При провале, по документации, «the Rollout aborts, setting the canary weight back to zero». Метрики привязаны к вреду: доля передач человеку, нарушения по детерминированным проверкам, ошибки маршрута на размеченной выборке, жалобы, latency p95 — в сравнении со стабильной версией в то же время.

Как выглядят пороги на практике (числа — пример, их выбирают до старта и записывают в Git): - передачи человеку: canary не больше стабильной версии плюс 2 процентных пункта, считать не раньше 300 разговоров; - нарушения по детерминированным проверкам (действие без подтверждения, сумма не совпала с таблицей тарифов): ноль, первое же — abort; - latency p95: не больше 1,2 × стабильной версии; - ошибки маршрута на размеченной выборке: не хуже стабильной версии.

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

Сколько ждать: считай по выборке, а не по часам

Утверждение: «новая версия не подняла тяжёлые сбои до 1 %». Если сбой на самом деле 1 %, вероятность увидеть хотя бы один за n разговоров равна 1 − 0,99ⁿ. Для 95 % нужно n ≈ 300.

Пример. Поток — 2 000 разговоров в час (допущение). Canary на 5 % — 100 разговоров в час. Значит, 3 часа, только чтобы заметить сбой с частотой 1 %. Обратная сторона, rule of three (правило трёх): 0 сбоев в n разговорах даёт верхнюю границу частоты около 3/n с уверенностью 95 %. После 100 разговоров без сбоев можно сказать только «ниже ~3 %».

Отсюда два вывода. Первый: «час на 5 % без тревог» ничего не доказывает про редкие нарушения. Редкое тяжёлое нарушение закрывают дизайном — правами tools, подтверждением действий, — а canary ловит заметные регрессии. Второй: выборку считают по сегментам. Если сегмент даёт 30 % трафика, его выборка втрое меньше, и canary стоит дольше либо этот сегмент проверяют результатами shadow.

Откат: что откатывается, а что нет

kubectl rollout undo возвращает прежнюю ревизию Deployment за секунды. Но откатываются только pods, не база и не индекс. Если новая версия добавила колонку и пишет записи по-новому, старый код после отката встретит незнакомые данные.

Решение — expand → migrate → contract. Сначала расширить схему, не ломая старый код (добавить колонку). Потом выкатить код, который понимает оба варианта. И только в следующем выпуске убрать старое. Тогда откат образа безопасен на любом шаге. С индексом RAG то же самое: новый индекс строят рядом со старым и переключают по alias (псевдониму); откат — вернуть alias назад.

После 100 % наблюдение не заканчивается: containment (доля решённых без человека), передачи человеку, повторное обращение за 48 часов, жалобы и ручная выборка разговоров раз в неделю (урок a7-8).