Импортозамещение инфраструктуры: новые решения для привычной работы

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

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

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

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

Вызовы-2022

Как правило, на заре информатизации компании выбирали Windows-ориентированные решения, затем к ним добавлялись элементы на Linux, а в последнее время бизнес начал использовать и облачные компоненты инфраструктуры.

Также на ранних стадиях развития корпоративных ИТ акцент делался на собственном «железе», сетевых компонентах и ПО, что определяло структуру штата ИТ-департаментов.

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

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

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

Подобная перестройка влечет за собой риски провалов в уровне стабильности и производительности ИТ-систем по причине перехода на новую платформу корпоративных приложений (1С вместо SAP), ее развертывания в рамках новых ОС (Linux вместо Windows) или перехода на новую СУБД (open source-продукты вместо проприетарных).

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

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

С чего начать

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

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

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

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

При переходе на полностью новые ОС или СУБД подтвердить стабильность систем оперативно в принципе невозможно, для этого нужно время – хотя бы месяц-два работы в полноценном продуктивном режиме.

Подготовка

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

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

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

В рамках первого этапа также подготавливается план перехода. В нем всегда учитываются критерии оценки качества основных характеристик системы.

Тесты, испытания и проверки

Далее начинается фаза тестирования системы. Формируется пул инфраструктурных ресурсов для продуктивного контура с учетом параметров целевой архитектуры. Это позволяет оценить, как ОС, СУБД, вспомогательные решения и прикладный слой будут работать после миграции.

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

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

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

Собственно миграция

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

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

Сама миграция проходит в один этап, но с нюансами: например, определенные сценарии переноса данных в новую СУБД PostgreSQL Astra Linux потребуют промежуточный этап их размещения в виде СУБД Microsoft.

Также 1С не всегда сможет «переварить» большие объемы данных с первого раза – масштабные базы могу выгружаться из старой системы и загружаться в новую вплоть до нескольких дней при условии успешной инициации процесса.

Средние оптимистичные сроки миграции с выгрузкой и загрузкой БД, оптимизацией ключевых параметров работы системы, адаптацией новой СУБД с высокой вероятностью необходимости дописывания кода, тестированием по ряду ключевых сценариев – от 6 месяцев.

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

Требования к железу и поддержка

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

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

Мало кто проводил полномасштабные нагрузочные тесты по 1С на рабочих конфигурациях, чтобы определить возможности Astra Linux Postgres SQL в сравнении с Microsoft SQL.

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

Автор Александр Сердюк, технический директор ГК «Эдит Про»