Опыт . Комплексный подход Миграция на Linux должна быть гибкой

Допустим, мы решили полностью перейти на свободное ПО. Но одно дело – быть при этом мирным одиночным пользователем, который борется с «копирайтами» на домашнем ПК, и совсем другое – руководителем организации. Для него процесс может оказаться вовсе не таким безоблачным и низкобюджетным. Ведь в стоимость миграции входят не только перенос данных и подготовительные работы, но и количество денег, потраченных на обучение пользователей для работы с новым для них софтом, и многие другие факторы.

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

Однако существуют, конечно, и другие сценарии. «Тут есть два подхода, – объясняет руководитель отдела консалтинга компании-дистрибьютора IT-сервисов VDEL Андрей МЕГАНОВ. – Во-первых, это полная замена существующих информационных систем как сервиса и, во-вторых, замена их структурных компонентов. В первом случае мы делим свою систему на функциональные компоненты и попытаемся заменить их поодиночке. Второй путь гораздо чаще приводит к неудачам. К нам довольно часто приходят люди и говорят: «У меня есть инфраструктура – серверы и десктопы. Я хочу заменить десктопы, потому что они дорогие, а вот серверы меня устраивают». В этом случае налицо грядущий провал миграции. У человека вряд ли что-либо получится, потому что он не очень представляет, чего ему хочется, и не готов идти на уступки в своих желаниях. Если же задача звучит иначе, скажем, «мы хотим изменить полностью функциональную компоненту», то такой подход сработает».

Например, у вас никогда не получится одновременно перейти на линуксовые десктопы и сохранить Active Direct (или любую другую программу, которая до этого эффективно управляла десктопами на Windows). После решения изменить любую системную компоненту будьте готовы сделать то же и с пограничными элементами системы, которые так или иначе связаны с заменяемой частью.

Истории успеха миграций, как и истории неудач, начинаются с правильной постановки задачи. Прежде всего нужно определить требования и ответить на вопрос: зачем вам это нужно? Чаще всего – для сокращения затрат, обеспечения гибкости и функциональности. Затем надо выбрать решение, на которое вы хотите мигрировать. Тут важно учесть близость к замещаемому решению, выяснить, насколько похожи заменяемые системы по своей функциональности, определить соответствие замещаемых компонент, а также иметь в виду, что какие-либо данные нельзя будет перенести. «И здесь у вас существует несколько вариантов выхода из ситуации, – рассуждает Меганов. – Можно просто выбросить какой-либо компонент, а можно разбить его на несколько, то есть заменить группой компонентов».

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

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

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

До того, как вы, по выражению руководителя отдела консалтинга, вооружившись топором, пойдете рубить вашу систему, стоит создать модель, «пилотную зону», то есть построить некую систему, которая функционально и структурно была бы близка к тому, что вы хотите создать в организации, но при этом не состояла из большого числа компонентов. «Нужно построить целевое решение, понять, как оно выглядит, проанализировать аспекты и проблемы, которые вы не учли на предыдущих этапах, устранить недочеты, – объясняет Меганов. – Пока пилотная система не будет устраивать вас полностью, к миграции приступать не стоит».

Например, перед нами стоит задача поменять ОС на рабочих столах с Windows на Linux по причине высокой стоимости одного и не слишком высокой стоимости другого. Первым делом мы проводим инвентаризацию софта, установленного на рабочих столах. Собираем серверные решения, использующиеся в работе с этим софтом. Решаем, чьими силами вы проводите миграцию: внутренними или же привлекаем специалистов извне. Назначаем ответственных. Определяем поиск решения: вычеркиваем тот софт, который не будем переводить, ограничиваем функциональность десктопов, то есть убираем все, что вам для работы не нужно. Ищем бесплатные аналоги платного ПО, учитывая при этом, что полных эквивалентов мы не найдем. Для такого софта есть несколько вариантов действий. Один из них – оставить текущее ПО, заменив лишь наиболее дорогостоящие компоненты. Например, оставляем Windows, но вместо офисного пакета Microsoft ставим OpenOffice. Можно также заменить ОС с последующим использованием эмулятора Windows для Linux – wine, что менее стабильно. Есть еще один способ. «Допустим, у вас есть два куска тяжелого незаменимого ПО, например чертежные системы, которые используются двумя или тремя пользователями в вашей организации, – объясняет Андрей Меганов. – Простой способ: разрешить этим пользователям не мигрировать. Выкинув два рабочих стола из общего процесса миграции, вы избавите себя от головной боли».