Процесс миграции модели

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

Что означает миграция модели

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

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

Когда мигрировать

Миграция обычно начинается по одной из четырех причин:

  • Модель уходит в отставку. В Foundry каждая общедоступная модель имеет дату вывода из эксплуатации, а более старые семейства моделей постепенно заменяются. Сведения о политике и датах вывода из эксплуатации см. в документах Политика жизненного цикла и поддержки моделей Foundry и График вывода моделей из эксплуатации.
  • Более эффективная модель доступна. Более новая модель обеспечивает более высокое качество, более низкую стоимость, меньшую задержку или функцию (например, структурированный вывод или улучшенный вызов инструментов), необходимую для вашей рабочей нагрузки.
  • Проблема с затратами или задержкой вызывает изменение. Задержка текущей модели или затраты на единицу больше не соответствуют вашим потребностям.
  • Разрыв возможностей блокирует продукт. Текущая модель не может сделать то, что ваш продукт теперь требует.

Что происходит на дату выхода на пенсию

Что Azure делает, когда модель выходит на пенсию, зависит от того, как вы покупаете емкость, и Foundry использует разные терминологии для каждого пути:

  • Развертывания “Стандартный”, “Глобальный стандартный” и “Стандартный для зоны данных” (с оплатой по мере использования) автоматически обновляются до новой версии поэтапно, от региона к региону. Вы управляете сроком с помощью параметра , задав одно из следующих значений: , или (это означает, что развертывание перестает работать после вывода из эксплуатации). Приоритетная обработка выполняется по тому же пути.
  • Подготовленные развертывания (PTU)не обновляются автоматически. Вы переносите их самостоятельно, либо на месте (трафик перемещается через 20–30 минутное окно без простоя), либо параллельно (вы можете выполнять новое развертывание, тестировать, перемещать трафик, удалять старый).
  • Пакетные развертывания выполняются по схеме параллельного развертывания: разверните новую модель, повторно отправьте задания, выведите из эксплуатации старое развертывание.

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

Миграция до даты выхода на пенсию

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

  • Модель замены становится доступной около 90 дней до выхода на пенсию в Global Standard, и около 30 дней до выхода на пенсию в подготовленных регионах, где предшественник выходит на пенсию. Используйте это окно для оценки новой модели и миграции вручную.
  • Сроки выхода на пенсию не расширяются. Исключений не предусмотрено, поэтому даже дата, которую вы не планировали, всё равно распространяется на вас.

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

Кто должен использовать процесс миграции

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

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

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

Этапы переноса

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

Выявление → Оценка → Адаптация → Проверка → Развертывание → Вывод из эксплуатации

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

В следующей таблице описаны все этапы и функции и средства Foundry, поддерживающие его. Функции доступны как в Microsoft Foundry, так и в Azure OpenAI, если не отмечены только Foundry, что означает, что Azure OpenAI не имеет эквивалента.

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

Phase Description Функции и инструменты
Откройте Узнайте, что изменение модели происходит или требуется, и решите, следует ли действовать.
Оценка Выберите целевую модель и убедитесь, что она доступна в оперативном режиме.
Адаптация Воспроизведение текущей рабочей нагрузки в новой модели, диагностика изменений поведения и повторная инженерия запросов, параметров, определений инструментов, выходных схем и вызывающего кода вокруг них.
Проверка Оцените адаптированную нагрузку по критериям качества, чтобы решить, можно ли её выпускать.
Развернуть Повышение производительности в рабочей среде путем поэтапного воздействия, мониторинга динамического поведения и фиксации или отката.
Retire Выведите из эксплуатации старое развертывание, освободите ресурсы, архивируйте результаты оценки и обновите связанную документацию.

Перед миграцией: подготовка тестового набора данных

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

Что следует учитывать

  • Создайте набор данных перед выбором целевого объекта. Набор данных описывает вашу рабочую нагрузку, а не целевую модель, поэтому его можно собрать параллельно с Discover.
  • Сбор входных данных из реальных или синтетических источников. Используйте захваченный рабочий трафик или примеры предметного домена в формате CSV или JSONL. Если у вас еще нет репрезентативных данных, создайте искусственные и состязательные входные данные с помощью симулятора.
  • Настройте инструментирование захвата до того, как это понадобится. Запись контента в продакшене включается только по желанию и никогда не действует задним числом, поэтому вы не можете анализировать трафик, который не записали. Начните регистрировать запросы, ответы, задержки и количество токенов уже сейчас.
  • Заморозить набор данных. Сохраняйте входные данные, эталонные значения и критерии успешности неизменными на протяжении всей миграции. Если любой из них изменится, вы больше не сможете сравнить исходные и целевые результаты.

Вам также потребуется перечень развертываний модели, которые использует ваша рабочая нагрузка, включая типы этих развертываний (стандартный, выделенный или пакетный). Для каждой модели укажите дату её вывода из эксплуатации и рекомендуемую замену из документа График вывода моделей из эксплуатации.

Этап 1. Обнаружение

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

Что следует учитывать

  • Какова дата выхода на пенсию, и сколько взлетно-посадочной полосы у вас на самом деле? Считайте дату прекращения поддержки за вычетом времени на проверку и развертывание фактическим сроком.
  • Есть ли конкретная предлагаемая замена, или вам нужно самостоятельно составить шорт-лист кандидатов?
  • Влечёт ли это изменение нормативные или региональные ограничения (для регулируемых рабочих нагрузок доступность и сертификация часто важнее качества)?

Где обычно ломается

Команды узнают о выводе из эксплуатации несистемно — по электронной почте, из баннера на портале или из внутреннего сообщения — и слишком поздно замечают этот сигнал. Эта задержка ещё больше сужает и без того узкое временное окно. Разработчики-одиночки и небольшие команды часто узнают о выводе из эксплуатации из-за сбоя в продакшене, а не из объявления.

Что вы приносите

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

Этап 2. Оценка

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

Что следует учитывать

  • Качество и позиционирование между кандидатами. Когда одновременно используется несколько моделей, определите, какая из них лучше подходит для вашей рабочей нагрузки по качеству, а не просто ту, что показывает лучший результат в общедоступном бенчмарке.
  • Стоимость при использовании собственного трафика. Структура ценообразования перемещается между поколениями моделей. Токены рассуждения, кэшированный ввод и накладные расходы на структурированный вывод могут изменить юнит-экономику в 2 раза и более, поэтому ежемесячные расходы следует прогнозировать на основе исторического трафика, а не только по прайс-листу.
  • Операционная доступность. Подтвердите регион, номер SKU и квоту, и что целевой объект может выполняться параллельно с источником, чтобы сохранить путь отката.
  • Контроль соответствия требованиям. Для нагрузок, подпадающих под нормативные требования, сертификация и региональная доступность позволяют сузить список вариантов ещё до обсуждения качества.

Где обычно ломается

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

Что вы приносите

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

Этап 3. Адаптация

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

Adapt — это больше, чем редактирование промптов

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

  • Параметры.temperature, top_p, max_tokens и элементы управления усилием рассуждения не имеют взаимно-однозначного соответствия между поколениями, и более новые семейства моделей могут не поддерживать некоторые параметры.
  • Определения инструментов. Возможно, потребуется переформулировать или уточнить имена аргументов, описания и обязательные поля, которые надежно направляли старую модель.
  • Схемы вывода. Модели отличаются в том, как они соответствуют структурированным выходным данным. Возможно, потребуется добавить в схему явные ограничения, которым прежняя модель соответствовала лишь приблизительно, или, наконец, станет возможно обеспечить строгое соблюдение схемы.
  • Вызывающий код. Различия между интерфейсом API и SDK (Chat Completions и Responses, формат потоковой передачи и новые или переименованные поля запроса). Кроме того, может потребоваться обновить нижестоящий анализ, предполагающий старую фигуру ответа.

Для рабочих нагрузок агента и рабочих процессов схема и вызов инструментов часто перевешивают запросы.

Что следует учитывать

  • Прослушайте повторно без изменений перед настройкой. Запустите текущую конфигурацию в целевой модели без каких-либо изменений. Этот подход помогает отделить изменения в поведении, внесенные моделью, от изменений, которые вносите вы, и дает точку отсчета.
  • Посмотрите, что именно смещается. Многословность, глубина рассуждений, следование структурированному формату вывода, формат вызова инструментов, поведение при отказе и вариативность задержки — всё это часто меняется.
  • Воспроизводите реальные трассы, чтобы выявлять регрессии при вызове инструментов. Дополнительные поля, переименованные аргументы и изменения в последовательности проявляются только в реальных трассировках, а не в одношаговых бенчмарках.
  • Отслеживайте изменения. Реинжиниринг промптов легко выполнить и легко утратить. Сохраните исходный и запишите, что изменилось и почему.

Функции Foundry

Три функции Foundry поддерживают этот этап:

  • Оптимизатор запросов — это кнопка "Оптимизация " непосредственно под полем системных инструкций на игровой площадке агента. Он реструктурирует инструкции с помощью рекомендаций по проектированию запросов, показывает причины каждого изменения в абзацах и поддерживает цикл итерации: добавьте предложение, например "сохранить схему JSON точно" и повторно оптимизировать. Доступно только в Foundry, а не Azure OpenAI.
  • Оптимизация агентов совместно оптимизирует инструкции, инструменты и выбор моделей для агентных нагрузок. Доступно только в Foundry, а не Azure OpenAI.
  • Симулятор создает искусственные и враждебные входные данные, если у вас нет промышленных данных для повторного воспроизведения.

Где обычно ломается

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

Что вы приносите

  • Начните с оптимизаторов, а затем проверьте. Они применяют общие лучшие практики за один проход, а не подгоняют их под ваш набор данных, и настраивают текст инструкций, а не определения инструментов или схемы вывода. Считайте результат добротным черновиком: сначала скопируйте свой исходный запрос (история версий отсутствует), а затем заново сверьте всё со своим зафиксированным набором данных, прежде чем доверять этому изменению.
  • Запланируйте дополнительную практическую работу для перекрестных семейных переездов. Нет процесса «оптимизировать под целевую модель X», поэтому переход между семействами моделей требует осознанной адаптации промпта и схемы.
  • Записывайте трафик заранее. Качество воспроизведения зависит только от качества захвата, а захват содержимого включается только с согласия пользователя и не применяется задним числом.

Этап 4. Проверка

Цель этапа валидации — определить, можно ли безопасно выпускать адаптированное решение, оценив его по критериям рубрики качества на тщательно подобранном наборе данных. Оценочная рубрика может быть основанной на правилах, на эталонных ответах, на подходе «LLM в роли судьи», на экспертной оценке человеком или на специализированном фреймворке для конкретной предметной области. Успешным результатом является создание заслуживающего доверия набора средств оценки, работающего на фиксированном наборе данных, которому доверяют как команда приложения, так и любые рецензенты.

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

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

Что следует учитывать

  • Держите набор данных и критерии замороженными. Это единственная наиболее важная дисциплина в процессе сохранения результатов сравнения.
  • Измеряйте три показателя, по которым принимается решение об утверждении: качество (оценки проверяющего или рецензента), задержку (время до получения первого токена и пропускную способность, только для того вызова, который вы переносите) и стоимость (стоимость входных и выходных токенов в расчёте на запрос).
  • Сопоставьте критерии оценки с объёмом работы. Рубрика для клинического суммирования, утверждение о последовательности вызовов инструментов для агентов или уже существующие сигналы пользовательской обратной связи могут быть более значимыми, чем обобщённая оценка.
  • Рассматривайте этот этап контроля как сигнал для ИИ-ориентированных команд. Вместо однократной проверки по принципу «прошёл/не прошёл» оценка выполняется непрерывно, при каждом коммите, и интегрируется с Roll out.

Функции Foundry

Две функции Foundry поддерживают этот этап:

  • Azure AI Evaluation SDK включает более 30 встроенных оценщиков, охватывающих обоснованность, релевантность, извлечение, связность, беглость, эталонные метрики (F1, BLEU и ROUGE), безопасность, оценщики агентов и оценщики Azure OpenAI. Он также включает настраиваемую LLM-модель, выступающую в роли судьи, для критериев оценки конкретных задач.
  • Оценка на портале использует те же средства оценки для модели, агента, набора данных и трассировки.

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

Dimension Что измерять Where
Quality Оценки вычислителя по исходному объекту и целевому объекту SDK для оценки Azure AI, оценка в портале
Latency Время до первого токена и пропускная способность Таблица лидеров бенчмарка, операционные показатели
Cost Стоимость входных и выходных токенов для каждого запроса Выходные данные оценки, цены на модель

Где обычно ломается

У большинства команд нет набора средств для оценки, а те, у кого он есть, часто разрабатывали его сами. Для регулируемых рабочих процессов обязательная проверка со стороны человека или службы управления качеством добавляется сверху и становится узким местом. Эти миграции останавливаются на этапе «Validate», а не «Adapt».

Что вы приносите

Оценщики готовы к запуску, но подготовка релевантного предметной области тестового набора из вашего собственного продакшен-трафика требует ручной работы для нагрузок моделей (не агентов). Вот почему этап подготовки окупается.

Этап 5. Развертывание

Цель этого этапа — поэтапно развернуть прошедшую проверку конфигурацию в промышленной среде: сначала в непроизводственных средах, затем по схеме canary или с распределением трафика по процентам, а затем для более широкого круга пользователей. На всём протяжении процесса отслеживайте текущую задержку, ошибки и, в идеале, качество по сравнению с базовым уровнем до миграции. Затем зафиксируйте изменения или выполните откат. Успешный результат — это постепенное внедрение с использованием канареечного, взвешенного или теневого трафика, оперативный сигнал о качестве, учитывающий не только задержку и ошибки, а также сохранённая возможность отката.

Что следует учитывать

  • Сведения о типе развертывания. Тип развертывания определяет принцип работы: развертывания семейства Standard могут автоматически обновляться по заданному вами расписанию. Подготовленные, пакетные и точно настроенные развертывания переносятся вручную. В следующей таблице показаны механики по типам.
  • Сохранение коридора отката. Оставьте старое развертывание доступным, пока не убедитесь, что всё работает правильно. Решения об откате, принятые из-за крайнего срока вывода из эксплуатации, а не на основе фактов, — это признак того, что вы начали слишком поздно.
  • Если вы не можете использовать режим тени или зеркального отображения. Регулируемые потоки (PHI, финансовые транзакции) часто не могут предоставлять новую модель реальному трафику клиентов. Эквивалент выполняет новую модель для рабочих входных данных в автономном режиме и сравнивает выходные данные со старой моделью, не влияя на пользователей.
  • Следите за регрессиями, которые не выявила офлайн-оценка. Задержку, наблюдаемую реальными пользователями, и поведение в граничных случаях можно выявить только под нагрузкой в продакшене.

Механика миграции по типу развертывания

Тип развертывания Способ миграции Quota
Стандартный, Глобальный стандартный, Стандартный для зоны данных Автоматическое обновление по поэтапному графику. Управление временем (versionUpgradeOptionOnceNewDefaultVersionAvailable, OnceCurrentVersionExpiredилиNoAutoUpgrade). Приоритетная обработка выполняется по тому же пути. Переносится автоматически
Обеспечено Вручную: на месте (трафик перемещается через 20–30 минутное окно) или параллельно (новое развертывание, смена трафика, удаление старого). Сначала убедитесь, что для целевой модели доступна квота
Batch Параллельно: разверните новую модель, повторно отправьте задания, а затем удалите старое развертывание. Убедитесь, что квота для целевой модели доступна
Точно настроен (вне области этой статьи) Не обновляется автоматически; отдельные сроки вывода из эксплуатации для обучения и развертывания. Перенастройте или дистиллируйте на замещающей базовой модели. Убедитесь, что квота для целевой модели доступна

После переключения трафика настройте непрерывную оценку, чтобы оценивать выборочную долю продуктивного трафика на панели мониторинга Foundry Observability с привязкой к трассировкам для анализа первопричин, а также получать оповещения Azure Monitor при снижении качества.

Где обычно ломается

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

Что вы приносите

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

Этап 6. Выход из эксплуатации

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

Что следует учитывать

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

Где обычно ломается

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

Что вы приносите

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

Миграция редко бывает бинарной.

Реальные миграции часто проходят в смешанном режиме: часть нагрузки работает на новой модели, тогда как чувствительный к задержкам или более рискованный контур остаётся на старой, иногда на несколько недель. Планируйте частичное развертывание и частичный откат вместо единовременного переключения со старой модели на новую. Этап Retire часто отстает от Roll out на недели или месяцы, и именно эти старые развертывания, которые продолжают существовать, проявляются как избыточное разрастание.

Связанные материалы

  • Last updated on