Комплексная методология проведения проектов миграции с инфраструктуры Microsoft — практика организации проектных работ и использования технологических компонентов (OSSDEVCONF-2017)
Материал из 0x1.tv
- Докладчик
- Иван Израйлев
Доклад посвящен методологии реализации проектов и миграции информационных систем с платформы Microsoft на свободную платформу.
Содержание
Видео
Посмотрели доклад? Понравился? Напишите комментарий! Не согласны? Тем более напишите.
Презентация
Thesis
Нам повезло быть свидетелями одного из самых масштабных изменений информационных технологий в России за всю историю — процесса перехода на свободную архитектуру. Большой вклад в интенсификацию этого процесса вносят инициативы государства вокруг преодоления критической зависимости от импортных проприентарных информационных систем. Сторонники свободных программ с разными чувствами наблюдают за этой историей, но ее влияние нельзя не отметить. При этом, тот внушительный объем нормативно-правовых актов по этой тематике на всех уровнях государственного управления, который вышел за последние 4 года — к сожалению, не содержит практически никаких ответов на вопросы как конкретно осуществлять проекты перехода.
А ведь эти проекты чрезвычайно сложны — мы переходим на совершенно чуждые текущим технологические платформы, а объем изменений столь велик, что требуется серьезный подход к организации проектных работ.
Хотел представить Вашему вниманию комплексную методологию проведения таких проектов из 12-ти функциональных блоков, для проработки:
- процессов управления на всех этапах жизненного цикла программных и аппаратных средств,
- специальных технологических компонентов без которых такой объем работ просто не осилить и
- задач управления ресурсами, прежде всего, человеческими.
Вначале мы делаем этап планирования — «Дорожную карту». Как может выглядеть структура документа:
- Описание текущей ситуации в организации
- Цели и задачи проекта миграции
- Организация проектных работ
- Анализ альтернатив в разрезе замещаемого ПО
- Высокоуровневый план проектов миграции
- Ожидаемые результаты миграции, критерии успеха и механизмы измерения
Здесь наиболее критичный блок — это наши цели. Они могут быть минимальные — например, обеспечить приемлемую работоспособность только вновь устанавливаемого свободного ПО без смены платформы. В других организациях цели могут быть более амбициозные — например полный переход на свободные технологии к 2020 году. Цели как обычно определяют все — и бюджеты которые будут нужны, и компетенции людей, и масштабы изменений.
Также на этом этапе проводится анализ альтернатив текущим технологиям на платформ Microsoft.
Следующий важный шаг после обоснования — это создание Руководящего документа «Стратегия миграции» с детализацией на среднесрочный период, где мы детально планируем весь портфель проектов. Структура документа может выглядеть так:
- Обоснование, основные цели и задачи (разделы из «Дорожной карты»)
- Детальный план проектов миграции (для каждого проекта):
- Организация проектных работ в разрезе этапов проектов:
- Содержание работ
- Результаты
- Ресурсы
- Трудозатраты
- Длительность
- Стоимость
- Расчет полной стоимости работ, спецификаций ПО и СВТ
- Детализация задач проекта в нотации Ганта
- Организация процессов управления жизненным циклом ПО и СВТ в рамках стратегии миграции
Итак, 12 потоков работ по порядку (далее будет удобно возвращаться к иллюстрации процессной модели см. Рис. \ref{ii:img001} для отслеживания логики):
Первый этап — это проработка инфраструктуры, которая нужна проекту — это, например, мощности для резервного копирования данных пользователей, тут обычно большие масштабы, ресурсы для документов, для технических средств и так далее — это каналы, мощности, объемы. Далее это изменения в текущих сервисах, например, нужно понять в какой домен войдут АРМы пользователей, если мы их отмигрируем на Linux, а сервера оставим на 2-й этап, как обеспечить совместимость с файловыми серверами в части прав пользователей и так далее.
Группа обеспечения должна не подставить остальных коллег и обеспечить проект техническим фундаментом.
Далее нужно разработать так называемый Стандартный образ операционной системы. Зачем? Дело в том, что если у Вас больше условно 150-ти компьютеров, то их физически невозможно оббежать — миграция может быть выполнена только в автоматическом режиме. И нужен не просто образ — а технология его сопровождения. Задайте себе вопрос сколько раз даже в простом проекте Вы будете собирать образа? Добавить драйвер — это новый образ, изменить настройку — новый образ, устранение ошибок на этапе тестирования — это сотня новых образов по 5—6 в день. Нужно построить машину по быстрой генерации образов и учету его состава, иначе вся история может сильно затянуться.
Далее, несмотря на стандартизацию образа, у нас много ПО стоит не у каждого пользователя. На практике — это более 70% всего ПО, поэтому это ПО нельзя включать в образ. А значит нам нужно создать механизмы управления таким ПО — репозитарии, упаковку пакетов для автоматического развертывания и так далее, и это крайне трудоемкий этап работ.
Вообще средства доставки ПО до АРМ — это сердце всего проекта, а потом — сердце процесса управления изменениями АРМ.
В результате в организации должен появится Репозитарий типового программного обеспечения, оформленный в виде стандарта и технологии.
Уверен, все осознают, что приличная часть программ по Windows на Linux не заработает. Более того, смею заявить, что даже при сверхусилиях в переходный период 3-5 лет ПО под платформу Майкрософт будет в каждой организации.
А значит нужно либо заставить такое ПО работать в окружении Linux с помощью эмуляции, виртуализации разных типов, терминальных систем, инфраструктуры VDI — способов не мало и каждый эффективен в разных случая по разному. Либо, выбрать альтернативное ПО работающее под Linux и перейти на него в рамках проекта. В любом случае, стратегически вопрос решается только переходом, потому что содержать гибридную инфраструктуру дело хлопотное.
Группа миграции отвечает за миграцию данных пользователей. Это очень специфический объем работ — во-первых, данных очень много, нужно уметь их анализировать, во-вторых — любые операции с данными (типа того что их удалить или переместить, или иначе структурировать) — все это требует согласования с пользователем или его руководителем. Нужно делать специальный интерфейс.
Здесь создается еще один серьезный операционный механизм — технологии для миграции пользовательских данных и настроек.
Информационная безопасность очевидный поток работ в любом проекте. Здесь особенность — Вы уже видите, в рамках такого проекта создается свежайшая организационная и техническая документация. Грех не воспользоваться и подготовить ОРД для текущих и перспективных автоматизированных систем в защищенном исполнении. У Вас отличный шанс внедрить единую технологию создания АСЗИ.
Когда все «разработчики» отработали свои куски — создан «стандартный образ», репозитарий типового программного обеспечения, механизмы совместимости, миграции данных и настроек пользователей, остальные механизмы — руководство передается этой группе, которая должна собрать из кусочков целостный операционный механизм миграции. Здесь работают архитекторы всего проекта.
Офис — В этом месте скажем честно — миграция с Microsoft Office на любую другую систему это чудовищная головная боль. Проблема в том, что офис проник везде — нам придется в 40 программах придумать как смигрировать отчетность, в 20 вывод печать, в 10 — интеграционный обмен.
Поэтому, выделяется отдельная группа для сквозных работ по всех функциональным блокам в части офисных систем.
Тестовая лаборатория — зачем она? Мы знаем, что даже у Windows есть проблемы с драйверами, а у нас тут достижения в этой области скажем скромно — чуть хуже. И на нашей чуть хуже в части драйверов платформе — куча приложений, которые печатают, сканируют, соединяется друг с другом на куче разнородной техники. И вспомним что Группа совместимости запускает все это на Linux весьма нетривиальными способами.
Поэтому отработка испытаний на реальном железе — критический элемент проекта миграции.
Как Вы понимаете, предстоит большой объем работы с людьми. Не скрою, такие проекты проходят скажем так с небольшой перчинкой, даже если все идет по плану. А как Вы хотели? Это глобальное, существенное изменение в огромном куске жизни людей. Среднестатистический работник умственного труда проводит со своим компьютером более половины времени жизни. Гораздо больше, чем с супругами и детьми. И тут мы резко меняем внешний вид и поведение ключевого спутника жизни — представьте себе реакцию. В общем, если повезет грамотно организовать работу с пользователями — поверьте, Вы решите самый главный, и самый ключевой риск проекта миграции.
В итоге — пользователи не должны отторгать систему.
Методика управления проектом обычная — планы, отчеты, жесткий контроль за сроками, работа с бюджетом проекта, с командой и тд и тп. Просто проекты очень сложные.
Апофеоз всего проекта — это результат потока работ «Перевод в эксплуатацию». Смотрите, когда мы все отмигритуем, что у нас еще останется? А останется у нас во первых, тонна накопленных знаний, высоклассный технический инструментарий и команда которая умеет в любых масштабах устанавливать любое ПО (включая перспективное) на любую технику. С невиданным ранее качеством и скоростью.
Эта группа берет проектные стандарты и процессы, и внедряет на постоянную жизнь. Некоторые вещи даже просятся в оргструктуру.
Мы считаем, что это и есть главный результат, не просто отмигрировать, а построить качественно новую ИТ платформу — выйти из проекта с существенным повышением зрелости управления ИТ в целом на много лет вперед.
В заключении хочется отметить — да, проекты миграции дело не простое, но никто и не обещал. А предлагаемая методология комплексно и детально описывает структуру реализации таких проектов.
- Брукс Ф., Мифический человеко-месяц, или как создаются программные системы., [1]
- Национальный стандарт РФ — ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств»
Примечания и ссылки
Plays:144 Comments:0