Как обеспечить цифровой суверенитет IT-продуктов

Сегодня поговорим о важном – о цифровом суверенитете и возможности автономно развивать российские цифровые продукты в текущих условиях рынка. Тема важна не только для вендоров, но и для заказчиков – никому не хочется завтра внезапно остаться без какой-то части внутренней IT-инфраструктуры и важных данных. Мы расскажем, как обстоят дела у нас и почему именно так.

Практически любой цифровой продукт использует opensource, и мы не исключение - дорого и бессмысленно изобретать колесо заново, когда в открытом доступе можно найти шины Pirelli.

В архитектуре продуктов для управления знаниями это могут быть как мелкие точечные кусочки функционала, так и самостоятельные продукты типа Liferay (портальный конструктор), Elasticsearch (поисковая система), PostgreSQL (СУБД) и т.д. Elasticsearch и PostgreSQL – уже своего рода неофициальный отраслевой стандарт – сложно найти компанию, в которой не установлены эти решения или их форки*.

Даже для форков первоисточникпрактически всегда - иностранный ресурс. Поэтому с приходом санкций перед вендорами (и нами тоже) встали 2 задачи:

• Защита от потери доступа к исходному коду – снятие риска невозможности внесения необходимых улучшений или исправлений;

• Защита от бэкдоров* и других уязвимостей, которые стали появляться в opensource решениях для ограничения использования странами под санкциями.

*Форк - копия открытого кода, на основе которой создается другой программный продукт. Например, LibreOffice можно считать форком OpenOffice.org.

*backdoor (букв. “черный вход, задняя дверь”) - дефекты алгоритма, которые намеренно встраиваются в него разработчиком.

Поэтому мы всей командой если и используем иностранный софт, то только тот, который не связан с рисками блокировки. Плюс сами дополнительно обеспечиваем безопасность для заказчика.

Мы руководствуемся следующими правилами:

• используем только софт, исходники которого доступны;

• исходники всех используемых решений должны храниться на российских серверах, которым не страшны санкции;
• в поставку заказчику должны идти только те версии, по которым мы видели исходники, сами сделали с них сборку, провели регресс-тестирование продукта;

• все это должно жить у нас в инфраструктуре.

Иностранные серверы и ЦОДы раньше использовались повсеместно. Как правило, инфраструктура зарубежных дата-центров была более современной: использовалось свежее оборудование, межсетевые экраны, более высокие стандарты качества и сервиса, был выше уровень безопасности и контроля хранения данных, индивидуальные SLA и т.д.

Например, многие компании с удовольствием пользовались услугами Hetzner, где цены были ощутимо приятнее, чем в российских ЦОДах.

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

У нас серверы всегда размещались в России. Во-первых, мы предоставляем свое решение не только on-premise, но и как готовый облачный сервис, а данные российских пользователей должны храниться на территории России.

Во-вторых, мы используем те же ЦОДы, что и многие наши клиенты. Это, в свою очередь:

• повышает стабильность релиза – мы банально "набиваем шишки" на инфраструктуре, схожей с той, что будет у заказчика;
• помогает воспроизвести непонятные фантомные проблемы заказчика, вызванные инфраструктурой, а не нашим ПО.

В общем, тут нам повезло, и проблемы срочного переезда с зарубежных серверов у нас не было.

Vendorlock - очень неприятная вещь. Поэтому мы изначально проектировали архитектуру таким образом, чтобы InKnowledge не зависела от конкретных сборок open-source-решений (того же Liferay или PostgreSQL).

Например:

• Inknowledge без разницы – работать с PostgreSQL или Postgres Pro;

• в зарубежных проектах мы могли ставить наши модули как поверх Liferay DXP (платная версия), т.к. там эта платформа более распространена, и у многих закуплены enterprise-лицензии, так и поверх "чистой" community edition, если она уже используется заказчиком.

Задолго до санкций на наших серверах были и все нужные исходники, и собственная сборка, в которой есть только модули, которые нам нужны. Сейчас если у заказчика нет своего Liferay, мы ставим свою сборку.

Также есть Liferay Russian Edition - это форк нашего партнера EmDev, который мы помогаем развивать. Первые версии Russian Edition появились еще в 2018 году. Форк очень живой, последнее обновление было совсем недавно.

EmDev занимался Liferay много лет, до ухода вендора был золотым партнером, а после стал еще активнее развивать отечественный форк.

Остальные небольшие решения мы уже частично хранили и собирали на своих серверах. Часть пришлось оперативно зеркалировать с Гитхаба - весна 22-го у наших девопсов была жаркой. Тогда же мы с болью переезжали с Gsuite на “Яндекс 360”. Но это уже совсем другая история, которой мы когда-нибудь поделимся...

L2U (Listen2U) - один из ведущих российских разработчиков KMS-решений для корпоративного сегмента и госструктур. Компания основана в 2016 году в Москве. За 7 лет работы реализовано более 20 успешных проектов в России, Европе и на Ближнем Востоке, в том числе с «Медси», «Комус», «Локо-банк», Московской городской избирательной комиссией и др.

Продукты компании - система управления знаниями InKnowledge и омниканальная платформа L2U. InKnowledge входит в ТОП рейтингов ведущих систем управления знаниями России по версии CCGuru, FastKMS и PLUS-Consulting (1-е место, 2023 год). Включена в единый реестр отечественного ПО.