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

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

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

Вот почему выборочное импортозамещение, по словам Михаила Гилязова из Скала^р (Группа Rubytech) больше не работает. Эксперт предлагает для него специальный термин — «лоскутное импортозамещение».

Он также подчеркивает, что рынок постепенно отказывается от внедрений «для галочки» в отчетности по комплаенсу или KPI, но инерция сохраняется. Переход к зрелой модели требует четкого понимания, где именно возникают разрывы.

Три зоны системной уязвимости

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

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

Вторая зона лежит в плоскости масштабирования. По словам того же Гилязова, продукт, стабильный на 4–10 узлах, может «посыпаться» при расширении до 70–100 серверов из-за архитектурных ограничений, не заложенных в исходный дизайн. Это типично для «молодых» решений, поскольку они проектировались для малых и средних инсталляций, но заказчики пытаются использовать их в корпоративных масштабах, без выполнения предварительных нагрузочных тестов.

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

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

По словам Алексея Какунина, генерального директора ЕМДЕВ, смешение нескольких продуктов с разными механизмами управления доступом делает проблему «рваного контура» особенно острой. При чем к этому, по его мнению, добавляется и версионная неоднородность. В одном окружении одновременно эксплуатируются Astra Linux, Alt Linux, РОСА и CentOS, а агент СЗИ, работающий на одной версии, на другой теряет часть функций. Алексей Парфентьев из «СерчИнформ» замечает, что выход обновления ОС и адаптация к нему средств защиты почти никогда не синхронизируются, что создает временной лаг, где система может стать либо незащищенной, либо нестабильной.

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

Доверяй, но проверяй

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

«Заявленная совместимость» до начала эксплуатации остается лишь маркетинговым утверждением, считает Алексей Какунин из ЕМДЕВ, поэтому в дополнение к ней рынок начинает «постепенно формировать культуру проверенной совместимости, когда заказчики запрашивают сертификаты и протоколы совместных испытаний еще на этапе пресейла».

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

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

И здесь возникает кажущееся противоречие. Если реальные условия невозможно воспроизвести в лаборатории, зачем вообще тестировать на стенде? На самом же деле правда, как обычно, где-то посередине. И она состоит в том, что, с одной стороны, да, невозможно проверить все нюансы заранее. И, опять же, да, можно выявить большинство проблем, приблизив стенд к «боевой» среде настолько, насколько это вообще реально.

Тестирование, по словам экспертов, не должно ограничиваться одним-единственным демонстрационным сервером.

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

Кто платит за разрыв?

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

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

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

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

Патч как лотерея

В гетерогенной среде обновление по принципу «ставим все по мере выхода» категорически неприемлемо. Каждый патч становится лотереей, в которой никто не может гарантировать, что обновление одного компонента не нарушит работу трех других. По мнению Михаила Гилязова, для решения этой проблемы необходимо наладить управляемый цикл, куда входят планирование, тестирование на стенде, согласованное окно изменений и обязательный план отката.

Многие компании приходят к внутренним матрицам совместимости, где фиксируют проверенные сочетания версий и конфигураций. И это кажется бюрократией только до первого крупного простоя. К практическим принципам управления Алексей Какунин относит публикацию Release Notes с детальным описанием изменений в API, уведомление партнеров до релиза (а не одновременно с ним) и обязательное обеспечение обратной совместимости в публичных интерфейсах.

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

Новая роль интегратора

Похоже, на российском рынке интегратор перестал довольствоваться ролью «монтажника» и стремится стать «архитектором ценности». Некоторые даже видят запрос на предиктивные исследования ценности и просчитывание экономического эффекта от внедрения.

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

Матрицы совместимости

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

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

Зона молчаливого конфликта

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

При этом Хабаров обращает внимание на еще один важный момент, связанный с безопасностью. По его словам, несогласованные обновления, неочевидные зависимости и «самодельные» интеграции создают идеальную почву для уязвимостей.

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

Хлам или «старое доброе»?

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

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

Один из экспертов предложил два варианта, продлевающие классическое противостояние Windows vs Linux. Мол, либо полностью переходите на Linux-решения, либо эмулируйте в нем привычное для вашего Legacy окружение Windows.

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

Вместо заключения

Российский ИТ-рынок проходит болезненный, но необходимый этап взросления. «Лоскутное импортозамещение» уступает место системной архитектурной работе. Сертификаты совместимости становятся менее значимыми, чем подтвержденная практика интероперабельности.

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