14 марта 2025 г.
В современном мире ИТ-решения приобретают все большее значения для бизнеса. При этом представители компаний при разработке и использовании таких решений хотят видеть инструмент, напоминающий собой машину для освоения требующихся ему задач. О том, какие мифы существуют в области открытых технологий, насколько они соответствуют действительности и какие существуют особенности работы с такими решениями, рассмотрим в нашем материале.
Насколько просто работать с Open Source
Российскому бизнесу от ИТ-продукта нужна готовая стратегия, предсказуемость и понятные алгоритмы. Ему важно понимать, сколько будет стоить продукт и какая от него будет выгода, каким образом и насколько быстро он решит его задачи, можно ли будет масштабировать решение. Именно это компаниям и дает Open Source.
В мире софта произошла революция, когда компании поняли, что могут зарабатывать на продукте с открытым кодом, добавляя свою стоимость для бизнеса в виде поддержки, профессиональных сервисов, обновлений, интеграций и других решений. Но почему таким компаниям платят, ведь все же просто — скачал и поставил?
Так мы сталкиваемся с первым мифом в области Open Source. Если исходники и документация доступны, то их можно просто скачивать и использовать. На самом деле, все несколько сложнее. Открытое ПО пишется для решения ИТ-задач, и его разработчики редко задумываются об удобстве использования и красивых интерфейсах. По нашему опыту, базовое вхождение нового сотрудника в OpenStack занимает от двух месяцев, а без поддержки со стороны вендора этот процесс будет значительно дольше, поскольку для работы с незнакомым продуктом нужно изучать документацию, читать исходные тексты, искать ответы в интернете и в других источниках.
Второй миф. Решение на основе Open Source просто работает. В действительности при внедрении такого продукта возникает целый пласт задач, связанных с его архитектурой и интеграцией в корпоративную инфраструктуру. Если говорить непосредственно об OpenStack, то при его использовании существует множество нюансов и развилок, которые могут различаться в зависимости от особенностей инфраструктуры компании.
Третий миф. Существует много софта на основе Open Source на любой вкус. Действительно, софта очень много, но подобрать решение, подходящее конкретной компании, и разобраться в нем бывает непросто. Если, например, надо решить, какую из открытых систем виртуализации выбрать или какая из систем деплоя OpenStack больше подойдет для достижения целей компании, то почти невозможно без помощи профессионалов провести сравнительный анализ в этих областях.
Можно ли доверять профессионалам из сети?
Четвертый миф. Большое сообщество все напишет за вас. На самом деле точки зрения представителей сообщества на работу с той или иной программой могут различаться. Сообщество разработчиков может годами не принимать коммиты, игнорировать слабости архитектуры, а то и вовсе перевыпустить его под несвободной лицензией.
Пятый миф. На рынке большое количество специалистов. С распространенными открытыми продуктами действительно работает много специалистов. Однако проверить их экспертизу сложно. К тому же нет общих критериев оценки такой экспертизы. В результате приходится учить и переучивать специалистов внутри компании.
Какие сложности могут возникнуть при внедрении продукта на основе Open Source
Чаще всего план по созданию собственного решения на основе Open Source выглядит так: заказчик планирует нанять команду, поставить перед ней задачу адаптации готового решения под нужды компании и в итоге получить рабочее решение, соответствующее его целям. Однако при таких доработках, которые обычно планируют реализовать в сжатые сроки, приходится или договариваться с сообществом, (что бывает непросто), или делать форк с затратами на поддержку в качестве техдолга, и это осложняет ситуацию, поскольку уводит все дальше от исходного кода.
Параллельно нужно будет наращивать внутреннюю экспертизу по поддержке, эксплуатации и разработке, чтобы решать проблемы в ходе выработки решения и после него. При этом у компании не будет помощника в лице вендора, и ему придется самостоятельно отвечать за получившееся решение с учетом специфики проблем созданного разработчиками продукта открытого софта.
Сложности могут возникнуть и при наборе core-команды решения, потому что может быть не совсем понятно, по каким критериям отбирать специалистов и сколько их должно быть. Кроме того, заказчику предстоит решить вопрос интегрирования продукта в корпоративную среду, в том числе разобраться, как мониторить решение, по каким метрикам и каким порогам должны быть алерты, каким образом осуществлять резервное копирование, как будет масштабироваться решение, а также ответить на другие не менее важные вопросы. И наконец, самым важным вопросом, на который нужно найти ответ, является стоимость конечного продукта.
Когда стоит использовать Open Source
Решения на основе Open Source точно нужно продолжать развивать, если в компании уже сформировалась экосистема таких продуктов. Или, если заботы о создании такой экосистемы берет на себя вендор. Например, Linux-дистрибутивы собирают и обновляют для заказчика пакетную базу, ведут багтрекеры, тестируют, документируют и выполняют множество других задач для создания полноценной базы по развитию Open Source решений.
Неоспоримое преимущество вендора в том, что он предлагает заказчику не только ИТ-решение, но и его адаптацию в инфраструктуру и помощь в решении базовых задач эксплуатации. Кроме этого, вендор может разработать архитектурное решение для конкретного заказчика по тому, как продукт лучше внедрять и использовать в дальнейшем. Также в его компетенцию входит поддержка в области дальнейшей эксплуатации продукта. Но трудности могут быть и в работе с вендорами.
В этом случае необходима совместная работа, в рамках которой заказчик объясняет, какой результат ему нужно получить. Не исключено, что в процессе заказчику придется поменять бизнес-процессы в части бюджетирования, делегирования, использования развернутых в облаке сервисов и в других направлениях деятельности, сделав их более удобными. Чтобы в результате получить индивидуальное облачное решение, максимально соответствующее его требованиям.
Источник: Дмитрий Кудюкин, IT-директор компании ITKey
