• Новости
• Блоги
• Аналитика
• Новости компаний
• В СНГ и в мире
• Анонсы

Как крупному бизнесу не разлюбить open source

«Роман» со свободным ПО вместо крепких взаимовыгодных отношений может превратиться в стойкую взаимную неприязнь – из-за ошибок, допущенных при планировании и внедрении. Как этого избежать?

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

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

Поэтому прежде чем запускать процесс перехода на СПО, бизнесу стоит ответить на несколько вопросов. Например, можно ли преодолеть сложности, связанные с этим процессом? Если да, то с чего начать? Какие из них могут оказаться критичными, а какие незначимыми и почему? Для начала надо знать сами сложности «в лицо». Рассмотрим их по порядку.

Рост персональной ответственности за проект

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

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

А при подборе решений на базе СПО вся тяжесть выбора, который еще нужно «продать» внутри компании, ложится на плечи одного человека – CIO, которому не всегда хочется рисковать, отстаивая свой обоснованный и выгодный, но непростой выбор перед руководством на разных ступенях иерархической лестницы.

Несовместимость версий и высокая вариативность решений

Еще одна большая проблема открытого ПО – разнообразие альтернатив и версий. Например, ОС Linux существует в форме десятков дистрибутивов. И в каждом из них могут использоваться (и используются!) не только разные версии одного и того же ПО, но и альтернативные компоненты или не полностью совместимые «форки», собранные к тому же с разными наборами параметров и поддерживаемых функций.

Возьмем, скажем, два популярных офисных пакета – OpenOffice и LibreOffice. Несмотря на происхождение от общего «предка», после их разделения ошибки, исправленные в одной версии, сохранялись в другой. Я не говорю уже об их неполной совместимости из-за реализации разных наборов функций. Эти различия не носят критического характера, но мы ведь говорим об одном и том же с точки зрения потребителя программном обеспечении.

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

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

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

Слом привычной структуры техподдержки

Если компания выбирает СПО, то поддержки от вендора она уже не получает. В итоге усекается традиционная пирамида техподдержки «первая g вторая g третья линия g вендор». Что же остается?

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

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

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

Переход на похожие продукты, а не на полностью эквивалентные

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

Приведу реальный пример, связанный с переходом по принципу «один в один» с Microsoft SQL Server на СУБД PostgreSQL как основную систему хранения данных для платформы «1С:Предприятие». Это исключительно важная задача практически для любого российского предприятия. Несомненно, PostgreSQL – это первоклассная зрелая СУБД, способная обеспечить не только великолепную производительность, но и устойчивую работу высоконагруженных систем. Но в этой конкретной ситуации она может работать в разы медленнее, чем можно было бы ожидать. Не из-за того, что она «плохая», а по причине того, что платформа «1C:Предприятие» и ее прикладное ПО для тех или иных предметных областей не используют ее сильные стороны, а на слабых она проигрывает. Предпосылки этой ситуации понятны: в настоящее время в «1С» степень оптимизации кода под MS SQL Server значительно выше, чем для PostgreSQL, да и разработчики прикладных решений при оптимизации процессов и запросов в основном ориентируются на MS SQL Server. Сегодня такие ситуации встречаются повсеместно.

Неопределенность сроков реализации проектов

Как уже, наверное, стало понятно, богатство выбора вариантов реализации, предлагаемое экосистемой СПО, и отсутствие готовых типовых решений могут значительно усложнить процесс выбора ПО для конкретного проекта и как минимум в полтора-два раза увеличить длительность внедрения. Ведь чтобы сделать осознанный выбор в пользу того или иного варианта, бизнесу придется провести значительный объем исследовательских и опытных работ, причем при отсутствии доступа к информации по похожим внедрениям! Риск здесь очевиден: проект может перерасти в недешевый «долгострой» с неясными перспективами. В то время как современный темп жизни (и, соответственно, проектной работы) требует минимального срока реализации проектов и быстрого возврата инвестиций.

Расчет экономической эффективности СПО

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

Как показывает практика, общая эффективность таких плохо просчитанных проектов будет невысока из-за повторения всех неверных этапов и «шишек» в каждой отдельной компании. Изобретение собственного «велосипеда» может не окупить всех рисков и затрат! Из многочисленных примеров возврата к проприетарному ПО именно потому, что «все неправильно рассчитали», можно вспомнить 65 школ Хакасии, где к концу 2011 г. как минимум половина компьютеров должны были работать на базе открытого программного обеспечения. Или же планы перевода на СПО всех средних школ РФ. Предполагаемый бюджет проекта сначала составлял 720 млн руб., потом был урезан в три раза, а потом и вовсе отменен. Поэтому точный подсчет предполагаемых затрат на все проектные стадии внедрения и сопровождения СПО, включая НИОКР (которых пока будет в два-три раза больше), – это, пожалуй, главное, о чем должны будут позаботиться бизнес или госструктуры.

Отсутствие опыта последовательного внедрения СПО

СПО получило чрезвычайно широкое распространение в ряде быстроразвивающихся стран Латинской Америки. К примеру, в Бразилии главным движущим фактором перехода на СПО тоже, как известно, была политическая ситуация. Но сегодня в этой стране, согласно данным опроса FLOSS World, 96% предприятий госсектора уже охвачено СПО, а 69% респондентов, участвовавших в опросе, отметили, что было бы полезно увеличить объем использования СПО конкретно в их организации. Это указывает на высокую сформированную государством культуру свободного ПО. Но такой уровень развития ИТ в целом и СПО в частности в госсекторе был подготовлен долгой историей последовательного, «мягкого» внедрения СПО. Начало было положено в 2000-е гг. запуском портала softwarelivre.gov.br. Эта площадка, когда-то бывшая лишь стартовой для проектов по СПО, сегодня стала одной из самых обширных баз знаний по предмету. Она содержит все официальные документы и нормативы, регулирующие работу с СПО в Бразилии, истории значимых внедрений в госсекторе, циклы видеолекций, информацию о сообществах и т.д. Кроме того, в стране создан целый ряд государственных репозиториев СПО на базе разных госучреждений. Опыт успешных репозиториев есть в Канаде, а также в Испании, Франции и других европейских странах.

В России история поступательного развития СПО не такая гладкая. Хотя инициатива разработки национальной программной платформы силами Минком­связи в декабре 2010 г. только подтверждает, что выгоды СПО превышают его минусы. Тем не менее, к сожалению, о российском репозитории готового СПО для госслужащих постепенно говорить перестали. Видимо, это был очередной громкий анонс. А жаль, ведь только в рамках его создания можно было бы пол­ностью устранить либо значительно смягчить сложности перехода на СПО, о которых я писал выше (проверкой продуктов на зрелость, на отсутствие незадекларированных возможностей и др.).

*  *  *

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