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

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

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

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

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

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

Будем ориентироваться на организации, где около тысячи пользователей, работающих с 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, веб-серверов. Часть порталов, движков для сайтов — кроссплатформенные, работающие и в одной, и в другой инфраструктуре — на них надо обратить пристальное внимание.

Еще часть решений может использовать разные базы данных. Например, Microsoft SQL Server работает и с Postgres и с MySQL. Все эти возможности нужно исследовать и зафиксировать.

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

И, наконец, остается часть программного обеспечения, которое не имеет совместимости с Linux, но является критичным для бизнеса. Его можно вынести на терминальные серверы. Да, какой-то «кусочек» Windows-инфраструктуры будет оставаться, но он будет постепенно «таять», по мере решения вопросов замены, улучшения совместимости ПО, его переписывания, запуска ПО на Wine.

Если же система масштабная, ее разрабатывали много лет, есть «толстый» клиент и ее переработка может стоить дороже, чем адаптация Wine, можно обратиться к разработчикам этой СПО-«прослойки», чтобы даже такая система смогла работать в Linux-среде, если нужно.

Говоря о среде виртуализации — можно спокойно мигрировать кластеры до 15 хостов.

Расширение пилотной группы, тиражирование успешного решения на все подразделения/сервисы. В этом этапе нет практически ничего нестандартного, кроме того, что работа с изменениями и ее результаты должны отслеживаться более тщательно, так как потери времени, сил и средств при сбоях и ошибках будут намного существеннее, чем в случаях с проприетарным ПО.

А поиск других решений в 3-5 раз дольше, чем в «мире Windows» (если нет уже наработанных или страховки в виде Центров компетенции у ИТ-подрядчиков или партнеров и их «надзора» за тиражированием).

Компания давно использует Open Source и успела убедиться в его возможностях на практике

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

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

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

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

Или, например, поддержки B2B/B2C-приложений, которые развиваются на базе Open Source (call-центры, кассы, «киоски», ERP от 1С). Компаниям, у которых работают эти приложения, стоит перевести на Open Source до трети инфраструктуры.

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

Автор: Павел Рыцев, ИТ-директор, руководитель Центра компетенции по импортозамещению и Open Source в ALP Group