Как не споткнуться о подводные камни при миграции на Linux?

ИТ-инфраструктура российских компаний годами строилась на решениях от Microsoft, но все изменилось после ухода вендора из России, когда наше будущее стало теснее связано с Linux. Сегодня кто-то готов до последнего откладывать миграцию на новую ОС, а кто-то уже прошел этот путь и готов делиться своим опытом. И хотя замена операционных систем на рабочих местах менее подвержена рискам, чем, например, замена облачных сервисов, но она требует никак не меньшей проработки. Здесь важно обратить фокус внимания не только на важность выбора продукта, но и на то, какие подводные камни могут поджидать в процессе перевода. О возможных проблемах в проектах миграции на Linux и способах их разрешения рассказывает старший системный архитектор ICL Services Ильдар Шайдуллин.

Совместимость и миграция

Первое, с чем сталкиваются все участники проекта замены операционных систем на пользовательских рабочих местах (АРМ) - это совместимость приложений, оборудования и операционных систем.

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

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

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

Этап 2 – тестирование. Проверяем на практике совместимость: подменный фонд, тестовый стенд или выборочная миграция. Вариант для тестирования зависит от доступных вам опций.

Этап 3 – актуализация. Когда появится подтверждение совместимости отдельных компонентов, используя новые данные, обновляем аналитическую таблицу и возвращаемся к перераспределению готовности функциональных групп, которая осуществлялась на первом этапе.

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

Для несовместимых компонентов можно выделить следующие рекомендации:

• При наличии возможности поменять несовместимые компоненты или оборудование совместить замену операционной системы с заменой компьютера. При этом желательно закупать устройства уже с подтверждённой совместимостью, либо перетасовать оборудование между рабочими местами.
• Провести адресную оценку приложений. Возможно, что у несовместимого приложения есть полнофункциональный аналог, а может быть, для замены одной программы нужно будет установить две "новые". Если приложение или информационная система в поддержке, стоит обратиться к производителю, вполне вероятно работы по его адаптации уже ведутся. В противном случае потребуется изучение возможности переноса таких приложений в отдельную среду: терминальные серверы, полноценный VDI, локальная виртуализация, использование программной среды Wine или выделенные рабочие места только для таких систем.
• В работе с принтерами и сканерами можно поменять схему подключения, например, c USB на Ethernet и наоборот. Также стоит изучить возможность их централизации на отдельном сервере Linux или Windows.

Максимальная адаптация с минимальными изменениями

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

Необходимость замены программного обеспечения вместе с ОС очевидна, а вот зависимости на всё информационное окружение – нет. Например, нужно использовать Active Directory от Microsoft для продолжения использования существующих учётных записей и из-за информационных систем, которые не поддерживают другие системы аутентификации. Да, системы Linux регистрируются в домене Active Directory, вот только привычное средство автоматизации через групповые политики будет недоступно. Иными словами: аутентификация с текущим логином-паролем и получение доступа, например, к сетевым дискам, работать будет, а настройка централизованного подключения этих дисков – нет. Для некоторых дистрибутивов существуют шаблоны групповых политик, но это будет скорее исключение, чем практика.

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

Проекты трансформации - это хороший повод поменять не только один продукт на другой, но и сам подход к работе с учётом новых вводных и реалий.

Информация об используемом ПО

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

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

Пользовательские данные.

Существует старая шутка - "системные администраторы делятся на тех, кто не делает бекапы и тех, кто уже делает". Зачастую все критичные системы учитывают это правило и даже имеют расписание проверки целостности этих резервных копий. Бремя сохранности пользовательских данных же обычно лежит на плечах самих пользователей, возможно, с каким-то дополнительным инструментом в виде сетевого пространства. Тут то и скрываются проблемы, которые неизбежно всплывут при миграции АРМ на другую ОС:

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

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

Жизнь между "до" и "после"

Наибольшее влияние на пользователя оказывает активная фаза трансформации - именно тогда, когда происходит замена рабочего места. Длительность этапа зависит от количества мигрируемых АРМ, сложности инфраструктуры и состава команды. Обычно процесс длится не меньше, чем 6 или даже 9 месяцев.

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

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

ЗАКЛЮЧЕНИЕ

Проекты импортозамещения клиентских систем так или иначе затрагивают почти все используемые информационные системы и компоненты компании. Важно не только выбрать продукты и составить план, но и правильно идти по намеченному сценарию, своевременно реагируя на отклонения. Только тщательное планирование и учет рисков, возникающих в процессе трансформации поможет избежать остановку бизнес-процессов. Максимально обезопасить инфраструктуру и обеспечить ее отказоустойчивость, оказать полную поддержку на каждом этапе и научить пользователей эффективно работать в новом ИТ-окружении помогут специалисты ICL Services, имеющие большой опыт работы с проектами по импортозамещению. Эксперты готовы реализовать проекты миграции "под ключ" (от 10 тысяч рублей на один АРМ* ) или помочь с его отдельными этапами.

*Индикативный расчет стоимости услуг приведен для типовой ИТ-инфраструктуры организации с 5000 АРМ, без учета поставки лицензий и не является офертой.