VMware и Broadcom: виртуализация как control plane ИТ и сдвиги

Что произошло и почему это важно для ИТ-директоров

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

Виртуализация для бизнеса — простыми словами

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

Почему платформа стала «центром управления» ИТ

Со временем виртуализация перестала быть просто технологией «уплотнения серверов». Вокруг неё выросли процессы и интеграции: стандарты развертывания, шаблоны, политики доступа, резервное копирование, мониторинг, управление сетью и хранилищами. В результате vSphere/vCenter во многих компаниях фактически выполняют роль control plane: через них принимаются решения «что где работает», «кто имеет доступ», «как обеспечивается отказоустойчивость».

Смена стратегии влияет не только на цену

Когда меняются правила лицензирования VMware и продуктовая стратегия, это затрагивает:

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

Этот материал будет полезен ИТ-директорам, инфраструктурным командам и закупкам: тем, кто отвечает одновременно за технологический риск, стоимость владения и понятный план действий для руководства.

Виртуализация как control plane: понятие простыми словами

Когда в ИТ говорят «control plane», имеют в виду не «ещё один продукт», а уровень управления, через который задаются правила для инфраструктуры. Если упростить: это единый пульт, где видно, что происходит с вычислениями, сетью и хранилищем, и где применяются политики — кто что может, какие нагрузки куда размещать и как реагировать на сбои.

Что именно становится «пультом управления»

В корпоративной виртуализации этот пульт чаще всего реализуется через связку вроде vSphere/vCenter: вы не настраиваете каждый сервер «вручную», а управляете пулом ресурсов. Отсюда и ощущение control plane:

• Вычисления: создание/перемещение виртуальных машин, лимиты CPU/RAM, приоритеты.
• Сеть: виртуальные коммутаторы, сегментация, правила доступа.
• Хранилище: политики размещения, производительность, репликация/снапшоты.
• Политики и доступ: роли, аудит, стандартные шаблоны.

Почему это влияет на скорость, безопасность и надёжность

Пульт управления превращает изменения в повторяемые операции. Нужно развернуть 30 одинаковых серверов для нового сервиса — вы используете шаблоны и политики, а не «ручную сборку». Безопасность усиливается тем, что правила задаются централизованно и их проще проверять на соответствие. Надёжность растёт, когда отказоустойчивость (перезапуск, миграции, балансировка) — не героизм администратора, а встроенный механизм.

Почему зависимость усиливается

Как только control plane становится центром процессов, к нему «прирастают» интеграции: резервное копирование, мониторинг, управление доступами, инциденты, автоматизация. В итоге зависимость — не только про гипервизор, а про всю операционную модель: навыки команды, процедуры, контракты, совместимость инструментов.

Бытовая аналогия

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

Как VMware стала центром управления инфраструктурой

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

От консолидации к управлению кластерами

vSphere и особенно vCenter постепенно стали тем слоем, через который ИТ-отдел описывает и контролирует вычислительные ресурсы: кластеры, пулы ресурсов, политики размещения, доступы, жизненный цикл виртуальных машин. На практике для многих команд это превратилось в «операционную систему» дата-центра: не важно, на каком именно физическом сервере работает нагрузка — важны правила, по которым она запускается, перемещается, защищается и обслуживается.

Автоматизация, шаблоны и самообслуживание

Со временем накапливался функционал, который превращает инфраструктуру в сервис:

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

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

На этом же этапе часто возникает потребность в внутренних инструментах поверх платформы: порталах заявок, автоматизированных runbook’ах, утилитах для инвентаризации/маркировки, интеграциях с ITSM и IAM. Такие вещи нередко удобно собирать быстро и итеративно — например, на TakProsto.AI (vibe-coding-платформе для российского рынка), где внутренние веб/серверные приложения можно собрать через чат, а затем при необходимости выгрузить исходный код и развернуть в своём контуре.

Почему вокруг платформы выросла экосистема

Когда одна точка управления становится стандартом де-факто, к ней начинают «прирастать» остальные критичные сервисы. Резервное копирование и восстановление ориентируются на снапшоты и инвентаризацию vCenter, мониторинг — на его метрики и события, DR-сценарии — на понятную модель кластеров и сетей. Со временем VMware оказывается не просто гипервизором, а центром интеграций: чем больше таких связей, тем сильнее платформа закрепляется в роли control plane для повседневной эксплуатации ИТ.

Где именно возникает зависимость: слои и интеграции

Зависимость от VMware редко ограничивается гипервизором. Обычно она «расползается» по нескольким слоям, и критичным становится не столько vSphere, сколько связка инструментов управления (vCenter, политики, интеграции), которые фактически задают правила работы всей инфраструктуры.

Разделяем уровни, чтобы увидеть «узлы привязки»

Вычисления. Кластеры, пулы ресурсов, правила размещения ВМ и автоматизация (HA/DRS) превращаются в привычный способ обеспечивать отказоустойчивость и предсказуемую производительность.

Сеть. Виртуальные коммутаторы и сетевые политики фиксируют, «как принято» подключать сервисы: VLAN/сегменты, правила безопасности, QoS, изоляция сред.

Хранилище. Датасторы, политики хранения, thin provisioning, а также то, как устроены снапшоты и репликации, становятся частью повседневной эксплуатации.

Управление и безопасность. Роли доступа, RBAC, шаблоны, теги, каталоги, а также аудит и распределение прав в vCenter часто встроены в процессы ИБ и внутренние регламенты.

Типовые зависимости, которые «прирастают» годами

На практике организация привыкает к конкретным механизмам: кластеры с HA/DRS, снапшоты для обслуживаний, золотые шаблоны ВМ, единая модель ролей и прав. Даже если есть альтернативный гипервизор, воспроизвести эти привычные «кнопки» один в один бывает сложно.

Что усложняет перенос

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

«Скрытые» процессы, которые опираются на платформу

Зависимость проявляется там, где её не ожидают: CI/CD использует шаблоны и быстрые клоны, ITSM — автосоздание ВМ и учет ресурсов, управление изменениями — типовые окна работ со снапшотами и откатами. Поэтому оценка зависимости — это не только инвентаризация ВМ, но и карта интеграций и процессов вокруг них.

Что меняется при смене владельца и стратегии поставщика

Смена владельца у крупного вендора почти всегда означает пересмотр того, как именно вы покупаете и используете продукт. Для ИТ-директора это прямое влияние на планирование: что останется доступным, сколько будет стоить, какие условия поддержки сохранятся и как быстро можно будет адаптироваться.

Типовые сдвиги: портфель, упаковка, лицензии, поддержка

Когда меняется стратегия, чаще всего меняются «правила игры» вокруг технологии:

• Портфель и приоритеты: часть продуктов может уйти в режим «только поддержка», а инвестиции — сместиться в ограниченный набор ключевых решений.
• Упаковка (bundling): привычные компоненты продаются иначе — например, в составе наборов, где вы платите за функции, которые вам не нужны, чтобы получить те, которые нужны.
• Модель лицензирования: меняется метрика (CPU/сокет → ядра, perpetual → подписка), что меняет экономику при росте нагрузки.
• Поддержка и SLA: пересматриваются уровни поддержки, сроки реакции, правила продления, требования к версиям и совместимости.

Почему это сразу отражается на бюджетировании (CAPEX/OPEX)

Изменение лицензирования и поддержки почти всегда сдвигает баланс между CAPEX и OPEX. Там, где раньше можно было «купить и амортизировать», появляется подписка и ежегодные обязательства. А там, где были точечные закупки, могут возникнуть многолетние контракты с условиями индексации и ограничениями на частичное снижение объёмов.

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

Главный вопрос: предсказуемость на 3–5 лет

Для control plane критична не только функциональность, но и предсказуемость условий. На горизонте 3–5 лет важно понять: как будут выглядеть правила продления, какие изменения возможны в прайсинге, что будет с поддержкой ваших версий и интеграций, и сколько времени у вас будет на адаптацию.

Принцип оценки: не только продукт, но и «правила игры»

При принятии решений оценивайте поставщика как систему:

• технология + дорожная карта,
• коммерческие условия и их стабильность,
• поддержка и операционные риски,
• гибкость выхода (насколько реалистично сменить курс без остановки бизнеса).

Если виртуализация — центр управления инфраструктурой, то изменения в «правилах игры» могут оказаться важнее, чем изменения в самой платформе.

Риски для бюджета и операционной устойчивости

Смена стратегии поставщика вокруг VMware обычно бьёт не по гипервизору как таковому, а по предсказуемости затрат и по способности ИТ-команды выполнять обязательства перед бизнесом в срок. Виртуализация, ставшая control plane, затрагивает слишком много зависимостей — поэтому даже небольшие изменения в лицензировании и поддержке дают непропорциональный эффект.

Типовые бюджетные риски

Самые частые сценарии выглядят так:

• Рост TCO: изменение модели лицензирования, пересчёт по ядрам/процессорам, рост стоимости поддержки, необходимость покупать «лишние» компоненты, чтобы сохранить привычный функционал.
• Сокращение гибкости закупок: меньше вариантов «точечно докупить», сложнее масштабировать расходы под реальную динамику нагрузки.
• Изменение состава бандлов: то, что раньше приобреталось отдельно или не требовалось, теперь может оказаться внутри пакета — или наоборот.
• Требования к минимальным объёмам: пороги по количеству лицензий/подписок или стандартные пакеты, из-за которых небольшие площадки становятся дороже относительно пользы.

Операционные риски: где срываются сроки

Критические точки — продление и поддержка. Если окно продления короткое или правила меняются ближе к дате, появляются простои в согласованиях, риски разрыва поддержки и задержки в закупке. Отдельно стоит оценить влияние на проекты модернизации: обновления vSphere/vCenter, расширение кластера, переход на новое железо или интеграции (backup, DR, мониторинг) могут потребовать «неожиданных» лицензий и пересмотра дизайна.

Риск «заморозки» архитектуры

Неопределённость часто приводит к тому, что команды откладывают обновления и избегают изменений, чтобы «не трогать работающие кластеры». Итог — рост техдолга и накопление уязвимостей, а также зависимость от устаревших версий и процессов.

Как фиксировать допущения в ИТ-дорожной карте

Заранее зафиксируйте в дорожной карте допущения и ограничения: дату и сценарий продления, допустимый бюджетный коридор, требования к поддержке (SLA, критичность), перечень «нельзя терять» (например, HA/DR, резервное копирование), а также триггеры пересмотра плана (изменение бандлов, минимальных объёмов, сроков поддержки). Это переводит обсуждение из эмоций в управляемую модель рисков и решений.

Как принять решение: критерии и вопросы к бизнесу

Решение «оставаться, мигрировать частично или выходить» нельзя принимать только по цене лицензий. Виртуализация давно управляет не отдельными серверами, а правилами работы ИТ: доступностью, скоростью изменений, безопасностью и тем, как бизнес получает новые сервисы. Поэтому начинать стоит с критериев, которые понятны руководству и владельцам продуктов.

Критерии, от которых зависит выбор

Сформулируйте несколько «границ», за которые ИТ не может выходить:

• Критичность сервисов: какие системы должны работать 24/7, а где допустим плановый простой.
• Допустимый простой и RTO/RPO: сколько часов (или минут) бизнес готов ждать восстановления и сколько данных можно потерять.
• Требования регуляторов и внутренней безопасности: хранение данных, сегментация, журналирование, сроки устранения уязвимостей.
• Сроки обновлений и поддержка: насколько часто вы обязаны обновляться (а значит — зависите от политики поставщика и партнёров).

Эти критерии сразу отсекут «красивые», но нереалистичные варианты (например, быстрый массовый переезд при жёстких требованиях к простою).

Матрица вариантов: три рабочих сценария

Удобно свести обсуждение к матрице из трёх направлений:

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

2. Гибридный подход — если есть «хвост» некритичных нагрузок, которые можно переводить поэтапно.

3. План выхода — если стратегия поставщика, условия лицензирования или сроки поддержки становятся несоразмерным риском.

Вопросы бизнесу, без которых решение будет случайным

Спросите напрямую:

• Где ожидается рост нагрузки (продажи, аналитика, новые филиалы) и как быстро нужно масштабироваться?
• Нужна ли скорость изменений: как часто запускаются новые продукты и сколько времени допустимо на инфраструктурные согласования?
• Есть ли планы по гибридному облаку или консолидации дата-центров в ближайшие 12–24 месяца?

Метрики, которые стоит собрать заранее

Чтобы разговор был предметным, подготовьте базовые числа: количество ВМ, текущие лицензии и их привязки, фактические нагрузки (CPU/RAM/хранилище), ключевые зависимости (бэкап, DR, мониторинг, сеть) и стоимость поддержки (деньги + трудозатраты команды).

С этим набором вы сможете обосновать выбор не «верой в технологию», а измеримыми ограничениями и ожиданиями бизнеса.

Сценарий 1 — остаться: как извлечь максимум и снизить риски

Остаться на VMware — это не «ничего не делать», а навести порядок так, чтобы платформа давала максимум ценности при минимальных сюрпризах по бюджету и эксплуатации. Этот сценарий обычно выбирают, когда миграция сейчас рискованнее: много критичных систем, жёсткие требования к совместимости, дефицит времени и людей.

1) Наведение порядка: меньше зоопарка, больше предсказуемости

Первый выигрыш — стандартизация. У многих компаний VMware работает годами и успела обрасти разными версиями vSphere/vCenter, «временными» кластерами, исключениями в настройках и разными подходами команд.

Сфокусируйтесь на трёх вещах:

• Стандартизируйте версии и конфигурации: сколько реально нужно версий ESXi, какие baseline по настройкам хостов, сетей, хранилищ.
• Приведите кластеры к понятной роли (прод/тест/VDI/DMZ и т.д.) и закрепите правила, где что размещается.
• Сократите «уникальные» интеграции и плагины до оправданного минимума — чем меньше исключений, тем проще обновления и аудит.

2) Оптимизация затрат: емкость, «мертвые» ВМ и дисциплина снапшотов

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

• Пересмотрите емкость: сравните выделенные ресурсы (vCPU/RAM/диски) с реальной утилизацией; уменьшайте оверсайзинг.
• Отключите/удалите неиспользуемые ВМ: «забытые» стенды, дубликаты, временные миграционные машины.
• Введите политику снапшотов: сроки жизни, ответственность владельца, автоматический контроль просроченных снапшотов.
• Повышайте утилизацию за счёт консолидации нагрузок в меньшем числе кластеров (там, где это допустимо по рискам и требованиям).

Важно: цель — не «выжать максимум», а получить управляемую плотность размещения, которая не ломает SLA.

3) Контроль рисков: продления, совместимость, план обновлений

При смене стратегии поставщика риски становятся более «календарными». Что нужно держать под контролем:

• Календарь продлений и поддержек: сроки контрактов, окна продления, условия лицензирования и поддержки.
• Матрица совместимости: железо, СХД, сетевые компоненты, резервное копирование, мониторинг.
• План обновлений: регулярные окна, критерии «можно/нельзя обновлять», тестовый контур, откат.

4) Документы, которые реально помогают

Остаться безопасно можно только если знания не в головах отдельных людей. Полезный минимум:

• Инвентаризация (хосты, кластеры, ВМ, зависимости, владельцы сервисов).
• Архитектурные принципы (стандарты версий, правила размещения, требования к HA/DR, допущения).
• План непрерывности (BCP/DR): RTO/RPO, приоритеты сервисов, процедуры восстановления, ответственные.

Такой «пакет порядка» не только снижает риски при эксплуатации VMware, но и оставляет вам опцию перейти к гибридному сценарию позже — уже с понятной картиной инфраструктуры.

Сценарий 2 — гибридный подход: мигрировать поэтапно

Гибридный подход — это не «сидеть на двух стульях», а сознательно разделить инфраструктуру на зоны: что остаётся на VMware сейчас, а что переводится на альтернативы по мере готовности. Такой сценарий часто самый реалистичный: он снижает риск остановок и даёт время перестроить процессы, не ломая всё сразу.

Когда имеет смысл частичный выход

Поэтапная миграция особенно уместна, если есть «естественные кандидаты» на перенос:

• Новые приложения: проще сразу запускать их на целевой платформе, чем потом переносить.
• Dev/Test и периферийные среды: ниже требования к SLA — удобно отработать подходы, автоматизацию и поддержку.
• VDI: можно выделить как отдельный домен (пулы, профили, хранение) и мигрировать независимо.
• DR (аварийное восстановление): перенос DR на другой стек иногда даёт быструю экономию и уменьшает критичность лицензий в резервном ЦОД.

Паттерны миграции: от быстрого до правильного

Обычно смешивают несколько паттернов:

1. «Лифт-энд-шифт» для типовых VM без сложных зависимостей (быстро, но не всегда оптимально по стоимости).
2. Переупаковка в контейнеры для сервисов, которые выигрывают от стандартизации деплоя и горизонтального масштабирования.
3. Замена отдельных компонентов: например, сначала сменить бэкап/DR, затем мониторинг, затем виртуализацию — чтобы не трогать всё одновременно.

Как не построить второй «замок»

Цель гибридного этапа — уменьшить привязку, а не заменить одну зависимость на другую. Практики, которые помогают:

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

Отдельно полезно стандартизировать вспомогательные внутренние сервисы (каталоги, формы заявок, автоматизация типовых операций) так, чтобы их было легко переносить вместе с платформой. Для таких задач иногда выбирают подход «быстро собрать — потом при необходимости доработать», например в TakProsto.AI: прототипы внутренних панелей/оркестрации можно сделать через чат, а при переходе на целевую инфраструктуру — развернуть в своём контуре или выгрузить исходники.

Пример плана на 6–12 месяцев

• 0–2 месяца: инвентаризация, классификация приложений, выбор целевых зон (что переносим первым), пилот на dev/test.
• 3–5 месяцев: миграция dev/test и части непроизводственных сервисов, настройка единого мониторинга/бэкапа.
• 6–9 месяцев: перенос выбранных прод-нагрузок «волнами» (по доменам/бизнес-процессам), отработка DR на новой платформе.
• 10–12 месяцев: оптимизация затрат, пересмотр контрактов и лицензий, решение: оставлять ли VMware как «ядро» или продолжать выход.

Контрольные точки лучше формулировать не в терминах «сколько VM перенесли», а по бизнес-результату: снижение рисков, предсказуемость бюджета, подтверждённые RTO/RPO и зрелость эксплуатации на целевой платформе.

Сценарий 3 — план выхода: как выбрать альтернативы без спешки

План выхода — это не «срочно уйти завтра», а управляемая опция, которая снижает переговорные и операционные риски. Его цель — понять, какие платформы реально подходят именно вам, сколько это будет стоить (деньги и время), и какие ограничения всплывут до того, как появится давление сроков.

Классы альтернатив (без «списка победителей»)

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

• Другие гипервизоры и их системы управления: вариант для организаций, где основной «груз» — ВМ, а приложения и процессы заточены под виртуализацию.
• Публичное облако: подходит, когда часть нагрузок можно перевести в модель потребления, а требования по размещению/задержкам/комплаенсу позволяют.
• Платформы контейнеров: разумный путь, если есть зрелость в DevOps и есть смысл «разрезать» монолиты или упаковать сервисы; но для наследуемых ВМ часто потребуется переходный период.

Часто оптимальной становится комбинация: часть ВМ остаётся, часть уходит в облако, часть постепенно контейнеризируется.

Критерии выбора: что проверять в первую очередь

Чтобы не сравнивать «по рекламным буклетам», задайте минимальный набор критериев:

• Совместимость: гостевые ОС, драйверы, особенности лицензирования приложений, требования к аппаратной платформе.
• Навыки команды: что уже умеете вы (эксплуатация, сеть, хранение, автоматизация), и чему придётся учиться.
• Экосистема бэкапов/DR: поддержка ваших текущих решений, RPO/RTO, возможность тестировать восстановление без героизма.
• Сеть и хранение: зависимость от конкретных сетевых функций, требования к latency/IOPS, поддержка SAN/NAS/SDN.

PoC: что измерять и какие «красные флажки» ловить

Тестовый контур (PoC) должен быть маленьким, но «похожим на жизнь»: 2–3 типовые нагрузки, резервное копирование, восстановление, мониторинг.

Измеряйте: производительность (CPU/RAM/IO), стабильность, время типовых операций (провижининг, миграции, восстановление), сложность администрирования, прозрачность метрик.

Красные флажки: невозможность нормально встроить бэкап/DR, нестабильные драйверы, неожиданные ограничения по сети/хранилищу, резкое усложнение рутинных операций, «магия» в поддержке (когда всё работает только в руках одного эксперта).

Обучение и процессы: чтобы это не было проектом только про технологии

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

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

Практический чек-лист: инвентаризация и готовность к изменениям

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

1) Единый реестр активов (факты вместо ощущений)

Соберите в одном месте (таблица, CMDB, любой удобный реестр) и назначьте владельца данных:

• ВМ: назначение, владельцы, критичность, ОС/версии, потребление CPU/RAM/Storage, привязки к кластерам/датасторам.
• Шаблоны, образы, golden images и кто их поддерживает.
• Сети: VLAN/сегменты, распределённые/стандартные коммутаторы, правила и зависимости.
• Политики: HA/DRS, storage policies, роли/права доступа, исключения и «ручные настройки».
• Интеграции: бэкап, мониторинг, CMDB, IAM/AD, сетевые и storage-плагины, автоматизация.
• Лицензии: что используется, где привязано, кто администрирует.

2) Классификация приложений (что можно трогать, а что нельзя)

Для каждого приложения зафиксируйте: критичность (финансы/клиенты/регуляторика), допустимые окна обслуживания, зависимости (БД, очереди, внешние API), владельцев бизнеса и ИТ, требования к производительности и доступности. Это позволит отделить «быстрые победы» от систем, которым нужен отдельный план.

3) Бэкапы и восстановление (проверяем реальность RPO/RTO)

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

4) Контракты и закупки (чек-лист для юристов и закупок)

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

План действий на 90 дней и как объяснить его руководству

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

Дни 1–30: быстро зафиксировать факты и владельцев

Соберите рабочую группу и договоритесь о едином канале коммуникации: ИТ (инфраструктура и эксплуатация), ИБ, финансы, закупки, владельцы ключевых сервисов. Важно, чтобы это был не «проект ИТ», а управленческая инициатива по снижению рисков.

За первый месяц подготовьте базовые артефакты:

• реестр платформы: vSphere/vCenter, зависимые продукты, интеграции, критичные кластеры и сервисы;
• текущие обязательства: лицензии, сроки, условия поддержки, привязка к железу/партнёрам;
• карта «что сломается/подорожает», если меняются правила лицензирования или поддержки.

Дни 31–60: оформить 3 сценария и диапазоны бюджета

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

Рекомендация: показывайте не только сумму, но и «что входит»: поддержка, обучение, миграционные работы, тестирование, простой/окна, дополнительные средства ИБ и резервного копирования.

Дни 61–90: запустить пилоты и определить стоп-критерии

Запланируйте 1–2 пилота, которые отражают реальную нагрузку (не лабораторную). Управляйте изменениями через этапность: сначала некритичные сервисы, затем более важные.

Заранее зафиксируйте стоп-критерии: например, недостижение целевых RTO/RPO, падение производительности выше порога, невозможность выполнить требования ИБ или превышение бюджета пилота.

Параллельно имеет смысл ускорить «обвязку» вокруг инфраструктуры: реестры, формы согласований, панели статуса, генерацию runbook’ов. Если таких инструментов не хватает, их можно быстро прототипировать на TakProsto.AI (с развертыванием в российском контуре и возможностью экспорта исходного кода), чтобы не откладывать операционную автоматизацию до завершения большой миграции.

Как упаковать для руководства

Соберите «один слайд» с решением: текущий статус, три сценария, верхнеуровневые риски и план на 90 дней с точками контроля. Финансовому блоку полезно приложить методику расчёта и чувствительность (что будет при росте цен/сокращении скидок).

Если нужно быстро навести порядок в расходах и подготовить аргументацию, начните с обновления дорожной карты и оценки затрат: /blog/it-cost-optimization.