В чем риски перевода крупной организации на опенсорс

Об авторе: Дмитрий Комиссаров, директор по разработке и развитию продуктов и основатель компании «МойОфис».

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

Существует два типа почтовых решений — классические системы, то есть разворачиваемые на собственной серверной инфраструктуре (on-premise), и облачные («рожденные для облака» или cloud-born), которые разработаны крупными почтовыми SaaS-провайдерами. Первые можно тиражировать, но они имеют пределы масштабирования, которые измеряются несколькими тысячами пользователей. Вторые же существуют в единственном экземпляре, полностью подконтрольны провайдеру и могут обслуживать десятки, даже сотни миллионов пользователей.

Приложения Cloud-born часто называют Cloud Native. Такие решения строятся как набор микросервисов, слабо связанных между собой и упакованных в контейнеры. Контейнеризированные приложения автоматически управляются облачными платформами, а сама микросервисная архитектура может масштабироваться до уровней, которые сложно достичь при обычном подходе. Cloud Native решения в сравнении с продуктами монолитной архитектуры более гибкие и стабильные. Показатели надежности продукта, построенного на принципе Cloud Native, позволяют обеспечить отсутствие времени видимого простоя – то есть, говоря на языке обычного пользователя, софт не будет «зависать». Можно считать, что решение соответствует принципу Cloud Native только в том случае, если оно способно к автоматическому мониторингу, самовосстановлению и масштабируемости.

Любой Enterprise-продукт требует длительного проектирования, разработки и усилий большой высококвалифицированной команды. Применяя только СПО, создавать решения такого класса гораздо сложнее. Нужно собрать команду, кто-то должен это финансировать, люди где-то должны работать: либо full-time на этом проекте, в режиме создания собственного СПО, либо рart-time при его создании. Сразу возникает вопрос – а насколько быстро такие команды придут к результату и насколько ответственно они будут подходить к своей работе?

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

Ключевой тренд в области корпоративных коммуникаций

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

В чем опасность применения опенсорса

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

• Технологические риски. Большая часть опенсорсных почтовых систем построена на старых принципах хранения почты в файловой системе. Архитектура не менялась с 1971 года — почта располагается внутри файловой системы отдельного сервера и хранится в виде файлов. Это накладывает ряд ограничений на масштабирование, надежность и отказоустойчивость почтового сервера, а кроме того, не позволяет разместить почту в геораспределенном кластере.
• Юридические риски. Когда продукты с СПО-компонентами поступают в коммерческий оборот и возникает обязательство о соблюдении лицензионных правил, установленных сообществом — например, раскрывать код или не продавать продукты на определенных территориях. Разработчик должен внимательно следить за всеми лицензиями и ограничениями, так как фактически он распространяет чужое СПО-решение и обязан соблюдать определенные регламенты.
• Риски информационной безопасности. Если в случае продуктов с проприетарной лицензией ответственность за устранение уязвимостей лежит на разработчике, то при обнаружении их в СПО-продуктах — исправлять код будет сообщество. При этом их устранение не является основной задачей контрибьюторов и мэйнтейнеров, такую работу они выполняют бесплатно и по собственной доброй воле.

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

К чему приводит игнорирование рисков

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

• Запрет использования продукта на определенной территории. Пример: сообщество Fedora Project изменило лицензионное соглашение и запретило поставки операционной системы в Крым. Надо понимать, что за каждым сообществом стоят интересы спонсирующей организации. Так, за Fedora Project стоит Red Hat, и именно эта компания (ныне IBM) причастна к изменению лицензионной политики.
• Обнаружение неустраненных критических уязвимостей, которые напрямую влияют на безопасность не только самого продукта, но и всей IT-инфраструктуры предприятия. Пример: в ядре Linux была обнаружена уязвимость, которая существует с момента появления OC, может наделить правами администратора любого пользователя и присутствует в большинстве дистрибутивов.
• Непрогнозируемые сроки внесения изменений в продукт при выявлении уязвимостей. Пример: в январе 2022 года была обнаружена серия критических ошибок в СПО-продукте log4j. Неравнодушные мэйнтейнеры оперативно отреагировали и начали устранять их, причем работая сверхурочно, отложив свои обычные рабочие и личные дела. Они посвятили более недели собственной жизни сообществу, хотя в принципе могли этого и не делать, и в итоге еще и столкнулись с негативной реакцией со стороны самого сообщества из-за недостаточно быстрого внесения правок.
• Остановка бизнес-процессов организации в связи со сложностями при администрировании и настройке СПО-компонентов. Пример: авария 2018 года в Росреестре, которую журналисты связывали с использованием СПО Ceph — тогда МФЦ в 50 регионах РФ лишились возможности проводить операции с недвижимостью. Разбор подобной ситуации был проведен в рамках конференции DevOpsConf Russia — исследователи потратили человеко-год ресурсов, чтобы выявить ограничения опенсорсного продукта, которые повышали вероятность наступления аварийных событий при масштабировании.

Разработчики продуктов на базе СПО также должны внимательно следить за применяемыми компонентами, их кодом и условиями лицензирования. Ниже — наиболее критичные риски разработчиков.

• Изменение лицензионного соглашения. Разработчик может потерять право продавать продукт на базе конкретного СПО, или же возникает обязательство разработчика по раскрытию исходного кода продукта. Пример: скандал из-за компонентов под GPL-лицензией в продуктах для TikTok — независимые аудиторы установили, что TikTok использовал в своих продуктах СПО-компоненты OBS Studio, но не объявил об этом, как требует лицензия. Под давлением общественности TikTok отказался от их использования в своих продуктах. Примером также является судебный иск в отношении ChessBase и последовавший отзыв лицензий на компоненты Stockfish, которые используются для создания шахматного ПО. Кроме этого, можно вспомнить и историю фреймворка Qt, создатель которого поменял лицензирование, и оказалось, что безопасно использовать можно только платную версию, стоимость которой составляет $4 тысячи за одно рабочее место в год без учета НДС. Если в вашей разработке присутствует много открытого кода, с которым произойдут подобные изменения, то стоимость его поддержки значительно вырастет и возникнет риск, что ваш IT-продукт просто перестанет существовать.
• Прекращение выпуска СПО-продукта. Наиболее ярким примером является история невероятно популярного проекта MySQL, который был поглощен Oracle в 2010 году и позже превращен в проприетарный. Другой пример — в 2021 году компания Red Hat предпочла закрыть проект CentOS в пользу собственной коммерческой разработки Red Hat Enterprise Linux.
• Замена кода СПО-продукта. Обострение геополитической ситуации уже привело к возникновению рисков нового типа — создатели СПО-продуктов могут ухудшать код компонентов или даже вовсе запрещать его использование в определенной стране. Пример: разработчик часто используемых библиотек colors.js (3,3 миллиарда скачиваний) и faker.js (272 миллиона скачиваний) при очередном релизе подменил исходный код вредоносным. Это привело к проблемам более чем у 19 тысяч проектов, которые использовали такое СПО.

Что предлагают российские производители

Недавно две российские IT-компании объявили о выпуске своих почтовых решений. В ноябре 2021 года «МойОфис» официально представил корпоративную почту нового поколения Mailion, пилотные проекты внедрения которой уже стартовали на нескольких крупнейших российских предприятиях. Другой игрок отечественного IT-рынка, НПО «РусБИТех» анонсировалпоявление почтового продукта RuPost со схожей функциональностью, который предположительно должен появиться на рынке в середине 2022 года. Ключевым различием двух разработок является технологический стек. В то время как инженеры МойОфис создают собственный продукт своими силами «с нуля» и доля СПО в нем, если считать в компонентах, не превышает 5%, наши коллеги напротив решили сформировать свое решение из множества доступных на рынке опенсорсных технологий.

Различия в подходах к разработке ПО

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

К каким выводам мы пришли, когда проектировали Mailion

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

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

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