# Как межсемейный UpdateFleet меняет единицу миграции

Межсемейный UpdateFleet отделяет выбор поддерживаемого флота от пересборки образов по поколениям. Пригодность образа и приёмка приложения остаются отдельными этапами.

Автор: Редакция Retrivium
Language: ru
Разбор опубликован: 2026-11-03
Дата события: 2026-09-29
Первоисточник новости: https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-workspaces-applications-unified-graphics-images/
Канонический URL: https://retrivium.ai/ru/retrospectives/retro-workspaces-cross-family-fleet/

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

## У прежней связки была история

[Запуск AppStream G6 17 июля 2025 года](https://aws.amazon.com/about-aws/whats-new/2025/07/amazon-appstream-2-0-support-gpu-based-instances/) расширил аппаратный набор потоковой доставки приложений. Ещё раньше [представление Blackwell RTX PRO компанией NVIDIA 18 марта 2025 года](https://nvidianews.nvidia.com/news/nvidia-blackwell-rtx-pro-workstations-servers-agentic-ai) установило очередное профессиональное поколение. Ни одна предпосылка сама по себе не предоставляла общего пути миграции образов.

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

## Что разрешает сентябрьский путь

[Объявление 29 сентября 2026 года](https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-workspaces-applications-unified-graphics-images/) поддерживает единые графические образы для G4dn, G5, G6 и G7. Для таких образов описана смена семейства GPU через консоль или API UpdateFleet. Существующий образ может пройти Managed Image Update; альтернативой является начало с единой базовой версии.

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

## Условный журнал миграции

| Решение | Какие подтверждения хранятся отдельно |
| --- | --- |
| Подготовка образа | Какой единый артефакт пригоден? |
| Цель флота | Какое поддерживаемое семейство выбрано? |
| Приёмка приложения | Завершается ли представительный проект? |
| Вариант восстановления | Какая известная конфигурация остаётся рабочей? |

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

## Почему меньшее изменение помогает диагностике

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

Если одновременно требуется отдельное исправление ПО, его можно записать другим изменением вместо сокрытия внутри миграции. Причинный вывод становится обоснованнее: команда способна отличить историю упаковки от выбора платформы и не объяснять любой результат одним общим словом «перенос».

## Граница эксплуатационного вывода

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

Материал [методика выбора GPU-облака](/ru/journal/gpu-cloud-shortlist-method/) помогает описать целевую платформу, а [план выхода для GPU](/ru/journal/gpu-exit-plan/) объясняет значение рабочего пути восстановления. Объявление создаёт более понятную границу изменения, но не превращает изменение конфигурации в доказательство успешного выполнения полезной работы.