Назад

2026/10/12

Большинство миграционных проектов начинается с решения: перейти с Oracle Java SE на OpenJDK, заменить дистрибутив Linux, срок поддержки которого истёк, или консолидировать серверы в частном облаке. На бумаге план обычно выглядит простым. Затем проектная команда обнаруживает среды выполнения Java, о которых никто не знал, серверы, за которые никто не отвечает, и приложения, незаметно зависящие от старой версии. Сроки сдвигаются, бюджеты растут.

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

Главное

  • Проведите полную инвентаризацию Java и Linux, прежде чем планировать какую-либо миграцию.
  • Для каждой среды выполнения фиксируйте полную версию, поставщика, путь и ответственного.
  • Ищите не только в списках пакетов, но и в файловой системе: многие среды выполнения просто распакованы из архива или встроены в приложения.
  • Распределите результаты по четырём группам (удалить, заменить, согласовать, выяснить) и планируйте на этой основе.

Почему инвентаризация предшествует миграции

Миграция хороша ровно настолько, насколько хороши сведения, на которых она основана. Без инвентаризации вы оцениваете объём работ по памяти, старым таблицам и лицензионным записям, и ни один из этих источников не отражает того, что реально работает сегодня.

Хорошая инвентаризация даёт вам три вещи:

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

Кроме того, она защищает вас в переговорах о лицензиях. Если поставщик спросит, сколько у вас установок, актуальная инвентаризация позволит ответить фактами, а не предположениями.

Что собирать: версии, поставщики, пути и ответственные

Для каждой установки Java соберите как минимум следующее:

  • Хост: имя машины, IP-адрес и тип: сервер, виртуальная машина или рабочая станция.
  • Версия: полная строка версии, например 1.8.0_202 или 17.0.10, а не просто «Java 8» или «Java 17».
  • Поставщик: кто собрал среду выполнения, например Oracle или один из дистрибутивов OpenJDK. По одной лишь версии этого не определить.
  • Тип и путь: полноценный JDK или только JRE, а также каталог установки.
  • Использование: какие приложения или службы её используют, если это удаётся выяснить.
  • Ответственный: команда или сотрудник, отвечающие за машину или приложение.

Для серверов Linux дополнительно соберите дистрибутив и его версию, версию ядра, основные установленные пакеты и запущенные службы. Так вы поймёте, какие серверы затрагивает не только миграция Java, но и миграция Linux.

Windows, Linux и рабочие станции: разные подходы

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

Серверы Windows

Установленные среды выполнения Java часто регистрируются в реестре Windows в разделе HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft, но далеко не все. Поиск по файловой системе надёжнее:

Get-ChildItem -Path C:\ -Filter java.exe -Recurse -ErrorAction SilentlyContinue |
  Select-Object FullName, @{n='Version'; e={$_.VersionInfo.ProductVersion}}

Проверяйте все диски, а не только C:, поскольку серверы приложений часто устанавливают на отдельный диск с данными.

Серверы Linux

В Linux сочетайте менеджер пакетов с поиском по файлам, поскольку многие среды выполнения Java распаковываются из архива, а не устанавливаются в виде пакета:

cat /etc/os-release
rpm -qa | grep -i -E 'jdk|jre|java'
find / -xdev -type f -name java -perm -u+x 2>/dev/null

В Debian или Ubuntu вместо rpm используйте dpkg -l | grep -i -E 'jdk|jre'. Если запустить каждый найденный исполняемый файл java с параметром -version, он покажет версию и, как правило, поставщика. Кроме того, в большинстве каталогов JDK есть файл release, в котором указан разработчик сборки (implementor).

Рабочие станции

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

Типичные сюрпризы (встроенные JRE, забытые серверы)

Почти любой проект по инвентаризации находит то, чего никто не ожидал. Чаще всего это:

  • Встроенные среды выполнения: многие коммерческие приложения поставляются с собственной частной средой выполнения Java внутри каталога установки. Она может не отображаться ни в реестре, ни в каком-либо списке пакетов.
  • Несколько версий на одной машине: при установке новой среды выполнения старые удаляют редко, поэтому на одном сервере их может оказаться три или четыре.
  • Забытые серверы: тестовые машины, старые серверы пакетной обработки и виртуальные машины, которые так и не были выведены из эксплуатации и часто работают на устаревших версиях без обновлений.
  • Неизвестные владельцы: машины, за которые никто не признаёт ответственности. По ним нужно принять решение до начала миграции, даже если это решение их отключить.

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

От инвентаризации к плану миграции

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

ГруппаЧто входитЧто делать
УдалитьСреды выполнения, которые больше не используютсяУдалить сейчас, чтобы снизить риски и лицензионные обязательства
ЗаменитьСреды выполнения, которыми вы управляете самиПосле тестирования перейти на поддерживаемую сборку OpenJDK
СогласоватьСреды выполнения, встроенные в сторонние приложенияСначала получить заявление о поддержке от поставщика приложения
ВыяснитьВсё, у чего нет владельца или понятного назначенияНайти владельца или принять решение об отключении

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

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

Чем может помочь LOGIQ

LOGIQ проводит проекты по инвентаризации и миграции сред Java и Linux, используя скрипты и процедуры, отработанные в реальных клиентских проектах на серверах Windows, серверах Linux и рабочих станциях. Если вам нужна помощь в проведении инвентаризации или в составлении на её основе плана миграции, свяжитесь с LOGIQ.