Переход на Linux: Быстрый старт

ИСТОРИЯ ПОЯВЛЕНИЯ ИНТЕРЕСА К LINUX В РОССИИ

10-15 лет назад некоторые российские компании изучали возможность перевода своей ИТ-инфраструктуры на условно-бесплатное программное обеспечение, как один из способов сокращения расходов на ИТ. К тому моменту уже появились российские разработчики, предлагающие различное ПО или ОС, как правило на базе Linux. Некоторым даже удавалось выстроить работающие процессы, базирующиеся на альтернативных продуктах, в том числе и облачных.

Но фактическим стандартом в области рабочих мест как в России, так и во всем мире всегда оставались продукты от Microsoft, представляющие собой органичную экосистему. Их использовали для обмена офисными документами, в качестве операционной системы для разработки и запуска специализированных приложений, серверных ОС и для других целей. Обучение в школах и ВУЗах также велось с учетом того, что у любого школьника дома есть компьютер с офисным пакетом, позволяющим просматривать и редактировать файлы стандартов .doc, .xls, .ppt, и возможностью установить учебное ПО, написанное под Windows. Вместе с этим разработчикам удалось реализовать удобный механизм подключения и настройки периферийного оборудования, когда большинство подключаемых устройств не требуют практически никаких действий от пользователя с момента первого подключения до начала работы. В случае же, если встроенных в ОС Windows драйверов оказывалось недостаточно, абсолютное большинство производителей всегда предоставляли в первую очередь драйвер для этой ОС, а потом уже для всех остальных ОС и их разновидностей.

После введения первых антироссийских санкций появился «Единый реестр российских программ для электронных вычислительных машин и баз данных» и сертификация ФСТЭК. А затем были внесены изменения в законодательство, обязывающие часть организаций использовать ПО либо из реестра, либо сертифицированное ФСТЭК. «Вишенкой на торте» стала поддержка введенных против нашей страны санкций рядом разработчиков ПО, в том числе и Microsoft, а именно, запрет на продажу лицензий на ПО и ОС.

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

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

ПРОБЛЕМЫ, ВОЗНИКАЮЩИЕ ПРИ ПЕРЕХОДЕ НА LINUX

Не для всех программных продуктов существуют версии для платформы Linux. Более того, производители периферии для ПК тоже далеко не всегда ставят в приоритет разработку драйверов под каждый дистрибутив Linux.

Если рассматривать внедрение ОС Linux на автоматизированных рабочих местах в корпоративных масштабах, то здесь вырисовываются как минимум две сложные задачи. Во-первых, гораздо меньше компонентов АРМ и периферийных устройств без дополнительных усилий исправно заработают на новой ОС, а, во-вторых, не каждое приложение удается запустить на ОС Linux.

 В целом, все приложения будут делиться на несколько групп:

• имеющие версию под ОС Linux, но даже и в этом случае успешный запуск под конкретный дистрибутив и версию ОС не гарантирован,
• имеющие аналог по ОС Linux,
• способные запускаться через wine - среду x86 под Linux,
• работающие исключительно под ОС Windows, но остается возможность их запуска через VDI.

Чтобы убедиться в возможности перехода на Linux и оценить реализуемость этой задачи, даже если вы сомневаетесь, будет правильно воспользоваться пилотным проектом. Запуск тестирования рекомендуется компаниям, в инфраструктуре которой работают более 500 пользователей.

Для организации пилота необходимо выбрать целевую группу. Это могут быть 10-15 опытных пользователей из числа сотрудников, которые будут проводить тестирование, смогут сфокусироваться на специфических требованиях, функционале или оборудовании, и в результате подтвердят успешность или «неуспешность» проекта. Кроме того, перед запуском пилота необходимо сформировать описание среды и функционала, который будет проверяться, и определить сроки и критерии успешности пилотного проекта. 

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

ТРЕБОВАНИЯ И ОГРАНИЧЕНИЯ ДЛЯ ПИЛОТНОГО ПРОЕКТА

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

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

ДЛИТЕЛЬНОСТЬ И СТОИМОСТЬ

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

Как правило пилот на Linux проводится на платной основе. Это обосновывается тем, что пилот требует значительных усилий по проверке совместимости оборудования и периферии, подготовке дистрибутивов ОС, анализу бизнес-процессов и используемого ПО, а также подготовительной работы по поиску и подготовке пакетов установки аналогов ПО для среды Linux.

РОЛИ ЗАКАЗЧИКА И ИНТЕГРАТОРА

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

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

ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ ВО ВРЕМЯ ПИЛОТА

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

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

 ЭТАПЫ ПРОВЕДЕНИЯ ПИЛОТА

 Проведение пилотного проекта состоит из нескольких этапов: