Уроки Мюнхена: миграция на свободное ПО

В 1980-х годах, когда корпорация IBM практически монопольно господствовала в мире ИТ, многие руководители соответствующих отделов при выборе поставщика придерживались правила: «за покупку решений от IBM еще никого не увольняли». Кому-то это помогло продвинуться по карьерной лестнице, а кому-то, кто неудачно выбрал сторону, — наоборот. С тех пор положение дел изменилось. Во-первых, исчезла модель оплаты ПО как обычного товара [1], во-вторых, начало развиваться движение СПО (Open Source Software, OSS). Как следствие, появились новые экономические ориентиры и стратегические активы, которыми организации смогли пользоваться по своему выбору, — мир стал другим.

В наши дни происходит беспрецедентный рост применения СПО. Например, на SourceForge, популярной площадке хостинга открытого кода, насчитывается уже более 430 тыс. проектов, а доля Apache и nginx среди всех веб-серверов в мире составляет 54% [2]. Численность пользователей Android на различных устройствах приближается к миллиарду [3].  Мир вступил в эпоху СПО — применение открытого кода для самых различных задач растет сегодня экспоненциальными темпами.

Если это так, почему то же самое не происходит в крупных корпорациях? Одно из возможных объяснений заключается в том, что, судя по статистике самой SourceFоrge, только 17% проектов миграции на СПО успешно развиваются, тогда как большинство бросается в самом начале. И причина кроется в самих истоках модели СПО, основанной на принципах свободы выполнения, копирования, распространения, изучения, изменения и совершенствования ПО, а также выбора формы распространения версии. Однако эти принципы создают риски, которые при отсутствии грамотного управления чреваты для организаций дорогостоящими неудачами. Кроме того, на предприятиях могут сторониться СПО, не желая переходить на продукты с неопределенным будущим и размытым жизненным циклом.

Еще одна вероятная причина — опасения, связанные с использованием СПО. В 2012 году из-за вредоносного кода, внедренного в открытую систему веб-аналитики piwik, пострадало более 480 тыс. сайтов, а в 2014 году из-за бреши Heartbleed в криптографическом пакете OpenSSL уязвимыми оказались такие крупные сайты, как Google, Facebook и Yahoo. Эти инциденты широко освещались в прессе, следствием чего могло стать восприятие продуктов с открытым кодом как незащищенных и потенциально опасных для предприятий. В результате во многих организациях по-прежнему не хотят внедрять СПО, поскольку ИТ-руководители ему не доверяют. По сути, зачастую дело не в реальном, а в воспринимаемом риске безопасности, что тем не менее влияет на принятие решения о внедрении.

На примере проекта внедрения Linux в администрации Мюнхена (точнее, операционной системы LiMux — дистрибутива, созданного на базе Ubuntu) рассмотрим принципы анализа связанных с СПО технологических рисков, а также разберем факторы, позволяющие снизить воспринимаемый уровень риска в процессе принятия решений о подобных внедрениях. Анализ факторов риска (см. врезку) позволил составить список рекомендаций ИТ-директорам по эффективному освоению продуктов СПО.

Linux в Мюнхене

Проект LiMux был начат администрацией Мюнхена в 2003 году после того, как городской совет решил отказаться от проприетарной системы и перейти на ПО с открытым кодом. Цель заключалась в том, чтобы заменить продукты Microsoft на свободные с открытым кодом. Толчком к этому послужило окончание поддержки Windows NT 4.0, которая использовалась в муниципалитете на более чем 14 тыс. настольных компьютеров. На всех также был установлен Microsoft Office 97 или Office 2000. Кроме того, применялось еще около 300 программных продуктов, включая браузеры, планировщики, клиенты для работы с мэйнфреймами на операционной системе Siemens BS2000 и сетевые клиенты Novell. Наряду со всем этим в администрации применялось более 170 приложений, созданных специально для конкретных задач: макросы, формы и различные дополнения для приложений Microsoft Office. Во многих случаях эти дополнения были разработаны сторонними компаниями, связанными с администрацией Мюнхена контрактными обязательствами. Также использовался ряд серверных продуктов, в том числе СУБД Oracle для Unix и Adabas/Natural для BS2000, файловые серверы Novell Netware и Sun PC-Netlink, сервер электронной почты Critical Path, календарные сервисы Oracle, факс-сервер Top Call и сервис каталогов X.500 Critical Path.

Руководство стояло перед выбором: либо перейти на новые версии продуктов Microsoft, либо полностью отказаться от проприетарных решений в пользу открытых. Выбор был сделан в пользу СПО, и через десять лет, в 2013 году, завершился проект по переводу почти 15 тыс. ПК на Linux¹. Большая продолжительность аналогичных проектов может стать для многих препятствием, ведь принцип «время — деньги» зачастую становится определяющим в принятии ИТ-решений. Но, так или иначе, за эти десять лет произошло немало событий, проливающих свет на технологические риски, связанные с переходом на СПО в организациях.

Десятилетняя история

В 2013 году Петер Хофман, руководитель проекта LiMux, объявил о его завершении: «LiMux закончен, мы превзошли большинство целевых показателей и уже несколько недель работаем в нормальном режиме». Ввиду высокой сложности имевшейся среды, процессов и требований, миграцию решено было проводить поэтапно. Главная задача LiMux состояла в обретении независимости от разработчиков и дистрибьюторов коммерческого ПО, прежде всего от Microsoft. Другими словами, основной движущей силой инициативы были не деньги, а желание получить больше контроля над обновлениями при выходе очередных версий. Именно это предполагает модель СПО — свободу выбора. Со времени своего зарождения в 2001 году проект прошел несколько этапов:

• 2001–2003 — первоначальные планы;
• 2003 — официальный запуск;
• 2004 — официальный указ о начале миграции;
• 2005 — начало перевода первых ПК на LiMux;
• 2008 — немецкая служба технического контроля и надзора сертифицировала внедряемую систему как дружественную пользователю и соответствующую стандартам удобства;
• 2009 — пилотная фаза и начало отказа от Microsoft Office;
• 2012 — на открытое ПО переведено 12 тыс. ПК;
• 2013 — завершение проекта, на Ubuntu Linux и LibreOffice переведено 14,8 тыс. ПК.

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

На протяжении всей инициативы по внедрению проекта в организации шла нормальная деятельность, которая не прерывалась из-за процессов миграции.

Трудности и риски LiMux

Первоначальные сложности отчасти были связаны с тем, что в 2002 году, когда был дан старт проекту, модель СПО еще не имела широкого признания в организациях и существенно отличалась от современного состояния. Если сегодня Android и Linux-серверы используются повсеместно, то 14 лет назад этого еще не было. Поэтому неудивительно, что в администрации Мюнхена после сравнительного анализа затрат на открытые и проприетарные решения не нашли финансовых оснований, оправдывающих переход на СПО. В итоге решение было принято по сугубо идеологическим соображениям — ради свободы выбора и избавления от привязки к поставщику.

Юридические проблемы

В 2004 году возникла юридическая заминка, связанная с правовыми конфликтами из-за патентов, касающихся Linux и не только. Выяснилось, что к проекту могли иметь отношение более 50 спорных патентов, в том числе патент Amazon на покупку в один клик, а также относящиеся к XML, формату JPEG, файловой системе CIFS и протоколу Server Message Block; большинство патентов принадлежали Microsoft. Миграцию приостановили, пока не был сделан вывод о том, что риск патентных конфликтов для проекта невысок.

Трудности отхода от Office

В 22 департаментах муниципалитета использовалось более 21 тыс. шаблонов и порядка 900 макросов. На стадии оценки масштабов проекта выяснилось, что специализированные дополнения создавались большим числом разработчиков с использованием нескольких языков программирования. Таким образом, отход от Microsoft Office оказался одним из самых сложных этапов. В конечном счете в результате консолидации осталось только 12 тыс. шаблонов и 100 макросов, централизованно управляемых, контролируемых и документируемых.

Сложности с обучением

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

Сложности с обеспечением устойчивого развития

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

Риск отсутствия интероперабельности

Один из главных рисков был связан с интероперабельностью — в частности, с возможными проблемами при обмене документами и данными. Было принято решение об использовании в рамках LiMux стандарта Open Document Format для документов, редактируемых в офисных приложениях. А проблемы, возникавшие в процессе обмена данными, решались сообща с представителями той стороны, с которой происходила связь.

Чрезмерная общая стоимость владения

Хотя целью внедрения LiMux не была экономия затрат, в ходе проекта выяснилось, что расходы на оплату услуг внешних консультантов оказались гораздо выше, чем ожидалось. Даже имел место спор по поводу общей стоимости владения проектом: официально было объявлено, что проект сэкономил городу десятки миллионов евро, тогда как Microsoft и HP опубликовали собственное исследование, которое показывало, что Мюнхен мог сэкономить 43,7 млн евро, если бы сохранил платформу Microsoft.

Дефицит специалистов

Чтобы восполнить пробелы в компетенции собственного департамента ИТ, мюнхенской администрации пришлось нанимать специалистов по Linux и обращаться к услугам сторонних консультантов. Большинство собственных сотрудников муниципалитета специализировались на продуктах Microsoft, в связи с чем пришлось делать значительные вложения в получение новых навыков в области СПО, чтобы обеспечить необходимый уровень поддержки пользователей. Понятно, что переход, скажем, с Windows NT на Windows 7 был бы менее затратен, чем с Windows NT на Linux.

Сложности со стандартизацией

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

Перевод пользователей на СПО

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

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

Рекомендации по проектам развертывания СПО

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

Поддержка — превыше всего

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

Тщательно оцените скрытые затраты

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

Запаситесь временем

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

Обеспечьте юридическую защиту и соблюдение нормативных требований

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

Удостоверьтесь в безопасности продукта

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

***

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

Литература

1. G. Schryen. Is Open Source Security a Myth? // Comm. ACM. — 2011. Vol. 54, № 5. — P. 130–140.
2. August 2013 Web Server Survey. Netcraft, 2014. URL: http://news.netcraft.com/archives/2013/08/09/august-2013-web-server-survey.html (дата обращения: 01.03.2017).
3. Gartner Says Worldwide Traditional PC, Tablet, Ultramobile and Mobile Phone Shipments on Pace to Grow 7.6 Percent in 2014. Gartner press release, 7 Jan. 2014. URL: http://www.gartner.com/newsroom/id/2645115 (дата обращения: 01.03.2017). 

Марио Силич (mario.silic@unisg.ch) — научный сотрудник, Андреа Бэк (andrea.back@unisg.ch) — профессор, Институт управления информацией, Университет Санкт-Галлена (Швейцария).