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

Технологический стек как стратегическое решение

Российский сектор ПО переходит в фазу замещения сложных систем. Требования к технологической зрелости отечественных решений и их способности интегрироваться друг с другом повышаются. По данным ассоциации РУССОФТ, в 2025 году рынок программного обеспечения в России вырос на 19%, до 2,3 трлн руб. При этом, по оценке CNews Analytics, наиболее реалистичным сценарием на 2025–2027 годы будет не полный отказ от иностранных технологий, а построение экосистемы совместимых решений разных производителей, ядром которой становится отечественный стек.

По словам директора центра «Инфраструктура» компании «ЛАНИТ-Интеграция» Александра Чупрунова, отправной точкой в комплексном проекте должен быть не продукт и не конкретный производитель, а требования самого заказчика: «На старте мы проводим аудит инфраструктуры клиента и определяем, в каких информационных системах он сейчас работает, какая у него стратегия по отказоустойчивости и насколько критичен выход из строя того или иного сервиса»,— поясняет эксперт.

Как оценить зрелость российского решения

Российские операционные системы обеспечили уже около 95% импортозамещения в госструктурах, а СУБД общего назначения закрывают порядка 70% потребностей корпоративного сектора, следует из данных CNews Analytics. При этом зрелость решений важно оценивать применительно к конкретному классу продуктов, закладывая в проект риски там, где отечественные аналоги пока не покрывают всю нишу.

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

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

Заявленная совместимость продуктов сама по себе не гарантирует, что вся связка будет стабильно работать в промышленной среде, поэтому в компании считают стендирование и пилотирование обязательными этапами любого проекта. «Каждое решение, которое на бумаге выглядит неплохо, нужно проверить на инфраструктуре, приближенной к реальной»,— подчеркивает Александр Чупрунов. Стендирование помогает команде сделать выводы о том, как продукт ведет себя в предпродуктивной среде. Финальная проверка — пилотирование в живом контуре заказчика, когда решение интегрируется с критически важными для бизнеса информационными системами и намеренно подвергается нагрузке, чтобы увидеть его реальные, а не заявленные характеристики отказоустойчивости и деградации. Для пилота выбирают критичный сегмент инфраструктуры и тестируют сценарии DRP (план аварийного восстановления) на соответствие целевым показателям RTO (время восстановления) и RPO (потеря данных). «Простой в несколько минут для ряда заказчиков — это миллиардные убытки, поэтому пилотам мы уделяем особое внимание»,— отмечает эксперт.

Зачастую масштаб современных инфраструктурных проектов делает проверку и внедрение вручную невозможными. Поэтому растет роль автоматизации — не только на этапе эксплуатации, но и в процессе аудита и внедрения. Это позволяет собрать данные об инфраструктуре заказчика и быстрее перейти к проектированию. Так, спикер привел в пример один из проектов «ЛАНИТ-Интеграции», где речь идет о более чем 1,5 тыс. серверных группировок: развернуть на таком объеме программные компоненты в ручном режиме означало бы растянуть внедрение на годы.

Как правильно собирать стек в 2026 году

Еще один важный вопрос — строить ли инфраструктуру на решениях одного вендора или комбинировать продукты разных производителей. По словам Александра Чупрунова, универсального ответа здесь нет.

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

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

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

Отказоустойчивая инфраструктура без потери управляемости: реальность, а не миф

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

По словам Николая Иванова, отказоустойчивость стоит рассматривать как совокупность нескольких уровней: резервирования вычислительных ресурсов, СХД, сети и инженерных систем ЦОДов; отказоустойчивости платформенного слоя — виртуализации, контейнерных платформ, баз данных и балансировщиков; резервирования прикладной архитектуры и данных с учетом консистентности транзакций; аварийного восстановления с целевыми показателями RTO и RPO и, наконец, эксплуатационного уровня — мониторинга, регламентов, автоматизации и регулярных учений.

Именно поэтому импортозамещение инфраструктуры далеко не всегда сводится к простой замене продукта. «Подход «заменим один продукт на другой» работает только в самых простых случаях. Иностранные решения годами формировали вокруг себя экосистему в реальных инфраструктурных проектах: процессы эксплуатации, интеграции, схемы мониторинга, резервного копирования, управления доступом»,— объясняет эксперт. Пересборка архитектуры требуется, когда меняется не один компонент, а целый технологический слой — платформа виртуализации, СХД, контур DevOps — и когда новая связка собирается из продуктов разных российских вендоров и open source компонентов.

Важно уделять внимание и мониторингу такой мультивендорной среды. «Мониторинг должен строиться не от продуктов, а от сервисов. Заказчику нужно осознавать не только то, что один сервер, кластер или база данных «зеленые», но и работает ли бизнес-сервис, есть ли деградация производительности и где находится причина проблемы»,— говорит Николай Иванов.

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

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