Импортозамещение как возможность для развития: План замены ПО в деталях

Перед российскими компаниями уже несколько лет стоит задача по импортозамещению иностранного программного обеспечения (ПО). Многие участники рынка достигли результатов на этом пути и смогли продолжить работу в условиях ухода с российского рынка зарубежных поставщиков ПО в течение 2022 года. В тоже время, предстоит ещё многое сделать для достижения ключевой цели — обретения технологической независимости от иностранного ПО.

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

При этом именно план импортозамещения является ключом к успеху. Мы считаем, что необходимость перехода на российские программные продукты нужно рассматривать как возможность для развития. Это удобный момент для снятия ограничений и накопленного годами технологического долга. В статье мы поделимся практикой СберТеха и расскажем о подходе, который позволяет достигать таких результатов. Для удобства наших читателей опишем его в структуре стандартных этапов: стратегия, аудит, проектирование и планирование.

𝓲

Freepik

Стратегия

Системный подход по замене ПО в дополнение к решению задачи импортозамещения позволяет снять накопленный технологический долг в части длительного времени разработки критичной для бизнеса функциональности (ТТМ, time-to-market), роста стоимости владения программно-аппаратными комплексами (TCO), ограничений в масштабируемости, недостаточной доступности и надёжности, а также дублирования функциональности.

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

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

Если частота и объём изменений требуют масштабирования разработки, следует ещё на стадии стратегии принять решение о применении микросервисного подхода.

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

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

Устранение дублирования функциональности положительно скажется на TCO и позволит избавиться от необходимости повторно решать одни и те же задачи несколько раз.

Обобщая сказанное выше, при формировании стратегии замены ПО мы рекомендуем исходить из следующих принципов:

1. Критическая, часто изменяющаяся функциональность должна находиться под полным операционным контролем компании на всех этапах, от разработки до эксплуатации.
2. Микросервисный (а не монолитный) подход — вариант первого выбора.
3. Только commodity-оборудование.
4. Только ПО, поддерживающее распределение данных и обеспечивающее защиту от отказов узлов оборудования.
5. Отказ от использования в ландшафте разных вариантов ПО для выполнения одной и той же функции.
   
   

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

Ещё один важный вопрос — это баланс между инвестициями в развитие существующих (заменяемых) систем и инвестициями в новые целевые системы. Баланс может быть описан в стратегии в виде критериев, определяющих два варианта выбора: развить и использовать функциональность существующего заменяемого ПО или через некоторое время выполнить развитие уже на базе нового. Если определить баланс неправильно, то может возникнуть гонка между старой и новой версией системы: невозможно будет перейти на новую версию, потому что в ней не будет доработок, уже реализованных в старой системе. Полностью заморозить развитие текущей версии системы, как правило, тоже невозможно, так как сама миграция может предъявлять к ней требования, без выполнения которых бесшовный переход невозможен.

Аудит

После того, как стратегия сформирована, нужно понять, как её воплотить. Для этого нужно посмотреть на ИТ-ландшафт с точки зрения метрик, описанных выше (частоты изменений, гранулярности элементов, TTM, TCO и т.д.). Это можно сделать на основе классификаций автоматизированных систем и их функциональных подсистем, которые уже используются в компании. Например, разделение на системное и прикладное ПО, если оно принято, хорошо коррелирует с потребностью в частых изменениях (для системного ПО такая потребность минимальна, для прикладного – наоборот). Другой пример: классификация по классам критичности хорошо коррелирует с требованиями доступности и надёжности.

В результате проведенного анализа должна быть собрана информация о каждом элементе ландшафта, его болевых точках). Например, она может выглядеть следующим образом:

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

Проектирование

На основе проведённого анализа можно сделать вывод о том, в каких частях ландшафта присутствуют несоответствия принципам выбранной стратегии, и принять решения о необходимых действиях по их устранению. Рассмотрим варианты разрешения несоответствий для АС:

1. Критичная система вне контура компании или отсутствие готового отечественного решения → переход к собственной разработке.
2. Проблемы с TTM, частотой и объёмом изменений → применение микросервисного подхода, масштабирование команд разработки.
3. В компании есть дублирующая функциональность → консолидация дублирующей функциональности в одной АС и предоставление в виде сервиса потребителям.
4. Проблемы с доступностью системы → применение резервирования.
5. Ограничения масштабируемости системы → применение шардирования.
6. Высокая TCO системы → перевод на commodity-сервера.
   
   

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

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

1. Поддерживать параллельную независимую разработку приложений множеством команд (поддерживать микросервисный подход);
2. Успешно функционировать на commodity-оборудовании и быть горизонтально-масштабируемой;
3. Позволять реализовывать приложения с применением шаблонов шардирования и распределения данных.
   
   

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

Рассмотрим один из возможных вариантов архитектуры, построенной на базе технологической платформы. Мы используем цифровую облачную платформу Platform V, состоящую из более чем 70 продуктов. Платформа представляет собой набор связанных технологических сервисов. Физически она состоит из контуров развёртывания, соответствующих заданным показателям доступности, надёжности, безопасности. Автоматизированные системы на базе как готового продукта, так и собственной разработки используют набор необходимых сервисов одного из контуров платформы. Разные контуры могут использоваться для размещения критичных и стандартных систем, а также систем головной и дочерних компаний и т.д.

В такой архитектуре каждая автоматизированная система потребляет различные сервисы технологической платформы. Например, для некой системы «Управление лояльностью клиентов» выбор сервисов из линейки цифровой облачной платформы Platform V может быть таким:

• Интерфейс — Platform V Starting Manager и Platform V UI Kits для создания интерфейса пользователя. Platform V IAM для аутентификации и авторизации пользователей.
• Бизнес-логика — Platform V Flow и Platform V Dynamic Decisions для начисления баллов лояльности и ручной корректировки начислений по запросу клиента или партнера.
• Работа с данными — Platform V DataSpace для формирования модели данных предметной области и работы с данными в терминах модели с СУБД Platform V Pangolin.
• Отчётность — Platform V SDP Analytics для формирования информационных панелей и отчётов, Platform V Print для формирования отчётов и документов на основе шаблонов.
• Интеграция — Platform V Synapse для интеграции с системами партнеров (участниками программы лояльности) через событийный обмен и файловую интеграцию.
• А также эксплуатация (Platform V Audit, Platform V Monitor), производство ПО (Platform V Works).

Планирование

Предлагаем придерживаться следующих принципов планирования проектов по импортозамещению с попутным решением технологических вопросов. Эти принципы мы используем в нашей практике:

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

2. У трансформации фронтальных приложений и их серверной части — больший приоритет, чем у остальных приложений. Такой подход устраняет вероятность влияния на клиентов и внутренних пользователей при преобразовании остальной части ландшафта и, кроме того, позволяет проводить каждое изменение в собственном темпе.

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

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

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

6. Для пилотирования необходимо выбирать наиболее критичные и сложные в реализации системы. Это позволит выявить и учесть большинство возможных негативных сценариев, которые не могут возникнуть в работе более простых систем. Только такой опыт можно уверенно тиражировать на остальную часть ландшафта. Это отличается от подхода «быстрой победы», когда приоритет отдаётся критичным и простым в реализации системам.

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

8. Аналитику данных (построение/модернизацию корпоративного хранилища с инструментами анализа данных) нужно рассматривать не в отдельности, а как неотъемлемую часть функциональности модернизируемых систем. В противном случае переход на новую версию системы приведёт к временной недоступности данных в корпоративном хранилище.

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