Переходим на Linux и СПО, мнения ИТ-практиков: Павел Рыцев, ALP Group

Допустим, в компании есть жесткое решение «уходим от Windows», как бы вы организовали процесс? Какой дистрибутив бы выбрали и почему именно этот? Какие ресурсы бы потребовались? Как бы выглядела схема перехода?

Если компания приняла жесткое и действительно непростое решение «ухода от Windows», перед ней возникает большой вопрос — а как вообще организовать этот непростой процесс? Какие ресурсы нужны в первую очередь? И как будет выглядеть схема перехода? Сегодня трудно получить надежный ответ на эти вопросы, за которым стоит реальный опыт. Поэтому я решил хотя бы отчасти восполнить этот пробел.

При этом я опираюсь на восьмилетний опыт полномасштабного применения ПО с открытым кодом в департаменте ИТ-аутсорсинга — как на технологическую основу. И на два с лишним года активной работы на рынке импортозамещения, в которые вместились: запуск центра компетенции по импортозамещению и свободному ПО, создание (совместно с компанией «Базальт СПО») особой технологии для поддержки российского ПО. Которая позволила поддерживать на основе SLA системообразующие ИТ-продукты — например, первую линейку операционных систем уровня предприятия (ОС АЛЬТ) и ведущую СУБД (Postgres Professional). Все это уже прошло проверку не только в пилотных, но и в реальных проектах.

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

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

Компания поддалась эмоциям и находится «в точке ноль»

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

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

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

Или возврат на стадию подбора новых аналогов (еще два месяца в общей сложности). Потом «пилотная» стадия проекта в 2-3 месяца. И основная — в 4-5 месяцев. С параллельным началом технической поддержки на этом этапе.
Серьезная, большая, дорогая и долгая работа. Но если подойти к этому правильно, компания может получить от перехода большие преимущества.

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

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

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

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

Нужно дописать много кода в очень короткий срок. Да мало ли еще что!

Полная информация об ИС и ИТ-сервисах (инвентаризация). Идеально, если у компании она уже есть — полностью актуальная, отражающая то, какие функции выполняет каждая система и каждый ИТ-сервис.

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

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

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

Например, сервис централизованного мониторинга и контроля (СЦМК) над «здоровьем» ИС, в котором уже настроенный технологический контур, лишь подстраиваемый под заказчика, идет «в комплекте» с экспертизой команды ИТ-специалистов (сеть, ОС, СУБД, бизнес-приложения и пр.).

В этом случае получение и обработка информации об ИТ-сервисах компании займет не годы, а 1-2 месяца — за счет быстрого включения СЦМК в работу и роботизированного сбора информации о состоянии ИТ-сервисов в режиме реального времени.

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

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

Этот этап компании, решившейся на «уход во вселенную Linux» не рекомендуется пропускать, поскольку даже самое жесткое решение о переходе на Linux не должно превращаться в суицидальное. Этот шаг может упростить обращение к поставщику ИТ-услуг, который умеет работать с российским ПО и у которого уже есть проверенные концепции и решения.

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

Подготовка плана и пилотирование проекта. Проект лучше пилотировать стандартно, на небольшом количестве пользователей (100-200 человек), на одно подразделение. Или же в пилотном режиме замещать какой-то один ИТ-сервис.

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

За год-два, пока длится импортозамещающий проект среднего объема, квалифицированный системный администратор способен переучиться и начать решать задачи, связанные, например, с ОС АЛЬТ. Тем более, что в эту ОС уже встроены механизмы замены MSAD на Samba DC и Exchange на SOGo.

Но решать эти задачи стоит все равно с учетом того, что переученный сотрудник всегда может получить помощь экспертов или же ИТ-партнера, например, в виде консультаций Центра компетенции по импортозамещению и Open Source.

Миграция. Разумнее и проще всего начинать миграцию со стандартных инфраструктурных сервисов: почты, файлового сервиса, DNS, DHCP, веб-серверов. Часть порталов, движков для сайтов — кроссплатформенные, работающие и в одной, и в другой инфраструктуре — на них надо обратить пристальное вн