Как крупному бизнесу не разлюбить Open Source из-за сложностей перехода
С государственным интересом в этом вопросе все понятно. Это, в первую очередь, повышение уровня технологической независимости государственных институтов, российской науки и экономики в целом, т.к. это является абсолютно необходимым условием для сохранения государственности и суверенитета. Но при этом практическим вопросам использования СПО в коммерческих предприятиях и госсекторе уделяется крайне мало внимания. А как мы уже говорили ранее, с учетом значительного снижения покупательной способности рубля, для российских коммерческих и государственных предприятий и организаций свободное ПО (СПО) сегодня может стать действительно выгодной по многим параметрам, а иногда и единственной реальной альтернативой уходу в «серую зону». Не только потому, что свободное ПО позволяет сократить или снять затраты на лицензионные отчисления и сэкономить сотни миллионов рублей (такой уровень экономии вполне типичен для практически любой организации из сегмента Enterprise), но и потому, что хорошо «закрывает» нехватку многих классов проприетарного отечественного ПО. А также позволяет нивелировать имеющийся в данный момент достаточно острый дефицит компетентных разработчиков.
Понимать реальные преимущества СПО и освободиться от ложных представлений в этом вопросе необходимо, поскольку необоснованные ожидания — это мина замедленного действия, способная со временем взорвать любой реальный проект импортозамещения. Но рассматривая варианты и выгоды перехода на свободное ПО, российскому бизнесу и госсектору важно не менее ясно понимать, что на этом пути неизбежно столкновение с целым рядом сложностей принципиального характера, к которым нужно быть готовым. В противном случае «роман» с СПО вместо крепких взаимовыгодных отношений может превратиться в стойкую взаимную неприязнь — из-за ошибок, допущенных при планировании и внедрении.
Поэтому прежде чем запускать реальный процесс по переходу на СПО, бизнесу стоит ответить на несколько важных вопросов. Например, возможно ли преодолеть эти сложности? Если да, то с чего начать? Какие из них могут оказаться критичными, а какие незначимыми и почему (для разных организаций набор критических сложностей будет разным)? Мы ответим на эти вопросы. Но для начала надо «знать в лицо» сами сложности. Этому вопросу и посвящена данная статья.
Возможные сложности перехода на решения, базирующиеся на СПО
Сложность № 1. Рост персональной ответственности за проект
При переходе на СПО из привычной цепочки работы с программным обеспечением исчезает вендор, что не может не повлиять самым существенным образом на механизм принятия решений о внедрении. Ведь любой западный производитель корпоративного ПО обеспечивает мощную маркетинговую и экспертную поддержку ИТ-директору и ИТ-специалисту. Без нее им просто не на кого опереться! Поэтому при реализации проекта, основанного на Open Source, ИТ-директор вынужден брать на себя гораздо большую ответственность за выбор решения и дальнейшую судьбу работ по нему, а также и за любые проблемы в ходе эксплуатации.
Например, наша компания давно и успешно использует у себя и у части клиентов маршрутизаторы и межсетевые экраны на основе сетевой операционной системы с открытым кодом VyOS. Это решение отлично зарекомендовало себя, особенно при работе в облачных и гибридных средах. Под «капотом» находится Linux и все привычные инструменты. Это обеспечивает решению отличный функционал. При этом все компоненты настраиваются из удобной и интуитивной консоли с простой и логичной системой команд и синтаксисом конфигурационных файлов, что не может не подкупать. Но многие клиенты все равно выбирают «Cisco и Ко». Не потому, что выбранные инструменты лучше подходят для решения их задач, а потому, что их использование привычнее. Этот выбор проще согласовывать внутри компании. И личного риска никакого — ведь это мировой бренд, который поддерживают российские интеграторы.
А при выборе и согласовании решений на базе СПО вся «тяжесть» выбора, который еще нужно «продать» внутри компании, ложится на плечи одного человека — CIO. Которому, учитывая нынешние сложные времена не всегда хочется рисковать, отстаивая свой обоснованный и выгодный, но непростой выбор перед руководством на разных ступенях иерархической лестницы.
Сложность № 2. Совместимость версий и высокая вариативность решений
Еще одна большая проблема открытого ПО — разнообразие альтернатив и версий. Например, ОС Linux существует в форме десятков дистрибутивов (если рассматривать только получившие достаточно широкое распространение). И в каждом из них могут использоваться (и используются!) не только разные версии одного и того же ПО, но и альтернативные компоненты или не полностью совместимые «форки», собранные, к тому же, с разными наборами параметров и поддерживаемых функций.
Возьмем, например, два популярных офисных пакета — OpenOffice и LibreOffice. Несмотря на происхождение от общего «прародителя», после их разделения ошибки, исправленные в одной версии, сохранялись в другой. Я не говорю уже об их неполной совместимости из-за реализации различного набора функций. Эти различия не носят критического характера, но мы ведь говорим об одном и том же программном обеспечении (с точки зрения потребителя).
Другой пример: после обнаружения ошибок в реализации некоторых функций в популярной криптографической библиотеке OpenSSL возникла целая россыпь «форков» и альтернативных версий библиотеки: LibreSSL, BoringSSL, Polar SSL, MatrixSSL. И, вероятно, это еще не весь список! Все они тоже лишь частично совместимы. И у всех у них, конечно, есть свои сторонники и противники...
Это очень серьезная проблема. Знаю? это не только в теории. Более пяти лет СПО составляет основу наших «боевых» систем, поддерживающих основную деятельность компании и работающих у десятков наших клиентов. На основе этого опыта я рекомендую при разработке и поддержке любой системы на базе свободного ПО учитывать не только перспективу совместного использования различных компонентов одного назначения (в которых по-разному реализованы отдельные функции), но и постоянно контролировать влияние происходящих в свободном ПО изменений. Т.к. невнимание к частому (иногда ежедневному!) изменению версий программного обеспечения с отрытым кодом может обернуться ненужными рисками и проблемами при планировании обновлений и развития системы, которая построена на базе стека свободных решений. Большую помощь здесь может оказать качественная система Service Desk, за фасадом которой скрывается полноценная реализация ИТ-процессов управления инцидентами, проблемами и — особенно! — изменениями.
Нередко в мире СПО возникают и еще более неприятные ситуации, когда авторы продукта начинают уделять ему слишком мало внимания или вовсе теряют к нему интерес, оставляя всех пользователей в подвешенном состоянии. Причины могут быть самыми разными вплоть до совершенно экзотических. Так, создатель и основной разработчик журналируемой файловой системы ReiserFS Ганс Рейзер отсидел несколько лет за убийство жены и по понятным причинам не мог работать над проектом. За это время одна из самых популярных и прогрессивных файловых систем, в которой многие видели одно из наиболее инновационных направлений в развитии системы локальной информации на Linux-машинах, практически ушла со сцены. Разумеется, эта конкретная ситуация единична, но проекты, завязанные на одного человека, могут замирать и обрываться по многим другим причинам.
Поэтому форс-мажоры, касающиеся развития «свободных продуктов», нужно «держать в голове» и заказчикам, и интеграторам, и сервисным компаниям. Решение здесь, увы, только одно: поиск замены такому компоненту и новая адаптация к нему всей системы.
Сложность № 3. Слом привычной для бизнеса структуры техподдержки
Если компания выбирает СПО, то поддержки от вендора она уже не получает. В итоге, усекается традиционная и привычная всем пирамида техподдержки «первая →вторая →третья линия →вендор». Что же остается?
Поддержка от сообщества (коммьюнити). Но она строго добровольна — никаких юридических обязательств перед пользователем у сообщества нет. Иными словами, если сообщество сочло задачу достаточно интересной — оно поможет и, вполне возможно, чрезвычайно оперативно, гораздо быстрее чем традиционный вендор. А нет — значит нет. Повторяю, никаких формальных обязательств сообщество на себя в таких случаях не берет. Да и результативное взаимодействие, позволяющее решать возникающие проблемы, возможно только при условии, что что коммьюнити и продукт достаточно зрелые и развитые, сообщество не расколото конфликтами и не разделено, например, серьезными идеологическими спорами о развитии продукта. А со стороны компании работает специалист, способный правильно и в полном объеме описать проблему. Потом и правильно интерпретировать ответ сообщества, адекватно и оперативно с ним взаимодействовать.
Для некоторых открытых продуктов, конечно, существует коммерческая поддержка, но ее осуществляют, в основном, западные компании. При этом ее стоимость, зачастую, соизмерима со стоимостью лицензирования проприетарного ПО.
Наращивание же собственных компетенций — процесс слишком сложный и длительный. Во-первых, здесь стоит учитывать, что это дело не одного дня, потому что профессионалы нужного уровня, как правило, давно и прочно заняты. А если такие люди и появляются на рынке труда, то они мгновенно оттуда исчезают. К тому же, компания должна быть еще и способна правильно оценить компетенции и практические навыки найденного специалиста. Как показывает практика, сделать это под силу только специалисту как минимум соизмеримого уровня. Во-вторых, в настоящее время в большинстве категорий СПО еще не определились лидеры по распространенности именно на российских предприятиях. А это затрудняет управление компетенциями для заказчиков, интеграторов, сервисных компаний и для самих ИТ-специалистов.
Сложность № 4. Переход происходит на похожие продукты, а не на полностью эквивалентные
При смене проприетарного продукта на его аналог из мира Open Source найти ему замену «один к одному», как правило, не удается. Поэтому очень часто правильнее сразу использовать несколько новых продуктов, каждый из которых выполняет свою часть функций. К тому же, даже похожие продукты, выполняющие одни и те же функции, могут реализовывать их абсолютно разными способами. В итоге новое решение, выполненное без учета этой специфики, может давать неоптимальные результаты. Не потому, что плох выбранный Open Source-продукт, а потому, что компонент, с которым компания решила работать, используется в системе неправильно, без учета его специфики.
Приведу реальный пример, связанный опять же с переходом по принципу «один в один» с Microsoft SQL Server на СУБД PostgreSQL как основную систему хранения данных для платформы «1С:Предприятие». Это исключительно важная задача практически для любого российского предприятия. Несомненно, PostgreSQL — это первоклассная зрелая СУБД, способная обеспечить не только великолепную производительность, но и устойчивую работу высоконагруженных систем. Но в этой конкретной ситуации она может работать в разы медленнее? чем можно было бы ожидать. Не из-за того, что она «плохая», а по причине того, что платформа «1C:Предприятие» (и её т.н. «конфигурации», т. е. прикладное ПО для тех или иных предметных областей) не использует ее сильные стороны, а на слабых проигрывает. Предпосылки этой ситуации понятны: в настоящее время в «1С» степень оптимизации кода под MS SQL Server значительно выше чем для PostgreSQL, да и разработчики прикладных решений при оптимизации процессов и запросов в основном ориентируются на свой опыт работы с MS SQL Server. Сегодня такие ситуации встречаются повсеместно.
Сложность № 5. Неопределенность сроков реализации проектов
Как уже, наверное, стало понятно, богатство выбора вариантов реализации, предлагаемое экосистемой СПО, и отсутствие готовых типовых решений, могут значительно усложнить процесс выбора ПО для конкретного проекта, и, как минимум, в
Сложность № 6. Расчет экономической эффективности СПО
Отсутствие серьезного опыта работы с СПО и непонимание того, на что нужно опираться при расчетах и какими нормативами руководствоваться, значительно усложняет задачу определения экономической эффективности проектов по внедрению ПО Open Source на предприятии. Неопределенность, возникающая в результате совокупного воздействия всех вышеописанных факторов, делает эту задачу только сложнее.
Как показывает практика, общая эффективность таких плохо просчитанных проектов будет невысока из-за повторения всех неверных этапов и «шишек» в каждой отдельно взятой компании. Потому что изобретение собственного «велосипеда» может не окупить всех рисков и затрат! Так, из многочисленных примеров возврата к проприетарному программному обеспечению именно потому, что «все неправильно рассчитали!» можно вспомнить 65 школ Хакасии, где к концу 2011 года как минимум половина компьютеров должны были работать на базе открытого программного обеспечения. Или же планы по переходу на СПО для всех средних школ РФ. Предполагаемый бюджет проекта сначала составлял 720 млн. рублей, потом был пересчитан и урезан в три раза, а потом и вовсе отменен. Поэтому точный подсчет предполагаемых затрат на все проектные стадии внедрения и сопровождения СПО, включая НИОКР (которого пока будет в
Сложность № 7. Отсутствие длительной истории последовательного внедрения СПО
СПО получило чрезвычайно широкое распространение в ряде быстроразвивающихся стран Латинской Америки. Здесь главным движущим фактором при переходе на СПО — в той же Бразилии, — как известно, тоже была политическая ситуация. Но сегодня в этой стране, согласно данным опроса FLOSS World, 96% предприятий госсектора уже охвачено СПО, а 69% респондентов, участвовавших в опросе, отмечают, что было бы полезно увеличить объем использования СПО конкретно в их организации. Это указывает на довольно высокую и уже сформированную государством «культуру свободного ПО». Но такой уровень развития ИТ в целом и СПО в частности в госсекторе был подготовлен долгой историей последовательного, «мягкого» внедрения СПО
В России же все не так гладко с наличием последовательной истории развития СПО. Хотя инициатива разработки национальной программной платформы (НПП) силами Минкомсвязи в декабре 2010 только подтверждает, что выгоды СПО превышают его минусы. Тем не менее, к большому сожалению, о российском репозитории готового СПО для госслужащих постепенно говорить перестали. Видимо, это был очередной громкий анонс. А жаль, ведь только в рамках выработки такого репозитория можно было бы полностью устранить, либо значительно смягчить сложности перехода на СПО, о которых я писал выше (проверкой продуктов на зрелость, на отсутствие незадекларированных возможностей и мн.др.).
В заключение
Итак, мы рассмотрели основные сложности, которые могут помешать компаниям успешно использовать СПО. Как можно заметить, большая часть поднятых проблем не является непреодолимой преградой, особенно если подойти к их решению сообща. Нарабатывая совместно базу типовых решений, стандартов и компетенций, а также попутно развивая кадровый фонд специалистов, способных эффективно использовать все преимущества СПО. И решать эту задачу конечно нужно на всех уровнях: государства, российской системы образования, отраслевых объединений (Ассоциаций, ИТ-гильдий и др.), крупных и средних участников ИТ-рынка (в основном, системных интеграторов и поставщиков аутсорсинговых ИТ-услуг). Ведь только общий интерес и объединенные целенаправленные усилия всех этих организаций могут создать условия для достижения реальных результатов.
Ну а пока этого не случилось, крупному бизнесу стоит иметь под рукой несколько «готовых рецептов», позволяющих эти сложности преодолеть, причем с минимальными затратами сил и средств. Я предложу их в следующей статье. И в дополнение к ним постараюсь на собственном опыте рассказать об обязательных шагах, которые должны предпринять системные интеграторы, чтобы со своей стороны помочь бизнесу сделать переход на СПО максимально гладким, безболезненным и выгодным.
