 |
|
|
|
Инфраструктурные решения на базе СПО. Как с ними работать?
Инфраструктурные решения на базе СПО.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Вопрос 1. На что необходимо обратить внимание клиенту при выборе российской ОС? Как оценить возможности СПО для конкретных нужд компании?
Наталия Ефимцева
– С точки зрения пользователей – это функциональность (решение каждодневных бизнес-задач) и простота интерфейса ОС, с точки зрения ИТ – возможности по автоматизации и интеграции в существующую ИТ-инфраструктуру. Еще одним важным фактором может быть присутствие в реестре российского ПО и сертификация ФСТЭК.
Как показывает наш проектный опыт и работа с функциональными требованиями, при переходе на отечественные продукты правильным подходом является подбор ПО – основываясь на той задаче, которая должна быть закрыта за счет внедрения решения, а не сравнение «feature by feature». Необходимо в первом приближении сформировать список ПО- кандидатов, опросить конечных пользователей и пользователей ИТ- подразделения, составить пользовательские истории (user story), проанализировать результаты и выбрать 1-2 решения для пилотного внедрения на тестовой группе сотрудников.
Григорий Розов
– Для начала нужно понять, о каком сегменте ОС (сервер/клиент) идет речь и какие есть сертификаты (если есть требование регулятора). Бывает так, что ОС – это основа всех остальных инфраструктурных программ. Например, ОС Astra Linux и система виртуализации «Брест».
Вадим Пономарев
– Очень важно учесть, что решения на открытом коде – это не противоположность проприетарного ПО в том плане, что они не полностью бесплатны. Сегодня нет практически ни одной информационной технологии, где открытый код не использовался бы в той или иной степени: любой разработчик может взять его за основу и, опираясь на него, создавать свое решение. Финальный же результат для клиента мало отличае».
Поэтому при выборе ПО, созданного на основе open source -решений, нет необходимости использовать какие-то отличные от выбора лицензионного софта критерии. Как и всегда, нужно обращать внимание на безопасность решения, примеры его успешного использования и анализировать, подходит ли оно по функциональности для вашего бизнеса.
Также необходимо обратить внимание на лицензию СПО: например, может ли пользователь кастомизировать решения под себя или нет, может ли использовать в закрытых коммерческих проектах, развивать собственный форк или не может.
Дмитрий Раков
– Наверное, одним из главных признаков хорошего СПО является его популярность. Системные администраторы в России, да и во всём мире, регулярно пробуют новые решения, и только лучшие из них, доказавшие свою высокую работоспособность в «боевых» условиях становятся по-настоящему востребованными.
Следует обратить внимание на историю и стабильность продукта – не посещают ли разработчика мысли «а брошу я всё это и напишу по новой». Хорошие продукты развиваются плавно и стабильно, сохраняя обратную совместимость.
Также следует обратить внимание и на совместимость его с действующим ПО, чтобы эффект от такой связки был положительным и по возможности синергетическим. А оценить это можно только путем тестирования.
Иван Федоров
– В первую очередь нужно отталкиваться от конкретной задачи, которую требуется решить. ОС может быть установлена как на рабочие места сотрудников компании для работы с каким-либо прикладным ПО, так и на серверное оборудование с целью запуска на нем каких-либо сервисов.
Как правило, при выборе системного/прикладного ПО сотрудники компании обращают внимание на уже имеющийся опыт использования данного ПО в различных сегментах рынка. Можно ли с его помощью решить поставленные задачи? Совместимо ли оно с имеющимся в компании оборудованием или требует его апгрейда? Кем поддерживается данное ПО, как часто обновляется? Насколько популярно ПО, можно ли в случае возникновения проблемы быстро найти решения на форумах и в тематических блогах? На все эти вопросы следует найти ответ в процессе поиска.
Илья Долгих
– Ремарка 1. Сейчас вопрос использования открытого, свободного и в идеале импортозамещенного программного обеспечения стоит перед всеми компании в РФ. Однако, прежде чем отвечать на вопросы, вынужден сделать ремарку об этих понятиях и определиться с терминологией.
Свободное программное обеспечение и программное обеспечение с открытым исходным кодом – это два разных понятия и далеко не все свободно распространяемое программное обеспечение имеет открытый исходный код и наоборот. В среде разработки существует три понятия, которые путают: свободное (Free Software), открытое (OpenSource) и бесплатное (Freeware) программное обеспечение.
СПО не может быть проприетарным и нарушающим «четыре свободы» лицензии GNU:
- Свобода 1 – запускать программу в любых целях.
- Свобода 2 – изучать программу и изменять под свои задачи (обязательный доступ к исходным текстам).
- Свобода 3 – распространять копии программ.
- Свобода 4 – улучшать программу и публиковать эти улучшения на благо всех людей.
Существует два мировых сообщества Open Source Initiative (OSI) и Free Software Foundation (FSF), занимающихся одним и тем же делом-продвижением идеи открытого и свободного ПО. Однако сторонники OSI и FSF по-разному понимают термины «свободный» и «открытый» исходники.
FSF акцентирует внимание на свободах пользователей, поскольку именно права человека на свободное распространение, модификацию и изучение используемого ПО является главным достоинством свободного открытого ПО. По мнению FSF «открытый код» не полностью передает важность движения и потенциальных долгосрочных социальных проблем, вызванных закрытым программным обеспечением. Соответственно FSF использует термин «free software».
OSI, в свою очередь, считает, что слово free сбивает людей с толку, намекая на бесплатность, и делают упор на эффективность открытых исходников как метода разработки, модернизации и сопровождения программ. OSI применяет термин – open source software.
Является ПО свободным или открытым зависит от лицензии, на условиях которой ПО и распространяется, и от того одобрена ли эта лицензия OSI или FSF.
Ремарка 2. Также хочется отметить, что фактически 100% компаний, на всем обозримом временном горизонте использовали тот или иной вид СПО в своей деятельности. Просто потому, что все использовали месенджеры, драйверы и программы, скачиваемые с официальных сайтов различных производителей оборудования, утилиты для решения тех или иных чисто айтишных задач и много другое.
Отвечая на вопрос в целом, по использованию СПО в инфраструктуре на корпоративном рынке, стоит обратить внимание, на стратегию развития ИТ в конкретной компании, базирующуюся на стратегию компании в целом. Сначала необходимо ответить на вопрос, какие конкретно бизнес- потребности информационные технологии должны закрыть в том или ином производственном процессе, и только потом приступать к выбору какого-либо решения.
Предполагаю, что в нашем случае речь пойдет об Open Sourse-программном обеспечении с открытым исходным кодом, распространяемым на условиях свободных лицензий. В свою очередь свободные лицензии делятся на два типа:
- permissive (либеральные, разрешительные: BSD, MIT, Apache). Позволяют использовать открытый программный код для создания коммерческого (проприетарного) ПО.
- copyleft – взаимные лицензии (General Public License, Mozilla PL, Common PL). Взаимные лицензии содержат принципиальное условие: используя этот программный код в своем продукте, разработчик должен распространять получившийся продукт на условиях исходной программы-принцип взаимности. Еще подобные лицензии называют «вирусными».
В первую очередь клиенту при выборе российской ОС надо обратить внимание на свои потребности, составить чек-лист критериев отбора решения и только потом приступать к выбору решений.
Выбор конкретной ОС имеет чисто прикладное значение, поскольку сама ОС не важна, важны лишь запускаемые в ней программы, в которых 99% времени и работают пользователи. Таким образом основным критерием является совместимость ОС с используемым ПО пользователей.
Дополнительными факторами могут являться поддержка и совместимость ОС с какими-либо инструментами управления инфраструктурой, соответствие ОС законодательству, например, в части ФЗ-152, ее стоимость или стоимость ее поддержки в долгосрочной перспективе.
Также ключевым фактором будет реальная стоимость проекта миграции текущей инфраструктуры на решения с выбранной ОС, и долгосрочные затраты на сопровождение и развитие.
Дмитрий Заруднев
– При выборе российской ОС следует обратить внимание на возможность развертывания и запуска вашего ПО в текущей операционной системе. Требуется детально изучить вопросы лицензирования ОС и безопасности. Дополнительным плюсом при выборе будет наличии сертификатов ФСТЭК и ФБС, особенно, если ваша компания занимается разработкой программного обеспечения для госсектора.
Изучите проекты, в которых используется ОС. Опыт успешного внедрения в крупных проектах и организациях является значительным фактором при выборе. Рекомендую в том числе, уточнить наличие технической поддержки и уровень ее доступности. Последним, но немаловажным фактором, является цена продукта.
Вадим Сабашный
– При выборе отечественной операционной системы прежде всего стоит обратить внимание на надежность и безопасность: ОС должна иметь высокий уровень защиты от вирусов и хакерских атак, а также гарантировать сохранность конфиденциальной информации.
Вторым по важности фактором является доступность необходимого программного обеспечения на данной платформе или совместимость с другими операционными системами на уровне бинарных файлов или исходных кодов. Важным фактором также является наличие поддержки и регулярный выход обновлений.
При оценке СПО прежде всего следует проверить, решает ли оно необходимые бизнес-задачи в полном объеме. В любом случае система будет использоваться в комплексе с другим программным обеспечением, поэтому важным критерием становится наличие технических возможностей интеграции и поддержки стандартных для отрасли протоколов и интерфейсов. Также рекомендую обратить внимание на то, кто является разработчиком и принимает решения о внесении изменений от разработчиков.
Филипп Щиров
– Прежде всего составьте список ПО, которые уже используются в организации, и посмотрите, могут ли они работать на ОС СПО, а также, какие из них, в противном случае, могут быть заменены на аналоги.
Далее обговорите, какие механизмы будут выбраны для миграции данных с текущего на замещающее ПО. Также обратите внимание на навыки подрядчиков и самой организации. Важно понять, сможете ли вы обслуживать СПО. Если нет, подумайте, каким образом необходимые компетенции будут приобретены. Например, с помощью новых подрядчиков или проведения обучения внутри компании.
Николай Молчанов
– В случае с самим открытым исходным кодом совершенно неважно, где он написан – в России или за рубежом. Нередко такие решения создаются международным сообществом разработчиков, в числе которых могут быть и российские. Open Source на то и открытый, что у него нет географической привязки.
Однако есть компании, которые разрабатывают так называемые форки: от основной ветки Open Source отделяется доступный на данный момент код, и после этого ведется его разработка уже собственными силами. Получается гибридный продукт: на выходе он коммерческий, но в его основе лежит открытый исходный код. И если такие решения создает российская компания, то это означает, что она всегда будет в пределах досягаемости, поскольку санкции закрыли доступ ко многим зарубежным коммерческим решениям, в том числе и на базе Open Source.
Что касается выбора, то прежде, чем выбирать поставщика, компания должна определиться, хочет ли она иметь дело с Open Source или лучше предпочесть коммерческое решение. Бытует стереотип, что Open Source бесплатный, но на самом деле это не так – сам код компания получит бесплатно, но внедрение, доводка, интеграция в существующую инфраструктуру могут обойтись в разы дороже, чем покупка коммерческого решения. Если для такой оценки не хватает собственной экспертизы, имеет смысл обратиться за услугой технологического консалтинга к внешним экспертам.
Тимур Бадретдинов
– Основные выгоды от использования ПО с открытым исходным кодом в том, что любой участник сообщества, будь то ИТ-компания, конечный заказчик или частное лицо может как вносить какие-то улучшения и изменения в продукт, так и пользоваться наработками других контрибьюторов.
Амир Гафуров
– При выборе российской ОС необходимо обращать внимание на ее совместимость с существующей инфраструктурой компании и наличие необходимого функционала для ее работы. Для оценки возможностей СПО для конкретных нужд компании можно провести комплексный анализ бизнес-процессов и запросов пользователей, а также рассмотреть отзывы и рекомендации других организаций, использующих данное решение.
Игорь Ляпунов
– Стоит начать с решаемой задачи и требований, которые будут предъявляться к ОС и базовым сервисам, например, к почте, базам данных.
Исходя из этого, станет понятно, нужны сертифицированные ОС или это необязательно. Также не менее важно посмотреть на наличие необходимых компонент решений (баз данных и др.) для выбранных версий операционных систем. Так, складывая по кусочкам решение на базе СПО и добывая информацию по аналогичному опыту в Интернете, можно оценить все возможности и препятствия использования этого ПО.
Вопрос 2. Выгоды и плюсы от использования отечественного ПО с открытым исходным кодом?
Вадим Пономарев
– Основной плюс использования решений на открытом коде – меньшая зависимость от глобальных событий. Дистрибутив продолжит функционировать в любом случае, в отличие от ситуации с лицензионным ПО, которое при неоплате откажется работать. Когда Selectel несколько лет назад принимал решение о развитии собственной платформы на базе открытого ПО, преимущества не казались настолько очевидными – затраты были велики, в то время как существовали проверенные временем альтернативы от крупных вендоров. Тем не менее, события последнего года и уход крупных зарубежных разработчиков особенно ярко выделили преимущества и доказали, что мы оказались правы.
Еще одним плюсом СПО являются требования к оборудованию. Среди крупных разработчиков, например, средств визуализации существуют достаточно жесткие ограничения используемой инфраструктуры, в то время как open source- решения зачастую готовы работать с любым «железом», которое позволяет запустить и использовать продукт.
Существенным преимуществом использования отечественного ПО является соответствие определенным требованиям государства. Например, поддержка российских стандартов шифрования. Также отечественное ПО позволяет использовать отечественные серверные решения, так как совместимость была протестирована и проверена самим разработчиком решения.
Минусом использования отечественного ПО, скорее всего, станет «отставание» от индустрии, потому что продукт, поддерживаемый одной страной, всегда будет немного отставать от проектов, поддерживаемых на глобальном рынке.
Наталия Ефимцева
– В последнее время было множество громких материалов о добавлении в различные зарубежные open source- решения закладок (т.е. вредоносного кода), проявляющих свое вредоносное действие по территориальному признаку либо пользователя, либо непосредственно установки решения. Последствиями таких атак могут быть как репутационные, так и финансовые издержки.
Всемирное Open Source сообщество выступило против подобных действий в своей среде, но исключить такие инциденты крайне трудно. При использовании отечественного ПО с открытым исходным кодом вероятность таких атак значительно меньше, хотя и не может быть исключена.
Также большинство Open Source- лицензий сформировано зарубежными компаниями. Даже для свободного ПО лицензионное соглашение присутствует и может иметь ограничения, связанные с его использованием для стран или компаний, находящимися под санкциями. Содержание и структуру этих соглашений, с одной стороны, контролирует сообщество, в котором существенную долю составляют зарубежные участники.
Здесь потенциально возникает множество рисков. Использование отечественного ПО поможет снизить или избежать этих рисков. Хотя здесь и остается еще не решенной проблема, связанная с тем, что многие российские продукты основаны на продуктах с «зарубежными» open source- лицензиями.
Вопросы поддержки и доступности решений также оказываются достаточно важными, особенно для бизнеса. Например, некоторые компании закрывают доступ к готовым образам своих продуктов с территории России. Другие вендоры не поступают так радикально, но не оказывают поддержку своих решений для российских компаний. Использование отечественного ПО позволяет избежать данных рисков и сложностей при внедрении и эксплуатации.
Интересным примером является инициатива Московской области, которая приняла закон о налоговом вычете за использование российское ПО.
Игорь Ляпунов
– Одним из важных аспектов в текущих реалиях является объединение усилий и активизация работы российских компаний-разработчиков по развитию российского СПО. В перспективе трех лет это принесет заметные плоды, увеличит разнообразие и надежность решений на рынке.
Кроме того, важным является тренд регуляторов на внедрение методологии безопасной разработки у российских вендоров, что тоже сыграет ключевую роль в горизонте пяти лет. Таким образом, станет больше интегрированного и качественного программного обеспечения. В остальном СПО уже доказывает, что способно покрыть любые потребности.
Григорий Розов
– Прежде всего это вендорская поддержка. С уходом западных вендоров потребность крупных ИТ-инфраструктур в вендорской поддержке не исчезла. Как правило, команды для развития ИТ-инфраструктуры у заказчика существуют далеко не всегда и не в полном объеме. Расходы на поддержку инфраструктуры – это основной элемент бюджета большинства компаний. Поэтому техническая поддержка от вендора крайне важна и потребность в ней есть. Российские производители ПО такую поддержку предоставляют.
Дмитрий Раков
– Главная выгода от использования отечественного ПО с открытым исходным кодом заключается в отсутствии риска блокировки доступа к хранилищу исходных кодов в условиях санкций.
Другим важным преимуществом является предоставление услуг по технической поддержке и сопровождению на русском языке. Но отечественное СПО обладает и преимуществами иностранного, а именно – доступностью исходного кода, высоким уровнем безопасности, простотой доработки под определённые нужды.
СПО можно применять практически в любом проекте, можно сертифицировать решения в ФСТЭК, можно проводить сканирование кода на уязвимости – с коммерческим ПО всё это невозможно. А ещё существует множество «идейных» людей, стремящихся найти уязвимости и закрыть их в популярных открытых проектах. Поэтому в большинстве случаев можно быть уверенным в их полной безопасности.
Илья Долгих
– Бесспорными плюсами является соответствие отечественного ПО российскому законодательству и снижение рисков функционирования используемого в хозяйственной деятельности ПО, из-за геополитической обстановки. Условным плюсом является возможность доработки ПО под нужды своей компании.
Однако данный плюс перекрывает минус зависимости компании от конкретных, нанятых в штат разработчиков, занимающихся доработкой систем на основе продуктов с открытым кодом.
Вадим Сабашный
– Прежде всего это близость разработчиков и возможность к ним обратиться при необходимости. Также в отечественном ПО можно ожидать поддержку специфичных для нашей страны протоколов, сервисов и программных интерфейсов к внешним системам. Скорее всего, для отечественного ПО больше комьюнити и специалистов на рынке труда.
Иван Федоров
– Во-первых, отсутствие материальных издержек на покупку лицензий. Во-вторых, ПО с открытым кодом подразумевает формирование сообщества разработчиков, что определенно идет на пользу как специалистам, так и разрабатываемому продукту.
Дмитрий Заруднев
– Самым значительным плюсом использования отечественного ПО с открытым исходном кодом является снижение затрат на разработку требуемого ПО силами вашей организации. Если выбранное вами СПО является достаточно популярным, то в этом случае к плюсам можно отнести большое количество вариантов использования данного СПО в разных проектах и организациях. Это, безусловно, позволяет выявлять и исправлять проблемы быстрее. Большое сообщество поддержки СПО, наличие специализированных форумов также позволяют быстрее получать поддержку по проблемам или требуемым доработкам.
Амир Гафуров
– Выгоды от использования отечественного ПО с открытым исходным кодом включают более низкие затраты на приобретение и поддержку, а также возможность внедрения индивидуальных изменений в исходный код. Кроме того, такие решения могут быть более надежными и безопасными благодаря возможности проверки кода разработчиками и сообществом пользователей.
Филипп Щиров
– Распространённые отечественные ПО с открытым исходным кодом являются ответвлениями – форками – зарубежного СПО, то есть мы получим те же плюсы, что и при его использовании: – экономию на лицензиях сейчас и в случае развития компании, – увеличение количества рабочих мест, – обновление компьютерного парка, – обновление устаревшего ПО.
Вопрос 3. Типичные проблемы, возникающие при внедрении и работе с инфраструктурными решениями на базе СПО?
Вадим Пономарев
– Основной проблемой является не слишком большая развитость рынка труда – решение на open source нужно администрировать и при необходимости развивать на клиентской стороне. По данным JetBrains, в 2021 году Россия не входила в топ-5 стран с наибольшим количеством разработчиков, расположившись на шестом месте. В 2022 году исследование в нашей стране не проводилось, но есть основания полагать, что количество специалистов сократилось.
Так как разработка СПО – достаточно комплексный процесс, который требует трудозатрат, наличие квалифицированных специалистов как со стороны клиента, так и со стороны разработчика критично. Есть некоторая специфика при собственной кастомизации СПО, и к разработчикам, работающим с СПО предъявляются дополнительные требования. Такой разработчик должен уметь взаимодействовать с комьюнити проекта, вести документацию, участвовать в общих обсуждениях и, отчасти, быть в команде вендора.
Только выполняя требования комьюнити и основного разработчика, можно вносить изменения и правки в исходный проект. В противном случае возникнет необходимость держать собственные копии (форки) проекта, что значительно усложнит их дальнейшую поддержку и обновление.
Есть и обратная сторона использования СПО в собственных решениях – это большая и бесконтрольная изменяемость проекта. То есть при каждом новом обновлении ПО вы получаете несколько сотен, а то и тысяч изменений, сделанных комьюнити проекта. При этом вы не можете достоверно проверить источник и качество этих изменений.
В 2022 году было несколько историй, когда в крупные open-source проекты были умышленно внесены правки, приносящие вред пользователям, и они успешно прошли code-review и все стандартные стадии проверки. Использование СПО предполагает, что вы понимаете эти риски и имеете средства контролировать качество и безопасность на своей стороне.
Дмитрий Раков
– Можно выделить две типичные проблемы. Первая связана с обеспечением совместимости с аппаратной составляющей ИТ-инфраструктуры. Так что наилучшим способом минимизации таких рисков будут инфраструктурные ПАК, где проблемы совместимости уже решены на стороне поставщика.
Вторая – это необходимость финансовой поддержки разработчика. К сожалению, не все пользователи это понимают. В России нет культуры отчисления части прибыли разработчикам СПО, на базе которого реализованы используемые ими решения. И если рядовых пользователей винить сложно, то компаниям пора перестраиваться. В противном случае, в отсутствии финансирования разработка сворачивается, а поддержка больше не оказывается.
Григорий Розов
– Если говорить о чистом СПО, то при внедрении можно встретить одну из ошибок, которая будет либо серьезно осложнять эксплуатацию решения, либо вообще не позволит перевести систему в продуктивный режим в ряде ситуаций. Ждать исправления можно месяц, а можно и год.
Если говорить о российском ПО на базе СПО, то здесь проблемы типовые. В работе напрямую с вендором можно встретить ошибки в документации, не всегда оттестированные свежие релизы. По опыту такие проблемы бывают не только у российских вендоров. Чтобы свести данные проблемы при работе с российским ПО к нулю, необходимо обратиться к системному интегратору, у которого имеется оттестированный вариант релиза требуемого ПО и значительный опыт работы с данным продуктом.
Еще стоит обратить внимание на то, что СПО – это Linux. А типичный системный администратор уровня Enterprise, как правило, работает с Windows.
Поэтому здесь потребуется переобучение сотрудников для работы не только с продуктом, но и с базовым стеком технологий Linux ОС.
Наталия Ефимцева
– Поддержка и безопасность могут являться двумя основными вопросами актуальными для подобных решений. Безопасность не менее актуальна и для проприетарных решений, и количество атак и уязвимостей связано не только с открытостью кода, но и с популярностью самого продукта.
Многие базируются на других open source- компонентах и имеют множество зависимостей, и получается пирамида: компрометация любого даже небольшого кубика приводит к потенциальной уязвимости во множестве связанных решений.
Другая проблема, связанная с безопасностью – то, что некоторые решения могут распространяться свободно, но без приобретенной поддержки обновления безопасности будут поставляться нерегулярно и с задержкой. Если вопросы интеграции и недоступности того или иного функционала компании-клиенты могут решить самостоятельно или с привлечением компании по аутсорсингу, то вопрос безопасности более комплексный и фундамент для некого закладывается именно разработчиками open source- решений, зрелостью их DevSecOps процессов и вовлеченностью.
Отечественные open source-решения значительно более молодые. Например, не все продукты имеют четкую дорожную карту и некую доказательную базу следования по этой карте, возникает риск того, что решение может быть заброшено как его создателями, так и сообществом или выпуск обновлений безопасности или обновлений, закрывающих баги, будет несвоевременным.
Николай Молчанов
– Самая слабая сторона – отсутствие технической поддержки и дорожной карты, плюс они не гарантируют нужную функциональность. Но тут важно разделять непосредственно решения с открытым исходным кодом и коммерческий или полукоммерческий продукт на его основе.
В первом случае задачи по техподдержке, адаптации, внедрению, устранению ошибок ложатся на плечи компании. Само решение она получает бесплатно, но ей, возможно, придется серьезно расширять штат для его техподдержки и доработки под ее нужды либо обращаться за этими же услугами на аутсорс. В результате это может обойтись дороже, чем покупка стандартного коммерческого коробочного решения со всеми прилагающимися сервисными услугами.
Во втором случае мы уже имеем дело не с чистым Open Source, а с гибридной схемой, когда берется решение с исходным кодом, дорабатывается и продается уже как коммерческий продукт. В этом случае оно уже предполагает и соответствующую техподдержку.
Иван Федоров
– Как минимум, проблема несоответствия ряду корпоративных требований, касающихся надежности/безопасности/наличию технической поддержки. За коммерческое ПО ответственность несет конкретная компания-разработчик. С ней или с ее партнерской сетью можно заключить договор на техническую поддержку и получать гарантированный сервис в случае ошибок/сбоев.
В компаниях с высокими требованиями к надежности ПО, где время на устранение возникших проблем исчисляется в лучшем случае часами, ответственный топ-менеджмент вряд ли допустит несертифицированное ПО, за которое несет ответственность какое-либо сообщество разработчиков.
Илья Долгих
– По объективным причинам СПО в инфраструктуре занимает незначительную долю рынка в сравнении с известными западными монстрами ИТ-отрасли. И как следствие на рынке труда отсутствует значимое количество специалистов, знакомых с внедряемым СПО, тем более специалистов, участвовавших в серьезны проектах, связанных с миграцией.
Компания, чей вид деятельности не связан с ИТ, должна сконцентрироваться на своих основных производственных процессах и не нагружать свои ИТ-подразделения крупными проектными задачами, с поиском специалистов, требуемых компетенцией. Реальная стоимость и сроки таких проектов практически непредсказуемы, а критерии их успешности трудно формализуемы. Поскольку проекты в рамках внутренних ИТ-подразделений часто реализуются даже без написания формального технического задания, то результат таких проектов случаен.
Дмитрий Заруднев
– К типичным проблемам можно отнести начальный этап внедрения. Самыми сложными, на мой взгляд, являются стартовая настройка среды выполнения и установка всех зависимостей для работы СПО с последующей интеграцией в ваше ПО.
К проблемам можно отнести отсутствие постоянной технической поддержки. Вы можете заявить о проблеме или попросить расширить текущий функционал, но вы не получите в ответ точных сроков выполнения. Возможны ситуации, когда СПО подходит вам по функционалу, но сама реализация является не оптимальной с точки зрения использования аппаратных ресурсов. Это может повлечь дополнительные издержки на закупку оборудования, если остановить свой выбор на данном СПО.
Вадим Сабашный
– Типичные проблемы:
- Нехватка экспертов по свободному программному обеспечению, что может повлечь за собой провальное внедрение проекта.
- Сложности в обновлении и совместимости различных компонентов программного обеспечения, которые могут воздействовать на производительность и стабильность работы системы.
- Отсутствие поддержки со стороны производителя программного обеспечения в случае возникновения проблем или необходимости решения инцидентов.
- Сложность настройки и интеграции с другими системами, что может затруднять процесс внедрения и снижать эффективность работы.
- Ограниченность функционала по сравнению с коммерческими аналогами, что может лимитировать возможности использования и расширения функционала системы.
- Необходимость постоянного мониторинга и анализа системных логов для выявления проблем и устранения неполадок в работе системы.
- Необходимость постоянного обновления и поддержки системы для обеспечения безопасности и защиты от угроз внешней среды.
Тимур Бадретдинов
– Три ключевых типа проблем: совместимость инфраструктурных решений с различным оборудованием и сторонним ПО, недостаточно качественно описанная документация, нехватка обучающих материалов для ИТ-специалистов и пользователей.
Амир Гафуров
– Типичные проблемы, возникающие при внедрении и работе с инфраструктурными решениями на базе СПО, могут быть связаны с необходимостью внесения изменений в существующие процессы и приложения, сложностью интеграции с программами зарубежных производителей и отсутствием профессионалов, специализирующихся на данном типе решений.
Игорь Ляпунов
– Важной проблемой является разрозненность программного обеспечения. СПО по сравнению с проприетарным имеет низкую интегрированность с другими системами, потому что выкладывается именно как «софт» и над собой часто не имеет сфокусированных продуктовых свойств.
Как правило, все, что предоставляется как СПО является базовыми версиями и не поддерживает Enterprise-функций и более сложных конфигураций. Простым примером здесь являются: невозможность подключения к службам каталогов, создания сложных отказоустойчивых кластеров баз данных и другое.
Филипп Щиров
– Проблемы могут возникнуть абсолютно разные: от несовместимости с текущим ПО до трудно диагностируемых. Например, когда ошибка возникает раз в полгода, а никто не понимает её причину.
С простыми ролями: интернет-шлюзами для небольших организаций, серверами хранения, контроллерами домена – средний и крупный бизнес может справиться самостоятельно.
А для решения более сложных вопросов, например, с серверами баз данных или системами резервного копирования, потребуется помощь либо сторонних подрядчиков, либо разработчиков и поставщиков.
Вопрос 4. Какие из них компания-клиент может решить сама, какие – только разработчики и поставщики?
Вадим Пономарев
– Разработчик в первую очередь занимается обновлениями и развитием ПО, в том числе, в плане безопасности, а также поддержкой пользователей, в то время как клиент может кастомизировать решение под свои нужды.
Если кастомизация не узконаправленная под конкретный проект или компанию, то клиенту стоит предложить эти изменения основному разработчику. Таким образом, не будет необходимости держать собственный форк проекта и значительно упростится дальнейшая поддержка. Также это именно тот путь, которым развивается все СПО в мире.
Дмитрий Раков
– Начать оказывать финансовую поддержку разработчикам СПО может любой желающий, в том числе и компания-клиент. Этим она обеспечит дальнейшее развитие и поддержку продукта. А вот проблемы, связанные с доработкой системы, устранением ошибок, выявлением уязвимостей, развитием функциональности и прочим, связанным с применением программного кода, могут решить только сами поставщики или разработчики такого ПО. Все остальные задачи выполнимы системными интеграторами, а также просто грамотными ИТ-специалистами, если мы имеем в виду компанию-клиента.
Иван Федоров
– Хорошим направлением развития для отечественных разработчиков будет наличие отечественных центров компетенции по ОС, которые смогут взять на себя ответственность за ту или иную сборку конкретного ПО и гарантировать его надежность и качественный сервис.
Также следует разделять системное ПО и прикладное, предназначенное для конкретного сегмента рынка. Достаточно популярным является симбиоз коммерческого ПО и ОС. Когда на базе системного ПО с открытым кодом отечественные разработчики строят свое коммерческое решение.
При этом в качестве операционной системы, СУБД и прочих компонентов выбираются конкретные, проверенные временем и сообществом сборки, на которых и строится разработка. По итогу получается продукт, за который отечественный разработчик берет ответственность перед рынком с точки зрения надежности, сопровождения и развития. По такому направлению идет и наша компания, предлагающая свое биллинговое решение на базе связки ОС и других различных компонентов с открытым кодом: Linux, PostgreSQL, FreeRADIUS и другими.
Илья Долгих
– Задачи приемки в опытную и промышленную эксплуатацию внедряемых систем, задачи, связанные с поддержкой и функциональным тестированием, стоит решать своими силами. Также самостоятельно стоит заниматься формированием и обучением собственного штата поддержки в связи с появлением новых инфраструктурных решений. Остальное лучше давать на откуп поставщикам решений, предварительно сформулировать техническое задание или хотя бы реестр основных потребностей и функциональных элементов будущей системы.
Дмитрий Заруднев
– Клиент может решить часть проблем самостоятельно. При наличии компетенций разработчиков, многие ошибки можно исправить собственными силами, а также доработать СПО под свои нужны. Исключение составляют серьезные, архитектурные переработки ПО. Данные задачи требуют полного понимания проекта и в этом случае лучше обратиться к разработчикам СПО.
Вадим Сабашный
– Компания-клиент может решить проблемы корректного выбора программного обеспечения, чтобы функционал соответствовал требованиям, а также выполнять мониторинг работоспособности. Для решения остальных проблем потребуется привлечение собственных разработчиков или обслуживающей организации.
Николай Молчанов
– Теоретически проблемы компания может решить и сама, если речь идет именно об Open Source, а не о коммерческом решении на его основе. Но для этого ей потребуются серьезные инвестиции.
Сейчас главным препятствием на пути развития Open Source остается недостаток экспертизы. Такие решения требуют высочайшей экспертизы на стороне компании, которая их использует, поскольку нужны большие усилия, чтобы добиться нужной функциональности, встроить их в инфраструктуру, обеспечить поддержку. Таких специалистов не хватало и раньше, а сейчас дефицит ощущается особенно остро, плюс их найм обойдется недешево. Поэтому зачастую будет эффективнее и дешевле обратиться в такие компании, как наша, за внешней экспертизой.
О разработчиках и поставщиках говорить не вполне корректно, если речь идет непосредственно об открытом коде – он находится в «свободном плавании», и никакой поддержки со стороны его создателей по умолчанию не предполагается. Если добавляется доработка, поддержка и так далее – мы уже имеем дело не с Open Source как таковым, а с коммерческим решением на его основе. И здесь уже выстраиваются стандартные отношения по модели «заказчик – поставщик».
Амир Гафуров
– Компания-клиент может решить проблемы, связанные с адаптацией внутренних процессов под новое решение и подготовкой персонала к работе с ним. Однако решение проблем, связанных с разработкой и интеграцией нового функционала, требует участия разработчиков и поставщиков СПО.
Игорь Ляпунов
– Проприетарная модель приучила нас получать функционал «из коробки». Она предлагает нам готовые продуманные решения за деньги. В этом случае мы приобретаем продукт.
Модель СПО бесплатно дает нам только базовые компоненты («полуфабрикаты») и продукт под себя мы должны собрать сами. Тут возникает необходимость набора специалистов, которые смогут собрать разное СПО в единый продукт для компании либо нужно прибегать к услугам консультантов. Все зависит от сложности задачи в моменте ее появления и необходимости дальнейшего развития решения. Есть мнение, что в перспективе 3-5 лет появится слой компаний-разработчиков решений на базе СПО, и эта дилемма будет решена.
Григорий Розов
– При наличии сотрудника, выделенного под администрирование Linux, проблемы, связанные с расхождением в документации при установке, можно решить самим. А вот проблемы, связанные с самим продуктом, получится решить только с вендорской поддержкой. При отсутствии у заказчика в штате такого инженера, который сможет поэкспериментировать с продуктом на базе Linux, внедрение даже не начнется.
Вопрос 5. Насколько готовы службы техподдержки российских ОС помогать клиентам с проблемами, возникающими при интеграции их решений с программами зарубежных производителей? Удовлетворены ли вы качеством техподдержки и обратной связью с компанией-разработчиком?
Вадим Пономарев
– В настоящий момент мы только на стадии добавления российских ОС в список предоставляемых сервисов Selectel. Мы тестируем несколько ОС от отечественных производителей, подходящих под разные задачи наших клиентов, но пока не набрали достаточно опыта для развернутого ответа по взаимодействию. Взаимодействие происходит в режиме «запрос на фичу» – ответ, без оперативной поддержки со стороны производителей и пока нареканий нет.
Дмитрий Раков
– Российским компаниям ещё только предстоит перестроиться. Большинство из них привыкли работать с крупными заказчиками, особенно в госсекторе, но конкуренция всё меняет. Компании не готовы предоставлять образцы ПО рядовым системным администраторам, не оказывают поддержку в публичных телеграмм-каналах или форумах, требуя официальные письма и подтверждение наличия лицензий. Это создаёт проблемы даже для лицензионных пользователей, а развитие комьюнити ставится под вопрос.
Мы часто сталкиваемся с тем, что лицензия приобретена на заказчика, и у нас просто нет возможности обратиться за поддержкой, что вместо решения проблемы превращается в процесс бесполезной переписки. Работа энтузиастов, записывающих уроки на Youtube или пишущих статьи, wiki и т.д. в таких условиях вообще невозможна. Это всё ставит в выгодное положение иностранных производителей, дающих доступ к ПО для личного некоммерческого использования, обучения и разработки.
Иван Федоров
– Насколько готовы – покажет время. Этот сегмент российского ИТ-рынка достаточно молод. Здесь очень важно качество официальной документации и оперативная компетентная поддержка разработчиков на различных тематических форумах. Но и качество самого ПО важно, если продукт принимается рынком, то сообщество поможет его развивать и поддерживать, если же нет – никакой сервис и документация не спасут.
Илья Долгих
– Они стараются… вероятно, очень стараются. Но тот путь, который прошли западные гиганты за десятилетия, невозможно пробежать за пару лет, даже при очень большом желании и финансовых возможностях. В связи с огромным спросом и бурным ростом компаний, производящих ПО в российском сегменте, возникают классические трудности разработчиков – качество тестирования выходящих в релиз решений и соответствие документации на системы последнему релизу.
Дмитрий Заруднев
– За последние годы качество поддержки со стороны российских производителей ПО значительно повысилось. Всё больше компаний используют российские ОС, возникает больше вопросов. В условиях конкуренции и роста рынка поставщики вынуждены повышать качество поддержки и сокращать время реагирования. Мой опыт общения с технической поддержкой ряда поставщиков ПО подтверждает это. Ответы стали обширными, зачастую от постановки проблемы до ее решения проходит не более 24 часов.
Григорий Розов
– Техническая поддержка российских ОС помогает своим клиентам, службы технической поддержки постоянно развиваются. Оперативность работы страдает только из-за общей перегрузки всех российских вендоров ПО. Качество технической поддержки «плавает» только в части документации, сами инженеры, как правило, достаточно квалифицированы.
Филипп Щиров
– Это не вопрос службы поддержки российских ОС. Они занимаются тем, что сопровождают написанные или импортированные ими ПО. Не исключено, что с определёнными зарубежными или даже с российскими ПО служба техподдержки никогда не встречалась, поэтому у неё может не быть специалистов по данным системам. Тогда вопросы придётся решать либо с помощью сообществ программ, с которыми возникли проблемы, либо с помощью сторонних, возможно, даже зарубежных подрядчиков.
Наталия Ефимцева
– Действительно, вопрос поддержки является очень важным, особенно в условиях возросшей потребности в российских ОС, и разные компании подходят к этому по-разному. Например, совместно с ГК Астра мы создали совместное предприятие для реализации проектов импортозамещения. На промежуточном этапе специалисты ICL поддерживают работоспособность ПО ушедших с рынка зарубежных вендоров с последующей миграцией на решения Астры.
Кроме того, плотно сотрудничаем со многими вендорами отечественного ПО (Р7-Офис, CommuniGate и др.) – не только внедряем и поддерживаем эти продукты, но и регулярно предоставляем обратную связь вендорам от пользователей. Получается синергия, позволяющая своевременно наиболее критичным требованиям попадать в дорожную карту продуктов.
Николай Молчанов
– Open Source, как уже было сказано, по умолчанию не предполагает техподдержки. Она может предоставляться на коммерческой основе – например, при подписке на решение, но тогда оно переходит из разряда свободных в разряд полукоммерческих или коммерческих.
Тимур Бадретдинов
– Четыре самых известных производителя российских ОС имеют достаточно адекватные уровни поддержки для клиентов. Интеграция российских решений с зарубежным ПО обычно является задачей компаний-интеграторов или специальных внедренческих подразделений производителей, а не функцией техподдержки. При этом, если клиенту хочется «персонального подхода», например, наличия выделенного технического аккаунт-менеджера, то такие опции также доступны у ряда российских вендоров в пакетах расширенной или привилегированной поддержки.
Амир Гафуров
– Готовность служб техподдержки российских ОС помогать клиентам с проблемами, возникающими при интеграции их решений с программами зарубежных производителей, зависит от опыта и компетенций конкретных компаний-разработчиков. Необходимо обращаться к отзывам других пользователей, чтобы оценить качество техподдержки и убедиться, что обратная связь с компанией-разработчиком доступна и эффективна.
Вопрос 6. Ваши советы тем, кто только собирается переходить на инфраструктурное решение на базе СПО.
Вадим Пономарев
– В первую очередь, хотелось бы посоветовать компаниям четко определиться с функциональностью, которая им необходима в работе решений на open source, а также понять, не нужна ли модификация или улучшение имеющейся ИТ-инфраструктуры под текущие запросы.
Кроме того, важно оценить, насколько быстро растет ваш бизнес и как скоро потребуется масштабирование используемых решений. Ясное понимание нужд компании облегчит вашу коммуникацию с интеграторами и разработчиками, а также поможет выбрать наилучшее решение из имеющихся на рынке.
Также необходимо учитывать, что потребуется найм новых ИТ-специалистов, имеющих опыт работы с этим СПО, или дополнительное обучение текущих сотрудников. Техническая поддержка интегратора в любом случае не сможет достаточно оперативно реагировать на возникающие проблемы, а также вносить все необходимые именно вашему проекту правки в исходный код. Поэтому для того, чтобы выбранные решения не тормозили развитие вашего бизнеса, придется задуматься о собственной, пусть и частичной, поддержке.
Дмитрий Раков
– Выбирайте поставщиков, проверенных временем – хорошие проекты развиваются годами и о них знает любой системный администратор. Не расценивайте СПО как бесплатный продукт, на котором можно сэкономить, а также будьте готовы к вложениям в разработку и доработку этих решений под себя. Ищите подходящего поставщика ПАК и приобретайте у него готовое решение. Если таковых нет, ищите системного интегратора, готового установить инфраструктурное СПО на имеющееся оборудование и предоставляющего требуемые гарантии работоспособности, поддержки и безопасности.
Иван Федоров
– Во-первых, не бояться этого перехода. В какой-то степени мы и так уже давно используем различного рода свободное ПО или ПО с открытым кодом. На серверах, как правило, стоит какой-нибудь из дистрибутивов Linux. Регулярно используются различного рода утилиты/среды разработки/компиляторы и т. д. Поэтому отказ от каких-либо коммерческих решений в пользу СПО не говорит о том, что новое решение будет хуже работать или иметь более скудный функционал.
Во-вторых, следить за общими тенденциями с точки зрения использования того или иного продукта/технологии. Обращать внимание на качество документации, комьюнити пользователей и разработчиков, кейсы использования.
Ну и, в-третьих, не возводить в культ ПО с открытым кодом, переход ради перехода или как «дань моде» может привести к результату обратному ожидаемому. Нужно всегда взвешенно принимать решения по поводу использования той или иной технологии/ПО для нужд бизнеса.
Илья Долгих
– СПО не цель, а средство и местами достаточно дорогое при непредвзятой оценке стоимости владения. Оно в первую очередь – средство обеспечения потребностей основного бизнеса ИТ-инструментами. И подходить к вопросам СПО надо ровно с теми же принципами, как и к обычному проприетарному ПО – через формирование и корректировку ИТ-стратегии развития, включающего аудит потребностей и модель рисков в разрезе текущей инфраструктуры. На основе скорректированной стратегии развития необходимо формировать текущий портфель проектов с ранжированием по срочности и критичности проектов, а также с учетом финансовых и кадровых возможностей.
В рамках плановых проверок компаний может возникнуть вопрос «лицензионной чистоты» установленного в компании СПО. Для минимизации рисков дополнительно следует подготовить нотариально заверенный перевод лицензионных соглашений если оригинал написан на иностранном языке. А также письмо Минэкономразвития РФ от 05.05.2009 № Д05-2235 «Об использовании свободного программного обеспечения» и ст. 1286.1 ГК РФ «Открытая лицензия».
Дмитрий Заруднев
– Тем, кто только собирается переходить на инфраструктурное решение на базе СПО я советую изучить вопросы лицензирования использования СПО. Часто уровень лицензий не позволяет использовать СПО в коммерческих проектах. Только для собственных нужд. Это важный аспект, если вы хотите работать в рамках правого поля.
Также, перед интеграцией СПО в ваше решение, проведите анализ самого кода. Редко, но всё же бывают случаи недобросовестных разработчиков, которые внедряют вредоносный код в своё ПО или же «плохой» код попадает в СПО посредством хакерской атаки. Размер сообщества разработчиков данного ПО и наличие разных каналов его поддержки также является важным моментом при выборе.
Вадим Сабашный
– Изучите потребности вашей компании. Составьте список необходимых программ и сервисов, чтобы определиться с выбором софта.
Оцените возможности свободного ПО в каждом из необходимых сегментов. Оцените, насколько уступает свободное ПО коммерческим решениям и уступает ли.
Ознакомьтесь с сообществами разработчиков и пользователей выбранного ПО. Важно понимать, что данное ПО широко используется и не возникнет проблем с поиском специалистов по его доработке и сопровождению. И чем больше пользователей у решения, тем больше вероятность, что на ошибку в ПО натолкнётесь не вы.
Произведите реальные тесты и сравнения. Не стоит стремиться к выполнению всех ваших задач с помощью свободных программ, если вы понимаете, что не уверены в их эффективности и безопасности. Произведите тесты, сравните активно используемые программы и решения, прежде чем выбирать свободные аналоги.
Обратитесь к профессиональным консультантам и специалистам. Если вы не знаете, какое программное обеспечение выбрать и как его настроить, обратитесь за помощью к профессионалам.
Наталия Ефимцева
– Высокоуровневый план может выглядеть следующим образом: формулирование набора функциональных требований; включить решения, которые удовлетворяю этим требованиям, в шорт-лист; реализовать пилотный проект; определить, каким образом может быть закрыт недостающий функционал (собственная разработка, стороннее решение, заказная разработка) и провести обучение сотрудников. Все вышеописанные действия можно выполнить самостоятельно или, например, обратиться в ICL Services, и наши специалисты сделают реализуют подобный проект под ключ.
Но на этом путь джедая не заканчивается. Внедрение СПО – это лишь верхняя часть айсберга, внедренное решение необходимо дорабатывать и поддерживать как на инфраструктурном уровне, так и на пользовательском, а это влечет за собой финансовые и ресурсные затраты. Необходимо оценить, готов ли внутренний ИТ-отдел компании самостоятельно решать эти задачи. Если такая готовность под вопросом, то имеет смысл рассмотреть варианты поддержки от вендора или от других сервисных компаний, которые на этом специализируются и готовы предоставлять 1,2 и 3 линии сопровождения.
Николай Молчанов
– Прежде всего взвесьте, что будет выгоднее и эффективнее именно вашей компании: Open Source или коммерческое пакетное решение. Вместе с коммерческим решением клиент получает и сервисные услуги. Open Source же требуют серьезной компетенции: необходима экспертиза, чтобы адаптировать продукт под конкретные задачи и поддерживать его работоспособность. И здесь потребуется либо пополнять штат соответствующими специалистами, либо обращаться за внешней экспертизой.
Амир Гафуров
– Советы тем, кто только собирается переходить на инфраструктурное решение на базе СПО, включают анализ текущей ситуации и бизнес-процессов, грамотную подготовку персонала и разработку плана внедрения с учетом особенностей компании и выбранного решения. Также рекомендуется обратиться к опыту других пользователей и специалистов в данной области для получения советов и рекомендаций.
Игорь Ляпунов
– При работе с СПО следует абстрагироваться от проприетарного ПО, перестать их сравнивать и решать задачу «с чистого листа». Это привычка, от которой отказаться сложно, но необходимо.
Григорий Розов
– Я рекомендую обращаться к системным интеграторам за советом, посмотреть готовые стенды, наметить дорожную карту миграции, провести пилоты необходимых решений.
Филипп Щиров
– Делюсь советами для тех, кто собирается переходить на инфраструктурные решения на базе свободного программного обеспечения: отнеситесь к переходу, как к полноценному проекту внедрения. Все этапы замены ПО нужно разбить на этапы.
Например, при переносе баз данных Microsoft на СПО 1С можно следовать в таком порядке: 1) файловые сервера, 2) контроллер домена, 3) сервера баз данных, 4) сервера 1С:Предприятие.
За каждый этап назначьте ответственного, обозначьте цели. Не переходите к следующему шагу, пока предыдущий не будет полностью сдан. Дождитесь, когда пройдёт полноценное тестирование и все пользователи останутся довольны результатами этапа.
Ключевые слова: инфраструктурные решения на базе свободного программного обеспечения, заказчик, разработчик, вендор, ИТ-специалисты.
Подпишитесь на журнал
Купите в Интернет-магазине
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
