Импортозамещение 3.0: как собрать отечественную ИТ-инфраструктуру, которая работает как система

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

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

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

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

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

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

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

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

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

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

Итог этого этапа — согласованные требования к производительности, восстановлению и сопровождению. Они станут критериями приемки, а не останутся общими пожеланиями.

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

Система хранения данных, или СХД, отвечает за размещение данных и доступ к ним. Поддержка нужного протокола подключения — только начало проверки. Например, iSCSI передает команды к дисковому хранилищу через IP-сеть, а Fibre Channel используется для специализированной сети хранения. Наличие этих интерфейсов еще не подтверждает корректную работу всей связки.

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

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

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

В программу испытаний стоит включить:

1. Производительность на характерной нагрузке: скорость операций и время ответа приложений, включая пиковые периоды.
2. Отказы: потерю сетевого соединения, отключение узла или контроллера, переключение сервисов и возвращение к штатной работе.
3. Восстановление: не только создание резервной копии, но и возврат данных и приложения в согласованное время.
4. Обновления: проверку выбранных версий и порядок возврата к прежней конфигурации, если изменение вызывает проблему.
5. Наблюдаемость: видит ли команда сбой в системе мониторинга и достаточно ли информации для поиска причины.

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

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

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

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

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

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

Российское оборудование, запись в реестре Минпромторга и статус доверенного программно-аппаратного комплекса — не одно и то же. Программно-аппаратный комплекс (ПАК) — сочетание оборудования и программ, предназначенное для определенной задачи.

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

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

Для сравнения вариантов полезна совокупная стоимость владения — TCO, от английского total cost of ownership. Это затраты на систему за выбранный период: оборудование, лицензии, внедрение, перенос данных, поддержка, запасные части, электричество, расширение и работа команды.

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

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

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

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

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

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

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