Просмотр исходного текста страницы Комплексная методология проведения проектов миграции с инфраструктуры Microsoft — практика организации проектных работ и использования технологических компонентов (OSSDEVCONF-2017)

;{{SpeakerInfo}}: {{Speaker|Иван Израйлев}}
<blockquote>
Доклад посвящен методологии реализации проектов и миграции информационных систем с платформы Microsoft на свободную платформу.
</blockquote>

{{VideoSection}}
{{vimeoembed|235962400|800|450}}

{{youtubelink|J0bDA-0hbfY}}


{{SlidesSection}}
[[File:Комплексная методология проведения проектов миграции с инфраструктуры Microsoft — практика организации проектных работ.pdf|left|page=-|300px]]

{{----}}

== Thesis ==
Нам повезло быть свидетелями одного из самых масштабных изменений информационных технологий в России за всю историю  — 
процесса перехода на свободную архитектуру. Большой вклад в интенсификацию этого процесса вносят инициативы государства
вокруг преодоления критической зависимости от импортных проприентарных информационных систем. Сторонники свободных
программ с разными чувствами наблюдают за этой историей, но ее влияние нельзя не отметить. При этом, тот внушительный
объем нормативно-правовых актов по этой тематике на всех уровнях государственного управления, который вышел за
последние 4 года — к сожалению, не содержит практически никаких ответов на вопросы как конкретно осуществлять проекты
перехода.

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

Хотел представить Вашему вниманию комплексную методологию проведения таких проектов из 12-ти функциональных блоков, для
проработки:

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

Вначале мы делаем этап планирования  —  «Дорожную карту». Как может выглядеть структура документа: 

#  Описание текущей ситуации в организации
#  Цели и задачи проекта миграции
#  Организация проектных работ
#  Анализ альтернатив в разрезе замещаемого ПО
#  Высокоуровневый план проектов миграции
#  Ожидаемые результаты миграции, критерии успеха и механизмы измерения

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

Также на этом этапе проводится анализ альтернатив текущим технологиям на платформ Microsoft.

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

#  Обоснование, основные цели и задачи (разделы из «Дорожной карты»)
#  Детальный план проектов миграции (для каждого проекта):
#  Организация проектных работ в разрезе этапов проектов:
##  Содержание работ
##  Результаты
##  Ресурсы
##  Трудозатраты
##  Длительность
##  Стоимость
##  Расчет полной стоимости работ, спецификаций ПО и СВТ
##  Детализация задач проекта в нотации Ганта
# Организация процессов управления жизненным циклом ПО и СВТ в рамках стратегии миграции

Итак, 12 потоков работ по порядку (далее будет удобно возвращаться к иллюстрации процессной модели см. Рис. \ref{ii:img001} для отслеживания
логики): 

[[File:Комплексная методология проведения проектов миграции с инфраструктуры Microsoft.svg|800px|center]]

Первый этап — это проработка инфраструктуры, которая нужна проекту  —  это, например, мощности для резервного
копирования данных пользователей, тут обычно большие масштабы, ресурсы для документов, для технических средств и так
далее  —  это каналы, мощности, объемы. Далее это изменения в текущих сервисах, например, нужно понять в какой домен
войдут АРМы пользователей, если мы их отмигрируем на Linux, а сервера оставим на 2-й этап, как обеспечить совместимость
с файловыми серверами в части прав пользователей и так далее. 

Группа обеспечения должна не подставить остальных коллег и обеспечить проект техническим фундаментом.

Далее нужно разработать так называемый Стандартный образ операционной системы. Зачем? Дело в том, что если у Вас больше
условно 150-ти компьютеров, то их физически невозможно оббежать  —  миграция может быть выполнена только в
автоматическом режиме. И нужен не просто образ  —  а технология его сопровождения. Задайте себе вопрос сколько раз
даже в простом проекте Вы будете собирать образа? Добавить драйвер  —  это новый образ, изменить настройку  —  новый
образ, устранение ошибок на этапе тестирования  —  это сотня новых образов по 5—6 в день. Нужно построить машину по
быстрой генерации образов и учету его состава, иначе вся история может сильно затянуться.

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

Вообще средства доставки ПО до АРМ  —  это сердце всего проекта, а потом  —  сердце процесса управления изменениями
АРМ.

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

Уверен, все осознают, что приличная часть программ по Windows на Linux не заработает. Более того, смею заявить, что даже
при сверхусилиях в переходный период 3-5 лет ПО под платформу Майкрософт будет в каждой организации.

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

Группа миграции отвечает за миграцию данных пользователей. Это очень специфический объем работ  —  во-первых, данных
очень много, нужно уметь их анализировать, во-вторых  —  любые операции с данными (типа того что их удалить или
переместить, или иначе структурировать)  —  все это требует согласования с пользователем или его руководителем. Нужно
делать специальный интерфейс.

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

Информационная безопасность очевидный поток работ в любом проекте. Здесь особенность  —  Вы уже видите, в рамках такого
проекта создается свежайшая организационная и техническая документация. Грех не воспользоваться и подготовить ОРД для
текущих и перспективных автоматизированных систем в защищенном исполнении. У Вас отличный шанс внедрить единую
технологию создания АСЗИ.

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

Офис — В этом месте скажем честно  —  миграция с Microsoft Office на любую другую систему это чудовищная головная боль.
Проблема в том, что офис проник везде  —  нам придется в 40 программах придумать как смигрировать отчетность, в 20
вывод печать, в 10  —  интеграционный обмен.

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

Тестовая лаборатория — зачем она? Мы знаем, что даже у Windows есть проблемы с драйверами, а у нас тут достижения в этой
области скажем скромно — чуть хуже. И на нашей чуть хуже в части драйверов платформе — куча приложений, которые
печатают, сканируют, соединяется друг с другом на куче разнородной техники. И вспомним что Группа совместимости
запускает все это на Linux весьма нетривиальными способами.

Поэтому отработка испытаний на реальном железе  —  критический элемент проекта миграции. 

Как Вы понимаете, предстоит большой объем работы с людьми. Не скрою, такие проекты проходят скажем так с небольшой
перчинкой, даже если все идет по плану. А как Вы хотели? Это глобальное, существенное изменение в огромном куске жизни
людей. Среднестатистический работник умственного труда проводит со своим компьютером более половины времени жизни.
Гораздо больше, чем с супругами и детьми. И тут мы резко меняем внешний вид и поведение ключевого спутника жизни  — 
представьте себе реакцию. В общем, если повезет грамотно организовать работу с пользователями  —  поверьте, Вы решите
самый главный, и самый ключевой риск проекта миграции.

В итоге  —  пользователи не должны отторгать систему.

Методика управления проектом обычная — планы, отчеты, жесткий контроль за сроками, работа с бюджетом проекта, с командой
и тд и тп. Просто проекты очень сложные. 

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

Эта группа берет проектные стандарты и процессы, и внедряет на постоянную жизнь. Некоторые вещи даже просятся в
оргструктуру. 

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

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

----
* <tt>Брукс Ф.</tt>, Мифический человеко-месяц, или как создаются программные системы., [http://www.lib.ru/CTOTOR/BRUKS/mithsoftware.txt]
* Национальный стандарт РФ — ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств»



{{LinksSection}}
<!-- <blockquote>[©]</blockquote> -->


<references/>

[[Категория:OSSDEVCONF-2017]]
{{stats|disqus_comments=0|refresh_time=2017-12-12T17:05:50.635097|vimeo_comments=0|vimeo_plays=11|youtube_comments=0|youtube_plays=3}}
[[Category:Open-source]]