Импортозамещение как катализатор инженерных улучшений — опыт Renue в миграции критичных систем

Импортозамещение как катализатор инженерных улучшений — опыт Renue в миграции критичных систем

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

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

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

С чего начинаются проекты импортозамещения

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

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

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

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

Как изучается текущая система

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

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

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

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

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

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

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

Определение целевой архитектуры и типовой импортозамещенный стек

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

Типовой импортозамещенный стек в наших проектах включает несколько базовых компонентов. В качестве СУБД используется PostgreSQL Pro с поддержкой потоковой репликации и инструментов автоматического переключения при отказах. Для оркестрации контейнеризованных сервисов применяется Kubernetes. Брокером сообщений для потоковой обработки данных служит Apache Kafka. Для хранения и агрегации событий аудита и статистической информации используется ClickHouse. Криптографические операции, включая проверку электронной подписи и шифрование, выполняются с помощью КриптоПро JCP. Этот стек изначально входит в реестр отечественного программного обеспечения и соответствует требованиям ФСТЭК и ФСБ для систем, обрабатывающих государственную информацию и относящихся к объектам КИИ.

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

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

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

Переходный период и одновременная совместимость

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

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

В крупных Enterprise-средах окружение (ERP, WMS, MDM, смежные ведомства) переходит на импортозамещенные решения по собственным графикам, которые редко совпадают с нашими. Чтобы разработка и тестирование новой системы не блокировались этой неопределенностью, мы создаем программные эмуляторы смежных систем. Эмулятор строится на основе анализа сетевого трафика или согласованного интерфейсного контракта и имитирует поведение реальной системы в объеме, достаточном для разработки и интеграционного тестирования. В проектах, где параллельно замещались ERP, WMS, ESB и MDM, мы создали эмуляторы всех внешних систем и вели разработку независимо от их фактической готовности.

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

Признаки успешного проекта импортозамещения

Для нас показатель качественно выполненного проекта – это измеримые результаты, которые заказчик видит и чувствует. Бизнес не останавливается ни на одном этапе миграции: производственные линии продолжают выпускать продукцию, государственные сервисы обрабатывают запросы, пользователи отмечают ускорение бизнес-процессов и снижение количества ошибок. Новая платформа оказывается быстрее и надежнее предыдущей при меньшей стоимости сопровождения и развития. Заказчик получает систему, которая спроектирована под российские требования безопасности. Мы передаем не только код, но и понятную архитектуру, документацию, а главное — предсказуемое поведение системы в реальных условиях эксплуатации.