К 2026 году главный вопрос российского импортозамещения сместился с «чем заменить?» на «как заставить работать вместе?». Эволюция была тернистой. Путь начался с аврального подбора любых работающих аналогов, как первых попавшихся тропинок в лесу. Затем он привел к усталости от этих поисков и разочарованию от мешанины разрозненных продуктов. После чего, наконец, мы начали выруливать на дорогу архитектурного мышления, где совместимость решений становится краеугольным камнем построения надежной и открытой для расширения корпоративной системы.
Сегодня заказчики уже не спрашивают о наличии сертификата совместимости. Вместо этого они хотят видеть проверенную схему интеграции. И вопросы у них довольно конкретные — какую, например, СУБД подключать к порталу, как обеспечить поддержку связки через два года и кто будет отвечать за ее жизненный цикл.
Сейчас на практике сталкиваются два полярных подхода. Существует последовательная архитектурная работа с целевым видением, опорными платформами и дорожной картой. И есть точечные замены «под норматив», когда компонент меняют по окончании поддержки или формального требования. На короткой дистанции второй путь кажется проще, но именно он ведет к непрозрачному ландшафту и хроническим конфликтам совместимости.
Вот почему выборочное импортозамещение, по словам Михаила Гилязова из Скала^р (Группа Rubytech) больше не работает. Эксперт предлагает для него специальный термин — «лоскутное импортозамещение».
Михаил Гилязов, директор по развитию бизнеса Скала^р (Группа Rubytech): «Лоскутное импортозамещение» — когда выбирались наименее критичные элементы и заменялись без оглядки на архитектуру — привело к исчерпанию запаса таких элементов. Да и практика показала: непродуманная стратегия ведет к повторной реализации проектов — приобретенное ПО не соответствует заявленным параметрам, и его приходится замещать другим, более дорогим решением».
Он также подчеркивает, что рынок постепенно отказывается от внедрений «для галочки» в отчетности по комплаенсу или KPI, но инерция сохраняется. Переход к зрелой модели требует четкого понимания, где именно возникают разрывы.
Три зоны системной уязвимости
Конфликты между российскими решениями концентрируются в трех типовых слоях, и каждый из них связан с фундаментальными проблемами, а не с «ошибками монтажа».
Первая зона, по словам эксперта, находится на стыке ОС с драйверами, прошивками, микрокодами и гипервизорами с системами хранения. Проблемы обостряются при высокой нагрузке. Гилязов утверждает, что начиная с 90% загрузки процессора или дисковых операций «даже малые задержки в обработке ошибок накапливаются и ведут к сбоям или деградации производительности». Дополнительные трудности состоят в том, что большинство российских вендоров не имеют доступа к низкоуровневой документации аппаратных платформ, поэтому их драйверы часто работают через прослойки, которые в критических режимах дают сбои.
Вторая зона лежит в плоскости масштабирования. По словам того же Гилязова, продукт, стабильный на 4–10 узлах, может «посыпаться» при расширении до 70–100 серверов из-за архитектурных ограничений, не заложенных в исходный дизайн. Это типично для «молодых» решений, поскольку они проектировались для малых и средних инсталляций, но заказчики пытаются использовать их в корпоративных масштабах, без выполнения предварительных нагрузочных тестов.
Третья и, пожалуй, самая частая боль проявляется на уровне разграничения доступа, когда нужно подружить аутентификацию и интеграционные протоколы. Разные продукты используют несогласованные контракты обмена, нестандартные форматы данных и собственные механизмы управления доступом. Это порождает расхождения в схемах токенов, таймаутах сессий и политиках паролей. Классический сценарий выглядит так: пользователь авторизуется в одной системе, но в соседней его сессия не распознается. Это создает эффект «рваного контура», на который указывают и другие эксперты.
Ирина Прыгунова, руководитель направления платформенных решений BPMSoft: «На уровне интеграции проблемы часто возникают из-за несогласованных контрактов обмена данными, а также использования нестандартных протоколов и форматов. Именно эти факторы чаще всего становятся причиной несовместимости и требуют дополнительной настройки взаимодействия между системами».
На практике это означает, что системы не могут корректно интерпретировать данные друг друга, что приводит к ошибкам на этапе обмена, сбоям в API-вызовах и необходимости создавать дополнительные интеграционные прослойки. Накапливаясь в корпоративной системе, все эти «костыли» снижают надежность и скорость работы всей связки.
По словам Алексея Какунина, генерального директора ЕМДЕВ, смешение нескольких продуктов с разными механизмами управления доступом делает проблему «рваного контура» особенно острой. При чем к этому, по его мнению, добавляется и версионная неоднородность. В одном окружении одновременно эксплуатируются Astra Linux, Alt Linux, РОСА и CentOS, а агент СЗИ, работающий на одной версии, на другой теряет часть функций. Алексей Парфентьев из «СерчИнформ» замечает, что выход обновления ОС и адаптация к нему средств защиты почти никогда не синхронизируются, что создает временной лаг, где система может стать либо незащищенной, либо нестабильной.
Подводя черту под списком частных проблем совместимости, Михаил Гилязов указывает на один общий для всех них источник, корень всех зол совместимости. По его мнению, решение лежит не в доработке отдельных продуктов, а в системной работе на уровне архитектуры и стандартов, и в России эта работа только начинается.
Михаил Гилязов, директор по развитию бизнеса Скала^р (Группа Rubytech): «Корень конфликтов — не в отсутствии продуктов, а в разнородности реализаций и отсутствии универсальных стандартов совместимости. Пока такие стандарты не сформированы, один из способов минимизировать риски — использовать программно-аппаратные комплексы, где все элементы заранее подобраны и проверены в единой архитектуре. В России такая практика активно развивается только последние несколько лет, и этот процесс требует времени».
Доверяй, но проверяй
Следовать этому принципу эксперты советуют в отношении сертификатов и заявлений вендоров о совместимости. По их словам, это вещь необходимая, но совершенно недостаточная. Причем некоторые из экспертов указывают на то, что бумаги фиксируют лишь лабораторные сценарии, которые почти никогда не воспроизводят реальную корпоративную среду. Сетевые политики, кастомные конфигурации безопасности, фактические объемы данных, версии драйверов и сотни других параметров невозможно проверить в стендовых условиях.
«Заявленная совместимость» до начала эксплуатации остается лишь маркетинговым утверждением, считает Алексей Какунин из ЕМДЕВ, поэтому в дополнение к ней рынок начинает «постепенно формировать культуру проверенной совместимости, когда заказчики запрашивают сертификаты и протоколы совместных испытаний еще на этапе пресейла».
Другие эксперты также говорят о недостаточности «бумажного» подтверждения совместимости и предлагают практику совместных испытаний на конкретных версиях продуктов в фиксированных конфигурациях с протоколированием сценариев.
Денис Хориков, директор технического департамента «Смарт Текнолоджис»: «Сертификаты, письма вендоров и перечни совместимых продуктов являются необходимым, но не достаточным основанием для внедрения. Окончательные выводы можно сделать только после испытаний на тестовом стенде или в пилотном проекте, воспроизводящем условия эксплуатации у заказчика».
Эту же мысль разделяет и Дмитрий Киселев генеральный директор Qlever Solutions. Но он же добавляет и долю скепсиса. По его мнению, реальная корпоративная среда всегда значительно сложнее любых «золотых стандартов». То, что работает на тестовом стенде вендора, может отказать в «боевом» контуре заказчика с его уникальной конфигурацией безопасности и сетевыми политиками.
И здесь возникает кажущееся противоречие. Если реальные условия невозможно воспроизвести в лаборатории, зачем вообще тестировать на стенде? На самом же деле правда, как обычно, где-то посередине. И она состоит в том, что, с одной стороны, да, невозможно проверить все нюансы заранее. И, опять же, да, можно выявить большинство проблем, приблизив стенд к «боевой» среде настолько, насколько это вообще реально.
Тестирование, по словам экспертов, не должно ограничиваться одним-единственным демонстрационным сервером.
Константин Хабаров, генеральный директор компании «Байт»: «Хороший тестовый стенд — это не «демосервер где‑то в углу», а максимально приближенная к «боевой» миниатюра: те же версии ОС, гипервизора, СУБД, те же типы нагрузок. Проверять нужно не только функциональность, но и поведение системы при отказах компонентов, при росте нагрузки, при обновлениях одного из слоев».
В подтверждение важности всестороннего тестирования совместимости эксперт из ЕМДЕВ описал кейс, когда на одном из проектов для промышленного предприятия развертывание полноценного стенда на основе резервной копии реального контура с «боевыми» данными и сценариями заняло дополнительные две недели, но сэкономило месяцы пострелизных разборок. Он также порекомендовал ряд обязательных сценариев, которые предусматривают стресс-тесты на согласованной пиковой нагрузке, испытания отказоустойчивости (особенно при аварийных перезапусках их чаще всего пропускают) и строгое документирование каждой проверенной конфигурации. Последнее особенно полезно для предотвращения часто возникающих проблем, связанных с утечкой мозгов из компании, когда ценные сведения, хранящаяся только в голове одного инженера, становятся недоступны после его ухода, что становится точкой риска для всей инфраструктуры.
Кто платит за разрыв?
Когда система падает на стыке двух продуктов, вендор указывает на интегратора, интегратор — на заказчика, а заказчик — на обоих. Эксперты отмечают, что вот эта вот классика жанра на самом деле не техническая проблема, а организационная и решать ее нужно на этапе заключения договоров, а не техподдержки.
Зоны ответственности при этом должны быть обозначены максимально четко. Вендор отвечает за корректную работу своего продукта в задокументированных конфигурациях и за своевременные уведомления об изменениях. Интегратор несет ответственность за архитектуру связки в целом, сборку продуктов в работающую среду, проведение тестирования и конечный результат внедрения. А на совести заказчика остается формулировка требований и предоставление среды для тестирования и эксплуатации. Причем желание сэкономить здесь чревато операционными проблемами.
Алексей Какунин, генеральный директор ЕМДЕВ: «Заказчик, который согласовывает требования к интеграции устно и экономит на тестовом стенде, принимает на себя значительную часть операционного риска».
Ну а если операционный швах таки случается, то компании норовят назначить виновного вместо того, чтобы искать и устранять проблему. Именно в этот момент техническая экспертиза интегратора оказывается как никогда кстати.
Иван Горбачев, руководитель направления унифицированных коммуникаций группы компаний «Информтехника»: «На практике именно интегратор помогает не «назначать виноватого», а быстро локализовать источник проблемы и довести решение до рабочего результата».
Поэтому идеальным форматом оформления отношений «заказчик — вендор — интегратор» может стать трехстороннее соглашение с прописанными зонами ответственности и эскалационными путями, но на текущий момент такая культура только складывается.
Патч как лотерея
В гетерогенной среде обновление по принципу «ставим все по мере выхода» категорически неприемлемо. Каждый патч становится лотереей, в которой никто не может гарантировать, что обновление одного компонента не нарушит работу трех других. По мнению Михаила Гилязова, для решения этой проблемы необходимо наладить управляемый цикл, куда входят планирование, тестирование на стенде, согласованное окно изменений и обязательный план отката.
Многие компании приходят к внутренним матрицам совместимости, где фиксируют проверенные сочетания версий и конфигураций. И это кажется бюрократией только до первого крупного простоя. К практическим принципам управления Алексей Какунин относит публикацию Release Notes с детальным описанием изменений в API, уведомление партнеров до релиза (а не одновременно с ним) и обязательное обеспечение обратной совместимости в публичных интерфейсах.
Михаил Гилязов рекомендует либо создавать собственный тестовый контур (мировой стандарт для крупных корпораций), либо передавать сопровождение на аутсорс интегратору с его стендом, либо использовать программно-аппаратный комплекс, где вендор юридически закрепляет ответственность за совместимость каждого обновления после полного цикла испытаний.
Новая роль интегратора
Похоже, на российском рынке интегратор перестал довольствоваться ролью «монтажника» и стремится стать «архитектором ценности». Некоторые даже видят запрос на предиктивные исследования ценности и просчитывание экономического эффекта от внедрения.
Дмитрий Золотарев, руководитель BPM-департамента ICL SOFT: «Раньше интегратор был в первую очередь «техническим мостом»: брал готовые продукты вендоров, настраивал интерфейсы, запускал пилот и сдавал проект. Сейчас от него ждут роли архитектора ценности: он должен заранее просчитывать, как решение повлияет на операционные метрики заказчика, как будет жить в продуктивной среде, как масштабироваться при росте нагрузки и как соответствовать регуляторным требованиям через годы после внедрения».
С одной стороны, было бы неплохо, если бы заказчики действительно были столь прозорливы и делегировали интегратору такие исследования. Но для этого нужен беспрецедентный уровень доверия, которого на рынке пока нет. Автору не удалось найти подтверждений реального запроса на «архитекторов ценности». Этот тезис выглядит скорее как попытка интеграторов переписать свою роль на более выгодных условиях. Заказчики же, по большому счету, продолжают ждать от интегратора того же, чего и раньше. В контексте совместимости, например, они хотят, чтобы все просто работало. Поэтому пока одни рассуждают об «архитектуре ценностей», другие во главу угла ставят «архитектурную работу», в том числе и над совместимостью. И сейчас это особенно актуально, потому что, как напоминает Юрий Орлянский, даже в золотую эру западных вендоров бесшовной интеграции не существовало.
Юрий Орлянский, генеральный директор ФОРБС Консалтинг: «Даже в эпоху SAP, Oracle и Microsoft бесшовная интеграция была лукавством — продукты развивались эволюционно, часть решений появлялась через поглощения, и интеграция все равно требовала отдельной архитектурной работы. В текущих российских реалиях подход «лучший в своем классе» стал еще более актуальным, а интегратор превратился в ключевого игрока, который собирает из разрозненных продуктов устойчивую инфраструктуру».
Матрицы совместимости
Внутренние матрицы совместимости становятся жизненно важным инструментом для крупных организаций. У каждой операционной системы, например, есть несколько линеек и множество версий, и для каждой комбинации «версия ОС + версия СЗИ + прикладное ПО» набор работающих функций может различаться. Без документирования проверенных конфигураций любое обновление становится риском.
Денис Хориков, директор технического департамента «Смарт Текнолоджис»: «Такие базы ведут и заказчики, и интеграторы, фиксируя в том числе сетевые ограничения и особенности ИБ-настроек. По мере накопления данных возрастает ценность ИИ-аналитики. При этом ИИ не заменяет эксперта, а помогает быстрее находить релевантные варианты применения решений, которые затем оценивает и подтверждает инженер».
При этом глубина матрицы должна соответствовать критичности системы. Если, например, вести ее кое-как, то от нее будет мало пользы. И наоборот, если детализация матрицы будет избыточной, ее ведение может превратиться в самоцель. Таким образом, эффективная матрица — это не ваши каракули в блокноте и не максимально подробный справочник, а инструмент, содержащий именно ту информацию, которая помогает принимать технические решения.
Зона молчаливого конфликта
Связка совместимости и безопасности часто недооценивается. На стыках систем возникают уязвимости, которые редко попадают в поле зрения на этапе проектирования. Один из экспертов выделил три узких места, где вопросы совместимости напрямую влияют на безопасность. Это несоответствие шифрования ГОСТам, конфликт средств защиты с прикладными системами и обновления, способные нарушить совместимость с другими компонентами.
Виктор Виноградов, директор по информационной безопасности mt cloud: «Совместимость напрямую влияет на три аспекта безопасности. Первый — уязвимые места на стыке систем: например, нет возможности использовать ГОСТ-шифрование, и трафик передается в открытом виде или с пониженной стойкостью, а средства мониторинга не видят события из-за разной логики аудита. Второй — конфликт средств защиты с прикладными системами, когда ради стабильности администраторы вынуждены частично отключать защитные механизмы, принося безопасность в жертву доступности. Третий — обновления: установка патчей безопасности от одного вендора ломает совместимость с другими компонентами, и компания либо не ставит критические исправления, либо ставит и получает отказ сервиса».
При этом Хабаров обращает внимание на еще один важный момент, связанный с безопасностью. По его словам, несогласованные обновления, неочевидные зависимости и «самодельные» интеграции создают идеальную почву для уязвимостей.
По словам экспертов, чем прозрачнее и формализованнее ландшафт, тем проще контролировать риски. Особую проблему представляет собой сертификация. Она выдается на конкретную версию с фиксированными контрольными суммами. Любое изменение любого компонента в связке делает конфигурацию формально несертифицированной. Циклы сертификации значительно длиннее циклов выпуска обновлений. И здесь возникает объективное противоречие, которое пока не имеет системного решения. Дополнительный риск лежит в плоскости управления, поскольку безопасность и совместимость традиционно курируются разными подразделениями, что порождает несогласованные политики доступа и расширение поверхности атаки через каждое новое API-соединение.
Хлам или «старое доброе»?
Полностью избавиться от унаследованных систем в большинстве компаний невозможно, считает Константин Хабаров. Но важно различать подход «тащить все старое как есть» и управляемую интеграцию. Legacy можно встраивать в новый стек, но только с ясными интерфейсами и границами ответственности. В некоторых случаях следует честно признать систему устаревшей, изолировать ее и постепенно выводить из эксплуатации, а не пытаться любой ценой сделать ее «полноценным гражданином» новой среды.
Более прагматичное решение предлагает Алексей Какунин. Он советует использовать сервисную шину ESB как переходный слой, а новые отечественные системы подключать к ней через адаптеры, обеспечивая трансформацию данных и двунаправленную синхронизацию в период параллельной эксплуатации. Это создаст управляемый переход, когда старая система остается в контуре ровно до того момента, как ее замена будет проверена и задокументирована.
Один из экспертов предложил два варианта, продлевающие классическое противостояние Windows vs Linux. Мол, либо полностью переходите на Linux-решения, либо эмулируйте в нем привычное для вашего Legacy окружение Windows.
Алексей Парфентьев, заместитель генерального директора по инновационной деятельности «СерчИнформ»: «Технически с Windows‑legacy работают либо через полную замену на Linux-решение, либо через эмуляцию системных библиотек, например Wine. Однако приложения, завязанные на закрытые проприетарные драйверы, в такой среде не работают и не могут быть сертифицированы. Единого рецепта нет, все определяется конкретной инфраструктурой, наличием исходных кодов и документации. Полная замена слишком затратна, поэтому чаще применяют постепенную модернизацию отдельных компонентов».
Другой, не вдаваясь в детали, поделился случаем из практики, когда удалось не только обеспечить совместимость отечественного аналитического продукта с зарубежным, но и заложить основу для последующей миграции «по мере готовности».
Андрей Харлак, технический директор Qlever Solutions «В одном из проектов нам удалось новый аналитический продукт интегрировать с существующим Power BI Report Server, сохранив накопленную экспертизу пользователей и предусмотрев план миграции на отечественное ПО при готовности заказчика».
Вместо заключения
Российский ИТ-рынок проходит болезненный, но необходимый этап взросления. «Лоскутное импортозамещение» уступает место системной архитектурной работе. Сертификаты совместимости становятся менее значимыми, чем подтвержденная практика интероперабельности.
При этом остаются нерешенными системные проблемы. И среди них: отсутствие единых отраслевых стандартов, версионная неоднородность, кадровый голод и регуляторная неопределенность. И все это в условиях, когда каждая новая связка требует отдельного тестирования. Поэтому чем раньше бизнес перестанет воспринимать совместимость как побочный эффект импортозамещения и начнет относиться к ней как к отдельной дисциплине постоянного инжиниринга, тем меньше будет неожиданных разрывов, простоев и конфликтов в ИТ-среде.